What an MCP Server Does in an Agentic Stack

Anthropic introduced MCP in November 2024 as an open standard for connecting AI systems to external tools, data sources, and services. Three roles define the protocol. The MCP client is the AI agent or application that needs information or wants to take action. The MCP server is a lightweight connector that exposes a specific data source or service to any compatible client. The target system is the database, API, file store, or SaaS platform the server wraps.

Here is what that means in practice: agents don't call external APIs directly. They send a structured, abstract query to the MCP server, which handles authentication, querying, formatting, and response normalization. One agent can connect to multiple MCP servers simultaneously, one for a file store, one for a database, one for a project management tool, all through the same protocol.

That design choice matters more than it first appears. MCP separates the agent's reasoning from the integration logic required to fulfill it. The agent doesn't need to know how GitHub's API is structured or what OAuth flow Salesforce requires; the server absorbs all of that complexity. The agent is never required to carry it.

One distinction worth holding onto: MCP functions as the agent's sensory interface to the outside world, while agent skills (the internal procedures an agent follows to reason and act) are its procedural memory. These are complementary, not competing.

The Three Things an MCP Server Actually Does at Runtime

People conflate what an MCP server does, and the conflation is usually where the misunderstanding starts.

Context retrieval is the first function: fetching relevant information from the connected source and returning it in a form the agent can reason over. Reading files, querying a database, pulling customer records.

Tool execution is where things get more consequential. The server exposes callable functions the agent can invoke: creating a ticket, sending a message, writing to a database, triggering a downstream workflow. This is two-way communication. A model connected only to retrieval can respond; a model connected to MCP servers can act. That gap separates agentic AI from retrieval-augmented generation, and it is not a minor distinction.

Permission brokering is the third function, and the one most consistently treated as secondary. The server mediates what the agent is allowed to see or do on behalf of a specific user, enforcing access boundaries before any data leaves the source system. When done well, it's invisible. When neglected, you find out at the worst possible moment. That moment is when something breaks in production with customer data involved.

Consider a multi-step task: an agent calls a knowledge base server, then a document store, then a project management tool, in sequence. Each server handles its own integration surface. The agent never accumulates knowledge of how any individual backend works; it receives normalized inputs and produces structured requests. That separation of concerns is what keeps the stack composable rather than fragile. It is also, not coincidentally, what makes the whole thing governable.

How MCP Turns a Brittle Integration Layer into a Composable One

Before MCP, every AI application that needed to touch an external system built its own connector. Its own authentication logic, its own data formatting, its own error handling. Multiply that by every AI application in an organization and every tool those applications need to reach, and you end up with an N×M integration problem: fragile, redundant, expensive to maintain. MCP collapses that into N+M. One server per tool, and any compatible client can use it.

Composability, in practical terms, means you can swap out one MCP server for a different backend and the agent's behavior doesn't change. The interface is stable even when the implementation underneath it shifts.

The multi-model implication here is significant and underappreciated. Business context, permissions, and integration logic live in the MCP layer, not inside any specific model. Switching from one LLM to another doesn't require rebuilding integrations. That directly addresses vendor lock-in in a way that prior proprietary mechanisms never could. OpenAI's Function Calling and Assistants API were powerful, but they didn't travel across model providers; organizations that built on them built parallel stacks instead of reusable infrastructure.

The ecosystem has validated this direction. By March 2026, Anthropic reported over 10,000 active public MCP servers and roughly 97 million monthly SDK downloads across Python and TypeScript. Integrations for Slack, GitHub, Salesforce, Stripe, Notion, and Linear exist on the server side. Claude, ChatGPT, Gemini, GitHub Copilot, and Cursor have all adopted the protocol on the client side. The protocol is approaching infrastructure status, which is partly why the governance question has become urgent.

The moment that confirmed this trajectory came in December 2025, when Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, co-founded with Block and OpenAI, and backed by Google, Microsoft, and AWS. That move transformed MCP from a single vendor's standard into vendor-neutral community infrastructure. The integration investment now travels with the organization, not with any particular model provider.

Where the Original Protocol Left Security to the Implementation

MCP was designed to make agents capable. Security was not a first principle in that design, and that gap has real consequences.

The original specification shipped without a mandatory authentication framework. The implicit trust model assumed servers were benign. According to The State of MCP Server Security 2025, only 18% of MCP server deployments implement any form of access scoping for tool permissions, and 53% expose credentials through hard-coded values in configuration files. Those aren't edge cases; that is the median deployment.

Without governance, organizations accumulate servers across teams, each with its own credentials, no least-privilege controls, no visibility to central IT. Research from Clutch Security found that in a typical 10,000-person organization, roughly 15% of employees run an average of two MCP servers each. That's over 3,000 deployments, most of them ungoverned. This is the shadow MCP proliferation problem, and it follows directly from treating MCP as a developer convenience rather than as infrastructure.

The June 2025 spec update introduced OAuth 2.1 support, which was a meaningful improvement. Fine-grained access controls, though, remain largely up to the implementation. The base protocol still doesn't enforce them, which means every organization is making architectural security decisions whether they intend to or not. Many organizations making those decisions are unaware they're making them, which is its own category of problem.

OWASP's MCP Top 10 for 2026 maps the full threat surface: tool poisoning, schema poisoning, tool shadowing, command injection through unsanitized input, shadow servers deployed outside governance, context over-sharing across shared sessions. In July 2025, Replit's AI agent deleted a production database containing over 1,200 records despite explicit instructions to implement a code and action freeze. That is a documented consequence of overprivileged MCP access; calling it a model failure misses the point entirely. The permissions structure made the failure possible.

Why Permissions Must Be Inherited Rather Than Redefined at the MCP Layer

