How MCP Became the Default Tool Layer for AI Agents in About a Year

I run six MCP servers in my daily workflow. Gmail, Google Calendar, Notion, Asana, Canva, and a local LightRAG server that gives my AI agent access to my entire knowledge vault. I set them all up over a few months, barely thinking about what I was actually doing — it just worked. You define a server, point your client at it, and suddenly your agent can do things it couldn't before.

It was only recently that I stopped to ask: why does this work so cleanly? What problem did MCP actually solve that every AI integration before it was getting wrong?

The answer is more interesting than "Anthropic built a good standard." MCP solved a coordination failure that was going to force a solution anyway. The only question was who would define the contract first.

The Mess Everyone Was Sitting In

Before November 2024, if you wanted to give an LLM access to external tools — a database, an API, a file system — you had roughly three options, none of them good.

The first was pure text. You described the tool in the system prompt and hoped the model would output something parseable. It worked until it didn't, and "until it didn't" happened a lot.

The second was OpenAI's function calling, which arrived in June 2023. You defined a JSON schema for each function, the model declared which function it wanted to call and with what arguments, your code executed it, and you fed the result back. This was genuinely better. Structured, predictable, and it caught the "model hallucinating argument names" class of bugs. Anthropic shipped a similar tool-use system on Claude. Google had Vertex AI tool definitions. Each was solving the same problem — the model declares intent, the application performs the call — but each ecosystem was a silo with its own schema format and its own client SDK.

The third was framework-level abstraction. LangChain, LlamaIndex and others tried to paper over this with their own tool wrappers. That gave you portability across models, but it was framework-level, not protocol-level: every framework had its own toolkit, every IDE that wanted to host an agent had to bring one of those frameworks in.

If you were building a serious agent — one that needed to work across models or plug into external tooling — you were writing adapter code. Lots of it. Every new tool was a new bespoke integration. Every provider change meant rewriting that integration. The maintenance surface grew proportionally to your ambition.

This is what economists call a coordination problem: everyone independently converging on the same pattern, but unable to interoperate because no one defined a shared contract first.

Three Layers, One Contract

On November 25, 2024, Anthropic published the Model Context Protocol. The timing mattered less than the insight behind it: the reason every AI tool integration was hard to maintain wasn't the tools themselves — it was that three distinct engineering problems kept getting conflated into one bespoke solution.

Tool awareness: How does the model know what tools exist? In function calling, you hardcode schemas into each API call. The model is blind to tools you haven't explicitly declared. MCP solves this with protocol-level discovery: servers declare capabilities and return their available tools, descriptions and input schemas through methods like tools/list, rather than every client hardcoding every schema.

Mediation and execution: Who actually runs the code? The model never does — it requests tool use. The host (the LLM application, like Claude Code or Cursor) and its embedded MCP client mediate that request, apply user-consent and security policy, and forward it to the MCP server. The server performs the operation or calls the upstream API and returns the result. Function calling already separated request from execution; MCP's contribution is making the host/client/server boundary part of the wire protocol so any client can talk to any server.

Result feedback: After a tool runs, how do results flow back into the model's reasoning? Raw strings work until the output is complex, partial, or needs to be combined with other results. MCP defines a standardized result envelope with content blocks (text, images, audio, embedded resources). Newer revisions add structuredContent with an optional output schema, so when you want strongly typed results you can have them.

Here's what that looks like versus the old approach:

The key line is the last one. Function calling is a protocol between you and one provider. MCP is a protocol between any server and any client, regardless of which model is doing the reasoning.

Why Everyone Fell In Line (Faster Than Expected)

My first reaction to MCP was skepticism. Anthropic was obviously motivated to define a standard that put Claude at the center. Why would OpenAI and Google adopt a protocol written by a competitor?

Because the alternative was worse. The coordination problem was real and growing. Every major lab was running its own incompatible tool system. Every enterprise integrating AI was writing redundant adapter layers. The total industry cost of fragmentation was enormous and obvious to everyone involved.

