MCP Is Not Good Yet — David Cramer, Sentry

What is MCP supposed to give an agent? For David Cramer, who built Sentry’s MCP server, the useful answer is a pluggable architecture for agents. Sentry collects application-monitoring data, including the bugs developers need to investigate. MCP provides a way to make that context available to agents outside Sentry. This is a B2B cloud-service perspective: local toolchains can have different requirements.

Sentry knows what is broken; developers use editors such as Cursor to fix it. Connecting those two environments gives MCP a concrete job: bring bug context into the place where the repair happens. The pressure to become an AI company becomes a more useful product question when phrased this way: can the developer access Sentry’s evidence without leaving the editor?

Cramer focused on the remote interface rather than a local process communicating over standard input and output, or stdio. In the trial he describes, VS Code Insiders provided usable OAuth support: connect Sentry’s MCP server, retrieve data through curated workflows, and let the editor’s agent use it. The client-support comparisons throughout this account describe his experience at the time of the recording, not a current compatibility matrix.

Preparing a screenshot the night before the talk, he connected the server in VS Code and asked it to fix all his bugs. Cramer reports roughly 20 Sentry API queries and an offhand estimated cost of $5 for that trial. The agent began attempting fixes, but he had not evaluated their quality. What the trial established for him was narrower and still useful: an outside service had supplied context inside the editor, where an agent could act on it.

At first, the integration looked straightforward. Sentry already had an API and its own OAuth provider, so much of the machinery appeared to exist. The friction came from adapting that implementation to the OAuth 2.1 and client-registration requirements of the protected remote flow. The historical MCP authorization specification made authorization optional at the protocol level; for a service exposing protected Sentry data, authentication was nevertheless essential.

Sentry used a Cloudflare Workers shim to put an MCP-facing OAuth and client-registration layer in front of its existing OAuth 2 API. That let Cramer reuse the service’s authentication infrastructure instead of replacing it. He recalls getting the initial implementation built in a couple of days, despite the compatibility work.

Authentication only gets the agent through the door. Behind it are API responses designed for other consumers: potentially enormous JSON payloads whose useful information is buried among unrelated fields. Mechanically turning every OpenAPI endpoint into a tool leaves the agent to discover the workflow and interpret all that data itself.

An MCP tool interface needs its own design. Start with how an agent will use the service, observe how it responds to the context supplied, and shape the interface around that behavior. The implementation can call an existing API underneath, but the agent-facing tools need not mirror its endpoints or return its responses unchanged.

Even a carefully designed server depends on its consuming clients. Cramer encountered uneven native authentication and frequent breakage: VS Code had become relatively stable in his use, while Cursor had broken more often. Claude had support, but Claude Code’s support was uncertain in his experience. Developer tools seemed further along than other enterprise agents, yet the underlying constraint remained: a plugin is only useful when its host can load and operate it reliably.

For a B2B SaaS integration, his recommendation is to prioritize a remote MCP server with OAuth. The reasons are familiar cloud-service reasons: the provider can deploy improvements, iterate quickly, and adjust security centrally. A product tied to a local device is a meaningful exception; a hosted service bringing bugs into Cursor usually is not.

Remote hosting does not remove the need to trust the tools an organization installs. Cramer warns about prompt injection and the risks of downloading arbitrary MCP packages, particularly in local environments. His practical boundary is to use providers that have earned trust, rather than treating the existence of an MCP integration as a security endorsement.

Native OAuth also changes setup from a package-installation exercise into a URL-based connection. Cramer reported Claude Desktop and VS Code Insiders support, expected Cursor support shortly, and remained unsure about Claude Code. Sentry initially used mcp-remote, a bridge between local clients and remote servers. It helped ship the integration, but he found the experience rough compared with a client that accepts an MCP URL and handles authentication itself.

Sentry’s response to the payload problem was to translate selected API responses into Markdown. For a bug lookup, that meant selecting the bare essentials and arranging them in a structure a human could follow. The selection matters as much as the format: converting an indiscriminate JSON dump into an equally indiscriminate Markdown document would not accomplish the same thing.

