Telebugs 1.17.0: Introducing MCP Support
In the 1.16.0 post, I wrote that the new REST API opened the door to MCP support. I expected that to be a "soon" thing. It turned out to be a "drop everything and build it now" thing.
Telebugs 1.17.0 adds MCP support. You can now connect AI coding tools to your self-hosted Telebugs instance and let them inspect real error data, pull reports, look at backtraces, and take scoped actions without copying stack traces back and forth like it is 2016.
This is one of those releases where the feature feels obvious in hindsight. Telebugs already knows what broke. Your coding tool already knows the code. MCP is the missing pipe between the two.
MCP Support
Telebugs now exposes a Streamable HTTP MCP endpoint at /mcp. Tools can discover it, register an OAuth client, ask for read or write scopes, and then call Telebugs tools using a normal bearer token.
The first set of tools covers the workflows I reach for most often:
- List projects, project users, error groups, reports, and notes.
- Inspect an error group or a specific report.
- Resolve, unresolve, mute, unmute, assign, unassign, and merge groups.
- Add and delete notes.
- Run bulk resolve, bulk mute, and bulk merge actions.
Connecting an AI coding tool to Telebugs over MCP.
The tools return real data, not vague "success" messages. Lists support cursor pagination with has_more and next_cursor. Error groups can be filtered by status, query, date range, and severity. Reports include the context you actually need: tags, culprit, breadcrumbs, and backtraces.
So instead of asking your editor "what might be wrong?" you can ask it "what is breaking in production right now?" and have it start from the same facts you see in Telebugs.
Authorization That Feels Normal
I did not want MCP access to feel like a secret admin backdoor. It uses OAuth with PKCE, dynamic client registration, short-lived access tokens, refresh tokens, and revocation. Clients request telebugs.read, telebugs.write, or both.
There is also a new Connected MCP apps page in account settings. If you try a tool and later change your mind, revoke it from there. No database spelunking, no "where did that token go?" ritual.
The MCP authorization screen shows the client, requested scopes, and the Telebugs account it wants to access.
One extra detail I care about: Telebugs marks values from error reports as untrusted in MCP responses. Error messages, breadcrumbs, frame context, and similar data often come from the application that crashed. Sometimes that application accepts public input. An AI tool should use that data for debugging, not treat it as instructions.
That sounds a little paranoid. It is the correct amount of paranoid.
Connected MCP apps can be reviewed and revoked from account settings.
The Quick 1.17.1 Patch
I also shipped 1.17.1 shortly after 1.17.0. I noticed a problem on the MCP authorization page right after the release and pushed a fix immediately.
Authorization screens need to be boring, clear, and trustworthy. The patch replaces the rough consent page with a proper MCP-specific layout, the right documentation link, requested permissions, client identity, Telebugs account target, and recognizable client logos for Claude, Cursor, Windsurf, and OpenAI/Codex where possible.
Not the release-day flourish I had planned, but I would rather ship the small fix quickly than pretend I did not see it.
Bulk Actions Got Better Too
MCP is the headline, but 1.17.0 also rounds out the bulk action work from the last release.
You can now bulk mute, unmute, and merge error groups from project error lists and the All Errors view. The same actions are available through the REST API and MCP tools, so the UI, API, and AI workflow all speak the same language.
Bulk mute, unmute, and merge actions in the error list.
This matters because production errors rarely arrive one at a time. A bad deploy can create a messy cluster of related groups. Being able to select the noise, merge what belongs together, and mute what is already understood makes cleanup feel much less like punishment.
Better Error Context
A lot of the quieter work in this release went into making report data better for both humans and tools.
Report responses now include backtraces and breadcrumbs. Culprit display is more consistent, especially for single-report groups. Error group filtering supports severity more cleanly, and MCP defaults to actionable severities unless you explicitly ask for telemetry-level events.
The goal is simple: when a tool asks Telebugs for context, it should get enough information to help without needing five follow-up calls just to understand the shape of the problem.
Other Improvements
There are a few smaller things in here too. The projects API can now filter by exact project name. Metadata pills became metadata tags, which are easier to scan and fit the rest of the interface better. I cleaned up spacing, dividers, menu hover states, badge corners, and dialog padding. I also fixed the mute/unmute icons being swapped in a couple of places, which was small but deeply annoying once you noticed it.
Under the hood, this release updates Ruby to 4.0.5, adds the mcp gem, and updates a handful of dependencies.
Full list, as always, is in the changelog.
Wrapping Up
The REST API made Telebugs programmable. MCP makes it conversational inside the tools where you already work. That is the part that feels exciting to me.
Error tracking has always been about shortening the distance between "something broke" and "I know what to fix." This release cuts out another chunk of that distance.
Telebugs 1.17.1 is live now. Update, connect your favorite MCP client, and try asking it what is currently breaking in production. If something feels off, write to [email protected]. I am also on X at @kyrylo and @TelebugsHQ.
For a shorter product overview of the workflow, see MCP for self-hosted error tracking.