OpenAI announced MCP support on March 26, 2025 — less than four months after launch. Sam Altman: "People love MCP and we are excited to add support across our products." Agents SDK support was available immediately; broader product support followed, with remote MCP support in the Responses API announced in May 2025. Google followed with MCP support in the Gemini API and Vertex AI Agent Builder. Microsoft shipped MCP servers for Azure, Sentinel, Dynamics 365, and Microsoft 365.

By December 2025, Anthropic had done something notable: they donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded by Anthropic, Block, and OpenAI. A standard that started in one company's lab was now governed by a neutral body with buy-in from three of the biggest players. That's not a vendor lock-in play — that's a coordination mechanism.

The adoption numbers reflect this. By March 2026, Anthropic reported 97M+ monthly SDK downloads across the Python and TypeScript SDKs, with 10,000+ active public MCP servers. The widely-cited trajectory along the way: ~2M at launch, ~22M after OpenAI's adoption announcement in March 2025, ~45M after Microsoft's Copilot Studio integration in mid-2025, then 97M+ by the 16-month mark. A March 2026 industry survey of 650 enterprise technology leaders reported 78% had at least one MCP-backed agent running — though most are still pilots. LangChain, CrewAI and AutoGen all support MCP through documented adapters and integrations.

This is what industry convergence looks like when the underlying engineering problem is real enough that everyone's solution independently looks the same.

What This Looks Like in Production: Sentry's MCP Server + Seer

The best way to understand why MCP matters beyond the theory is to look at how Sentry layered it into their debugging workflow.

Here's the problem Sentry was solving: developers debug production issues by switching between their IDE and Sentry's dashboard — pulling stack traces, reading event logs, cross-referencing errors. That context switch is expensive and interruptive. The obvious answer is to bring Sentry data into the developer's IDE. The hard part is doing that without writing a bespoke integration for every IDE and every AI coding assistant on the market.

Their solution is two layers, and the distinction matters. The Sentry MCP server (open-sourced on GitHub) makes issue and debugging context available to MCP-compatible coding agents like Cursor and Claude Code — paste a Sentry issue URL and the server pulls stack traces, event details, tags, breadcrumbs, and related context. Separately, Seer/Autofix — Sentry's reasoning layer — uses Sentry telemetry plus codebase context to perform root-cause analysis, suggest fixes and help create PRs. The MCP server is the data plane; Seer is what does the thinking.

The important thing about this architecture isn't the AI part — it's the protocol layer. Sentry built one server. That server works with any MCP-compatible client. They didn't write a Cursor plugin, a Claude Code plugin, and a VS Code plugin. They wrote one MCP server and got all three for free.

// Illustrative tool shape — Sentry's actual server defines a richer set of
// tools and the names may have evolved. The point is the protocol contract:
// any MCP client can discover and call this without Sentry writing
// IDE-specific integrations.
{
  name: "get_issue_details",
  description: "Fetch full details for a Sentry issue including stack trace and events",
  inputSchema: {
    type: "object",
    properties: {
      issue_id: { type: "string", description: "Sentry issue ID or URL" }
    },
    required: ["issue_id"]
  }
}

This is the flywheel MCP creates: server authors write once, client authors write once, and every combination works. Before MCP, every intersection was a custom integration. With MCP, there are no intersections — just a shared protocol.

The Agent-Mac Lesson: I Was Using It Before I Understood It

My own MCP setup is a good illustration of how easy it is to miss what you're actually running.

For months, I treated my MCP servers as configuration details. You add them to Claude Code's settings, they show up as available tools, and your agent can use them. I didn't think much about the architecture.

// .claude/settings.json — illustrative; package names depend on which
// MCP server you install (community Gmail/Calendar servers, vendor
// servers, or your own).
{
  "mcpServers": {
    "gmail": { "command": "npx", "args": ["mcp-server-gmail"] },
    "lightrag": { "command": "python3", "args": ["-m", "lightrag.mcp_server"] }
  }
}

