What is an MCP server?

Where does an MCP server sit in an AI architecture?

Here is the picture to keep in mind for the rest of the article.

User → LLM → Agent → MCP Server → Enterprise Systems

Each layer has a specific job:

• LLM. Understands what the user asked. Presents the final answer in plain language.
• Agent. Decides what actions to take and in what order.
• MCP Server. Exposes the tools and data the agent can use. Routes the calls.
• Enterprise Systems. Do the actual work. CRM, databases, case management, knowledge graphs, anything the business already runs.

The MCP server is one piece of this stack, not all of it. The LLM generates the language. Planning falls to the agent. The enterprise systems do the actual work. Without the MCP server in the middle, the agent has no way to reach the systems and the LLM has nothing concrete to answer with.

A salesperson asks the AI assistant, "What is the renewal status of our top three customers in Germany?" The LLM understands the question. The agent decides to pull the top three German customers, then check each contract renewal. The MCP server tells the agent which tools are available and routes those calls. The CRM and contract system return the data. The LLM writes the answer. Without the MCP server, the agent has the plan but no way to execute it.

How does an MCP server work?

An MCP server consists of three primitives and an authentication layer.

• Tools. Actions the agent can invoke. A CRM MCP server might expose a tool that pulls customer records and another that fetches contract renewal dates. Each tool tells the agent what inputs it needs and what it will return.
• Resources. Data the agent can read for context. A document repository MCP server exposes documents the agent can fetch by reference.
• Prompts. Reusable templates the server publishes for common workflows. A monitoring MCP server might publish a "diagnose latency spike" prompt the assistant offers as a one-click action.
• Authentication. The MCP server checks an identity token at the protocol layer. Propagating that identity through to the back-end systems is a separate problem the protocol does not solve.

The agent does not need to know any of this in advance. The MCP server tells it upon connecting. That runtime-discovery property is what distinguishes an MCP server from a hard-wired API integration.

What problems does an MCP server solve?

An MCP server addresses four specific needs, all related to the access layer:

• Tool discovery. The agent finds out what is available at runtime, instead of being hard-coded against a fixed list.
• Standardized integration. One protocol means one integration shape across every tool, instead of bespoke work for each AI vendor.
• Agent interoperability. A Claude agent and a Microsoft Copilot agent can both talk to the same MCP server without re-engineering.
• Reduced connector sprawl. Instead of N tools by M AI providers, you build N MCP servers, and any provider can reach them.

The collapse from N×M to N+M is the structural reason MCP exists. It is also why Microsoft, Google, AWS, and Cloudflare have all published reference implementations within eighteen months of the standard's launch.

When should you choose MCP instead of REST?

The question is who the consumer is, and how much governance work you are ready to do.

Use a REST API when the consumer is application code that knows in advance what it is calling, the contract is stable, and the back-end already handles authentication and audit on a per-request basis.

Use an MCP server when the consumer is an AI agent that needs to discover capabilities at runtime, the integration surface is broad enough that hand-coding each tool would be uneconomic, and you have a defensible answer for who is calling, what they are allowed to do, and how the action is recorded.

Wrapping an existing REST API in an MCP server is the right move when you want to give AI agents access to a system you already expose. The wrap solves discovery and composition. It does not solve identity propagation, audit, or data boundary. Those are separate pieces of work.

Two out of three is not enough on the MCP side. The most common pilot failure is meeting the first two conditions, shipping a working demo, and failing the production review when the governance question arrives.

What does an MCP server not solve?

An MCP server provides access to enterprise systems. It does not automatically provide governance over that access. Four things in particular it does not give you:

• Identity propagation. Knowing which human is behind a given AI action.
• Audit. A defensible trail showing who triggered what, when, and what came back.
• Governance. Controls on what data the AI is allowed to see and where it is allowed to go.
• Context quality. Whether the data the agent is reading is the right data, joined the right way, with the right business meaning. An agent reading from disconnected, unresolved systems will be confidently wrong.

These are the questions a compliance reviewer will ask before signing off on the pilot. The MCP server does not have answers to any of them by default.

Why do MCP deployments fail in production?

A common scenario is that the demo works, but the compliance review fails. Security researchers documented over thirty CVEs in MCP-related software between January and February 2026 alone, including one CVSS 9.6 remote code execution flaw in a package downloaded nearly half a million times by AI developers. Past the supply-chain risk, three patterns kill most production deployments:

• The service account trap. Most production MCP deployments call the back-end systems with a single shared credential. The AI agent has the permissions of every user combined, and frameworks like SOC 2, HIPAA, PCI-DSS, and GDPR all require per-user accountability the shared credential cannot give.
• The identity-forwarding gap. The user authenticates to the AI assistant, but the identity does not propagate through to the underlying system. The back-end sees the AI agent, not the human who asked the question.
• The audit attribution gap. The log records that a tool was called. It does not record who triggered the action, what context the agent was working from, or whether a policy check was made before the action ran.

These are governance problems. The MCP server can be perfectly compliant on the wire and still fail every one.

What should enterprise buyers evaluate before deployment?

Five questions to ask any team proposing an MCP rollout:

1. How is identity propagated? Does the system know which human triggered each AI action, or is the agent running as a shared account?
2. How is audit information captured? Is the log enough to defend in front of a compliance reviewer, or does it stop at "a tool was called"?
3. Where does data travel? Does the architecture keep sensitive data inside the enterprise boundary, or does it leave on every prompt?
4. What context is the agent querying? Is the agent reading from a governed connected data layer, or stitching together raw systems each time?
5. Can actions be attributed back to a specific user? If a reviewer asks "who did this", can you answer in one query?

If the answer to any of these is "we will figure that out in production", the production review is going to find it first.