What Is an MCP Server and What Does It Actually Do

Every AI model that needs to check a database, send an email, or read a file used to need its own custom connector to do it. MCP exists to kill that requirement: it's the piece of infrastructure that gave AI models a shared, standard way to reach into the outside world, instead of forcing every developer to write bespoke glue code for every combination of model and tool. This piece walks through what the protocol actually is, how its architecture divides responsibility, and why the same eighteen months that produced explosive adoption also produced a security record the industry hasn't reckoned with yet.

Before Anthropic published the Model Context Protocol in November 2024, the actual state of affairs was worse than most people remember. A team wanting one model to query a relational database wrote one integration. A team wanting a different model to do the same thing wrote a different one, because no shared interface existed between a model and the tools it needed. Anthropic has a name for the resulting mess: the N×M problem: N tools and M model front-ends each needing to talk to each other, so the number of custom connectors required grows combinatorially. Ten tools and five models means 50 integrations, each with its own auth flow, its own schema, its own way of failing at 2am.

Partial fixes existed before MCP: plugin systems, vendor-specific tool-calling formats. But they solved the problem for one vendor at a time, so the fragmentation just moved instead of disappearing. Developers spent real hours maintaining connectors instead of building the capability those connectors were supposed to support. Tool invocation behaved differently depending on which model was calling it, and because every vendor defined its own schema conventions, tool-use behavior didn't transfer cleanly between systems. MCP collapses that combinatorial explosion into a much smaller, additive set of connections: one protocol, and every tool or model that implements it can talk to every other one.

What MCP is: a protocol, not a library

MCP is a specification. Not an SDK, not a framework, not something to install. The closer comparison is REST or GraphQL: an agreed-upon shape for a conversation, not a piece of software that does the talking for you.

More specifically, it's an open, evolving JSON-RPC-based standard that lets any AI application discover tools, reusable prompts, resources, and other context from a remote server, then invoke them through a structured session. Anthropic published the spec in November 2024 and maintains it openly on GitHub. A protocol that only one company controls functions as a product with a generous API and a company that can change the terms whenever it wants, which affects how much any adopter can rely on its rules staying fixed. It's a product with a generous API and a company that can change the terms whenever it wants.

The governance handoff in December 2025 made that distinction real. Anthropic transferred governance of MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded alongside Block and OpenAI. Platinum member seats now include Google, Microsoft, AWS, and Bloomberg, on top of the three co-founders. That's a list of companies who compete aggressively with each other everywhere else, agreeing to share governance of the plumbing that runs beneath all of them, because the protocol has gotten too load-bearing for any single vendor to keep steering alone. Moves like that don't happen out of generosity. They happen once a piece of infrastructure has gotten too load-bearing for any single vendor to keep steering alone.

The three-part architecture: host, client, and server

MCP's architecture splits into three roles, and blurring them together is probably the single most common mistake people bring to the protocol.

The host is the AI application itself, the thing a person actually opens and uses, such as a code editor with model features built in, a chat interface, or an agent platform. The host contains the language model and is where the user's intent originates.

The client lives inside the host, and that detail gets skipped over more often than it should. Each client manages a one-to-one stateful session with a specific MCP server. It's the translator: it takes what the model wants to do and turns it into a properly formatted MCP protocol message, then takes the server's response and turns it back into something the model can reason about. One client, one server, one session, no exceptions to that pairing.

The server is the external component doing the actual work: it touches files on disk, a production database, or a third-party API. Tools, resources, and prompts all live here.

A host isn't limited to one client. It can spin up several isolated client instances at once, each with its own session and its own permission scope, so a client talking to a company's Slack workspace doesn't leak context into a client talking to its database instance. All of this rides on JSON-RPC, a deliberate and fairly old-school choice that keeps the protocol language-agnostic and transport-flexible. A server written in one programming language can talk to a client written in another without either side caring what's on the other end of the wire.

The host also acts as gatekeeper. It decides which client gets to invoke which tool, handles whatever authorization and consent the user needs to grant, and aggregates context across multiple server sessions without letting data cross between domains that shouldn't touch. An agent juggling five MCP servers at once needs something that keeps a financial record from bleeding into a customer support ticket just because both happened to pass through the same model context. The host does that job, and if it doesn't do that job well, nothing downstream fixes it.

What an MCP server exposes: tools, resources, and prompts