The naive approach is to define access rules inside each MCP server individually. That appears reasonable until you have ten servers with ten separately maintained access rule sets that will diverge over time, produce inconsistent enforcement, and cannot be audited as a coherent system. You've solved the integration fragmentation problem and recreated it one layer up, at permissions. Different maze, same problem.

The correct architecture is inheritance: MCP servers that derive permissions directly from the underlying source systems, so that when someone's access to a Salesforce record is revoked, that revocation propagates automatically to every agent that would have retrieved it. No manual synchronization, no lag, no reconciliation spreadsheet someone has to maintain.

Shared credentials make this impossible. If multiple agents share one API key or service account token, there is no way to link a specific tool call to a specific user. The attribution that every major compliance framework requires simply disappears.

What inherited permissions require in practice: per-user or per-agent identity passed through the MCP call; the server checking that identity against the source system's own access controls before returning data; no caching of results across sessions or users. That last requirement deserves particular attention. Agents must use MCP servers that map API requests in-memory and pass results directly to the caller. Any shadow copy of retrieved data becomes a compliance liability, particularly under GDPR's right to erasure. A result cached somewhere in the MCP layer after a user's data has been deleted is not minor technical debt; it is a regulatory exposure with a specific enforcement mechanism behind it.

What Compliance Frameworks Actually Require of an MCP Deployment

There is no AI exception in HIPAA, SOC 2, or GDPR. An MCP deployment that accesses regulated data inherits the compliance obligations of that data, fully and without carve-outs.

The audit trail gap is the most acute problem in current deployments. A 2025 survey found fewer than 30% of AI systems had structured audit trails of agent tool access, and fewer than 15% could reconstruct the full decision path for an agent action. For regulated industries, that isn't an operational gap; it is a direct compliance failure, and regulators have shown they will treat it as one.

HIPAA requires audit trails attributable to an identifiable user or service for every access to protected health information; shared-credential deployments fail this directly. SOC 2's CC6 control family requires access controls with documented evidence of enforcement, and MCP governance infrastructure is in scope for Type II audits when it handles financial data or systems of record. GDPR is more expansive: Articles 5, 28, 30, 32, 33, 34, and 15 through 22 collectively impose processing principles, processor contracts, records of processing, security measures, breach notification requirements, and data subject rights. All of them apply to the MCP layer if that layer touches personal data.

Regulators issued €1.2 billion in GDPR fines during 2024 alone. Cumulative penalties since the regulation took effect have reached €5.88 billion. These figures are not hypothetical projections; they are enforcement history.

The EU AI Act adds a forward-looking deadline: full high-risk AI system requirements become enforceable on August 2, 2026. MCP servers themselves are not "AI systems" under the Act's definition, but the workflows they enable are. That makes the MCP architecture choice a direct compliance decision, with fines reaching €35 million or 7% of global turnover for the most serious violations.

Application-layer security scattered across dozens of independently developed MCP servers cannot be audited as a system. Consistency and demonstrability require enforcement at the infrastructure layer. The compliance frameworks don't specify how to build the infrastructure, but they are specific about what it must be able to prove.

Human-in-the-Loop as a Structural Feature, Not an Afterthought

Well-governed tool access doesn't eliminate the need for human checkpoints. Industry research consistently places model error rates in complex multi-step tasks somewhere between 5% and 15%. At enterprise scale, that range translates to thousands of flawed actions per day. Governance has to account for error, not just for intent.

MCP's elicitation feature, introduced in the June 2025 spec revision, formalizes the mechanism: servers can pause tool execution and request structured input from the user via the client before proceeding. The capability exists at the protocol level. Whether organizations use it is an architectural and policy decision, and many are still treating it as optional when the risk profile says otherwise.

The pattern in mature production deployments is consistent: autonomous execution for routine, low-stakes tasks; mandatory human approval when an action involves money, access changes, policy implications, or customer commitments. Pinterest has formalized this in their production deployment, mandating human-in-the-loop approval for all sensitive MCP operations. That is a threshold encoded in architecture, not a policy document that gets followed inconsistently because the system doesn't enforce it.

EU AI Act Article 14 and NIST's AI Risk Management Framework both recommend demonstrable human oversight: trained, measurable, provable. The word "demonstrable" carries the architectural requirement. Every approval must be logged, covering who approved it, what they approved, and when. Audit trails need to capture not just tool calls but the human decisions that authorized them, because an approval that isn't documented didn't happen. At least not in any way a regulator will credit.

Why the MCP Server Becomes the Organizational Unit Enterprises Govern Around

Each MCP server is a discrete, versioned, auditable unit. It exposes a defined set of tools, enforces a defined access policy, and produces a structured log. That profile makes it the natural place to attach governance controls. Organizations that recognize this early build infrastructure that scales; organizations that don't recognize it are usually the ones with the 3,000-server shadow proliferation problem described earlier.

A shared registry of approved MCP servers replaces ungoverned sprawl with a governed catalog. Version control and rollback mean changes to a server's behavior are tracked and reversible. Access scoping in the registry means teams can find and reuse servers without inheriting each other's permissions. Gartner projects that 70% of software engineering teams building multimodal applications will use AI gateways by 2028, up from 25% in 2025.

The reuse argument follows directly from this structure: a governed MCP server built once by one team can be published to a registry and consumed by any team with appropriate access. Multiple teams independently rebuilding the same connector for the same underlying system is a governance failure, not a technical inevitability.

And because the integration logic and permissions live in the MCP server rather than in the model, the same governed server works whether the agent running against it is Claude, ChatGPT, Gemini, or Cursor. Consistency across surfaces, without rebuilding for each one.

The governance choices are not adjacent to the architecture. They are the architecture, and that was true from the first deployment.