MCP Server Infrastructure: Production Patterns for Agent Tool Serving at Scale

The Model Context Protocol (MCP) is the most widely adopted standard for agent-tool communication, with Stacklok’s 2026 survey finding that 41% of software organizations already have MCP servers in limited or broad production [4]. But the gap between a demo MCP server and a production deployment is vast. The same survey found that among those who evaluated MCP and chose not to adopt it, security concerns and context-management scalability were the top two blockers [4].

This post covers the architecture patterns that separate production-grade MCP infrastructure from proof-of-concept servers. We examine four categories of failure — context overload, security vulnerabilities, tool description quality, and error handling — and the engineering patterns that address each.

The Context Window Tax

The most immediate production problem with MCP is the context tax. Each MCP server exposes a set of tools via JSON-RPC 2.0 [2]. When an agent connects to multiple servers — a common pattern in production — tool definitions accumulate linearly in the model’s context window.

Anthropic’s engineering team documented this directly: “Today developers routinely build agents with access to hundreds or thousands of tools across dozens of MCP servers.” The problem is that “tool definitions overload the context window,” degrading output quality and increasing latency [1]. Each tool definition includes a name, description, and parameter schema — easily 200–500 tokens per tool. Twenty servers with ten tools each means 40,000–100,000 tokens consumed before any actual work begins.

EclipseSource’s analysis from January 2026 quantified this further: “Each MCP server brings 5–15 tools. That’s 40+ tool definitions sitting there, burning tokens before the agent writes a single line of code” [5]. The phrase “context overload” emerged to describe agents that become indecisive or produce lower-quality output simply because too many tool options compete for the model’s attention window.

Pattern: Code Execution Instead of Direct Tool Calls

Anthropic’s response to this problem was a fundamental rethinking of how agents interact with MCP servers. Instead of the agent calling MCP tools directly — which requires every tool definition to sit in context — the agent writes code that calls the tools, and a sandboxed runtime executes it [1]. This collapses hundreds of tool definitions into a single code-generation capability that occupies a fraction of the context.

The architecture follows this flow:

Agent → writes Python/TypeScript → sandbox executes → code calls MCP tools → results returned

The agent only needs to know about a small set of “code execution” tools at the protocol level. Tool-specific definitions are fetched lazily — the agent can introspect tool schemas via MCP’s tools/list endpoint when needed, rather than loading them all upfront [7]. This pattern reduces context consumption by roughly 60–80% in Anthropic’s reported benchmarks, though the exact numbers depend on server count and tool complexity [1].

Pattern: Tool Search and Dynamic Registration

Anthropic’s advanced tool use platform introduced tool search — a retrieval-augmented approach where tool definitions are indexed and only the most relevant subset is injected into context [7]. This mirrors the same information-retrieval pattern that solved context window limits in RAG systems: index everything, retrieve the top-k on demand.

The engineering tradeoff is latency. Tool search adds an embedding lookup and vector similarity scan before each turn. In practice this adds 50–200ms per turn, but the context savings (10–20x reduction in tool definition tokens) more than compensate when an agent needs access to hundreds of tools across dozens of servers.

Security: The Wild West of Tool Execution

The MCP specification defines a transport layer and a protocol for tool discovery/invocation, but it delegates security to the server implementation [2]. This has predictable consequences.

CVE-2025-53967 is an instructive case. The Framelink Figma MCP server, before version 0.6.3, allowed an unauthenticated remote attacker to execute arbitrary operating system commands through a command injection vulnerability in the MCP server’s file path handling [3]. The root cause was simple: the server passed user-controlled input (file paths from Figma) directly to shell execution without sanitization. GitHub’s advisory noted the vulnerability was “caused by the unsanitized use of input parameters” [3].

This pattern repeats across MCP servers because the protocol provides no security boundary. The arXiv taxonomy paper by Taraghi et al. systematically analyzed real faults in MCP software and found that input sanitization failures, authentication/authorization gaps, and insecure transport defaults were the three most common vulnerability categories [2].

Pattern: Sandboxed Execution Environments

The mitigation is well-understood: every MCP server should run in a sandboxed environment with the principle of least privilege. Docker containers with read-only root filesystems, no network access beyond the MCP transport, and no host filesystem mounts are the baseline. For servers that legitimately need file system access (like code execution sandboxes), seccomp profiles and AppArmor/SELinux policies limit what syscalls are available [2].

Anthropic’s code execution sandbox runs inside a gVisor container with explicitly enumerated syscall permissions — the agent can read/write files, make HTTP requests, and call MCP tools, but cannot load kernel modules, create raw sockets, or modify system configuration [1]. This is the security model that production MCP deployments should emulate.

Pattern: Transport-Level Authentication

The MCP specification supports both stdio (for local processes) and SSE (for remote servers). Production deployments should never use unauthenticated SSE. The protocol’s 2025 specification leaves authentication as an implementation detail, but production patterns demand:

