MCP Is Your Production Bottleneck: How the Standard Became Your Infrastructure
Here's the honest truth about agent scaling in 2026: model capability is no longer the bottleneck. Integration is.
Your agent works brilliantly on a demo. Claude Code can summarize a file, query a database, make an API call, update Slack—all in the same session. You ship it to two teams. Suddenly you have 20 different tools spread across GitHub, Jira, Linear, Slack, AWS, your internal APIs. Each one needs a custom integration. Each agent framework implements tool calling differently.
Before MCP, ten agents and 100 tools required 1,000 custom integrations. Now you build once and reuse everywhere.
But here's what most teams discover in production: MCP standardization solves the integration problem. It doesn't solve the governance problem.
The Tool Chaos Problem
You deploy your first two coding agents—one for infrastructure, one for documentation. They share a GitHub connection, they both call AWS APIs, they both need Slack integration for notifications. Each agent implementation (Claude Code vs Cursor vs OpenCode) handles tool authorization slightly differently. Your infrastructure ops team freaks out—suddenly those agents have access to production systems.
Five agents later, you have:
- Five separate GitHub OAuth flows
- Five separate AWS credential scopes
- Inconsistent audit trails across runtimes
- No unified way to say "this agent can call this tool" without redeploying code
- No visibility into which tool calls succeeded, which failed, or how much they cost
This is where teams hit the wall that MCP doesn't solve alone.
MCP Is the Transport. Control Planes Are the Guardrails.
Model Context Protocol is having its "USB-C moment" in 2026. It's genuinely great—you write one tool adapter, Anthropic's spec handles the rest. The problem is that MCP is transport, not governance.
MCP says: "Here are the tools. Here's how to call them."
MCP doesn't say:
- Which agent is authorized to call which tool
- How to credential-scope tools so agents only see the ones they need
- How to audit who called what and when
- How to change tool permissions without redeploying agents
- How to enforce tool rate limits per agent
The teams that scale agents in 2026 separate this cleanly: MCP for tool standardization, control planes for governance.
The Production Pattern
The emerging pattern is:
- MCP server layer - standardized tool definitions (GitHub, Slack, Linear MCP servers)
- Control plane - orchestration, credential scoping, authorization, audit trails
- Agent runtimes - logic execution (Claude Code, Cursor, OpenCode)
- Data plane gateway - fast routing and tool call translation
Each layer has a job:
- MCP handles tool discovery and invocation format
- Control planes handle access control and observability
- Runtimes handle reasoning and decision-making
- Gateways handle speed and provider abstraction
You're not choosing between MCP and control planes. You're composing them. MCP without governance doesn't scale past one agent. Control planes without MCP reinvent the wheel for every tool.
Why This Matters Right Now
Orchestration and reliability have become critical. Multi-step workflows amplify both the upside of agents and the operational challenges that come with them.
In practice, that means:
- Your first agent (single runtime, 5 tools): MCP alone is fine
- Your second agent (different runtime, overlapping tools): you need unified credentialing
- Three agents on three runtimes with shared tools: you need authorization + audit trails
- Five agents with cross-team access: you need a control plane full stop
The teams that are scaling agents in Q3 2026 are the ones that realized: MCP is the language, but the control plane is the grammar.
How Infrastructure Bridges This
Production agent infrastructure explicitly separates these layers:
- MCP integration: Pre-wired MCP servers (GitHub, Slack, Linear) that show up as tools for agents
- Credential scoping: Agents see only the tools they're authorized for; credentials are vaulted, never returned to agents
- Tool invocation audit: Every tool call is logged with timestamp, agent identity, result, cost
- Authorization per agent: Change which tools an agent can call without redeploying the agent
- Multi-runtime support: Same MCP servers work for agents on Claude Code, Cursor, OpenCode—no tool rewrite needed
The pattern is: MCP handles the "what tools exist" question. Control planes handle the "who can call what" question. Your agents handle the "when should I call this tool" question.
Practical Example
Imagine three coding agents:
- Agent A: handles internal tooling (needs GitHub, Linear, internal APIs)
- Agent B: handles infrastructure (needs GitHub, AWS, Terraform registry)
- Agent C: handles security (needs AWS, GitHub, internal logging)
Without a control plane, each agent gets hardcoded connections to each tool. You deploy five times to adjust permissions. One misconfiguration, and Agent C suddenly has access to your Terraform state.
With MCP + control plane:
- You define one GitHub MCP server (standardized)
- Agent A, B, C all see it
- Control plane scopes credentials: Agent A gets read-only access to your repo, Agent B gets infrastructure read/write, Agent C gets read-only + audit log access
- One OAuth refresh token stored in the vault, used by all three agents
- One audit trail showing which agent called which tool and when
- Tomorrow, you change Agent B's permissions without touching code
Same tools, three different permission sets, unified audit trail, no code deployments.
The Evaluation Question
When you're evaluating agent platforms in 2026, the right questions aren't about raw model capability anymore. They're about infrastructure:
- MCP support: Can your platform integrate MCP servers?
- Credential centralization: Can you store credentials once and scope them per agent?
- Tool-level authorization: Can you say "this agent can call this tool" without redeploying?
- Audit trails: Can you answer "which agent called which tool last week" without log digging?
- Multi-runtime: Can you use the same tools across Claude Code, Cursor, and OpenCode?
If the answer to more than one is "no," your agent platform isn't built for production scale.
Why This Pattern Works
MCP is great because it prevents tool fragmentation. Control planes are necessary because MCP doesn't prevent authorization fragmentation.
The teams scaling agents fastest in 2026 aren't the ones with the smartest models. They're the ones with the cleanest layer separation: standardized tools (MCP), unified governance (control plane), predictable runtimes, fast routing.
This is what "production agent infrastructure" looks like in 2026: not "which AI model," but "which control plane, MCP integration, and data plane."
Paul Twist is an AI engineer in Berlin. He writes about making agent infrastructure that actually works in production.
Resources for deeper exploration:
- Model Context Protocol official spec
- Production agent infrastructure documentation
- LiteLLM Agent Platform patterns for MCP integration and control planes
- State of AI Agents 2026 report on production deployment patterns
Top comments (1)
Strong framing. One caveat in the practical example: “one OAuth refresh token … used by all three agents” can turn the control plane into a shared-principal blast radius. I’d prefer workload identity → token exchange → short-lived, audience-bound upstream credentials per agent/tool invocation, with authorization rechecked at execution time. Then revoking Agent B cannot be bypassed by an already-running session or cached token.
I’d also test the control plane with mid-workflow revocation, confused-deputy calls across tenants, vault outage/fail-closed behavior, and audit correlation from user intent to upstream request ID. Centralized governance is valuable; centralized standing credentials are the part I’d avoid.