An MCP server exposes three kinds of primitives, and conflating them is where a lot of confusion starts.

Tools are callable functions: place an order, run a vulnerability check, query the customer database. Each one ships with a name, a description, an input schema, and an output schema, published in a machine-readable manifest. Nobody has to tell the model in advance what a given server can do. It reads the manifest and figures it out.

Resources are things the model reads rather than runs: documents, FAQ files, the contents of a repository, entries in a knowledge base. This is how a model grounds its answers in something more current than its training data, instead of guessing at what changed since the last training cutoff.

Prompts are reusable templates the server exposes, so agents run consistent, admin-approved instructions instead of reconstructing a prompt from scratch every time a task comes up.

The discovery mechanism is what separates this from a traditional API integration. At the start of a session, an agent can ask a server what it can do and get back a full, current manifest of tools and schemas, no hard-coded configuration file required on the client side. When a server is swapped out, or what it exposes is updated, the client picks up the change automatically at the next session.

A tool call follows a fairly predictable loop. The model reads the manifest and plans a sequence of actions. It sends a tool call as a JSON-RPC request. The server executes the logic, whatever that means for that particular tool: querying a backend, fetching a file, hitting a third-party API. The server returns a structured response, the model folds that into its working context, and decides what to do next. Repeat until the task finishes.

That loop answers one of the more persistent complaints about language models directly: hallucination. A model wired to a live MCP server doesn't guess at the current state of a system. It asks, and the response reflects actual state at the moment of the query. That doesn't make the model infallible, nowhere close, but it does close off an entire category of error that used to be baked into how these systems worked.

Transport options and the July 2026 shift to a stateless protocol core

MCP supports two transport mechanisms, and the choice between them tends to map directly onto where the server runs.

stdio has the client spawn the MCP server as a child process and talk to it over stdin/stdout. No network configuration, no infrastructure to stand up, strong process isolation almost for free. It fits CLI tools, desktop applications, and local development: anywhere the server and client live on the same machine.

Streamable HTTP sends JSON-RPC messages over HTTP POST, with the server responding either as a server-sent-events stream or as a plain JSON object. This is what gets through firewalls, load balancers, and CDNs, and it's the only option that makes sense once a single agent backend needs to serve many concurrent client sessions instead of one local process.

The more consequential recent development is the spec revision dated July 28, 2026. David Soria Parra, a technical staff member at Anthropic, has called it the most substantial change to the protocol since authorization support was added, a meaningful claim given how much authorization work MCP has absorbed in its short life.

The 2026-07-28 revision removes the initialize handshake and the session header from the protocol's core, moving MCP toward a stateless design. Teams running MCP servers at scale can retire the sticky-session infrastructure and session stores that a stateful protocol had forced on them. Fewer moving parts to keep synchronized means fewer places for session state to drift or leak, and that matters more than it sounds like it should once you're running thousands of concurrent sessions.

The same revision tightens security in two specific ways. Clients must now validate the iss parameter on authorization responses, as RFC 9207 requires, closing off a class of mix-up attacks where a client could be tricked into trusting a token meant for a different authorization server. And Resource Indicators, defined in RFC 8707, let a client state explicitly which MCP server a given token is meant for, preventing a token issued for one server from being replayed against a different one. Neither fix is flashy. Both are the unglamorous kind of change that makes a protocol actually safe to run in production instead of merely looking like it is.

How fast MCP has been adopted

At launch in November 2024, MCP SDKs were seeing roughly 100,000 monthly downloads. By March 2026, that figure had reached 97 million monthly, a jump of nearly three orders of magnitude in under a year and a half.

The server registry tells the same story from a different angle. Public MCP servers numbered around 1,200 in the first quarter of 2025. By March 2026, the registry had passed 10,000 active public servers. Separately, a GitHub search for repositories tagged mcp-server returned 15,926 results as of May 2026, which says something about how much of this activity happens outside any official registry entirely, in the sprawling, half-documented way most open ecosystems actually grow.

The list of companies that adopted the protocol reads like a rough map of where enterprise AI infrastructure sits today: OpenAI in March 2025, Microsoft in May 2025, AWS building support starting April 2025, and then the December 2025 governance handoff to the Linux Foundation that formalized what had already become a multi-vendor standard in practice. Gartner has projected that 75% of API gateway vendors will ship MCP features by the end of 2026, a projection that matters more than the download numbers. API gateway support signals that MCP has become plumbing that enterprises assume will be there, which carries more weight than download numbers alone. SDK downloads measure enthusiasm. API gateway support measures whether MCP has become plumbing that enterprises assume will be there, the way they assume TCP/IP or OAuth will be there.