• JWT-based authentication with short-lived tokens for SSE connections
• mTLS for server-to-server communication in multi-service architectures
• Rate limiting per-client at the transport layer before any tool logic executes

The Stacklok survey found that organizations with mature MCP deployments universally required authentication at the transport layer, while pilot-stage deployments frequently skipped it [4].

Tool Description Quality and Agent Reliability

A subtler but equally damaging production failure comes from tool description quality. The arXiv paper “Model Context Protocol (MCP) Tool Descriptions Are Smelly!” (2602.14878) documented that vague, inconsistent, or overly verbose tool descriptions were the single biggest source of agent tool-selection errors [6]. When an agent mis-picks a tool because the description says “get data” instead of “fetch repository commit history by hash,” the downstream consequences — wrong API calls, corrupted state, wasted tokens — cascade through the agent’s trajectory.

The study found that more verbose descriptions actually decreased accuracy. Tool descriptions averaging 15–25 words with concrete parameter examples outperformed descriptions over 40 words. The key was specificity: “Fetch a GitHub commit by its SHA hash” beat “Get commit data for a repository” every time, even though the shorter one was also clear [6].

Pattern: Structured Tool Descriptions

Production tool descriptions should follow a standard template:

Action: [single sentence, verb-first]
When: [explicit conditions for use]
Examples: [1–2 concrete parameter examples]
Failures: [known error conditions and what the agent should do instead]

This structure reduces the model’s ambiguity in tool selection because it maps the decision to conditions the agent can evaluate. The “Failures” field is especially important — without it, agents retry failing tools with slightly different parameters rather than switching strategies.

Pattern: Runtime Usage Monitoring

Production MCP deployments should track tool invocation patterns and flag servers where the agent frequently selects the wrong tool or retries excessively. This data feeds back into description quality — if a tool is never selected despite being available, either the description is wrong or the tool isn’t useful. The arXiv taxonomy paper reported that 23% of analyzed MCP faults were related to tool discovery and selection, making this the second-largest category after security issues [2].

Error Handling and Consistency

MCP servers have no standardized error reporting. The JSON-RPC 2.0 layer provides error codes, but individual servers implement them inconsistently. One server might return -32000: Tool execution failed while another returns -32603: Internal error for the same condition. Some servers return structured error data in the data field; others return a plain string in message [2].

This inconsistency is not abstract — it directly affects agent reliability. An agent cannot implement a retry or fallback strategy when it cannot distinguish between a transient error (rate limit, timeout) and a permanent error (invalid arguments, missing resource). The result is either infinite retry loops or premature abandonment of valid tool calls.

Pattern: Structured Error Contracts

Production deployments should standardize on an error contract:

{
  "code": -32000,
  "message": "Tool execution failed",
  "data": {
    "errorType": "transient|permanent|auth",
    "retryable": true,
    "retryAfterMs": 5000,
    "details": "Rate limit exceeded: 100 requests per minute"
  }
}

The errorType and retryable fields give the agent unambiguous signal for decision-making. This pattern is not part of the MCP specification but is widely adopted in production deployments at scale, based on practices documented in the taxonomy paper’s analysis of production MCP setups [2].

The Roadmap Ahead

MCP’s 2026 roadmap prioritizes transport scalability, agent-to-agent communication, and governance [4]. The protocol’s rapid adoption — 41% of surveyed organizations in production within 18 months of the initial November 2024 announcement — means the gap between early adopters and production-grade maturity will widen. Organizations that invest now in the patterns described here — code execution for context management, sandboxed containment for security, structured descriptions for reliability, and standardized error contracts for resilience — will be the ones whose MCP infrastructure survives at scale.

The rest will rediscover, one incident at a time, that a protocol that connects an AI agent to the internet is only as reliable as its production deployment patterns.

---

References

[1] Anthropic, “Code execution with MCP: building more efficient AI agents,” Nov 2025. https://www.anthropic.com/engineering/code-execution-with-mcp

[2] M. Taraghi et al., “Real Faults in Model Context Protocol (MCP) Software: a Comprehensive Taxonomy,” arXiv:2603.05637, Mar 2026. https://arxiv.org/abs/2603.05637

[3] NVD, “CVE-2025-53967 — Framelink Figma MCP Server Remote Code Execution,” Oct 2025. https://nvd.nist.gov/vuln/detail/CVE-2025-53967

[4] Stacklok, “State of Model Context Protocol in Software 2026,” Jan 2026. https://stacklok.com/wp-content/uploads/2026/01/State-of-MCP-in-Software-2026_FINAL.pdf

[5] EclipseSource, “MCP and Context Overload: Why More Tools Make Your AI Agent Worse,” Jan 2026. https://eclipsesource.com/blogs/2026/01/22/mcp-context-overload/

[6] “Model Context Protocol (MCP) Tool Descriptions Are Smelly! Towards Systematic Tool Description Engineering,” arXiv:2602.14878, Feb 2026.

[7] Anthropic, “Introducing advanced tool use on the Claude Developer Platform,” Nov 2025. https://www.anthropic.com/engineering/advanced-tool-use