cs.SEMar 12, 2026

Bridging Protocol and Production: Design Patterns for Deploying AI Agents with Model Context Protocol

Authors: Vasundra Srinivasan

Read PDF
Ask AI
Cite

Copy citation

DOINot available for this paper

Abstract

The Model Context Protocol (MCP) standardizes how AI agents discover and invoke external tools, with over 10,000 active servers and 97 million monthly SDK downloads as of early 2026. Yet MCP does not yet standardize how agents safely operate those tools at production scale. Three protocol-level primitives remain missing: identity propagation, adaptive tool budgeting, and structured error semantics. This paper identifies these gaps through field lessons from an enterprise deployment of an AI agent platform integrated with a major cloud provider's MCP servers (client name redacted). We propose three mechanisms to fill them: (1) the Context-Aware Broker Protocol (CABP), which extends JSON-RPC with identity-scoped request routing via a six-stage broker pipeline; (2) Adaptive Timeout Budget Allocation (ATBA), which frames sequential tool invocation as a budget allocation problem over heterogeneous latency distributions; and (3) the Structured Error Recovery Framework (SERF), which provides machine-readable failure semantics that enable deterministic agent self-correction. We organize production failure modes into five design dimensions (server contracts, user context, timeouts, errors, and observability), document concrete failure vignettes, and present a production readiness checklist. All three algorithms are formalized as testable hypotheses with reproducible experimental methodology. Field observations demonstrate that while MCP provides a solid protocol foundation, reliable agent tool integration requires infrastructure-level mechanisms that the specification does not yet address.

Figures & tables

DimensionMCPRESTGraphQL
Tool discoveryRuntime via tools/list ; agent learns available tools dynamicallyNone; endpoints must be hard-coded or documented out-of-bandIntrospection query provides schema, but no semantic descriptions
Capability negotiationinitialize handshake advertises features (async, sampling, etc.)None; client must know server capabilities a prioriNone; schema is static
Agent compatibilitySupported natively by Claude, ChatGPT, Cursor, VS Code, Copilot, and 500+ clientsRequires per-platform adapterRequires per-platform adapter
Async operationsMCP Tasks (experimental) with polling and progressWebhooks or polling (no standard)Subscriptions (WebSocket)
Error semanticsTwo-tier: protocol (JSON-RPC) + tool ( isError )HTTP status codes onlyerrors array with extensions
User contextGap: not in spec (broker pattern required)Standard: OAuth headersStandard: context headers
Table 1: Protocol comparison for agent-to-tool communication
Figure 1: End-to-end deployment architecture. Solid arrows indicate request flow; the dashed arrow shows OpenTelemetry trace propagation across all layers.
Figure 2: The CABP broker pipeline. Stages 2 and 3 can reject requests (dashed red arrows). Stage 4 forwards the enriched request to the MCP server. Stage 5 filters the response before returning to the agent.
ToolTypical LatencyCategory
FetchResources200msRead
FetchServices150msRead
FetchUsageLimits300msRead
CreateLimitRequest400msWrite
Planner overhead∼\sim 500msSystem
Total∼\sim 1,550ms 
Table 2: Latency budget for a 4-tool sequential chain
Figure 3: Turn budget consumption for a 4-tool sequential chain. Top: nominal case completes with headroom. Bottom: a p99 latency spike in the third tool exhausts the entire budget.
Figure 4: Two-tier error handling flow. Tier 1 (protocol) errors are handled automatically by the MCP framework. Tier 2 (tool) errors are injected into the agent’s context, where the retryable flag and suggested_action determine recovery behavior.
CategoryMetrics
Per-Requestrequest_id , tool_name , user_id , tenant_id , timestamp , latency_ms , status , error_code , sanitized input_params , output_size_bytes
Aggregatedp50/p95/p99 latency per tool, success rate per tool, requests/sec per tenant, error rate by type, cache hit rate, circuit breaker state
Health/health endpoint (200 = alive), /ready endpoint (200 = can serve traffic), upstream dependency health, connection pool utilization
SecurityAuth failures per source IP, token validation failures, cross-tenant access attempts (target: 0), rate limit violations per user
Table 3: MCP server instrumentation taxonomy
IDThreatAttack VectorImpactPrimary Mitigation
T1Prompt injectionMalicious tool response dataAgent manipulationResponse sanitization + output schema enforcement
T2Data exfiltrationTool input parametersData leakageInput minimization + broker auditing + egress controls
T3Privilege escalationTool chain manipulationUnauthorized writesBroker-enforced ACLs + write confirmation
T4Denial of serviceSlow/large tool responsesBudget exhaustionPer-tool timeouts + response size limits + circuit breakers
Table 4: MCP threat model summary
Figure 5: Static vs. ATBA budget allocation for a 100s turn budget across 4 tools. ATBA assigns proportionally larger budgets to high-variance tools (FetchUsageLimits, CreateLimitRequest) and tighter budgets to consistently fast tools.
More in this topic

