MCP is a plug-in architecture for agents, so an MCP server needs to be designed around how agents use context rather than exposed as a direct copy of an API.
2
Remote MCP with OAuth is the practical path for B2B cloud services, while standard IO brings security and deployment problems that businesses should treat carefully.
3
The larger opportunity is to expose controlled agents through MCP, because owning the agent gives a service control over prompts, models, tool calls, results, and cost.
Summary
David Cramer describes MCP from the perspective of building Sentry's server for enterprise cloud services. He defines it as a plug-in architecture for agents, then explains why simply turning an OpenAPI description into tools produces poor results. Models need concise tool descriptions, human-readable responses, useful errors, and carefully selected context. Sentry returns Markdown for some workflows because it is easier for a model to reason about than large JSON payloads. The implementation also brings OAuth compatibility issues, client instability, token limits, and token costs. Cramer recommends remote MCP with OAuth for most B2B SaaS companies and warns against installing untrusted tools. His strongest view is that companies should build agents and expose those agents through MCP. An agent can hide multiple calls, control the prompt and model, and return a useful result. Sentry's root-cause analysis agent shows the promise, although missing streaming responses make the workflow awkward. MCP is accessible, but it requires ongoing iteration rather than a one-time integration.
Cramer defines MCP in simple terms: it is a pluggable architecture for agents. His examples come from Sentry, a B2B cloud service that helps teams monitor applications and fix bugs. An MCP connection can bring Sentry data and workflows into tools such as VS Code or Cursor, so bugs can appear inside the developer's editor. In his own test, he asked VS Code to fix all his bugs. The client made about 20 Sentry API queries, cost roughly five dollars, and started producing fixes whose quality he did not trust. The useful part was that Sentry's context reached the editor through an external service.
An MCP server needs its own design instead of exposing an API wholesale
Cramer rejects the idea that MCP can sit directly on top of OpenAPI. Exposing every existing endpoint as a tool gives agents giant JSON payloads and poor choices. An MCP server can use an API underneath, but it needs to be designed around how an agent receives and uses context. Sentry translates some API responses into Markdown and gives the model only the information needed for a workflow such as retrieving a bug. Cramer says this is not a scientific solution, but human-readable structure works better because language models can reason about it more easily than arbitrary payloads.
OAuth and client support make the first integration harder than it looks
The initial implementation appears simple when a company already has an API and an OAuth provider, but MCP's OAuth requirements introduce compatibility work. Cramer had to deal with OAuth 2.1, a Cloudflare shim, and a client-registration mechanism on Cloudflare Workers. Once the server is connected, the client can still be the source of failures. Native authentication support varies across products, and Cursor had broken for him repeatedly while VS Code worked relatively well. Companies building for third-party agents therefore depend on the quality and timing of those clients.
Remote MCP is the practical choice for most B2B cloud services
For a B2B SaaS company that wants its service to work inside different agents, Cramer recommends focusing on remote MCP and OAuth. A remote service keeps the normal advantages of a cloud product: the company can iterate, ship changes quickly, and manage security. He sees standard IO as a poor fit for this setting and says its security problems include the risk of prompt injection. His advice is to avoid allowing random MCP tools inside an organization and to avoid downloading untrusted packages from the internet.
Tool descriptions, errors, and output all become agent context
An MCP server has to explain its tools clearly enough for an unknown client and model to select the right one at the right time. Cramer says tool descriptions can run into token limits, and even choosing between tools is difficult for models. Errors need the same care. In his example, the agent queried every Sentry organization he could access instead of making one focused call. A human-readable error can help the model recover because the model cannot rely on the hardcoded assumptions that a conventional API client might use. The server also has to account for token cost, since returning too much data can make a call far more expensive and still fail.
Cramer says an MCP server is not a set-and-forget integration. Sentry was still updating it every week and examining what clients were doing. Tool descriptions, responses, workflows, and limits all need adjustment as the surrounding clients and models change. In his view, MCP is still a glimmer rather than a finished product. The Sentry test that made around 20 API calls for a simple request shows why this monitoring and iteration matter. An implementation can work technically while producing wasteful calls or unreliable results.
Exposing agents through MCP gives the service more control
Cramer's strongest recommendation is to build agents and expose them through MCP. He describes agents as service architectures with a newer name. When a company owns the agent, it controls the prompt that calls tools, the model, the number of background calls, the returned result, and much of the cost. Sentry is testing this approach with an agent that performs root-cause analysis on application problems. The current MCP flow starts a job and polls for completion because tool responses do not stream yet. The workflow is awkward, and the agent can give up, but Cramer sees this agent-to-agent pattern as the larger source of value.
The technology is accessible despite the rough edges
Cramer argues that the new terminology makes MCP and agents seem more mysterious than they are. He compares MCP to a plug-in architecture, agents to services, and many tool calls to ordinary API calls with a different response format. Sentry built its first server in about two days. The team also used Cloudflare Workers and an OAuth proxy even though Sentry had not used Cloudflare before, partly because Sentry did not operate WebSocket infrastructure and needed a way to support the protocol. His conclusion is practical: build a server, expect bugs, and learn from the behavior.
"MCP is a pluggable architecture for agents. Full stop."01:46
Who should watch
You run a B2B SaaS product and have been asked to add MCP without knowing whether a direct API integration is enough.
Your team is designing tools for Cursor, VS Code, or other third-party agents and needs practical guidance on context, errors, token limits, and OAuth.
You are deciding whether to expose raw tools or build a controlled agent that can manage the workflow behind an MCP interface.
