SUMM

David Kramer, founder of Sentry, gives a last-minute talk sharing opinions based on experience building Sentry's MCP server, mainly for a B2B SaaS context
Sentry's core business is application monitoring, aimed at fixing bugs for internet-based applications
MCP (Model Connected Plug-in/Provider) is framed as a simple, pluggable architecture for agents, discussed mainly for enterprise, cloud-based services

MCP currently feels like a trendy concept with unclear definitions, compared to phenomena like the early crypto wave
Many opinions about MCP come from people who have not actually built systems using it
Sentry's experimentation with MCP is oriented toward B2B SaaS workflows, like integrating bug fixing into cloud-based editors

There are two main interfaces for MCP: remote and standard IO; remote is emphasized as more useful for businesses
VS Code Insiders offers the most useful support for MCP currently; Cursor is also working on this
Integrating Sentry's MCP with VS Code enables enhanced contextual workflows, such as fixing bugs directly from the editor
The initial integration required little boilerplate for companies already supporting OAuth and having APIs

While spinning up an MCP server seems straightforward, OAuth 2.1 is required, which is not widely supported yet
Sentry used Cloudflare Workers as a shim to manage OAuth 2.1; complexities exist, but building a functional MCP server took only a couple of days
Plug-and-play does not work: exposing your whole Open API as MCP tools yields poor results; extensive adaptation, massaging, and context-aware design are needed

Native MCP support exists in clients like VS Code Insiders, Cursor (soon), and partially in Cloud Code and others
Adapting services to existing developer tools (like editors) works reasonably well, but enterprise use outside this ecosystem may be less mature
User experience is still rough and in a beta stage; frequent breaking changes are common

OAuth matters most for B2B SaaS, especially when integrating with remote MCP servers
Building remote MCP servers offers the same advantages as traditional cloud services: fast iteration, maintainability, security
Security is a major concern; only use MCP tools from trusted sources to avoid risks like prompt injection
Avoid focusing on the standard IO interface, which has severe security concerns

You cannot simply proxy your existing API; MCP endpoints must be carefully crafted to provide useful, human-readable context
Sentry converts some API responses directly to markdown, prioritizing human and agent readability over machine-oriented JSON
Good error messages and context are crucial for both humans and agents; generic or unstructured responses degrade agent performance
Token and description length limits can break workflows, requiring iterative tuning and evolution of responses

Building agents—dedicated services orchestrating interactions—provides greater control, flexibility, and reliability than offloading everything to remote tools
MCP's primary value lies as a plug-in architecture for agents, but streaming responses for tools are lacking
Sentry’s own agent does detailed root cause analysis; exposing this via MCP is still challenging due to lack of streaming, requiring workarounds like polling
True potential will manifest as B2B companies offer tailored, agent-driven workflows over MCP

The technical challenges are manageable; building a basic MCP integration can be done very rapidly even by busy executives
Most complexity comes from adapting existing tech to new standards, not inventing fundamentally new solutions
The field is littered with hyped-up terminology, but the underlying concepts remain standard software and service patterns
Early adopters can expect lots of bugs and rough edges, but the presenter believes MCP’s architecture is here to stay
Focus efforts on agent-based workflows and context optimization, rather than just exposing APIs via MCP

MCP Is Not Good Yet — David Cramer, Sentry