MCP Explained: How AI Models Talk to Your Tools (and What Comes Next)

Published

15 July 2026

Listen to this post using the player at the bottom of the page.

Right now, in the session I'm using to write this post, I have about fifteen MCP servers wired into Claude Code. GitHub, Gmail, Google Calendar, Google Drive, Vercel, a Mermaid diagram tool. I didn't write a single integration for any of them. I added them, and the model started using them.

That's the whole pitch for the Model Context Protocol in one sentence: it's the thing that let fifteen completely unrelated services plug into an AI assistant without fifteen bespoke adapters. Before MCP, every one of those integrations was a one-off. Custom function schemas, custom auth handling, custom retry logic, all written again for whichever model happened to be calling the shots that week. MCP turned that into a solved problem, and it did it fast enough that I'd bet most developers using AI coding tools today are relying on it without knowing its name.

The problem it actually solves

Before November 2024, if you wanted an LLM to read a file, query a database, or open a GitHub issue, you wrote a tool definition specific to that model's function-calling format. OpenAI's schema wasn't Anthropic's, and neither was Google's. Multiply that by every tool you wanted to connect, and every model you wanted to support, and you had an M×N integration problem: M models times N tools, each pair built by hand.

Anthropic open-sourced MCP in November 2024 to collapse that grid. The idea is boring in the best way: define one protocol for how an AI application talks to a tool or data source, and let anyone implement either side. Write a server once, and it works with any host that speaks the protocol. Build a host once, and it can use any server on the internet.

It worked. OpenAI added MCP support to its products in March 2025. Google DeepMind followed. By the end of 2025 there were reportedly over ten thousand public MCP servers, and it had become the default way agentic coding tools connect to the outside world.

How it actually works

MCP has three moving parts, and the names matter because they show up constantly once you start reading server docs.

Host is the application the human actually uses, like Claude Code, Claude Desktop, or an IDE extension.
Client lives inside the host and manages exactly one connection to exactly one server. If your host is talking to five servers, it's running five clients.
Server is the thing exposing capabilities, wrapping GitHub's API, a Postgres database, or your local filesystem behind a shared interface.

Everything travels as JSON-RPC 2.0 over one of two transports: stdio for a server running as a local subprocess (most CLI-based MCP servers work this way), or Streamable HTTP for a remote server you connect to over the network. That transport choice is about to matter a lot more, and I'll get to why.

How data flows through MCP

One client per connected server, all speaking the same JSON-RPC protocol, so the host never writes custom integration code per tool.

On top of that transport, the spec defines a handful of primitives. Servers expose three of them: Tools are functions the model can call (create a PR, run a query), Resources are addressable data the host can pull into context (a file, a database schema), and Prompts are reusable, user-triggered templates the server author ships alongside its tools. Clients expose the other direction: Sampling lets a server ask the host's own model to generate a completion, Roots tell a server which directories it's allowed to touch, and Elicitation lets a server pause mid-task and ask the human a question before continuing.

A real tool call on the wire is nothing more exotic than this:

json

{  "jsonrpc": "2.0",  "id": 7,  "method": "tools/call",  "params": {    "name": "create_issue",    "arguments": {      "owner": "levi-putna",      "repo": "twistedbrackets.com",      "title": "Add dark mode toggle to nav"    }  }}

The server does the actual work against GitHub's API and replies with a result the model can read as plain content:

json

{  "jsonrpc": "2.0",  "id": 7,  "result": {    "content": [{ "type": "text", "text": "Created issue #42" }],    "isError": false  }}

No magic. The magic, such as it is, is that this shape is identical whether the server wraps GitHub, a weather API, or your company's internal ticketing system, and any MCP-speaking host can drive it.

It's not a standard yet, and that's worth saying plainly

