Every other AI agent post you read right now starts the same way: "MCP changed everything." 6 months ago, that was almost true. Anthropic published the Model Context Protocol, every major model vendor adopted it, and the agent ecosystem stopped reinventing tool calling for the fiftieth time.
Then teams tried to ship an MCP server to production, and the silence got loud.
This is the post nobody wrote yet. What MCP actually is, where it ends, and what you still have to build before the security team will sign off on your MCP server doing anything useful in your business.
What MCP solved
Before MCP, every agent framework had its own tool calling shape. LangChain tools, CrewAI tools, OpenAI function calling, Anthropic tool use, AutoGen handoffs. The signatures were all different. If you wanted your refund agent to also work in your support agent, you were rewriting the tool definitions twice.
MCP fixed that. The Model Context Protocol is an open standard for how LLMs talk to tools, resources, and prompts. The model speaks MCP. The tools speak MCP. The transport in between is JSON-RPC over stdio, HTTP, or WebSocket. Tools become portable across models, agents, and frameworks. Write 1 MCP server for your CRM, plug it into Claude, GPT-5, your in-house Mistral, and any agent built on top.
This is real progress. The "every framework reinvents tool calling" tax is gone. The cognitive load of agent development drops. The same MCP server you ship for your internal agent can be reused by a customer agent, a teammate's IDE, or a workflow you write 6 months from now.
If the goal was a clean interface between models and tools, MCP did the job.
But that was the goal. Not the rest of the goals.
What MCP leaves to you
Read the spec. MCP defines 4 things: how a client and server initialize a session, how the server advertises its tools and resources, how tool calls are made and responses returned, and a few transport details.
That is the entire scope.
Nothing in the spec says how the user is authenticated. Nothing says how the agent's identity is established. Nothing defines what actions are logged or where. Nothing handles secrets. Nothing says what runs the server, how it scales, how it gets deployed, or how it survives a restart. Nothing addresses how tools are versioned across releases, how schema changes get rolled out, or what happens when 2 agents try to use the same tool at the same time.
This is by design. MCP is a wire protocol. The same way HTTP is not a web app, MCP is not an agent platform.
The trap is that most "MCP server" examples online look like complete products. A 40 line Python file that exposes a get_orders tool. You run it. Claude Desktop connects to it. It works. You think you have shipped something.
You have not. You have shipped a localhost demo. Everything else is still ahead of you.
The 7 things production MCP needs that MCP does not give you
Let's walk through what your security team, your SRE team, and your finance team are going to ask the moment you say "we're deploying an MCP server".
1. Who is calling the tool. MCP servers run tools on behalf of someone. Is that someone a user? An agent? A service? A teammate's IDE session? The spec is silent. Most reference implementations either skip auth entirely or wrap the server behind an API key shared across every caller. That single key is now a master key. Anyone who has it can call any tool on any data. There is no way to revoke it without breaking everyone. There is no audit trail because every call looks identical.
What you actually need: an identity per caller, tied to your IdP (Okta, Microsoft Entra, Google Workspace, Auth0). Tokens that expire. Service identities for agents that are distinct from user identities. The same OIDC layer your human apps use, extended to your MCP layer. This is the same problem we covered in the SSO guide for AI-coded internal apps, and the answer is the same: do not invent it per server.
2. Which tools that caller is allowed to use. Even after you know who is calling, you have to decide what they can do. The standard MCP server pattern lists every tool to every connected client. The CRM MCP server hands the same delete_account tool to a customer support agent, an analyst agent, and the CEO's vibe-coded morning briefing agent. None of those callers should have the same set of allowed actions.
What you actually need: per-tool RBAC enforced at the server layer, with the policy decision made outside the agent. The agent never picks whether it is allowed to call a tool. The server checks against the caller's role and the resource's policy. We covered the underlying model in RBAC for Internal Tools. MCP servers inherit it. They do not reinvent it.
3. An audit trail of what happened. Every tool call your MCP server runs is a write the business has to be able to account for. Who called the tool. With what arguments. Against what data. What was returned. What downstream side effect occurred. When SOC 2, HIPAA, or the next vendor security questionnaire shows up, "we did not log it" is not an answer.
What you actually need: an immutable, append-only audit log scoped to the user, agent, tool, and resource. Retention long enough for your compliance regime. Queryable when an incident happens. This is the same audit layer your human apps already have, and your MCP servers have to plug into it, not maintain a sidecar log file that someone has to remember to look at.
4. Secrets the server uses. Your MCP server has API keys. Stripe, Salesforce, your internal Postgres, the AWS credentials it needs to read a bucket. Where do those live? In an env var on the host? In a file next to the binary? In code? The "MCP server in a Docker image" pattern most teams default to puts secrets one kubectl exec away from anyone with cluster access.
What you actually need: an encrypted vault that issues short-lived credentials to the MCP server at runtime, scoped to the tool that needs them, with rotation handled outside the server's code. Same secrets layer your apps use.
5. A place to run. Localhost works for a demo. Production needs a process supervisor, restart policy, log shipping, metrics, network policy, TLS, request limits, a load balancer if you scale beyond 1 instance. None of that is in the MCP spec, and none of it is in the reference implementations.
What you actually need: a runtime that handles the boring parts. Process lifecycle, health checks, restart on failure, scaling, network ingress, TLS termination. The same deployment substrate your apps run on. If your MCP server is the only thing on its own bespoke deploy, you are running 2 production stacks for 1 product, and the MCP one is the underloved cousin.
6. Quotas and blast radius limits. An agent connected to your MCP server can call tools in a loop. If the model decides to "investigate further" 200 times in a row, your CRM gets hit with 200 reads. If the agent decides to "update each record" across 50,000 rows, the side effect is unbounded. The spec does not constrain this. Most MCP servers do not.
What you actually need: rate limits per caller, spend caps per session, write quotas with approval gates above a threshold. We went into this in detail in Agentic AI vs AI Agents for agentic systems specifically, but the limit applies to every MCP server that exposes write tools.
7. Tool versioning, deprecation, and schema drift. Your get_orders tool returned 5 fields in v1. In v2 you renamed one and added 2. Every agent that hard-coded the v1 shape now silently breaks or worse, silently produces wrong outputs. MCP gives you a way to advertise the current tool list. It does not give you a way to manage change over time.
What you actually need: tool definitions tracked the same way you track API versions. Deprecation windows. Tested before promotion. The same change management you apply to your internal HTTP APIs, because that is what MCP servers are.
The platform shape that MCP needs
Notice the pattern. Every gap in the MCP spec is something the rest of your platform already does for your regular apps. Identity. RBAC. Audit. Secrets. Deployment. Quotas. Versioning.
The instinct in most teams is to bolt these onto the MCP server one at a time. Add an OIDC middleware. Wrap each tool in a permission check. Stand up a sidecar for audit logging. Mount a secrets file. Configure a deployment. Add a rate limiter. Build a tool registry.
You can do this. Every team we've seen do it ends up with 4 to 6 weeks of platform work per MCP server, and the result is a slightly different reimplementation of the same controls for every server. Server 1 has rate limits. Server 2 forgot. Server 3 has audit logs in a different format. Server 4 hardcoded an API key.
This is exactly the failure mode we wrote about in Code Is Now Free. Governance Is Not.. MCP made writing the tool cheaper. It did not solve any of the surrounding work, and per-server governance does not compose.
The structural answer is the same one that applies to AI agents in general: governance has to live below the server, in a shared platform, not next to it in each server's code.
A production checklist for MCP servers
Before you put an MCP server in front of an agent that can do anything beyond read public data, walk through this list.
| Capability | What it means | Where it should live |
|---|---|---|
| Caller identity | Every call carries a verified identity (user, agent, service) | Shared OIDC layer |
| Per-tool RBAC | Permission to call this tool, on this resource, by this caller | Platform policy engine |
| Audit logging | Append-only record of who called what, with what, against what | Shared audit store |
| Secrets management | Server credentials issued at runtime, scoped, rotatable | Encrypted vault |
| Deployment runtime | Process lifecycle, scaling, health, TLS, ingress | Shared deploy substrate |
| Quotas | Rate limits, spend caps, write quotas, approval gates | Platform, per caller and per prompt |
| Versioning | Tool schemas tracked, deprecations managed | Tool registry |
| Observability | Traces, metrics, error rates per tool and caller | Shared observability stack |
If any row in the right column says "in the MCP server's code", you are rebuilding platform work. If the row is blank, your security team will write it in for you the week before launch.
In RootCX: every MCP server you build runs inside Core, the same runtime your apps and agents share. Callers authenticate through the project's OIDC layer (Okta, Entra, Google Workspace, Auth0). Per-tool RBAC is enforced before the tool function even runs. Every tool call is appended to the project's immutable audit log, scoped to user, agent, tool, and resource. Secrets come from the encrypted vault, issued at call time. Deployment is one click. Rate limits and quotas apply per caller and per prompt. The MCP server is the business logic. The platform handles everything else.
Where MCP fits in the stack
To be clear, MCP is the right interface for tool calling. It is winning, and it should win. Standardizing the wire format between models and tools removes a real source of pain.
The mistake is treating MCP as the answer to "how do I ship an AI agent stack to production". It is the answer to "how do my tools and my model talk to each other". Those are different questions.
A useful analogy: HTTP is a protocol. Web apps need HTTP. They also need a server, a database, a session layer, auth, logging, deployment, and a CDN. Nobody confuses "we use HTTP" with "we have a web platform". MCP deserves the same treatment. We use MCP. We also have a platform.
Teams that treat MCP as a platform end up with the same failure mode that every "AI agent in a Python file" team hits. The demo works. Production is 2 months of unplanned work. The security review fails because nobody can answer "who called the tool" with a name. The first incident costs a weekend because the audit log is grep against a logfile that rolled over yesterday.
Teams that treat MCP as a protocol on top of a platform ship in days. The MCP server is 200 lines of business logic. The platform provides everything else.
When to write an MCP server vs an app vs an agent
A common confusion right now is when to expose something as an MCP server, when to build it as an internal app, and when to wrap it in an agent. The answer depends on what is calling it.
Build it as an MCP server when the consumer is going to be 1 or more AI agents or IDEs that already speak MCP, and the unit of work is a clean tool call (read this, write that, query something). The CRM lookup, the refund issue, the customer summary write. Any tool that multiple agents will reuse.
Build it as an internal app when the consumer is a human, the workflow has UI state, or the value is in the interface. The dashboard, the approval queue, the report builder. Some of these will also expose MCP tools to agents, that is fine.
Build it as an agent when the work involves reasoning, sequencing, replanning, or talking to a user in natural language. The agent then calls MCP servers as its tools.
In practice you ship all 3. They share a platform. The MCP servers expose tools. The apps expose UI. The agents reason and call. The platform handles identity, permissions, audit, secrets, and deployment for all 3. This is the shared infrastructure thesis applied to the MCP era.
The MCP era needs a platform era
The agent ecosystem has spent the last year fixing tool calling. That work is done. MCP is the answer.
The next year is about everything tool calling left unsolved. Identity for the caller. Permissions for the call. Audit for the side effects. Secrets for the credentials. Deployment for the server. Quotas for the loops. Versioning for the schemas.
If your team is shipping MCP servers and the answer to any of those is "we'll figure it out", that figuring out is the actual project. The MCP server is the easy part.
We built RootCX so that the MCP server is the part you write, and everything else is already there. Same OIDC your humans use. Same RBAC. Same audit log. Same vault. One deploy. You can start a project free and ship your first MCP server before lunch.