What Is an MCP Server and How It Works

Before MCP, every AI app that wanted to touch a database, a file system, or a SaaS tool had to build its own connection to it. No shortcuts. If you had N AI applications and M data sources, you needed N×M custom integrations, and each one came with its own maintenance schedule, its own auth logic, its own documentation nobody read until something broke.

Add one new AI tool to your stack, and you rebuilt connections to every data source you already had. Add one new data source, and you touched every AI app already in production. This wasn't a gap you could patch with better tooling. It was a structural problem, and it only got worse as more AI applications entered the picture.

Anthropic released the Model Context Protocol in November 2024 to fix exactly this. The idea was simple: collapse N×M custom integrations into one reusable interface. Build a server once, and any compliant AI application can use it. In December 2025, Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation, handing long-term stewardship of the protocol to a neutral body rather than keeping it under one company's roof. That move signals something: this isn't a side project anymore. It's infrastructure.

Understanding what MCP replaced is the fastest way to understand how it works, and where it breaks. That's what this piece walks through.

What an MCP server actually is

An MCP server is a small application that exposes data, tools, and functionality to AI models through the MCP protocol. Picture it sitting between an AI model and the outside world, whether that's a database, an API, a SaaS platform, or a file system, translating requests back and forth in a format the model can actually act on.

The server isn't the AI. It's the interface that makes the AI useful once it steps outside its own context window.

One detail worth sitting with: MCP servers describe themselves. They advertise their own capabilities, so an AI model can figure out what a server can do without anyone hardcoding that knowledge into the model ahead of time. That's what makes MCP a protocol, not a product. Any server that follows the spec works with any host that follows the spec, no matter who built either one.

The adoption numbers back up how far this has spread. As of April 2026, the Linux Foundation reports 97 million monthly SDK downloads across Python and TypeScript combined, and more than 10,000 active public MCP servers. Over 100 enterprises have joined the Agentic AI Foundation as supporters. This is well past the experimental stage.

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

MCP has three roles, and mixing them up will confuse you fast.

The host is the AI application or environment where the user actually works: an IDE, a chat interface, an agent runtime. This is where the large language model lives, and where the person sits down and starts typing.

The client lives inside the host. Its job is managing the connection to one specific MCP server on behalf of the model. Think of it as the go-between.

The server is the external service providing context, data, or executable capability. It never contains the model itself; it just answers to it.

A host can talk to multiple servers at once, and it does this by spinning up a separate client connection for each one. Each of those connections stays isolated. Capabilities and security boundaries from one server don't spill over into another by default, which matters a lot once you start thinking about governance. You can apply permissions, set audit scope, and lock down access at the level of a single connection, not the whole system.

A useful way to hold this in your head: the host is the employee, the client is the badge reader, the server is the room behind the door. The badge reader only ever handles one door at a time.

What MCP servers expose: tools, resources, and prompts

Servers offer three kinds of capability, and each one carries a different level of risk.

Tools are executable functions the model can call on its own. Query a database, open a GitHub issue, update a Salesforce record, kick off a workflow in Workday: these are all tool calls. They're defined using JSON Schema, so the model knows exactly what inputs it needs to supply. And critically, the model decides when to invoke a tool. Nobody has to tell it "do this now" in the moment. That autonomy is exactly why tools carry the highest risk in the whole system: the effects are real, and sometimes they can't be undone.

Resources expose data: files, API responses, database query results. They're read-oriented. The application decides how that data gets used, whether it's passed straight to the model, searched with embeddings, or filtered down first. Lower risk than tools, since nothing gets executed, but it's still a door into your data, and it needs to be scoped carefully.

Prompts are structured templates for interaction patterns. They need explicit invocation from a user; nothing about them fires automatically. Of the three, prompts carry the least autonomy and the most predictable authorization boundary.

Here's the part people miss: these three categories are not interchangeable, and a security policy built for prompts will fall flat the moment you apply it to tools. Worth adding one more wrinkle: a server's capability list can change depending on who's authenticated. Two users hitting the same server might see two different sets of tools. That's exactly where identity-aware access control stops being a nice-to-have and starts being the thing holding the whole system up.

