MCP Error Tracking for AI Debugging | Telebugs

Quick answer: what is MCP error tracking?

MCP error tracking means connecting an AI coding tool to structured error tracker data through the Model Context Protocol. The official MCP docs describe MCP as an open-source standard for connecting AI applications to external systems. In Telebugs, that external system is your self-hosted error tracker.

Instead of copying a stack trace into chat, an approved MCP client can ask Telebugs for the error group, reports, backtraces, breadcrumbs, release, environment, notes, and project context it needs to help debug the issue.

Why MCP matters for error tracking

Error tracking is full of context: stack traces, culprit frames, request data, breadcrumbs, users, environments, releases, notes, assignments, and the history of what your team has already tried. That context is valuable, but it often sits one browser tab away from the code editor where the fix actually happens.

MCP (Model Context Protocol) gives AI coding tools a standard way to ask Telebugs for that context. Instead of pasting a stack trace into a chat window, you can connect Claude, Cursor, Windsurf, OpenAI/Codex, or another MCP client to your Telebugs instance and let it inspect the same facts you see in the dashboard.

The goal is not magic. The goal is a shorter path from "production is broken" to "this is the file and line I need to change."

What Telebugs exposes through MCP

Telebugs exposes a Streamable HTTP MCP endpoint at /mcp. After authorization, an MCP client can use Telebugs tools to read the debugging context that matters:

• List projects, project users, error groups, reports, and notes.
• Inspect a specific error group or report, including backtraces and breadcrumbs.
• Filter error groups by status, query, date range, and severity.
• Resolve, unresolve, mute, unmute, assign, unassign, merge, and add notes when write access is granted.
• Run bulk resolve, bulk mute, and bulk merge actions for cleanup workflows.

That means your coding tool can start from live production evidence: "show me the newest unresolved Rails errors," "inspect the top Next.js exception from the last deploy," or "summarize the breadcrumbs for this failing checkout report."

MCP error tracking vs pasting stack traces

Debugging step	Copy-paste workflow	MCP error tracking
Starting context	A stack trace or screenshot copied from the browser.	Structured group, report, release, environment, breadcrumb, and note data from Telebugs.
Follow-up questions	You keep switching tabs and pasting more evidence.	The client can ask Telebugs for related reports, affected users, and recent activity.
Access control	The pasted data leaves its original workflow with little structure.	Access is granted through scoped OAuth, and connected apps can be revoked.
Actions	You return to the dashboard to resolve, mute, assign, or add notes.	Trusted clients with write scope can take approved cleanup actions through Telebugs tools.

Example MCP debugging workflows

The useful part of MCP is not that an AI tool can see a stack trace. The useful part is that it can ask follow-up questions against the same structured error tracker your team uses every day.

• Triage after an alert. Ask your editor to inspect the newest unresolved production error, summarize the affected release, and point out the most suspicious stack frame.
• Compare repeated reports. Have the tool look across multiple reports in the same group to find the shared request path, user action, environment, or breadcrumb pattern.
• Prepare a fix. Let the tool combine Telebugs context with the local repository so it can open the likely file, explain the failure path, and suggest a focused patch.
• Clean up known noise. With write access, a trusted client can mute, resolve, assign, merge, or add notes after you approve that workflow.

This works especially well for teams using Sentry SDK compatible error tracking, because the SDKs already send rich context: breadcrumbs, tags, release names, user data, extras, and request details.

Secure by default, not a secret backdoor

MCP access should feel like a normal connected app, not a hidden admin tunnel. For HTTP-based servers, the MCP authorization spec is based on OAuth 2.1 and related metadata standards. Telebugs uses OAuth with PKCE, dynamic client registration, short-lived access tokens, refresh tokens, and revocation.

Clients request explicit scopes:

• telebugs.read for reading projects, errors, reports, notes, and context.
• telebugs.write for actions like resolving, muting, assigning, merging, and adding notes.

Connected MCP apps can be reviewed and revoked from account settings. If a tool is no longer trusted, remove its access without digging through the database.

