What is MCP? The Model Context Protocol, explained

The one-sentence version

The Model Context Protocol - MCP - is an open standard that lets an AI application connect to outside systems: your files, your database, your calendar, your accounting software, a code repository. Instead of an AI that can only talk about your data, you get an AI that can actually read it and act on it.

The protocol's own documentation offers the shortest explanation: think of MCP like a USB-C port for AI applications. USB-C gave every gadget one connector instead of a drawer full of proprietary cables. MCP gives every AI application one way to plug into every tool, instead of a custom integration for each pair.

The problem it solved

Before MCP, connecting an AI to a data source meant writing a bespoke connector for that exact pair. Want Claude to read your Google Drive? Custom code. Want ChatGPT to check your inventory database? Different custom code. Want either of them to also see your CRM, your calendar, and your project tracker? More custom code, each one its own little project with its own auth handling and its own bugs.

The math is what made it unsustainable. If you have M AI applications and N tools they might need, that is M times N integrations to build and maintain - a connector for every combination. A shared protocol collapses that to M plus N: each AI app implements MCP once as a client, each tool implements it once as a server, and every combination works. That is the entire trick, and it is the same trick every successful standard has ever pulled.

What came before: the plugin era

MCP was not the first attempt at connecting AI to the outside world, and knowing what it replaced explains why it won. In March 2023, OpenAI launched ChatGPT plugins - third-party services publishing a manifest file that told ChatGPT how to call their APIs. It worked, but it was strictly a ChatGPT feature: the manifest format, the review process, the whole ecosystem belonged to one company's product. Plugins were quietly deprecated in favor of custom GPTs and their "Actions" within about a year.

June 2023 brought function calling to the OpenAI API - the model outputs structured JSON saying which function to call and with what arguments. Every lab shipped its own version of the same idea, which solved the output format but not the wiring: you still wrote, hosted, and maintained every integration yourself, and a tool built for one vendor's schema did nothing for another's. MCP is what happened when someone finally standardized the plumbing instead of the product.

How it started: November 2024

Anthropic open-sourced MCP on November 25, 2024. It was created inside the company by engineers David Soria Parra and Justin Spahr-Summers, and launched with three pieces: the protocol specification and SDKs, MCP server support inside the Claude Desktop apps, and an open-source repository of reference servers for systems like Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer.

Anthropic's stated motivation was that even the best models were isolated from the data they needed - every new source meant another custom integration, so truly connected assistants could not scale. Early adopters were mostly developer tools: Block and Apollo on the company side, and coding tools like Zed, Replit, Sourcegraph, and Codeium wiring it into their agents.

Worth pausing on: Anthropic gave it away. The spec was published openly, the SDKs were open source, and the servers repo was public. There was no Claude-only licensing hook, which is a large part of why what happened next was possible.

The unusual part: the rivals adopted it

Standards fail for a simple reason: the company that invents them keeps control, so competitors refuse to touch them. MCP dodged that. On March 26, 2025, OpenAI CEO Sam Altman announced on X that OpenAI would support MCP across its products - a competitor formally adopting Anthropic's standard, starting with the Agents SDK and rolling into ChatGPT and the Responses API. Google's DeepMind followed within days, announcing MCP support for Gemini.

That is the moment MCP stopped being an Anthropic feature and became industry infrastructure. When the three major model labs all implement the same connector format, every tool builder only needs to build one server to reach all of them - and the network effect runs itself.

How it works: host, client, server

The architecture has three players. The host is the AI application you actually use - Claude Desktop, ChatGPT, an editor like VS Code or Cursor. Inside the host, a client is created for each connected server, holding one dedicated connection. The server is the program that exposes a system's data and actions - a filesystem server, a Postgres server, a Sentry server.

So when VS Code connects to both a local filesystem server and Sentry's remote server, it spins up two clients with two dedicated connections. Each server does one job and describes its capabilities when asked, so the host always knows what is available on each connection.

What a server can offer: tools, resources, prompts

MCP defines three primitives a server can expose. Tools are executable functions - things the AI can do, like querying a database, creating a calendar event, or sending a Slack message. Resources are readable data - file contents, database records, API responses the AI can pull in as context. Prompts are reusable templates that structure interactions, so a server can ship the right way to ask for its own features.

The client discovers them dynamically: it asks the server for its list of tools or resources, then calls what it needs. A database server might expose a query tool, a resource describing the schema, and a prompt template with examples - the model gets capability, context, and usage hints from the same connection.

Servers can also ask questions back. A primitive called elicitation lets a server request missing input from the user mid-task - useful when a tool needs a date range or a confirmation the model cannot guess.

Local and remote servers

Servers come in two flavors depending on where they run. Local servers launch as a process on your own machine and communicate over standard input/output - fast, no network involved, and the right choice for things like reading your local files or a development database.

Remote servers run on someone else's infrastructure and speak Streamable HTTP - normal HTTP requests with optional server-sent events for streaming. This is how you connect Claude or ChatGPT to a SaaS tool like Sentry or Notion, and it is where authentication matters: the spec recommends standard OAuth, the same sign-in-and-grant-access flow you already use when an app asks to access your Google account.

