MCP Explained: How AI Models Talk to Your Tools (and What Shipped in 2026)

MCP (Model Context Protocol) is an open protocol that defines a standard way for AI models to connect to external tools, data sources, and services. Instead of writing bespoke integrations for every model-tool combination, you implement one server that speaks MCP and it works with any host that speaks the same protocol: Claude Code, ChatGPT, Cursor, or whatever comes next.

That's the direct answer. The longer version is worth reading if you're building anything that plugs an AI into the outside world, because the spec finalised on July 28, 2026, and several things changed in ways that matter for how you deploy and secure MCP servers.

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 MCP 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.

When you're thinking about how MCP fits into AI agent workflows (the mechanics of why the model can execute a multi-step task at all), it helps to understand how an LLM actually reads a prompt at the token and attention level. The context that comes back from an MCP tool call is just more tokens, and the model reasons over them the same way it reasons over everything else.

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 matters a lot more now that the finalised spec made the protocol core stateless (more on that in a moment).

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:

{  "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:

{  "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 now 2026-07-28) rather than semver.

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 actually shipped in the July 2026 spec

The spec revision that locked in May 2026 finalised on July 28, 2026. As of September 2026, this is the current stable revision. Four changes stand out.

The protocol core went 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. 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 got stricter. Six proposals tightened 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. This matters for security governance: the question of what permissions a connected server actually has is now more formally defined, even if enforcing least-privilege still sits with whoever deploys the server. If you're thinking through the governance implications of agentic tools that can act on your behalf, the AI liability post covers what "the AI did it" means legally when an action goes wrong.

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.

How MCP fits into agent development

If you're building a proper development workflow around AI coding agents (not just ad-hoc prompting but a repeatable process with specs, tests, and governed deployments), MCP servers are typically how you give the agent access to external state. The development harness post covers how to structure that pipeline with skills, change control, and verification gates. The key thing MCP adds to that picture is a standardised way to give an agent access to external systems without writing bespoke integration code every time.

The architectural principles that make codebases easier for AI agents to work in safely, particularly SOLID principles applied to agentic code, matter here too. An MCP server with a narrow, single-responsibility interface is easier to reason about and audit than one that conflates ten unrelated operations into a single tool schema.

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 2026-07-28 revision is live, the stateless core is shipping, and anyone building hosted MCP infrastructure now has a stable target to design to.

FAQ

What does MCP stand for?

Model Context Protocol. It's an open protocol for connecting AI models to external tools, data sources, and services via a standardised JSON-RPC 2.0 interface.

Is MCP the same as a function-calling API?

Not quite. Function calling is a feature of a specific model's API (OpenAI's, Anthropic's, etc.) where you define tool schemas inline per request. MCP is a separate protocol layer that sits between the host application and a tool server. The host translates MCP tool results into whatever function-calling format the underlying model expects. The benefit is that you write the server once and it works across any MCP-speaking host, regardless of which model is under the hood.

What's the difference between an MCP tool, resource, and prompt?

• Tool: a function the model can call (create a PR, run a SQL query, send an email). The model decides when to call it; the server executes it.
• Resource: addressable data the host can pull into context (a file path, a database schema, a document). Unlike tools, resources are read-only and the host decides when to load them.
• Prompt: a reusable, user-triggered instruction template the server ships alongside its tools. Useful for complex, parameterised prompts that benefit from being versioned and distributed with the server.

What happened with the July 2026 spec revision?

The 2026-07-28 revision finalised on schedule. The headline changes were: a stateless protocol core (no more sticky session requirements), a new opt-in Extensions mechanism (first two extensions: MCP Apps and Tasks), tighter OAuth 2.0/OIDC alignment for authorisation, and a formal deprecation policy with a minimum twelve-month window before removals. The spec is now at modelcontextprotocol.io/specification/2026-07-28.

Who governs MCP now?

As of December 2025, MCP is governed by the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation. The Technical Steering Committee includes Anthropic, OpenAI, Microsoft, Google, and Amazon. Anthropic donated the spec to the foundation alongside Block's goose and OpenAI's AGENTS.md. It is not yet a formal IETF standard, though the IETF is the most likely eventual destination given the protocol sits on JSON-RPC over HTTP.

Is MCP secure to use?

MCP servers can be a significant attack surface. A server with write access to your production database and your email is a very attractive target. The July 2026 spec tightened OAuth 2.0 and OIDC alignment, but protocol-level auth is only part of the picture. Least-privilege scoping (giving each server only the permissions it needs), running servers you actually trust, and maintaining a human review gate before consequential actions all matter. The spec now defines the auth primitives more clearly; enforcing sensible scopes is still on whoever deploys the server.

Can I run my own private MCP server?

Yes, and for anything touching internal systems you almost certainly should. The stdio transport is the simplest path: your host application spawns the server as a local subprocess, and communication stays entirely on your machine. Remote servers use Streamable HTTP and require you to handle auth. The stateless core in the 2026-07-28 revision makes remote deployment behind a standard load balancer straightforward for the first time.

Further reading

• Specification (2026-07-28): the current stable spec text
• modelcontextprotocol/modelcontextprotocol on GitHub: spec source, schema, and release history
• 2026 MCP Roadmap: the four priority areas driving 2026 proposals
• The 2026-07-28 Release Candidate: details on the stateless core, Extensions, and auth changes
• MCP joins the Agentic AI Foundation: the governance handover from Anthropic to the AAIF
• Anthropic's announcement of the donation
• AAIF Technical Steering Committee: current member list and charter

Worth watching that changelog directly rather than trusting a blog post, mine included, to stay current for long. I'll probably be back here in six months telling you which of these bets I lost.