RetraceKit remote MCP: triage from your IDE

RetraceKit now exposes a remote MCP server. Point an MCP client at it, and the agent can list issues and incidents, open a ref, change status, or pull an AI brief without leaving the chat.

Works with Cursor, Claude Code, OpenAI Codex, VS Code (Copilot Chat / MCP), and other IDEs or CLIs that speak Streamable HTTP. Same URL and Bearer key everywhere; only the config file format changes per product.

Endpoint: https://api.retracekit.cloud/mcp (Streamable HTTP, STATELESS). Auth: the same project API key you already use in the SDK. Reference: MCP docs.

Client setup

Every client needs two things:

1. URL: https://api.retracekit.cloud/mcp
2. Header: Authorization: Bearer <project-api-key>

Cursor

Project or user mcp.json:

{
  "mcpServers": {
    "retracekit": {
      "url": "https://api.retracekit.cloud/mcp",
      "headers": {
        "Authorization": "Bearer ${env:RETRACE_KIT_API_KEY}"
      }
    }
  }
}

Set RETRACE_KIT_API_KEY to the key from project settings in the app. Reload MCP in Cursor if tools do not show up.

Claude Code, Codex, VS Code, and others

Same endpoint and Bearer header. Paste them into whatever remote MCP / HTTP MCP config that product uses (Claude Code MCP settings, Codex MCP config, VS Code mcp.json, Windsurf, Zed, and so on). If the UI asks for transport, pick Streamable HTTP (or the equivalent “HTTP” / “remote URL” option), not stdio.

You do not need a separate RetraceKit MCP token.

What the tools do

Tool	Use
list_projects	The project tied to the API key
list_issues / get_issue	Filter by status, open PRO-123
update_issue_status	OPEN, RESOLVED, IGNORED
list_incidents / get_incident	Outages, evidence, linked issues
update_incident_status	INVESTIGATING, RESOLVED, ACTIVE
list_issue_incidents	Incidents linked to one issue
explain_issue / explain_incident	Cached or fresh AI brief

List tools take projectKey (for example PRO). Detail tools take human refs: issue PRO-123, incident PRO-I1.

Examples

Below, PRO is the project key. Swap it for yours from list_projects.

Find the noisiest incident and fix it in my repo

One prompt that spans MCP and your working tree:

Look at the noisiest open incident in RetraceKit for this project. Find the root cause in my codebase and fix it. Mark the incident INVESTIGATING while you work, then RESOLVED when the fix is in.

What a capable agent typically does:

1. list_projects → learn projectKey (for example PRO)
2. list_incidents with projectKey=PRO (no status → skips resolved). Pick the row with the highest eventCount / affectedUsers / linked issues
3. get_incident on that ref (PRO-I…) — surface, evidence, linked issue refs
4. explain_incident — short brief of what broke
5. update_incident_status → INVESTIGATING
6. For each linked issue: get_issue (and maybe explain_issue) — last stack frames, file, line, release
7. Open those files in the repo, change the code, run tests if you have them
8. update_incident_status → RESOLVED (and optionally resolve the linked issues)

You can tighten the ask:

Same, but only production (environment on the last event). Prefer the incident on route /checkout. Do not resolve until you show me the diff.

Or keep it chatty and short:

What’s on fire in RetraceKit? Trace it into this repo and patch it.

MCP gives the agent the crash surface and stacks. The IDE still owns the edit. Without MCP, the agent guesses from your local logs; with it, it starts from the same incident you see in the app.

Confirm the key

Which RetraceKit project is this MCP key for?

Agent calls list_projects and gets something like { "id": "…", "key": "PRO", "name": "Checkout" }. Use that key in every list call.

Morning open-issue scan

List open issues for PRO, page 0, size 20. Summarize title, occurrences, and last event message.

list_issues
  projectKey: PRO
  status: OPEN
  page: 0
  size: 20

To page further: same call with page: 1. For resolved noise:

list_issues
  projectKey: PRO
  status: RESOLVED

Open one issue and read the stack

Open PRO-42. Show the last event URL, release, and stack frames.

get_issue
  issueRef: PRO-42

Response includes title, status, occurrences, fingerprint, and last (name, message, timestamp, url, release, environment, sessionId, truncated stack).

Resolve, ignore, or reopen

PRO-42 is a known flaky test. Mark it resolved.

update_issue_status
  issueRef: PRO-42
  status: RESOLVED

PRO-7 is bot traffic. Ignore it.

update_issue_status
  issueRef: PRO-7
  status: IGNORED

PRO-7 was ignored by mistake. Set it back to open.

update_issue_status
  issueRef: PRO-7
  status: OPEN

AI brief on an issue

Explain PRO-42 in plain language. What broke, who is hit, what to try first?

explain_issue
  issueRef: PRO-42

You get whatHappened, likelyImpact, probableFix, plus cache flags (cached, stale, generationFailed). Same content as the explain button in the app.

Active incidents

List non-resolved incidents for PRO. Which surfaces are on fire?

list_incidents
  projectKey: PRO

Omit status to skip RESOLVED. Or filter:

list_incidents
  projectKey: PRO
  status: ACTIVE

Allowed filters: CANDIDATE, ACTIVE, INVESTIGATING, RESOLVED, REOPENED.

Dig into one incident

Open PRO-I3. List linked issues and evidence bullets.

get_incident
  incidentRef: PRO-I3

Then mark it under investigation:

update_incident_status
  incidentRef: PRO-I3
  status: INVESTIGATING

When the fix is live:

update_incident_status
  incidentRef: PRO-I3
  status: RESOLVED

To put it back in the open bucket: status: ACTIVE.

From issue to its incidents

Which incidents include PRO-42?

list_issue_incidents
  issueRef: PRO-42

Useful when one fingerprint shows up in several outages.

Incident AI brief

Explain PRO-I3. Keep it short so I can paste it into Slack.

explain_incident
  incidentRef: PRO-I3

Full triage loop (one prompt)

For project PRO: list open incidents. For the top one, get detail, explain it, list linked issues, and set status to INVESTIGATING. Then open the first linked issue and show the last stack.

Expected tools, in order:

1. list_incidents (projectKey=PRO)
2. get_incident (PRO-I…)
3. explain_incident
4. list_issue_incidents or read linkedIssues from detail
5. update_incident_status → INVESTIGATING
6. get_issue on the first linked ref

What fails on purpose

Get OTHER-99 with a PRO API key.

The server rejects refs outside the authenticated project (Issue not found / Incident not found). Same for list_issues with projectKey=OTHER.

The agent stays on that project. A key for PRO cannot read or mutate refs like OTHER-7.

Links

• MCP docs
• Setup / API key
• Incidents
• Plans

FAQ

Do I need a separate MCP token?

No. Use the project API key from project settings in the app. Same value as SDK apiKey / RETRACE_KIT_API_KEY.

Which clients work?

Any MCP client that speaks Streamable HTTP with a Bearer header. Cursor, Claude Code, OpenAI Codex, VS Code Copilot Chat, and similar IDEs or CLIs. We show a Cursor mcp.json; other clients use the same URL and Authorization header in their own config shape.

Can one key see every project?

No. The key is scoped to one project. List tools must pass that project's projectKey. Detail tools only accept refs for that project (for example PRO-123).

What can the agent change?

Issue status (OPEN, RESOLVED, IGNORED) and manual incident status (INVESTIGATING, RESOLVED, ACTIVE). Read tools cover lists, detail, linked incidents, and AI explanations.

Is MCP on every plan?

Yes. Remote MCP is available on Free, Plus, and Pro. Explain tools use the same AI path as the app.