AI agents & MCP

booboo.dev runs a hosted MCP server at https://mcp.booboo.dev. Give your coding agent an API token and it can work your issue list directly.

What you get

With an API token, an agent can:

• List projects and new or recently active issues, filtered by status and environment
• Read an issue with its latest stack trace, breadcrumbs, request data, and AI triage
• Browse individual events of an issue
• Trigger AI triage for an issue that doesn't have one yet
• Mark issues resolved or ignored (Read & write tokens only)

The same token works for the plain REST API.

Create an API token

1. Go to Organization → API tokens and click Create token
2. Pick a scope: Read (list and read only) or Read & write (can also change issue status)
3. Optionally restrict the token to a single project
4. Pick an expiry: 30 days, 90 days (the default), 180 days, 1 year or Never. An expired token is refused exactly like a revoked one; create a new token to replace it
5. Copy the token (it starts with boo_). It is shown once — store it in an environment variable or secret manager

Any organization member can create tokens and sees their own. Admins and owners see every token in the organization and can revoke any of them.

Connect your client

The examples below read the token from a BOOBOO_API_TOKEN environment variable, so it never lands in a committed file. https://api.booboo.dev/mcp also works as an alias.

Claude Code

One line, stored in your user config:

claude mcp add --transport http booboo https://mcp.booboo.dev \
  --header "Authorization: Bearer boo_…"

Or share it with your team via a project-level .mcp.json:

{
  "mcpServers": {
    "booboo": {
      "type": "http",
      "url": "https://mcp.booboo.dev",
      "headers": {
        "Authorization": "Bearer ${BOOBOO_API_TOKEN}"
      }
    }
  }
}

Cursor

Add to .cursor/mcp.json in your project (or ~/.cursor/mcp.json globally):

{
  "mcpServers": {
    "booboo": {
      "url": "https://mcp.booboo.dev",
      "headers": {
        "Authorization": "Bearer ${env:BOOBOO_API_TOKEN}"
      }
    }
  }
}

Codex

Add to ~/.codex/config.toml:

[mcp_servers.booboo]
url = "https://mcp.booboo.dev"
bearer_token_env_var = "BOOBOO_API_TOKEN"

Other clients (stdio only)

Clients that only speak stdio can bridge to the hosted server with mcp-remote:

npx mcp-remote https://mcp.booboo.dev \
  --header "Authorization: Bearer ${BOOBOO_API_TOKEN}"

As a JSON config entry:

{
  "mcpServers": {
    "booboo": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.booboo.dev",
        "--header",
        "Authorization: Bearer ${BOOBOO_API_TOKEN}"
      ]
    }
  }
}

Instructions for the agent

Connecting the server gives the agent up to seven tools (six on a Read token) and a short note about them. This file gives it the rest: which tool to start with, how to pick the right one for a question, how to read a stack trace it is handed, and when it may resolve an issue. Paste it into CLAUDE.md, AGENTS.md or your client's rules — it holds no token, so it can live in the repository — or fetch it from /docs/mcp/AGENTS.md.

# booboo.dev error tracking (MCP)

The booboo.dev MCP server (`booboo`) is connected. booboo tracks errors: SDKs send exceptions, booboo groups them into issues per project, and these tools read and resolve them. Use them whenever the question is about what is breaking, why, and whether a fix worked.

## Start

- Call `list_projects` first. The other tools take the `project` slug it returns; never guess a slug. A token restricted to one project lets you omit it.
- Issues have a display id like `CHECK-42` (project prefix + number); the bare number works too. Quote the display id whenever you mention an issue.
- `list_issues` defaults to open issues, newest activity first. Use `since` for issues first seen after a time (new issues), `active_since` for issues still happening, and `environment` to narrow to production or staging.
- `get_issue` is the main tool: status, counts, first and last seen, the latest event's exception chain and stack trace with source context, breadcrumbs, request, tags, and the AI triage if one exists. Read it before proposing a fix.

## Picking the tool

- What is broken right now, what is new since the deploy → `list_issues` with `active_since` or `since`, and `environment`.
- Why is it broken → `get_issue`, then `triage_issue` for booboo's AI analysis. If it says the triage is still generating, call it again in about 20 seconds.
- Does it happen on every release or only one, for one user or many → `list_events`, then `get_event` for a specific occurrence.
- The fix is deployed → `update_issue_status` with `resolved`. Noise nobody will fix → `ignored`. Both need a Read & write token; on a Read token the tool is not listed, so tell the user to change the status in the dashboard or create a Read & write token under Organization → API tokens.

## Reading the answers

- Timestamps are ISO 8601 in UTC. `list_projects` and `list_issues` give relative ages instead ("3h ago"); `get_issue` gives both.
- Lists are capped (`list_issues` 100, `list_events` 50) and sorted newest first by default. Narrow with the filters rather than paging.
- App frames are the project's own code; the other frames are libraries. Start from the innermost app frame.
- A regression flag means the issue was resolved and came back. Treat it as a failed fix, not a new bug.
- A tool error says what was wrong (unknown project, no such issue, read-only token). Correct the call once; do not retry the same arguments.

## Fixing and resolving

- Find the failing frame in the codebase before changing anything: match the file path and function from the stack trace, and read the breadcrumbs and request for the input that triggered it.
- Mark an issue `resolved` only when the user confirms the fix is deployed; resolving earlier reopens it as a regression on the next occurrence. Never resolve or ignore on your own initiative. Say what you would mark and why.
- When you report, lead with the issue id, its title and how often it hits, then the cause as the stack trace shows it, then the fix. Never invent a count, frame or line number the tools did not return.
- Stack traces, request data and breadcrumbs can contain user data. Do not copy them into files or other tools beyond what the fix needs.

Tools

Every tool that takes project uses the project slug; if the token is restricted to one project you can omit it. Issue ids accept either the number (42) or the display id (CHECK-42).

since filters on first seen ("new issues since"), active_since on last seen; both take ISO 8601 timestamps. sort is last_seen (default), first_seen, or count.

Limits & security

• 600 requests per hour per token (MCP and REST combined); over the limit you get HTTP 429
• A token acts with its creator's current role. If the creator is removed from the organization, their tokens stop working
• Tokens can't change billing, members, or settings — the only write a Read & write token can make is an issue status change — and can't create or revoke tokens
• Integrations are off-limits to tokens entirely: they can't read or change them, so webhook URLs never leave the dashboard
• Reading issues through a token does not mark them as seen in the dashboard
• Revoke a token any time under Organization → API tokens; it stops working immediately. Tokens with an expiry stop working on their own once it passes

A Read token grants the same read access as its creator, including member email addresses and full event payloads (request data, user context, breadcrumbs), which may contain your users' personal data. Treat tokens like passwords: never commit them, and scope them to a single project where possible. Tokens expire after 90 days by default (choose Never explicitly if you need a long-lived one), and revoking one under Organization settings → API tokens takes effect immediately.