How communication works between client and server

Every message between client and server travels as JSON-RPC 2.0. Two transport methods are in current use.

Standard input/output, or stdio, works for local servers. It's synchronous and fast, the right pick when client and server sit on the same machine.

Streamable HTTP is the recommended transport for remote servers as of the June 2025 spec revision. It runs on standard HTTP infrastructure, so load balancers, CDNs, and proxies all just work. If you came across older MCP documentation describing HTTP+SSE as the transport, know that it was deprecated in the March 2025 revision and fully removed by June 2025.

Before any of this exchanges real data, client and server run through a handshake. The client sends an initialize request. The server answers with its capability listing, meaning whatever tools, resources, and prompts it currently exposes. The client then sends a notifications/initialized message to confirm it's ready to go. Nothing meaningful happens on either side until this handshake wraps up.

Here's the detail that matters most for security: a server can update its tool definitions after the handshake completes, and it doesn't have to tell the client. Most clients don't catch this. It's not a bug in any one implementation; it's how the protocol was built. At small scale, that's a minor quirk. At enterprise scale, with thousands of servers and no one watching every update, it becomes a real opening for attack, which I'll get to shortly.

What real enterprise deployments actually use MCP for

Walk into most enterprise MCP deployments and you'll find the same categories showing up again and again: file system access, database queries, code repository management, calendar and scheduling, internal chat platforms.

The interesting stuff happens when these connect across systems. A customer support agent looks up an account, opens a ticket, and processes a refund, all across separate backend systems, in one session. An HR agent kicks off an approval chain directly in Workday. An engineering agent reads a Slack thread, opens a GitHub issue, and writes up a Jira ticket, no human copying and pasting between tabs.

MindStudio's research found companies implementing MCP saw a 30% cut in development overhead and 50 to 75% faster completion on AI-assisted tasks. That tracks with the whole point of the protocol: fewer integration seams means less engineering time spent gluing systems together, and more time spent on the actual work.

Gartner projects that up to 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from under 5% at the time the projection was made. As that number climbs, the volume of MCP connections running inside enterprise environments climbs right along with it. MindStudio also found that over 70% of organizations plan to roll out MCP-compatible systems within two years. This isn't a pilot-stage technology anymore; it's moving into production, and it's moving fast.

The security threats that emerge when agents operate through MCP at scale

Here's where the story turns. MindStudio's research found that 7.2% of MCP servers carry security vulnerabilities, and the count of publicly exposed servers nearly tripled to 1,467, with 492 of those lacking basic authentication or encryption entirely. The Cloud Security Alliance logged more than 30 CVEs in the first two months of 2026 alone. That's not a fluke; it's what you get when a protocol this rich in permissions gets deployed faster than the governance around it can catch up.

Tool poisoning is the structural attack everyone in this space now has to think about. Invariant Labs first disclosed it in April 2025. The mechanic is simple and nasty: tool descriptions get fed straight into the model's context window, and an attacker can bury malicious instructions inside those descriptions. Most users never see the full tool description in the interface, so the model just carries out the injected instruction, invisibly, without anyone noticing. The MCPTox benchmark tested 45 live MCP servers and 353 real tools against poisoned descriptions, and found attack success rates above 60% across popular agents, topping out at 72%.

The counterintuitive finding here is worth sitting with. More capable models often did worse, because their stronger instruction-following made them more likely to comply with malicious metadata baked into a tool description. Claude-3.7-Sonnet refused poisoned tool calls less than 3% of the time in that study, which, oddly, was the best result on the board. Two CVEs, CVE-2025-54136 and CVE-2025-54135, formalized two variants of this attack in 2025.

Then there's the rug pull. A server behaves well when it's first installed, earns trust and permissions over time, and then a later update quietly changes what it does. Since servers can update their tool definitions without notifying the client, and most clients never catch it, this slips through easily. Invariant Labs built a proof-of-concept in 2025 where a malicious MCP server, sitting in the same agent context as a legitimate WhatsApp server, silently read and exported a user's full message history. No user error involved. No network exploit needed. Just proximity and trust.

