@swyx: explain this

@GergelyOrosz @dsp_ @zeeg explain this

https://t.co/zp1DOKtxDD

TL;DR

MCP (Model Context Protocol) is a hot but immature technology that promises a pluggable architecture for AI agents; building a practical MCP server requires deep design thinking, not just wrapping an existing API, and the ecosystem is still catching up.

What Is MCP? A Pluggable Architecture for Agents

MCP (Model Context Protocol) is described by David Kramer (Sentry founder and engineer) as “a pluggable architecture for agents.” In the context of B2B SaaS companies like Sentry, it acts as a bridge between AI-powered tools (editors, agents) and backend services. Kramer’s perspective comes from building Sentry’s own MCP server – a practical, production‑facing implementation.

The core idea is simple: instead of manually context‑switching between an editor and a monitoring tool, an agent (e.g., a coding assistant in VS Code) can directly query Sentry’s data, retrieve bugs, and even attempt fixes. Kramer’s demo showed VS Code Insiders making 20 API calls to Sentry in seconds, costing about $5 in tokens – a glimpse of both the potential and the current rough edges.

Building an MCP Server for a B2B SaaS: Lessons from Sentry

Kramer highlights two MCP interfaces: remote (OAuth‑based) and std I/O. For cloud services, the remote interface is the only sensible choice.

OAuth 2.1 – The First Hurdle

Most companies already have OAuth, but MCP requires OAuth 2.1, a version Kramer hadn’t encountered before. Sentry used a Cloudflare Shim to proxy their existing OAuth 2.0 API and implement the 2.1 client registration. The whole integration took a few days – doable, but not trivial. For enterprises, this step is where many get stuck.

The Real Challenge: Don’t Just Wrap Your API

“MCP is not OpenAPI on top,” Kramer stresses. Exposing all your API endpoints as tools gives the worst possible result – the agent cannot reason about huge JSON payloads. You must design the system around agentic consumption:

• Return minimal, human‑readable context – Sentry returns structured Markdown instead of raw JSON. If a human can reason about it, a language model can too.
• Craft tool descriptions carefully – These descriptions compete for token limits and must guide the agent’s decisions.
• Design errors for agents – Errors are still context; give human‑friendly explanations so the model can recover gracefully.

Kramer’s team updates their MCP server weekly, tweaking descriptions and responses based on observed agent behavior.

Client Support is Still Beta

Only a few clients fully support remote MCP with OAuth today: VS Code Insiders (works well with OAuth), and Cursor (promised support “this week”). Other editors like Cloud Code have partial support. The experience is “rough, beta, fine.” You’re dependent on the client’s implementation to be stable.

Key Recommendations for B2B SaaS Companies

1. Only care about remote MCP with OAuth. If you’re running a cloud service, the same benefits (rapid iteration, centralised security, controlled deployment) apply. Focus on the remote spec and ignore std I/O for now.
2. Do not expose raw APIs as tools. Invest effort in crafting agent‑friendly endpoints – structured Markdown, clear tool descriptions, and thoughtful error messages.
3. Watch the token cost. Tool calls that previously cost $1 can balloon to $10 when the model consumes huge contexts. Keep descriptions short and responses concise.
4. Security: don’t trust arbitrary MCP tools. Std I/O interfaces introduce injection risks. Only allow tools from trusted sources – especially within an organisation.
5. Iterate constantly. MCP is not “set and forget.” Monitor how agents use your tools and refine the design weekly.

The Elephant in the Room: Agents Talking to Agents

Kramer notes that MCP currently lacks streaming responses for tools. When you move toward agent‑to‑agent interactions (not agent‑to‑human), this becomes a major limitation. The ecosystem is still early – but the direction is clear.

Source

Watch the full talk: @swyx: explain this