What MCP servers do in real production agentic workflows

Agentic, in this context, means something specific: a model reasoning across multiple steps, pulling live data as it goes, triggering real actions based on the current state of real systems, and adjusting its plan as new information comes back from each tool call. It's a description of a control loop that runs without a human deciding each step in advance, not a synonym for automated. It's a description of a control loop that runs without a human deciding each step in advance.

This pattern appears across a fairly wide range of enterprise use cases already, driven by MCP servers replacing custom-built integrations. Integrations with Google Drive, Slack, and Gmail let an AI assistant search documents, manage messages, and automate parts of a workflow through standard MCP servers rather than integrations built and maintained by hand for each service. On the data side, MCP servers sitting in front of PostgreSQL, vector databases, and analytics platforms let business users query in plain language and get automated pipeline construction back, closing a gap that used to require someone who could actually write SQL.

DevOps is where the scale gets genuinely large. Copilots built for engineering teams can connect to many tools spread across Git, CI/CD pipelines, monitoring, cloud infrastructure, and secrets management, each exposed through its own MCP server. Customer support bots follow a comparable pattern on the business side, orchestrating CRM systems, email, order management, a knowledge base, ticketing, and analytics inside a single agent session, often with several tools exposed per server.

The more interesting structural pattern is multi-server orchestration, where the output of one MCP server becomes the direct input to the next. That chaining turns a set of individual integrations into an actual pipeline spanning multiple systems, without a developer writing custom code to bridge each handoff. One internal case cited in industry research gives a sense of scale: over a 30-day window, 93% of one company's R&D organization used AI coding tools, processing 51.47 billion input tokens and 361.12 million output tokens through Workers AI in that same period. Numbers like that make the abstract phrase "AI embedded in engineering" considerably more concrete, and considerably harder to dismiss as a pilot project that never shipped.

The security gap between MCP's growth and production-safe deployment

Traditional API security assumed requests follow predictable patterns a developer defined ahead of time. MCP breaks that assumption on purpose: the entire point of an agent is that it decides, at runtime, which tools to call and in what order, driven by a prompt rather than a fixed code path. That demands continuous authorization thinking instead of a security review done once at build time. The industry hasn't caught up to that demand, and the numbers make the gap hard to argue with.

Most MCP servers running today are not safe to put in front of production data, and the statistics aren't ambiguous about it. Between 24% and 25% of MCP servers currently in the wild run with no authentication. Only 8.5% use OAuth, the mechanism most security teams would treat as table stakes for anything touching production systems. Fifty-eight percent of implementations wrap existing APIs, which sounds efficient until you think through what it actually means: whatever attack surface that underlying API already had gets inherited by the MCP layer sitting on top of it, without necessarily inheriting the protections built around the original API. And 82% of implementations carry path traversal risk, a vulnerability class that predates MCP by decades and, evidently, hasn't gone anywhere just because the interface on top of it got newer.

Roughly half of builders (50%) name security and access control as their single biggest challenge with MCP, and 38% say security concerns are actively holding back further adoption inside their organizations. That's a widely shared worry. That's half the people building on the protocol saying, out loud, that they don't trust their own deployment.

By early 2026, researchers had located nearly 7,000 MCP servers exposed directly on the open internet: unauthenticated, discoverable, callable by anyone who found them. In a single 60-day window, more than 30 CVEs were disclosed against MCP implementations, including CVE-2026-33032, rated at a CVSS score of 9.8, actively exploited rather than sitting as a theoretical risk in an advisory somewhere.

None of that undercuts what MCP accomplished structurally. The N×M problem forced every tool to integrate separately with every model, and the adoption curve says the industry agrees the fix was worth building. But a standard that makes it trivially easy to stand up a server also makes it trivially easy to stand up an insecure one, and the growth numbers from the previous section and the vulnerability numbers in this one describe the same eighteen months from two different angles. One might argue that's the actual story of MCP's first two years: not adoption versus security, but adoption that outran security because nothing in the spec forced the two to move together. Whether the next round of implementations closes that gap, or the ecosystem just keeps compounding both curves at once, remains unanswered.