CVE-2025-6514 is the largest confirmed incident tied to MCP so far, affecting more than 437,000 downloads through a single npm package called mcp-remote. It carries a CVSS score of 9.6, about as critical as these ratings go. The flaw: an OAuth proxy blindly trusted whatever authorization endpoint a server handed it. A malicious server returned an endpoint containing a shell command injection, and the proxy passed it straight to the system shell. The result was arbitrary remote code execution, running with the user's own privileges, triggered by what looked like an ordinary OAuth login.

Cross-tenant leakage isn't hypothetical either. In June 2025, Asana launched an MCP-powered feature and then discovered a bug letting customer data bleed across separate customers' MCP instances. They pulled the integration offline for two weeks to patch it. This happened at a well-resourced company, in a production system, not a lab demo.

Tool shadowing rounds out the list: an attacker registers a tool with a name almost identical to a legitimate internal one, and if the model's router picks the shadowed tool instead, sensitive inputs go straight to the attacker's endpoint. And on the supply chain side, the first malicious MCP package showed up in public registries in September 2025. Typosquatting and fake "official" servers are active patterns now. Any team pulling servers from public registries without vetting them first is exposed to exactly this.

Why authentication is the unresolved load-bearing problem

Conventional software authenticates a human against a system. You prove who you are once, you get a session, you go about your work.

Agentic MCP deployments break that model, because the agent acts on its own, often across several systems, frequently with no human anywhere near the moment of action. Authentication has to stretch down to machine-to-machine, at the depth of an individual tool call, not just at login.

The MCP spec lays out how OAuth is supposed to work inside the protocol, but leaves the actual implementation up to each server. CVE-2025-6514 is what happens when that implementation goes sideways.

Then there's credential sprawl. Every MCP server connection can demand its own set of credentials, and without a central place to manage them, those credentials end up scattered: environment variables, config files, agent memory. All places a rug pull attack or a supply chain compromise can go digging.

Identity has to travel with the action. If an agent calls three tools across two different MCP servers in a single session, the audit log needs to show which user's identity authorized each individual call, not just that "the agent did something." K2view's research found that 45% of organizations say they're focused on production or scale for generative AI in 2026, yet 76% cite guardrails and 62% cite data readiness as real constraints. Read that together and it says something plain: most organizations are scaling straight into governance gaps, not past them.

Securing the server alone doesn't fix this. Identity has to run through the host, the client, and the server, at every single step, or the whole chain is only as strong as its weakest handoff.

What governance and audit requirements look like when agents act through MCP

When an agent calls a tool, something real happens: a record gets updated, a file gets touched, a message goes out. Organizations need to be able to reconstruct, after the fact, who authorized it, what went in, and what came out.

Standard audit logs were built to record human actions. MCP-mediated agent actions happen at machine speed, across multiple servers, frequently with zero human touchpoint at the moment of execution. That's a mismatch, and it shows up in three specific gaps that ordinary logging doesn't cover.

First, tool-call depth visibility: knowing not just that an agent ran, but exactly which tool it called, on which server, with what parameters. Second, identity binding: tying every single tool call back to the human whose permissions actually authorized it, not just to the agent's service account. Third, tamper-proof records: logs that can't be edited after the fact, which matters a great deal for any compliance framework demanding immutable evidence.

Policy enforcement needs to reach down to that same tool-call depth. An organization needs to say, plainly, "this role can call read tools on the CRM server, but not write tools," and have that rule enforced at the protocol level, not bolted on as an application-layer guardrail that a clever prompt can talk around.

Intent drift deserves its own mention here, because it's a risk that's specific to this kind of system. An agent gets authorized for one task, and over the course of a session it gradually widens its own tool usage in ways nobody explicitly signed off on. Nothing malicious has to happen for that to be a problem. The agent is just doing its job a little too broadly, and if nobody's watching at the tool-call level, nobody notices until the scope has already crept well past where it started.