MCP — the Model Context Protocol — is an open standard for connecting AI applications to the systems where useful work actually happens: file systems, databases, SaaS products, internal APIs. Anthropic open-sourced it in November 2024, OpenAI and Google adopted it within six months, and by the end of 2025 it had been handed to a vendor-neutral foundation. In under two years it went from a lab release to the default answer to a question every AI product had been solving badly on its own: how does a model get at your stuff?
The official docs describe MCP as a USB-C port for AI applications, and the analogy holds up. Before USB-C, every device shipped its own charger. Before MCP, every AI app shipped its own plugin system, and every tool vendor had to integrate with each one separately. MCP replaces that mess with a single protocol: build one server for your data source and it works with every MCP-capable app; build one client into your app and it can talk to every MCP server.
By the end of this post you will know the integration problem MCP solves, how hosts, clients, and servers fit together, what a tool definition looks like on the wire, where servers run and how authentication works, how MCP relates to plain function calling, when to build your own server, and the security posture you should insist on before wiring an agent into anything real.
The N×M integration problem
Count the AI applications that might want access to your data: Claude, ChatGPT, Cursor, VS Code, an internal support bot, whatever agent you deploy next year. Call that N. Now count the systems they need to touch: GitHub, Postgres, Slack, Google Drive, your CRM, your ticketing system. Call that M. Without a shared protocol, full coverage requires N×M bespoke integrations, each with its own auth handling, its own data format, and its own maintenance burden. In practice nobody builds N×M; each vendor builds a handful of flagship integrations and everything else stays disconnected.
This is the same shape of problem code editors once had with programming languages, and MCP borrows its solution directly from the Language Server Protocol, which turned editors-times-languages into editors-plus-languages. With MCP, the person who knows the data source builds one server; the person who builds the AI app implements one client. N×M becomes N+M — and, just as importantly, the integration effort lands with the party best placed to do it. Sentry maintains the Sentry server, your platform team maintains the server for your internal API, and neither needs to know or care which AI app sits on the other end.
Hosts, clients, and servers
The protocol defines three participants:
- Host — the AI application itself: Claude Desktop, Claude Code, VS Code, ChatGPT, or your own agent. The host owns the model, the conversation, and the user relationship.
- Client — a component inside the host that maintains a dedicated one-to-one connection with a single server. A host connected to four servers runs four clients.
- Server — a program that exposes context and capabilities: the filesystem server, the GitHub server, the thing you build for your own database.
Messages between client and server are JSON-RPC 2.0 in both directions, carried over one of two transports. Stdio is for local servers: the host launches the server as a subprocess and talks to it over stdin and stdout, with no network involved. Streamable HTTP is for remote servers: the client sends HTTP POST requests and the server can stream responses back using server-sent events. The messages are identical either way; the transport is just plumbing. The current revision of the specification (2026-07-28, as of this writing) also made the protocol stateless — every request carries the protocol version and capability information it needs — which makes remote servers far easier to scale behind ordinary load balancers.
Tools, resources, and prompts
A server can expose three kinds of things, and the distinction is really about who decides when each one gets used:
- Tools are functions the model chooses to invoke: run a query, create a ticket, search the docs. This is the primitive that gets nearly all the attention.
- Resources are data the application attaches as context — file contents, a database schema, a log excerpt. The model does not fetch these on its own; the host or the user selects them.
- Prompts are reusable templates the user invokes explicitly, typically surfaced as slash commands.
Clients discover everything at runtime through list methods such as tools/list, then act through calls like tools/call — nothing is hardcoded into the host, so a server can add or change tools without any host shipping an update.
What a tool definition looks like
A tool is described by a name, a human-readable description, and a JSON Schema for its input. Here is a complete, representative definition, straight out of a tools/list response:
{
"name": "search_orders",
"title": "Search Orders",
"description": "Search customer orders by text query and optional status filter. Returns the 20 most recent matches.",
"inputSchema": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "Free-text search over order contents"
},
"status": {
"type": "string",
"enum": ["open", "shipped", "cancelled"]
}
},
"required": ["query"]
}
}Two things are worth noticing. First, there is nothing AI-specific here — it is an ordinary function signature in JSON Schema clothing. Second, the description fields are not documentation for humans; they are prompt text. The model reads them to decide when to call the tool and how to fill in the arguments, so vague descriptions produce vague tool use. Writing good tool descriptions is closer to prompt engineering than to API design.
How MCP relates to plain function calling
Every major model API already supports function calling: you send tool definitions with your request, the model replies with a structured call, your code executes it, and the loop continues — the loop at the heart of every AI agent. MCP does not replace or modify any of that. The model API never sees MCP; the host converts each server’s tool listings into whatever format its model expects. What MCP standardizes is everything around the model call — how tools are packaged, discovered, transported, and shared — so that a tool built once is usable from any host instead of being welded into one codebase. Function calling is the calling convention; MCP is the package manager.
Where servers run, and how authentication works
Local servers run as subprocesses on your machine over stdio. They act with your local privileges: the filesystem server reads whatever your user account can read, and a database server connects with whatever credentials you hand it. Those credentials usually arrive as environment variables in the host’s config file — workable for a personal API key, clumsy and hard to audit at team scale.
Remote servers are hosted services, run by the vendor that owns the underlying product. The spec leans on standard HTTP authentication for these and recommends OAuth: the host walks you through a browser consent flow and receives a scoped, revocable token. This is the better model for anything multi-user — no long-lived secrets sitting in dotfiles, permissions scoped to what you actually granted, and the vendor can update the server without anyone reinstalling anything.
The practical reality in 2026 is a mix. Developer workflows still lean heavily on local stdio servers, while popular SaaS products increasingly operate official remote servers. If a server touches production data or acts on behalf of more than one person, prefer the remote, OAuth-gated version.
From lab release to shared standard
Anthropic released MCP as an open-source project on November 25, 2024, with Python and TypeScript SDKs and pre-built servers for systems like Google Drive, Slack, GitHub, and Postgres. Early adopters included Block and Apollo, plus developer tools such as Zed, Replit, and Sourcegraph. A protocol published by one model vendor could easily have died there. It did not.
In March 2025, OpenAI adopted MCP across its Agents SDK, with ChatGPT support following. In April 2025, Google announced it would support MCP in Gemini and its SDKs. Microsoft wired it into VS Code and Copilot. Direct competitors adopting a rival’s protocol is rare, and it is the strongest signal in this whole story: the integration layer is now the same no matter which model wins your bake-off — the criteria in how to choose an LLM are free to change without your integrations changing with them.
The governance followed the adoption. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with Google, Microsoft, AWS, and Cloudflare among the backers. The announcement cited more than 10,000 active public MCP servers and over 97 million monthly SDK downloads across Python and TypeScript. Whatever those numbers are today, the structural fact matters more: no single vendor owns the protocol anymore.
When to build your own MCP server
The default answer is: do not. Check the official reference servers and your vendors’ hosted offerings first — for mainstream products, someone has almost certainly built the integration already, and the official one will track API changes that yours will not.
Building your own makes sense in three situations:
- Internal systems. Nobody else will ever write the server for your company’s admin API or your internal database. This is the overwhelmingly common case.
- The same capability across multiple hosts. If you want one integration available in Claude Code, an internal chatbot, and an IDE, a single MCP server beats three bespoke ones.
- A curated surface. A server can expose five safe, well-described actions instead of a raw API with two hundred endpoints — which is better for both safety and model accuracy.
Conversely, if exactly one application you control needs exactly one integration, plain function calling inside your own agent code is less machinery for the same result. MCP earns its overhead when tools are shared across hosts, not within one. And remember that every tool attached to a conversation rides along in the context window on every request and is billed as input tokens — the pricing mechanics punish bloated tool lists twice, once in cost and once in the model’s focus. Keep the surface small and the descriptions tight.
An MCP server is an access grant
The most useful security framing is this: connecting a server is not installing a feature, it is granting access. Whatever the server can do, the model can now attempt — and models make mistakes, get manipulated, and misread ambiguous instructions. Least privilege is the whole game. Use read-only credentials wherever writes are not needed, scope tokens narrowly, and split high-privilege actions into separate servers you connect only when required.
The sharpest risk is prompt injection. Tools return content the model then reads — web pages, emails, ticket bodies, search results — and that content can contain instructions. A hostile string inside a support ticket can steer a model into calling other tools it has access to. The dangerous combination is well known: access to private data, exposure to untrusted content, and an ability to communicate externally, all in one session. Break at least one leg of that triangle. Keep destructive actions behind human approval, treat everything a tool returns as untrusted input, and log tool calls so you can audit what an agent actually did rather than what you assumed it did.
Bottom line
- MCP is plumbing: an open standard that turns the N×M integration problem into N+M by standardizing how AI apps discover and call external tools, resources, and prompts.
- Hosts run clients; clients hold one connection each to servers; local servers speak stdio, remote ones streamable HTTP with OAuth.
- It complements function calling rather than replacing it — the model API is untouched; MCP standardizes the packaging around it.
- Use existing servers by default. Build your own for internal systems, or when one integration must serve many hosts.
- Treat every connected server as an access grant: least privilege, human approval for destructive actions, and the assumption that anything a tool returns may be hostile.
Protocols win by being boring, and MCP has gotten satisfyingly boring fast: multi-vendor governance, stable primitives, and an ecosystem where the interesting work is what you connect, not how. That is exactly what you want from infrastructure.