# 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.