Underneath both transports the message format is identical - JSON-RPC 2.0, a boring, well-understood RPC standard. Boring is a compliment here: nothing exotic to learn, and the same payloads work whether the server is a subprocess or a datacenter away.

A real exchange, step by step

It helps to see the actual conversation between client and server, because it is simpler than the architecture suggests. When a host connects, it sends a discovery request asking the server what it is and what it can do: the protocol versions it speaks, the capabilities it offers, its identity. The client then asks for the available primitives - tools/list returns each tool's name, a natural-language description, and a JSON Schema for its inputs.

Those descriptions flow into the model's context, which is how the AI "knows" the tools exist at all. When you ask for something that needs one, the model emits a tools/call request with arguments matching the schema, the server executes it - reading the file, running the query - and returns the result, which lands back in the model's context as ground truth to answer with. Discovery, listing, calling, results: four verbs cover most of the protocol. The statelessness matters here too - every request carries its own version and capability metadata, so the server never has to remember what the last request established.

What using it actually looks like

The abstract picture gets clearer with real setups. Connect Claude Desktop to the filesystem and Google Drive servers, and it can summarize documents that actually exist on your machine rather than ones you pasted in. Connect an editor like VS Code or Cursor to Sentry's MCP server, and the coding assistant can read real stack traces and error reports while it writes the fix - not a description of the error, the error.

A Postgres MCP server lets an assistant answer questions straight from a database - show me last month's orders, which customers have not reordered - with the query executed against real tables. Hook up a calendar and an inbox and the assistant stops advising you to check your schedule and just checks it. Every one of these existed before as a pile of custom glue code; now each is a config entry pointing at a server someone else maintains.

A workflow end to end

To make it concrete, take one mundane business task: "put together my Monday morning brief." With four servers connected - calendar, email, the company database, and Slack - a single request can fan out across all of them: the client asks each server what it offers, the model calls the calendar tool for this week's meetings, queries the database for new orders and open quotes, scans the Slack server for threads waiting on a reply, and writes the digest.

Nothing about that brief is exotic AI - each step is a lookup any staff member could run. What changed is that the assistant executes the whole chain in one request, with your approval checkpoints in between, instead of you copying numbers between five tabs. The time saved is real but modest; the interesting part is that the wiring to do it is a configuration file, not a development project.

The scale it reached

The adoption numbers moved fast. Anthropic reported more than 97 million monthly SDK downloads across Python and TypeScript alone by the end of 2025, with official SDKs in every major language. Claude's own connector directory lists over 75 integrations, and an official community Registry catalogs public servers - you can browse it the way you would a package index.

On the client side, support now spans Claude, ChatGPT, VS Code, Cursor, Windsurf, Zed, and a long tail of smaller tools. For a developer the conclusion writes itself: build one MCP server for your product and it becomes reachable by essentially every major AI application at once.

MCP is not a replacement for APIs

A common confusion worth clearing up: MCP does not replace the APIs your tools already have - it wraps them. A well-built MCP server is a translation layer: it exposes the same capabilities the underlying API offers, but describes them in the standard format any MCP client can understand and call.

That distinction matters practically. A tool with a clean, well-documented API is a short step from a good MCP server. A tool with no API, or a hostile one, is a much longer step. Which is why, when you are choosing software you will live with for years, the quality of its API now decides more than it used to - it determines whether the tool can join this ecosystem at all.

The security question, honestly

Connecting an AI to real systems creates real attack surface, and researchers found it quickly. In April 2025, security firm Invariant Labs published research on what they called tool poisoning attacks: a malicious MCP server can hide instructions inside its tool descriptions - invisible to the user, visible to the model - that steer the agent into exfiltrating files or hijacking other tools. Their follow-ups demonstrated rug pulls, where a benign-looking server swaps its tools for malicious ones after you approved it, and shadowing, where one server's tool description quietly overrides another trusted server's behavior.

These are not theoretical - OWASP documents the attack class, and a real CVE (CVE-2025-54136) was assigned in July 2025 for the rug-pull pattern in a production AI environment. Lab benchmarks showed the attacks succeeding more often than not against unguarded setups.

The defenses are mostly discipline, not new technology: only connect servers you trust, prefer official servers from the registry over random GitHub finds, keep human approval enabled for anything that changes data or sends anything anywhere, use OAuth-scoped permissions instead of all-powerful keys, and scan configurations with tools like mcp-scan that look for poisoned descriptions. An agent that can read files and send messages is powerful precisely because it can do damage - grant it the same care you would grant a new employee with database access.

The honest limitations

Separate from attacks, the protocol has plain engineering limits worth naming. Context bloat is the big one: every connected server's tool descriptions occupy space in the model's context window, and a setup with thousands of available tools crowds out the actual work. That problem got large enough that Anthropic shipped Tool Search and programmatic tool calling - features that let clients discover and invoke tools without loading every description at once - specifically to serve production deployments at scale.