This also matches the spirit of the MCP tools guidance: servers should enforce access controls and validate tool inputs, while clients should show tool usage clearly and ask for confirmation on sensitive operations.

Privacy-friendly AI debugging

Telebugs is self-hosted, so your production error tracker lives on your infrastructure. MCP does not change that. A coding tool connects to your Telebugs instance with your permission, using the scopes you approved.

Telebugs also marks values from error reports as untrusted in MCP responses. Error messages, breadcrumbs, frame context, request values, and similar fields can contain user-provided input. AI tools should use that data for debugging, not treat it as instructions.

This is especially useful for teams that want AI-assisted debugging but do not want to move error tracking into another hosted observability product. See the privacy-first error tracking guide for the broader data-control story.

What MCP does not replace

MCP is an interface for debugging context. It is not a replacement for the error tracker itself.

• Telebugs still collects errors from your apps, groups related reports, and stores the history.
• Notifications and rules still decide when someone needs to know about a new issue, recurrence, or spike.
• Retention and purging still define how long error data stays around on your infrastructure.
• Your team still decides what code changes, what gets resolved, and which connected tools are trusted.

Think of MCP as a bridge between error tracking and the coding tools where fixes happen. The source of truth remains Telebugs.

Where this fits

MCP is a practical layer on top of the core Telebugs workflow:

• Error tracking stays first. Telebugs still collects, groups, and notifies you about production errors.
• Sentry SDK compatibility still matters. Your apps keep sending rich error context through familiar SDKs.
• Notifications still wake the right person. MCP helps after the alert, when someone needs to inspect and fix the issue.
• AI is optional. Telebugs remains useful without any AI tool connected.

If MCP is part of why you are comparing error tracking tools, see the self-hosted error tracking guide, the error tracking alternatives hub, and the Sentry alternative page for where AI-friendly debugging fits in the broader decision.

For the release story and implementation details, read Telebugs 1.17.0: Introducing MCP Support.

Frequently asked questions

What is MCP error tracking?

MCP error tracking connects an AI coding tool to structured error data through the Model Context Protocol. In Telebugs, that means an approved client can inspect error groups, reports, stack traces, breadcrumbs, releases, notes, and related context from your self-hosted error tracker.

What is MCP?

MCP is the Model Context Protocol, a standard way for AI tools to connect to external systems and request structured context or actions. Telebugs uses it to expose error tracking data to authorized MCP clients.

Which AI coding tools work with Telebugs MCP?

Telebugs is designed for MCP clients such as Claude, Cursor, Windsurf, OpenAI/Codex, and other tools that support HTTP MCP servers with OAuth authorization.

Can MCP inspect stack traces and breadcrumbs?

Yes. Telebugs MCP tools can expose reports, backtraces, breadcrumbs, tags, releases, notes, and related group context to authorized clients so debugging starts from the same evidence your team sees in Telebugs.

Can an AI tool change my errors?

Only if you grant write access. Read-only access lets the client inspect projects, groups, reports, breadcrumbs, backtraces, and notes. Write access is required for actions like resolving, muting, assigning, merging, or adding notes.

Is MCP error tracking safe for production data?

It can be, when access is scoped and reviewed. Telebugs uses OAuth authorization, read/write scopes, short-lived access tokens, revocation, and untrusted-data markings for values that come from error reports.

Does MCP send my error data to Telebugs cloud?

No. Telebugs is self-hosted. The MCP endpoint runs on your Telebugs instance, and connected clients access that instance with the permissions you approve.

Does MCP replace my error tracker?

No. MCP is the connection layer. Telebugs still collects errors, groups reports, stores history, sends notifications, manages retention, and remains the source of truth for production error data.

Do I have to use AI tools with Telebugs?

No. MCP is optional. Telebugs remains a normal self-hosted error tracker with grouping, notifications, releases, sourcemaps, notes, and team workflows even if you never connect an AI tool.

Can I revoke MCP access?

Yes. Connected MCP apps can be reviewed and revoked from account settings.

Ready to debug production errors from your coding tool?

Read the MCP release notes, browse the Telebugs manual, or get Telebugs and connect an MCP client to your own error tracker.