Scaling an MCP Server for Error Monitoring to 60 Million Monthly Requests

sentry · Tech · 2024 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Production MCP server for error monitoring and coding assistants

Sentry needed to turn a copy-paste debugging workflow into a production MCP integration that lets AI coding assistants query error context and trigger fixes while remaining observable, concise, and reliable at high request volume.

Constraints:

MCP clients differ in transports and rendering behavior.
Tool descriptions determine whether assistants call the correct Sentry tools.
Returning too much issue context pollutes the coding assistant's working context.
The MCP server itself has production failure modes and tool-call errors.
The team does not control Cursor, Claude Desktop, or other clients consuming the MCP responses.

Architecture

Sentry's MCP server exposes 10-15 tools, especially issue-detail retrieval, search, and issue-fix initiation. It uses Markdown tool descriptions and responses, examples in descriptions, concise returned context, optional AI agents inside MCP tools to filter responses, re-anchoring prompts for long sessions, and production observability across transports, clients, slow tools, and tool-call failures.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  A["MCP clients"] --> B["Sentry MCP server"]
  C["MCP transports"] --> B
  B --> D["Tool description layer"]
  B --> E["Sentry issue data"]
  E --> F["Embedded MCP agent"]
  F --> B
  B --> G["Sentry fix agent"]
  B --> H["MCP observability"]
  C --> H

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`MCP clients`	Cursor, Claude Desktop, VS Code, and other AI coding clients that call Sentry tools.	`Sentry MCP server`
`Sentry MCP server`	Production service exposing Sentry error-monitoring tools through MCP transports.	`MCP transports`, `Tool description layer`, `Sentry issue data`, `Sentry fix agent`, `MCP observability`
`MCP transports`	Local stdio, HTTP streamable, and SSE transport paths used by different clients.	`Sentry MCP server`, `MCP observability`
`Tool description layer`	Markdown descriptions, examples, and parameter guidance that teach clients when and how to call tools.	`Sentry MCP server`
`Sentry issue data`	Error details, events, projects, and organization data returned to coding assistants.	`Embedded MCP agent`
`Embedded MCP agent`	Optional agent inside MCP tools that filters and summarizes Sentry context before returning it.	`Sentry issue data`, `Sentry MCP server`
`Sentry fix agent`	Internal AI agent invoked by the MCP server to begin automated issue fixes.	`Sentry MCP server`
`MCP observability`	Dashboards and instrumentation for transports, clients, tools, latency, and errors.	`Sentry MCP server`

Data flow

A coding assistant calls Sentry's MCP server through stdio, HTTP streamable, or SSE. The server uses tool descriptions and examples to guide calls, retrieves Sentry issue context or launches Sentry's fix agent, optionally filters context through an internal agent, returns concise Markdown to the client, and records observability data about transport, tool usage, latency, and failures.

3 supporting quotes

“people will go into our platform see I don't know like a front end error a back end error or some kind of error then copy the page and tell to curs or something like hey fix it.”transcript, stated

“We have morely more like 10 to 15 tools but we have three that are the most used one.”transcript, stated

“you can actually see the transport distribution right here. So you will have for example for us this is uh from a demo of mine.”transcript, stated

Why this architecture

Sentry treats an MCP server as a production service and a context-control boundary: because it cannot control the client model, it controls tool descriptions, response format, returned context, and observability inside the server.

3 supporting quotes

“if you have an MCP server with an AA agent you can control what you return you can control what you do out there”transcript, stated

“the goal is to treat the MCP server as a production service.”transcript, stated

“you are fully responsible of what's happening in inside there.”transcript, stated

Models used: AI coding assistants · Sentry internal AI agent · embedded MCP agent

Scale