Quality variance is real too. The registry lowers the barrier to publishing a server, which means maintenance quality ranges from excellent official servers to weekend experiments that break quietly. A local stdio server is, by definition, arbitrary code running on your machine - treat installing one like installing any other software, because that is what it is. Remote-server authorization has matured with OAuth in the spec, but the ecosystem still spans servers that implement it well, partially, and not at all.

And a gentle note of historical humility: standards have a way of spawning competing standards, and MCP itself only settled the connector layer because the major labs agreed to it. The donation to a neutral foundation was partly an answer to that risk - governance designed so the standard outlives any one company's incentive to keep it open.

MCP vs WebMCP: two ends of the same idea

If you have read our PageSpeed Insights article, you have met WebMCP - the browser-side proposal that lets a website declare its forms and tools so AI agents can use them directly. The two are easy to confuse and worth separating.

MCP connects an AI application to servers of tools and data - it lives on the agent's side. WebMCP lets a website announce what agents can do on it - it lives on the site's side. The same site could expose a Supabase-backed API through an MCP server for agents that speak MCP, and register WebMCP tools for agents arriving in a browser. Complementary ends of one bet: that software will increasingly be used by agents, not just people.

The sibling standards: A2A and AGENTS.md

MCP did not become the whole answer by itself - it sits in a small family of complementary standards. The closest sibling is A2A, the Agent2Agent protocol Google launched in April 2025 and donated to the Linux Foundation that June. The boundary is clean: MCP is agent-to-tool - how an agent reaches capabilities and data. A2A is agent-to-agent - how independent agents discover each other and delegate work. Their own docs put it plainly: equip agents with MCP, communicate with A2A.

The third piece is humbler: AGENTS.md, a convention for a plain Markdown file in a repository that tells AI agents how the project works - how to build it, test it, and what conventions to follow. No protocol at all, just a README written for a machine audience. All three now live under Linux Foundation governance, which is the tidy end-state: tools, agents, and repositories each with a vendor-neutral standard.

How the spec has matured

The specification is versioned by date rather than semver, and the release cadence tells the story of a standard hardening in public. The launch spec in November 2024 defined the core: JSON-RPC messaging, the three primitives, and a local stdio transport plus an early HTTP option. The March 2025 revision landed in the same week OpenAI adopted the protocol, replacing the clunkier HTTP-plus-SSE transport with Streamable HTTP and beginning the OAuth authorization work remote servers needed.

June 2025's revision added the features production deployments were asking for: structured tool output so results are machine-readable, resource links in tool responses, elicitation so servers can ask users for missing input, and the OAuth resource-server classification that sharpened the security model. The November 25, 2025 release - exactly a year after launch - added asynchronous operations for long-running tasks, formal statelessness, server identity verification, and an official extensions mechanism. The latest revisions have started pruning too: sampling, an early client-side primitive for server-initiated model calls, is deprecated as of the 2026-07-28 spec.

Where the standard is heading

The most visible extension so far is MCP Apps, which lets a server return an interactive interface instead of plain text - so a booking tool can render an actual date picker inside the AI app rather than asking you to type a date. On the scale side, Anthropic shipped Tool Search and programmatic tool calling so clients can handle thousands of available tools without drowning the context window. The direction is clear: richer interactions on one end, enterprise plumbing on the other.

Who owns it now

In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a new directed fund under the Linux Foundation - the same neutral steward behind Linux, Kubernetes, and Node.js. The foundation was co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg; Block's goose agent framework and the AGENTS.md convention joined as sibling projects.

For anyone building on the standard, that is the strongest possible signal. The protocol's future is governed by a vendor-neutral body, not by the fortunes or politics of any single AI company - the same arrangement that made the web's own standards durable.

Building your own server

If a system you own needs to be reachable by agents, the build is smaller than it sounds. Official SDKs exist for every major language - TypeScript, Python, C#, Java, Kotlin, Swift, Rust, Go, and more - and a tool is essentially a function plus a name, a description, and a JSON Schema for its inputs. The hard parts are design questions, not code: which operations are safe to expose, what the descriptions should say, and how much access a caller should get.

The tooling around it is mature already. The MCP Inspector gives you an interactive workbench for poking a server during development, the official Registry is where finished servers get listed for discovery, and the community maintains reference implementations worth reading before writing your own. For a SaaS product or an internal tool, publishing one MCP server is the difference between "AI apps can work with this" and a paragraph in a features page claiming they could.

What it means if you are having something built

You do not need to understand JSON-RPC to benefit from this. The practical takeaway is simpler: the software world is reorganizing around the assumption that AI agents will be real users of your systems. When your bookings, inventory, or customer records sit behind clean, well-structured APIs - like the ones a Supabase backend gives you - your systems can plug into that world the moment a server exists, rather than being rebuilt for it later.

This is part of how we think about builds now: structured data, real APIs, machine-readable surfaces. It is the same instinct behind the agent-readiness audits in our Lighthouse work and the architecture of the projects in our portfolio. If you want to talk through what that looks like for your platform, book a call.