Tool-Using Agents

Tool-using agents plan and act through external tools, APIs, software interfaces, and environments to complete tasks beyond language generation.

See all 277 papers

Explore similar work

CardsList
Sep 22, 2026

A2M: Trace-Optimized Agent Hijacking in the MCP Ecosystem

Agents using the Model Context Protocol (MCP) rely on semantic matching to select tools from third-party servers, exposing a semantic supply-chain risk through attacker-controlled metadata and outputs. We introduce A2M (Attraction-to-Manipulation), a two-stage black-box framework for hijacking MCP agents. The Attraction phase optimizes tool metadata to increase invocation probability; the Manipulation phase uses execution traces to refine adversarial tool returns that steer agents toward attacker-desired outcomes. On LiveMCPBench, direct attacks optimized and evaluated on GLM-4.6 achieve a macro-average malicious tool invocation rate of 93.6% across four scenarios, increase weighted token costs to 32.4×\times the benign baseline under Cognitive Denial of Service, and attain a mean attack success rate of 74.4% across Information Exfiltration, Environment Integrity Compromise, and Reasoning Derailment. Transfer to four other models without re-optimization yields corresponding macro-averages of 63.6%, 2.7×\times, and 24.5%. These findings motivate stronger tool vetting and runtime isolation in MCP ecosystems. Code is publicly available at https://github.com/Lilaizhen/A2M.

Laizhen Li, Xuan Wang, Peicheng Zhao +4

Shenzhen Institutes of Advanced Technology, Chinese Academy of Sciences · University of Chinese Academy of Sciences · Nanyang Technological University +3

MCP SecurityAI Agent SecurityBlack-Box Adversarial Attacks
AskPDF
Sep 28, 2026

MCP Error Messages Written for Developers Hurt the Most Capable Agents Most

Many Model Context Protocol (MCP) servers wrap web APIs built for human developers, and their error messages tell the reader to run a command, edit a configuration, open a web page or wait. Many agents that read them can only call the server's tools. In 150 widely used MCP servers, 949 of 3,001 error messages tell the caller what to do next, and half of these steps depend on something the server cannot see about the caller. On credential errors, 62 of 67 steps ask for a terminal command, a configuration change or a web page; on rate limits, 20 of 30 say to wait and retry without naming the call to repeat. We tested five OpenAI models that act only through the tools of Berkeley Function Calling Leaderboard tasks, and the agents did what the step said. On expired credentials, a terminal command in the step left 45% of tasks recovered, and the loss it caused grew from 18 points for GPT-5.5 to 69 for GPT-6 Astra. On a rate limit, GitHub's "Wait before retrying." left 6%. We tested two remedies. For MCP developers, naming a server tool in the step raised recovery on expired credentials to 84%, with the login tool in place of the command, and on a rate limit to 88%, with the call to repeat in place of the bare wait. For agent developers, deleting the step with a one-sentence prompt before the model reads it raised recovery on expired credentials to 82%.

Xiaonan Xu, Wenjing Wu

College of Computing, Georgia Institute of Technology, Atlanta, GA 30332, USA · Department of Computer Science, University of Colorado Boulder, Boulder, CO 80309, USA

LLM Tool UseModel Context ProtocolLLM Agent ReliabilityError Feedback
AskPDF
Mar 25, 2026

AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A

AI agents increasingly call tools via the Model Context Protocol (MCP) and delegate to other agents via Agent-to-Agent (A2A), yet neither protocol verifies agent identity. A scan of approximately 2,000 MCP servers found all lacked authentication. In our survey, we did not identify a prior implemented protocol that jointly combines public-key verifiable delegation, holder-side attenuation, expressive chained policy, transport bindings across MCP/A2A/HTTP, and provenance-oriented completion records. We introduce Invocation-Bound Capability Tokens (IBCTs), a primitive that fuses identity, attenuated authorization, and provenance binding into a single append-only token chain. IBCTs operate in two wire formats: compact mode (a signed JWT for single-hop cases) and chained mode (a Biscuit token with Datalog policies for multi-hop delegation). We provide reference implementations in Python and Rust with full cross-language interoperability. Compact mode verification takes 0.049ms (Rust) and 0.189ms (Python), with 0.22ms overhead over no-auth in real MCP-over-HTTP deployment. In a real multi-agent deployment with Gemini 2.5 Flash, AIP adds 2.35ms of overhead (0.086% of total end-to-end latency). Adversarial evaluation across 600 attack attempts shows 100% rejection rate, with two attack categories (delegation depth violation and audit evasion through empty context) uniquely caught by AIP's chained delegation model that neither unsigned nor plain JWT deployments detect.

Sunil Prakash

Indian School of Business, India

AI Agent SecurityTool Access Control for LLM AgentsLLM Agent VerificationCapability-Based Security
AskPDF