Cramer explicitly calls the Markdown preference unscientific. It is a practical choice from his implementation, not evidence that Markdown universally outperforms JSON. The broader constraint is that a third-party server does not choose the consuming model, control its task, or know what else occupies its context. Its responses need to remain useful under those unknown conditions.

Context begins before a tool returns anything. A tool description helps the agent decide whether to call it, when to call it, and why to choose it over a neighboring tool. Those descriptions also consume tokens, so adding more explanation creates its own limits. Errors belong to the same interface: they are information the agent must use to decide what happens next.

The bug-fixing trial shows the limits of descriptions alone. The agent queried every Sentry organization Cramer could access. He reports approximately 20 calls where he expected one. Even with contextual guidance, it did not infer the intended scope of the task.

When an argument is invalid, return an explanation a human could use to correct it. A conventional API client may contain explicit recovery logic for known error codes; an unknown agent is reasoning from the response it receives. An error that explains what was invalid gives it a better basis for recovery than an opaque failure.

A server that returns everything also passes the cost of interpreting everything to the consumer. Cramer illustrates the risk with a hypothetical tool call whose token burden raises its cost from $1 to $10; this is an example, not a measured result. Payload design therefore affects both whether the agent can use a response and what the user pays for that attempt.

Size can cause outright failure as well. Cramer encountered limits involving tool tokens or description length, although he could not identify whether VS Code or OpenAI imposed them, or whether they still applied. This makes an MCP server an ongoing product responsibility: Sentry was still adjusting its implementation weekly, observing behavior and revising it rather than treating the first working connection as completion.

These constraints lead to Cramer’s larger recommendation: build agents and expose them through MCP. MCP supplies the plugin interface; a provider-owned agent supplies the service behavior. That architecture lets the company with domain knowledge perform the work instead of asking an unfamiliar client agent to reconstruct the entire workflow.

Sentry had begun doing this, but long-running work exposed another limitation: its integration could not stream partial tool results back as the work progressed. Cramer uses agent-to-agent here in the general sense of one agent invoking another service’s agent, not Google’s named protocol.

Owning the inner agent changes who can influence the outcome:

The provider can make several internal calls, control their prompts, and package the results into one response. In exchange for paying for that agent, it gains greater responsibility for success and failure. That is Cramer’s bet for where B2B services can add value through MCP.

Sentry’s example is Seer, an agent that uses application-failure data to perform root-cause analysis. Cramer describes its analysis as high quality, without supplying a benchmark. The results were exposed primarily through Sentry’s UI and also through MCP. The MCP path required the consuming agent to manage a sequence:

1. Start the analysis job.
2. Check whether the job has finished.
3. Continue checking until a result becomes available.

The failure was not necessarily inside the analysis itself: the consuming agent could give up while waiting. Starting useful work and successfully delivering its result are separate obligations.

This is a limitation of the described tool-result workflow, not a claim that MCP lacked streaming transport. The historical transport specification already supported HTTP with optional SSE; transport streaming does not itself provide incremental analysis results. It also did not require WebSockets, a distinction relevant to Cramer’s deployment account below.

The promise is that a client can request domain work without implementing the domain agent itself. Cramer also points to the Sentry MCP repository, correcting his initial description of its availability from open source to Fair Source. That qualification matters: access to the code should not be read as an unrestricted open-source license.

Cramer recalls building the initial integration in two days; that was a starting point, not a claim of production maturity. His closing analogies make the work approachable: MCP resembles a plugin architecture, agents resemble services, and many tools are API calls with adapted response formats. Familiar software-engineering responsibilities remain beneath the new vocabulary.

Cloudflare reduced the infrastructure work. Sentry had not used it before this project, according to Cramer, but Workers and its OAuth proxy let the team put the necessary layer in place quickly. He also notes that Sentry did not operate WebSocket infrastructure; adopting hosted connection-handling infrastructure helped them avoid building that operational capability themselves.

An accessible first implementation can still be buggy and require sustained iteration. The useful direction is to keep building through those integration problems while concentrating on workflows the provider understands: use the service’s data, own the agent behavior where it matters, and supply the context that lets the surrounding system accomplish the user’s task.