People throw the word "standard" around MCP pretty loosely, including me a paragraph ago. It isn't one, not in the sense that HTTP or TLS are standards. Those went through a body like the IETF: a formal process, multiple independent implementations required before ratification, a version number you can point to and say "this is fixed." MCP is a specification maintained by a foundation that's less than a year old, still versioned by dated revisions (2025-03-26, 2025-06-18, and a 2025-11-25 release that's already being superseded) rather than semver, and still actively rewriting parts of its own core.

That's not a knock on it. It's just the honest state of things. What did happen is real and worth tracking: in December 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation, alongside Block's goose and OpenAI's AGENTS.md. The foundation's Technical Steering Committee now includes Anthropic, OpenAI, Microsoft, Google, and Amazon. That's five companies that compete directly with each other, sitting on the same committee, because none of them wants to maintain a competing protocol and all of them want a say in where this one goes.

That's a meaningfully different governance model to six months earlier, when it was effectively an Anthropic project other companies had adopted. It's also still young. There's no independent ratification body, no multi-year stability guarantee, and the 2026 roadmap is explicit that proposals get fast-tracked or slow-walked depending on whether they match four priority areas the working groups picked for themselves. Call it what it is: a fast-moving, multi-vendor specification with real industry weight behind it, on a path toward becoming a standard, not there yet.

What's shipping right now

This is the part that makes writing this post today, rather than six months ago, worth doing. A release candidate for the next spec revision locked on May 21, 2026, and finalises on July 28, less than two weeks from now. Four changes stand out.

The protocol core goes stateless. Earlier versions pinned a client to one server instance for the life of a session, via an initialize handshake and an Mcp-Session-Id header. That's exactly the kind of thing that forces you into sticky sessions and a shared session store the moment you want to run more than one server instance. Dropping it means a remote MCP server can now sit behind a plain round-robin load balancer, the same way any other stateless HTTP API does. Anyone who's had to fight session affinity in a load balancer config knows why that's worth a spec change.

New capabilities ship as opt-in extensions. Rather than growing the core spec forever, new features now version independently. The first two official extensions are MCP Apps, which lets a server ship a server-rendered HTML interface instead of just plain text or JSON back to the host, and Tasks, which formalises long-running, asynchronous work instead of everyone inventing their own polling convention.

Authorisation gets stricter. Six proposals tighten alignment with OAuth 2.0 and OpenID Connect, including issuer validation and application-type declarations at client registration. Anyone who's stood up a remote MCP server and had to reason about token scopes will recognise why this needed hardening.

Breaking changes now follow a real deprecation policy. Active, then Deprecated, then Removed, with a minimum twelve-month window between them. That's the clearest sign yet that the maintainers know enterprises are depending on this now, not just weekend projects.

Where I think this goes next

Everything above is documented. This part is me, going out on a limb, so take it as opinion.

Remote, hosted MCP servers overtake local stdio servers for anything beyond personal dev tooling within the next year. That's my first bet. The stateless core removes the last real excuse not to run a server as a normal scaled HTTP service, and ops teams will take that trade every time.

MCP Apps, I'd wager, becomes the default way agent products render anything richer than text, and a small ecosystem of shared UI components grows up around it, the same way the web sprouted component libraries once HTML5 gave everyone a shared target. Right now every host builds its own bespoke rendering for every tool's output. That doesn't survive contact with an actual extension built for the job.

Tasks quietly turns into the thing that decides whether MCP or a dedicated orchestration framework owns "real" agentic workflows. If MCP can natively express a job that takes twenty minutes, retries on transient failure, and expires cleanly, a chunk of what people currently reach for LangGraph or Temporal to do stops needing a separate framework at all.

And governance gets harder before it gets easier. Five competing vendors on one steering committee is a recipe for slower consensus, not faster. My bet is the spec cadence stretches out from roughly quarterly to something closer to twice a year within eighteen months, and that within two or three years MCP ends up on a path toward an actual standards body submission (IETF is the obvious candidate, given the protocol is already JSON-RPC over HTTP), the same way WebSocket and other web-era protocols eventually formalised once the informal spec had proven itself at scale.

None of that is set. What is set is that the protocol you're using today through Claude Code, Cursor, or ChatGPT will look different by the end of the month, and materially different in a year.