MCP Is the USB of AI — But You Still Need an Electrician
In November 2024, Anthropic quietly open-sourced a protocol called MCP — the Model Context Protocol. It defined a standard way for AI models to discover and invoke external tools. Within weeks, every major AI lab and tooling vendor had adopted it. By early 2026, Anthropic reports that MCP SDKs are downloaded more than 97 million times per month across Python and TypeScript — a figure that includes CI/CD pipeline automation, but still reflects massive ecosystem adoption. The protocol has moved to Linux Foundation governance, with contributions from OpenAI, Google DeepMind, Microsoft, and dozens of infrastructure companies.
MCP won. The format war is over. If you are building AI agents that interact with the outside world — databases, APIs, file systems, SaaS platforms — you are building on MCP. And that is genuinely good news.
But there is a dangerous assumption spreading through enterprise teams right now: that adopting MCP means you are ready for production agentic AI. It does not. MCP gives you a universal connector. It does not give you the wiring, the circuit breakers, or the building inspector. And if you plug in without those, you are going to trip something far worse than a fuse.
What MCP Actually Is
MCP is a protocol specification. It defines how an AI agent (the “client”) communicates with tool providers (the “servers”). An MCP server exposes a set of capabilities — functions the agent can call, resources it can read, prompts it can use — through a standardized JSON-RPC interface. The agent discovers what is available, negotiates capabilities, and makes structured calls.
The analogy everyone uses is USB-C. Before MCP, every tool integration was bespoke. You wrote custom function-calling schemas for OpenAI, different tool definitions for Claude, yet another format for Gemini. MCP collapses that into one specification. Write an MCP server once, and any MCP-compatible agent can use it.
This is genuinely transformative for the ecosystem. MCP servers now exist for Postgres, Slack, GitHub, Jira, Salesforce, AWS, GCP, Stripe, and hundreds of other services. The long tail of integrations is being built by the community at remarkable speed. If your enterprise tools expose an API, there is probably an MCP server for it already — or there will be within weeks.
But here is where the analogy matters: USB-C is a connector. It does not tell you whether the device on the other end is safe to plug in. It does not monitor power draw. It does not ask for permission before transferring data. It connects. That is its job. Everything else is your responsibility.
The Three Gaps MCP Does Not Close
Our platform is built for enterprise teams deploying agentic AI into regulated, high-stakes environments — financial services, healthcare, public sector, logistics. In those settings, the same three gaps surface once MCP enters the conversation.
Gap 1: Security — MCP Servers Run with the Keys to the Kingdom
An MCP server runs as a process on a host machine — or in a container, or as a remote service. By default, it has access to whatever the host process has access to. If you spin up an MCP server for Postgres, that server has the database credentials. If you run an MCP server for your filesystem, that server can read and write files with the permissions of the user that launched it.
MCP itself has no built-in sandboxing model. There is no concept of “this agent can read from table X but not table Y.” There is no credential scoping that says “this tool can call the Slack API but only post to the #engineering channel.” The protocol defines how to call a tool. It does not define who should be allowed to, under what conditions, with what constraints.
In development, this is fine. In production, it is a security incident waiting to happen. An agent that hallucinates a destructive SQL query and sends it through an MCP server with full database credentials is not a theoretical risk. It is the default configuration.
The MCP specification explicitly acknowledges this: security is the responsibility of the implementation, not the protocol. That is architecturally correct — and operationally terrifying for enterprise teams.
Gap 2: Governance — No Approval Workflows, No Audit Trail
When an MCP-connected agent decides to call a tool, the call executes. There is no built-in concept of “wait for human approval before running this operation.” There is no approval queue. There is no audit log that records who requested what, which agent made the call, what parameters were sent, and what the tool returned.
For internal developer tools, this might be acceptable. For anything touching customer data, financial transactions, production infrastructure, or regulated workflows, it is a non-starter. Every compliance framework — SOC 2, HIPAA, FedRAMP, SOX — requires demonstrable access controls and audit trails for automated systems that touch sensitive resources. MCP does not provide them because MCP is not trying to be a governance layer. It is a wire protocol.
The result is that enterprise teams either bolt governance on as an afterthought — wrapping MCP calls in ad hoc middleware that is fragile, inconsistent, and hard to audit — or they block MCP adoption entirely because the governance story is not there. Neither outcome is good.
Gap 3: Operations — A Protocol Is Not a Platform
MCP defines request-response communication between a client and a server. It does not define how to monitor those interactions in production. It does not provide rate limiting to prevent runaway agents from hammering an API endpoint. It does not include failover logic for when an MCP server goes down. It does not handle multi-model routing — choosing which LLM processes which request based on cost, latency, or capability.
Production agentic systems are distributed systems. They need observability: traces, metrics, alerting. They need resilience: retries, circuit breakers, graceful degradation. They need cost management: token budgets, model selection policies, usage attribution. MCP is a spoke in this wheel — an important spoke, but one spoke.
Teams that treat MCP adoption as the finish line find themselves rebuilding platform-level infrastructure from scratch three months later, usually under the pressure of a production incident that exposed the gaps.
Closing the Gaps: What a Production MCP Stack Looks Like
At AgenticWork, we build the governance and operations layers that sit on top of MCP. Our platform is designed around the assumption that MCP is the right tool-communication standard — and that production deployments need significantly more than a communication standard. The platform includes purpose-built tools for every stage of the MCP lifecycle: building servers, securing them, routing model traffic across them, and monitoring everything in production.
MCP Development: MCP Workshop, CodeMode, and agenticode-cli
Building production-grade MCP servers is the first challenge most teams face. Our platform's MCP Workshop provides a complete environment for creating, testing, and deploying MCP servers — with hot-reload during development and zero-downtime deployment to production. Teams can iterate on server implementations in real time, test tool schemas against live agents, and push to production without interrupting running workflows.
For developers who prefer a code-first approach, CodeMode provides VS Code in the browser with AI pair programming and Kubernetes sandbox isolation — build and test MCP servers in an environment that mirrors production from the start. For CI/CD integration, agenticode-cli enables script-based MCP server development, automated testing, and pipeline-driven deployments. Together, these tools cover the full MCP development workflow from prototype to production.
Security: DLP Scanner, OBO Authentication, and RBAC
Every MCP tool invocation in a platform-managed system runs in an isolated execution environment. Credentials are scoped per tool, per agent, per task. A Postgres MCP server does not get full database credentials — it gets a read-only connection to specific schemas, with query complexity limits, issued as a short-lived token that expires when the task completes.
The DLP Scanner monitors all data flowing through MCP tool calls in real time, detecting and redacting PII across 50+ data patterns before sensitive information leaves your environment. OBO (On-Behalf-Of) Authenticationensures that when AI agents invoke MCP tools, they act with the identity and permissions of the requesting user — not with a privileged service account. RBAC provides per-tool granularity: define exactly which agents, users, and roles can access each MCP server and which operations they can perform.
This is not a wrapper around MCP — it is the execution environment that MCP servers run inside. The protocol works exactly as specified. The security boundary is enforced at the infrastructure layer, not the protocol layer, which is where it belongs.
Governance: Audit System and Human-in-the-Loop Gates
The platform's Audit System records every MCP tool invocation in immutable logs with cryptographic hashing — tamper-evident records designed to support SOC 2, HIPAA, and FedRAMP-aligned audit and access-control requirements. Every interaction captures: the originating request, the agent's chain of reasoning, the tool call parameters, the approval decision, the execution result, and the downstream effects. This is not optional logging you can enable — it is a structural part of the platform that cannot be bypassed.
Mandatory human-in-the-loop (HITL) approval gates pause execution before high-risk tool calls. A human reviewer sees the agent's reasoning, the proposed tool call with exact parameters, the relevant context, and the risk classification. For high-volume, low-risk operations, HITL policies can be tuned to auto-approve with logging. The governance model is explicit, configurable, and auditable — not absent.
Operations: SmartModelRouter and Production Observability
SmartModelRouter handles multi-model routing for agentic workflows across 15+ model families through 5 provider integrations. Not every sub-task requires the same model. A classification step might use a small, fast model. A complex reasoning step might need a frontier model. The Intelligence Slider (0-100) lets teams tune the cost-quality tradeoff per workflow, while automatic failover chains ensure requests are never dropped when a provider is unavailable.
On the observability side, every MCP tool call is instrumented with OpenTelemetry traces. You get end-to-end visibility: which agent initiated the workflow, which tools were called, how long each step took, what tokens were consumed, where failures occurred. This integrates with standard monitoring stacks — Grafana, Datadog, whatever your team already uses. When an agent misbehaves at 2 AM, you can trace exactly what happened and why, down to the individual tool call.
MCP Is the Foundation, Not the Building
We are bullish on MCP. The protocol solved a real problem — AI tool integration was a fragmented mess, and now it is not. The Linux Foundation stewardship means the specification will evolve through open governance, not a single vendor's roadmap. The ecosystem of MCP servers is growing faster than any of us expected.
But enterprise teams need to be clear-eyed about what MCP is and what it is not. It is a wire protocol for tool communication. It is not a security model. It is not a governance framework. It is not an operations platform. Those layers need to exist, and they need to be designed with the same rigor you would apply to any production system that touches sensitive data and critical workflows.
The USB-C analogy works better than most people realize. USB-C is a brilliant standard. It is also the connector used in the most common charging-related house fires. The connector is not the problem — the problem is what happens when you plug in without the right safeguards on the other end.
MCP gives you the port. We help you wire the building to code.