What I didn't fully appreciate: Claude Code is the MCP host in this setup. It runs an embedded MCP client that calls each server's tools/list (tool awareness), forwards tool invocations to the servers (which execute and return structured results), and feeds those results back into the model's context. I'm not writing any of that machinery — it's just the protocol working.

The honest mistake I made early on was thinking "MCP is just fancy function calling." It's not. Function calling is a pattern. MCP is a contract. The difference is that a contract can be implemented independently by many parties and still interoperate. A pattern can't.

When LightRAG started supporting MCP last year, I didn't change anything in my agent. I pointed Claude Code at the new server endpoint and it worked immediately. That's the protocol doing its job.

Where This Goes Next: The Web Becomes a Tool Surface

The same problem MCP solved for LLM-to-API connections is now being applied to LLM-to-web connections, and it's further along than most people realize.

Chrome has made WebMCP available through an early preview / prototyping path. The premise is identical to MCP but applied to browser interactions: instead of agents scraping HTML (thousands of tokens per page, fragile, constantly breaking on layout changes), websites expose structured tools directly.

Two APIs in the current draft:

Declarative: Annotate your existing HTML forms with tool metadata. An agent wanting to submit a support ticket calls submit_ticket, not "find the form, fill each field, click submit." No JavaScript required.

Imperative: JavaScript-based, developer-defined JSON schemas. For complex stateful workflows that go beyond forms.

The efficiency argument is concrete: browser automation via screenshots burns thousands of tokens per interaction. A single tool call replaces dozens of DOM interactions. And unlike scraping, the interface is stable — the website author controls what tools they expose, and that contract doesn't change when they redesign their UI.

The WebMCP draft is being shaped through the W3C community process, with engineers from Microsoft and Google as editors — not a finished standard, but real cross-vendor work in the open. There's already a community npm package (@mcp-b/global) that polyfills the navigator.modelContext API in browsers without native support — useful for early testing, but not an official release, so treat it as an experiment.

Standards Win for Boring Reasons

MCP started under MIT and is transitioning to a mixed model — Apache-2.0 for new code and spec contributions, CC-BY-4.0 for documentation, with older unrelicensed contributions remaining MIT. Vendor-neutral since the Linux Foundation handoff, solving a problem everyone had. Those are the conditions under which standards win.

TCP/IP won not because it was technically perfect but because the cost of every network speaking its own protocol eventually exceeded the cost of switching to a common one. USB-C won not because it was the best connector anyone ever designed but because the fragmentation of charging standards got expensive enough that even competing manufacturers agreed to end it.

MCP is at that inflection point for AI tool use. The cross-vendor buy-in and adoption curve suggest we're well past the experiment stage and into "how do we build on it well?" territory.

The security concerns are real and worth taking seriously — there have been genuine incidents (token leaks, RCE bugs in third-party servers, supply chain risks). The governance model through the Agentic AI Foundation is the right structural response, but it'll take time to mature. The performance costs (context bloat from large tool manifests, double-hop latency) are real architectural constraints worth understanding before you design an agent that chains 10 MCP calls in a row. MCP's spec defines protocol-level errors and tool-result errors (including isError on tool results), but higher-level conventions — version compatibility, deployment lifecycle, operational semantics across servers — are still maturing.

There's also a longer-term open question worth sitting with: as models become more capable and autonomous, the need for structured tool discovery may diminish. A sufficiently smart agent might navigate tool surfaces the way a good engineer navigates a new codebase — by reading, probing, and figuring it out. MCP is the right answer for the models we have today. Whether it's the right answer for the models we'll have in five years is genuinely uncertain.

But those are the problems you have after a standard wins. They're much better problems than the ones you have when everyone's building incompatible solutions to the same engineering problem.

Six MCP servers running, and I barely think about it. A year ago, that would have been six custom integrations. The boring infrastructure winning is usually how this ends.