Sentry's MCP server scaled from 30 million to 60 million monthly requests.
“we were at 30 million request uh per month. We are now at 60 which is almost the double”transcript, stated
More than 5,000 organizations use the MCP server.
“We have right now more than 5,000 organizations using our MCP server.”transcript, stated
The MCP server had more than 45,000 tool-call errors per month.
“we have more than uh 45,000 tool call errors per month”transcript, stated
A three-person special projects team built and managed the MCP server.
“we are just three of us building the MCP server.”transcript, stated

Alternatives considered (roads not taken)

Leave the copy-paste workflow in place

Rejected because: MCP offered a better interface for developers already asking coding assistants to fix Sentry issues.

“people will go into our platform see I don't know like a front end error a back end error or some kind of error then copy the page”transcript, stated

Return full pages of Sentry context

Rejected because: Large irrelevant payloads pollute the coding assistant's context and drift away from the original task.

“full page is not useful information depending of the query of the agent.”transcript, stated

Treat MCP as a demo integration

Rejected because: Transport-specific outages and tool errors showed it needed production-service observability and incident handling.

“we didn't have a way to change from one transport to the other to see the analytics.”transcript, stated

Patterns

`tool-use-orchestration` (agent-architecture)

The MCP server exposes Sentry issue and fix tools to AI coding assistants through a controlled protocol interface.

“get issue detail details. This is the page that I told you you have an error you have all the details about it.”transcript, stated

`context-engineering` (context)

Sentry designs MCP responses, tool descriptions, and embedded filtering to prevent context pollution.

“context pollution is the more measurable distance u between original intent and what's the current direction”transcript, stated

`observability-tracing` (operations)

The team instruments transports, clients, tool usage, latency, and error classes as production observability.

“if you want to have observability you have to know what happened.”transcript, stated

`structured-output-contract` (interface)

Markdown tool descriptions and examples serve as a model-readable contract for tool calls and responses.

“one we do everything in markdown. This”transcript, stated

Tradeoffs

Response format

Chose Markdown over XML or JSON responses.

Rationale: Markdown is human-readable and many MCP clients render it natively.

“we do everything in markdown. This was for us. I know people return responses and talk to um to the agents in XML or JSON”transcript, stated

Context control boundary

Chose embedded agent inside MCP tools over letting the client model handle all filtering.

Rationale: Sentry cannot control the client, but it can control what its MCP server returns.

“if you have an MCP server with an AA agent you can control what you return you can control what you do out there”transcript, stated

Gotchas (what bit them)

If the MCP server is not called, it is the server author's problem.

Root cause: Tool descriptions and metadata are part of the product contract for agent behavior.

Resolution: Write concise Markdown descriptions with concrete call examples and parameters.

“if there's an issue our MCP server like uh our agent should know by the description of our MCP server and the description of the tools”transcript, stated

Unfiltered issue context pollutes the assistant's context window.

Root cause: Full Sentry pages can be too large or irrelevant to the user's immediate task.

Resolution: Return concise Markdown and use an embedded agent to filter useful information.

“full page is not useful information depending of the query of the agent.”transcript, stated

Transport-specific MCP outages can be invisible without observability.

Root cause: The team initially lacked transport-level analytics across stdio, HTTP streamable, and SSE.

Resolution: Build dashboards that segment traffic by transport, client, tool, latency, and error details.

“the 10% of our queries that were actually um stdio were broken.”transcript, stated

Evaluation

Sentry evaluates MCP production health through request volume, organization count, tool usage, transport distribution, slowest tools, tool-call errors, and incidents.

Metrics: monthly requests · organizations using MCP · tool-call errors · transport distribution · tool latency · client distribution

“you will have here your three transports. And you will see which clients do you have”transcript, stated

“the idea is to know what which tool call failed and what information you can get from there”transcript, stated

Outcomes

The MCP server scaled to 60 million monthly requests.
More than 5,000 organizations used it.
Sentry identified and fixed transport-specific failure visibility gaps.
The team began treating the MCP server as a normal production service with alerts and incidents.

The MCP server is operated by a small special-projects team but handles millions of requests and tens of thousands of tool errors per month.