Paper deep dive
MCP Server Architecture Patterns for LLM-Integrated Applications
Carson Rodrigues, Oysturn Vas
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 96%
Last extracted: 7/5/2026, 3:47:57 AM
Summary
This industry experience paper identifies and catalogs five recurring architectural patterns for Model Context Protocol (MCP) servers: Resource Gateway, Tool Orchestrator, Stateful Session Server, Proxy Aggregator, and Domain-Specific Adapter. The research, based on a corpus of 15 servers (including production servers from the ANSYR platform), also identifies four anti-patterns (The God Tool, Unsanitized Resource Content, Synchronous Long-Running Operations, and Missing/Vague Tool Descriptions) and evaluates the impact of tool counts on LLM selection accuracy. The study provides quantitative validation through inter-rater reliability testing and transport overhead measurements.
Entities (10)
Relation Signals (4)
Anthropic â introduced â Model Context Protocol
confidence 100% · The Model Context Protocol (MCP), introduced by Anthropic in November 2024
Claude-Haiku-4.5 â isaffectedby â tool-count limit
confidence 100% · tool-selection accuracy drops below 90% between 10 and 15 tools per context for Claude Haiku 4.5
Resource Gateway â isapatternof â Model Context Protocol
confidence 100% · catalogues five recurring MCP server architectural patterns... Resource Gateway...
ANSYR â uses â Model Context Protocol
confidence 90% · five production servers from the ANSYR voice AI platform
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:The Model Context Protocol (MCP), introduced by Anthropic in November 2024, defines a standardized interface for connecting large language models (LLMs) to external tools, data sources, and services. Within months of release, hundreds of community-built MCP servers appeared on GitHub, but no software-maintenance literature has yet described how the ecosystem is being structured in production. This industry experience paper catalogues five recurring MCP server architectural patterns observed across an enumerated corpus of fifteen independently developed servers (five production servers from the ANSYR voice AI platform plus ten public servers from the official MCP registry): Resource Gateway, Tool Orchestrator, Stateful Session Server, Proxy Aggregator, and Domain-Specific Adapter. Each pattern is described in the structured form of Gamma et al.: context, problem, solution, and consequences. We also document four anti-patterns and a set of cross-cutting concerns around authentication, versioning, and observability. The quantitative evaluation contributes three measurements: inter-rater reliability of the taxonomy across two independent LLM raters on 54 held-out servers (Cohen's kappa = 0.76), which also localizes three pattern-boundary ambiguities; transport overhead measured end-to-end on loopback and modeled for cross-host paths; and a tool-count study showing tool-selection accuracy drops below 90% between 10 and 15 tools per context for Claude Haiku 4.5 and between 20 and 30 tools for Sonnet 4. Code, corpus, and prompts are released as a replication package.
Tags
Links
- Source: https://arxiv.org/abs/2606.30317v1
- Canonical: https://arxiv.org/abs/2606.30317v1
Trouble viewing inline? Open PDF directly â
Full Text
45,124 characters extracted from source content.
Expand or collapse full text
MCP Server Architecture Patterns for LLM-Integrated Applications Carson Rodrigues Celabe carson@celabe.com Oysturn Vas University of Waterloo ovas@uwaterloo.ca AbstractâThe Model Context Protocol (MCP), introduced by Anthropic in November 2024, defines a standardized interface for connecting large language models (LLMs) to external tools, data sources, and services. Within months of release, hundreds of community-built MCP servers appeared on GitHub, but no software-maintenance literature has yet described how the ecosystem is being structured in production. This industry experience paper catalogues five recurring MCP server architec- tural patterns observed across an enumerated corpus of fifteen independently developed servers (five production servers from the ANSYR voice AI platform plus ten public servers from the official MCP registry): Resource Gateway, Tool Orchestrator, Stateful Session Server, Proxy Aggregator, and Domain-Specific Adapter. Each pattern is described in the structured form established by Gamma et al. [1]: context, problem, solution, and consequences. We also document four anti-patterns and a set of cross-cutting concerns around authentication, versioning, and observability. Quantitative evaluation contributes three measurements: inter- rater reliability of the taxonomy across two independent LLM raters on 54 held-out servers (Cohenâs Îș = 0.76), which also localizes three pattern-boundary ambiguities; transport overhead measured end-to-end on loopback (stdio: 0.01 ms p 50 ; streamable- http: 0.39 ms p 50 ) and modeled for cross-host paths from same- region network baselines (â30 ms p 50 baseline plus protocol overhead); and a tool-count study showing accuracy drops below 90% between 10 and 15 tools per context for Claude Haiku 4.5 and between 20 and 30 tools for Sonnet 4. Code, corpus, and prompts are released at https://github.com/rodriguescarson/ mcp-patterns-icsme2026. Index TermsâModel Context Protocol, MCP, LLM integra- tion, software architecture, software maintenance, software evo- lution, design patterns, AI agents, industry experience I. INTRODUCTION Connecting LLMs to external systems used to mean hand- rolling function-calling schemas in prompt templates and re- implementing the glue code for every new model. The Model Context Protocol (MCP) [2] standardizes this: a clientâserver protocol where MCP servers expose tools (callable functions), resources (URI-addressed data), and prompts (reusable tem- plates) to any MCP-compatible client. A single server works with Claude, GPT-4, Gemini, or any other compliant agent without modification. The protocol has been adopted quickly. Hundreds of servers appeared on GitHub and the MCP registry [3] within months of release. What is missing is a body of architectural guid- ance to help practitioners make good design decisions, and a maintenance-and-evolution view of how the ecosystem is structuring itself in production. Questions that come up re- peatedly in practice include: âą How should tools be decomposed? When does one tool become two? âą When is server-side state justified, and how should it be managed? âą How should an operator aggregate capabilities from many servers? âą When should a server wrap a complex API rather than exposing it directly? These are not MCP-specific questions; they are API design questions seen through the specific constraints of LLM clients. LLMs select tools by reading natural language descriptions, not by browsing documentation or examining schemas. They are sensitive to schema complexity in ways that human devel- opers are not. A tool that a human engineer would find obvious can be invisible or ambiguous to an LLM if the description is missing or poorly written. This paper draws on production MCP server deployments at Celabe (operator of the ANSYR voice AI platform, with five MCP servers in production since late 2024) plus a review of the public MCP server ecosystem to identify five patterns that address these questions, four anti-patterns, and a set of cross- cutting concerns. The patterns follow the structured format of Gamma et al. [1] and apply the framing of enterprise integra- tion patterns [4] to the MCP context. Section I enumerates the corpus and the coding protocol; Sections IVâV present the patterns and anti-patterns; Section VI reports quantitative eval- uation; Section VIII discusses limitations, threats to validity, and reproducibility. I. BACKGROUND A. The Model Context Protocol MCP [2] is built on JSON-RPC 2.0 and defines three primitives. Tools are callable functions with a name, nat- ural language description, and JSON Schema input speci- fication. Resources are URI-addressed endpoints the LLM can read; they can be static (files, documents) or dynamic (live database queries). Prompts are parameterized templates managed server-side, surfaced to users or agents on request. Two transport options are defined: stdio for local in-process communication and streamable-http (HTTP with optional server-sent events) for remote servers. arXiv:2606.30317v1 [cs.SE] 29 Jun 2026 TABLE I EACH MCP PATTERN HAS A CLASSICAL ANCESTOR; THE CONTRIBUTION IS THE LLM-CLIENT DELTA. MCP patternAncestorLLM-client delta Resource GatewayRepository / RESTresources named for LLM retrieval Tool OrchestratorFacade / Mediatortool set sized to selection accuracy StatefulSession Server Session / Mementostate implicit, not in the prompt Proxy AggregatorProxy / API gateway partitions tools to fit con- text Domain-Specific Adapter Adapter (GoF)validationasnatural- language guardrails B. Relationship to Prior Work MCP extends the function-calling capabilities introduced by OpenAI [5] and Anthropic [6] but separates the tool imple- mentation from the LLM that calls it. The clearest analogy is the Language Server Protocol (LSP) [7]: LSP standardized the interface between editors and language intelligence tools, enabling the same server to work in VS Code, Neovim, and Emacs without modification. MCP aims for the same decoupling between agent and capability provider. The pattern methodology used here draws on Gamma et al. [1], Fowlerâs enterprise application patterns [8], and Hohpe & Woolfâs integration patterns [4]. We apply the same struc- tured description format (context, problem, solution, conse- quences, known uses), adapted to the constraints of LLM- facing APIs. We do not claim the structural skeletons are new; each has a clear ancestor in classical software architecture (Table I). The contribution is the delta introduced when the client is an LLM that selects operations by reading natural- language descriptions rather than by consulting documenta- tion: a constraint absent from REST [9], GraphQL [10], and LSP [7], and the reason the anti-patterns (§V) and the tool- count limit (§VI-C) arise at all. C. LLM Tool Use and Agent Architecture Prior work on LLM tool use spans evaluation benchmarks (ToolBench-style suites [11], function-calling benchmarks [5], [6]), agent architectures that compose tools at runtime (Re- Act [12], AutoGPT-style loops [13], LangChain [14]), and infrastructure for browser-controlling agents [15]. These con- tributions focus on the client side: how an agent decides which tool to call. MCP shifts attention to the server side: how the catalog of capabilities is structured, named, and grouped. Our pattern catalog complements rather than replaces this prior work, providing vocabulary for the architectural decisions a server author makes once a protocol like MCP exists. A nascent literature studies MCP itself, but from angles or- thogonal to architecture. Hou et al. [16] survey MCPâs security threats and open research directions; Hasan et al. [17] mine public MCP servers for security and maintainability smells; and Guo et al. [18] measure the >8,000-server ecosystem at scale. These characterize what the ecosystem contains and TABLE I ENUMERATED CORPUS OF FIFTEEN MCP SERVERS USED TO DERIVE THE PATTERN CATALOG. PUBLIC SERVERS LINK TO THEIR CANONICAL IMPLEMENTATION; ANSYR (PRODUCTION) SERVERS ARE ANONYMIZED. ServerCategoryPrimary pattern Production (Celabe / ANSYR), N = 5 Server-AVoice-tool aggregatorTool Orchestrator Server-BPer-call dialogue ses- sion StatefulSession Server Server-CTelephony/SIP adapter Domain-Specific Adapter Server-DCustomer/CRMread gateway Resource Gateway Server-EMulti-tenant aggrega- tor Proxy Aggregator Public (modelcontextprotocol/servers), N = 10 filesystemLocal filesResource Gateway postgresRelational DBResource Gateway sqliteEmbedded DBResource Gateway githubVCS / issue APITool Orchestrator slackMessaging APITool Orchestrator brave-searchWeb searchTool Orchestrator fetchGeneric HTTPTool Orchestrator puppeteerBrowser automationStatefulSession Server memoryPer-session KV storeStatefulSession Server gitRepository stateStatefulSession Server where it is vulnerable; none catalogs the recurring server-side design structures, or the LLM-client constraint that shapes them, which is the gap this paper addresses. Our anti-patterns (§V) and the maintainability smells of Hasan et al. are com- plementary views of the same servers. I. METHODOLOGY AND CORPUS A. Corpus The pattern catalog was derived from an enumerated corpus of fifteen independently developed MCP servers: five production servers from the ANSYR voice AI plat- form (operated by Celabe; deployed late 2024 through early 2025) and ten public servers from the official modelcontextprotocol/servers registry. Table I lists the corpus. ANSYR servers are identified by anonymized handles (Server-A through Server-E) for IP reasons, with deployment category and primary pattern disclosed in the table; public servers are listed by full GitHub path. The com- plete machine-readable corpus, with timestamps and primary- pattern assignments, is included in the replication package (corpus.json). B. Coding Protocol Data extraction. For each server we read a fixed set of sources and extracted five artifacts: (i) the tool, resource, and prompt registrations (the setRequestHandler calls and their JSON schemas) from source code; (i) the transport configuration; (i) any server-side session or state handling; (iv) delegation to other MCP servers; and (v) domain-specific validation or business logic. For the ten public servers these came from the GitHub repository (source code, README, and published documentation); for the five production servers, from the source and deployment configuration. We did not rely on README prose alone, since a README often omits the structural decisions of interest. Coding. We then applied a two-cycle qualitative coding procedure [19]. First-cycle open coding by the first author labeled the recurring structural decisions in each extracted artifact. A second-cycle pattern coding pass [19] grouped the first-cycle codes into candidate patterns by shared structure and shared problem; a candidate was promoted to the catalog only if it appeared independently in at least two servers and addressed a problem without an obvious prior solution. The second author independently reviewed the resulting taxonomy against the corpus, and the two co-authors resolved disagree- ments by discussion. Because this review was a verification pass rather than independent dual coding, we measure inter- rater reliability separately, on a held-out corpus with two independent raters, in §VI-A (Cohenâs Îș = 0.76 between raters). IV. FIVE MCP ARCHITECTURE PATTERNS A. Pattern 1: Resource Gateway Also known as: Data Facade, Context Provider 1) Context: An LLM agent needs to read structured data from one or more backend systems (databases, document stores, third-party APIs) and ground its responses in that data. 2) Problem: How should an MCP server expose backend data to an LLM in a way that is queryable, protected against prompt injection via untrusted data, and consistent across backend schema changes? 3) Solution: Structure the server as a gateway that mediates all data access. Expose read operations as Resources (list, get by ID) and parameterized queries as Tools when the query parameters would be unsafe in an open URI template. Insert a sanitization layer that strips or escapes injected content from backend responses before they reach the LLM. Listing 1. Resource Gateway: MongoDB document exposure with sanitization server.setRequestHandler(ListResourcesRequestSchema, async () => ( resources: await db.collection(âdocumentsâ) .find(, projection: _id: 1, title: 1, updatedAt: 1 ) .toArray() .then(docs => docs.map(d => ( uri: âdoc://$d._idâ, name: d.title, mimeType: âapplication/jsonâ ))) )); server.setRequestHandler(ReadResourceRequestSchema, async (req) => const id = req.params.uri.replace(âdoc://â, â); const doc = await db.collection(âdocumentsâ). findOne( _id: id ); // Strip injected content before the LLM sees it return contents: [ uri: req.params.uri, text: sanitize(JSON.stringify(doc)) ] ; ); 4) Consequences: Benefits: Single enforcement point for access control; the LLM sees a stable interface even when the backend schema changes; prompt injection risk is contained at one layer. Liabilities: An extra network hop on every read; schema changes in the backend propagate to the MCP server; complex joins or aggregations can be awkward to express as resources. 5) Known Uses: Database connectors (PostgreSQL, Mon- goDB), document store bridges (Notion, Google Drive), REST API wrappers (GitHub, Jira, Linear). B. Pattern 2: Tool Orchestrator Also known as: Action Hub, Workflow Facade 1) Context: An LLM agent needs to perform actions that span multiple external systems: for example, creating a ticket, notifying an assignee, and posting to a channel. 2) Problem: How should multi-system workflows be ex- posed without requiring the LLM to understand each systemâs API, manage intermediate state across calls, or handle partial failure? 3) Solution: Expose composite tools that encapsulate com- plete workflows. Each tool performs all sub-calls internally and returns a single summary. The LLM sees one operation; the server handles the orchestration. Listing 2. Tool Orchestrator: cross-system workflow as one tool server.setRequestHandler(CallToolRequestSchema, async (req) => if (req.params.name === âcreate_and_notify_ticketâ ) const title, description, assignee = req. params.arguments; // Three API calls, one tool const ticket = await jira.createIssue( title, description ); await slack.postMessage(assignee.slackId, âTicket $ticket.key assigned to youâ); await email.send(assignee.email, âNew ticket: $ ticket.keyâ); return content: [ type: âtextâ, text: âCreated $ticket.key, notified $ assignee.nameâ ] ; ); 4) Consequences: Benefits: Reduces LLM reasoning bur- den; enables transaction-like semantics for multi-step opera- tions; hides API surface area that the LLM does not need to reason about. Liabilities: Individual sub-tools are harder to reuse when workflows change; partial failure handling is the serverâs responsibility rather than the LLMâs; workflow logic is now encoded in two places (the tool and whatever documentation describes it). 5) Known Uses: CI/CD automation servers, DevOps work- flow tools, customer support action hubs. C. Pattern 3: Stateful Session Server Also known as: Conversational Context Server 1) Context: An LLM agent conducts a multi-turn interac- tion where later calls depend on state established earlier: an open file, an in-progress database transaction, an authenticated user. 2) Problem: MCP tool calls are stateless request-response by default. How should state that must persist across multiple calls within a session be managed? 3) Solution: Generate a session identifier on connection and include it in all tool responses. All subsequent tool calls carry the session ID. The server maintains per-session context in memory (or Redis for horizontally-scaled deployments). Sessions expire on inactivity. Listing 3. Stateful Session Server: context preserved across calls const sessions = new Map<string, SessionContext>(); server.setRequestHandler(CallToolRequestSchema, async (req) => const sessionId = req.params.arguments._sessionId as string; let session = sessions.get(sessionId); if (req.params.name === âopen_fileâ) const content = await fs.readFile(req.params. arguments.path, âutf-8â); sessions.set(sessionId, filePath: req.params. arguments.path, content, edits: [] ); return content: [ type: âtextâ, text: âOpened $req.params.arguments.path ($ content.length chars)â ] ; if (req.params.name === âedit_fileâ) if (!session?.filePath) throw new Error(âNofile openinthissessionâ); session.edits.push(req.params.arguments.edit); return content: [ type: âtextâ, text: âEdit appliedâ ] ; ); 4) Consequences: Benefits: Multi-turn workflows become natural; redundant data transfer is eliminated; transactional semantics are achievable. Liabilities: Memory leaks if sessions are not reaped; hor- izontal scaling requires a distributed session store; the LLM must reliably pass session IDs, which is not guaranteed. 5) Known Uses: Code editing agents (open â edit â save), database transaction servers, multi-step form assistants. D. Pattern 4: Proxy Aggregator Also known as: MCP Router, Multi-Server Facade 1) Context: An LLM agent needs capabilities from many distinct MCP servers, but the client configuration limits how many server connections it can maintain, or an operator needs centralized authentication and logging across a fleet. 2) Problem: How should multiple upstream MCP servers be presented as a single endpoint without losing per-server identity, versioning, or failure isolation? 3) Solution: Build a proxy server that connects to N upstream servers, namespacing tool names by server to prevent collisions and routing each call to the correct upstream. Two variants differ in what they expose. A static-merge aggregator surfaces the union of all upstream tools at once; this simplifies client configuration but raises the visible tool count, which degrades LLM selection accuracy once the merged catalog exceeds the budget of §VI-C. A scoped aggregator instead exposes only the subset of upstream tools relevant to the current task, retrieving candidates per request (retrieval-over- tools [20]) rather than listing the whole fleet. Reach for the scoped variant whenever aggregation would otherwise push a context past the tool-count limit; the listing below shows the static-merge core, onto which a per-request filter is layered for the scoped variant. Listing 4. Proxy Aggregator: namespaced routing across upstream servers // Build merged tool list with namespace prefixes const allTools = (await Promise.all( upstreamServers.map(async (s) => const tools = await s.client.listTools(); return tools.map(t => ( ...t, name: â$s.namespace__$t.nameâ, // e.g. " github__create_pr" _upstream: s )); ) )).flat(); // Route by namespace prefix server.setRequestHandler(CallToolRequestSchema, async (req) => const [ns, ...rest] = req.params.name.split(â__â); const upstream = upstreamServers.find(s => s. namespace === ns); return upstream.client.callTool( name: rest.join( â__â), arguments: req.params.arguments ); ); 4) Consequences: Benefits: Simplifies client configuration; enables centralized auth and audit logging; supports tool discovery across a large server fleet. Liabilities: Introduces a single point of failure; adds one network hop to every call; namespace collisions require careful governance; upstream server failures surface through the ag- gregate; and the scoped variant adds a per-request tool-retrieval step that must itself be fast and accurate. 5) Known Uses: Enterprise MCP gateways, developer plat- form aggregators, multi-domain AI assistant backends. E. Pattern 5: Domain-Specific Adapter Also known as: Semantic Layer, Domain Translator 1) Context: An existing system has a useful but LLM- hostile API: machine-readable identifiers, low-level operations, complex authentication flows, or output formats that require substantial post-processing. 2) Problem: How should an MCP server translate a com- plex, low-level API into a form that an LLM can use accu- rately, without reimplementing business logic in the server? 3) Solution: Build a semantic adapter that wraps the ex- isting API and adds: human-readable tool descriptions that guide LLM selection; input normalization (accepting natural language dates, names, fuzzy identifiers); output enrichment (resolving IDs to display names); and error translation (con- verting API error codes to plain English). 4) Consequences: Benefits: LLM tool selection accuracy improves when descriptions are precise; API complexity is isolated to the adapter; backend API versioning can be ab- sorbed in the adapter layer. Liabilities: The adapter must be updated when the under- lying API changes; over-engineering is a real risk when the underlying API is already LLM-friendly. 5) Known Uses: CRM adapters (Salesforce, HubSpot), financial data connectors, healthcare record systems. V. ANTI-PATTERNS The four anti-patterns below were not the dominant struc- ture of any server in the derivation corpus (Table I); a well- maintained server avoids them. We recorded them during development and code review of the production servers as recurring local mistakes that degrade LLM tool use, and cross- checked each against issues and pull-request discussions in the public repositories. We report them because each corresponds to a concrete, repeated failure mode with a known fix, which is the useful unit for a practitioner even though no single server in the corpus is defined by one. A. The God Tool A single tool accepts a large, undifferentiated schema such as do_anything(action: string, params: object), and the LLM must reason about what âactionâ means. Tool selection accuracy collapses. The fix is decom- position: give each distinct operation its own named tool with a precise schema and description. B. Unsanitized Resource Content Returning user-generated content (comments, document bodies, form inputs) directly in resource responses without sanitization. A document containing âIgnore previous instruc- tions and. . . â will be processed by the LLM as instruction, not data. Sanitize all externally-sourced content before it enters the MCP response. C. Synchronous Long-Running Operations Exposing video encoding, large file processing, or any operation that takes more than a few seconds as a synchronous tool. MCP has no built-in async callback mechanism; the client times out. Pattern: return a job ID synchronously and expose a separate poll_job(id) tool. D. Missing or Vague Tool Descriptions Providing a tool with name send_message and no de- scription, or a description that simply restates the name. LLMs choose tools by reading descriptions, not by inspecting schemas. Write descriptions that explain what the tool does, when to use it, and what it returns, as if explaining it to someone who has never seen it before. VI. QUANTITATIVE EVALUATION To complement the qualitative pattern descriptions we ran three experiments: a taxonomy reliability study in which two independent LLM raters classify 54 held-out servers (§VI-A); a transport latency benchmark with end-to-end measured rows for in-host transports and modeled rows for cross-host trans- ports (§VI-B); and an analysis of tool-count vs. selection accuracy (§VI-C). All experiments are reproducible from the replication package at https://github.com/rodriguescarson/ mcp-patterns-icsme2026. A. Pattern Classification and Inter-Rater Reliability We evaluate whether the five-pattern taxonomy can be ap- plied reliably by independent raters, and where its boundaries are fuzzy. We assembled a held-out corpus of 54 servers (from the official MCP registry and popular community servers, none used to derive the patterns) and wrote neutral, function-focused descriptions that state what each server does without naming any architecture (e.g., âstage changes, commit, show diffs, and switch branches in a repositoryâ). Two independent raters (Claude Haiku 4.5 and Claude Sonnet 4, at temperature 0 for reproducibility, each given only the five pattern definitions) classified every server. We report Cohenâs Îș between the raters (bootstrap 95% CI over servers) and each raterâs agreement with the authorsâ labels. We deliberately avoid the easier protocol of classifying canonical descriptions that name their own architecture: a pilot on author-written canonical descrip- tions scored 97%, but that measures description wording, not whether the taxonomy survives realistic, architecture-neutral inputs. Inter-rater agreement is substantial: Îș = 0.76 (95% CI [0.62, 0.88]; 81.5% raw agreement), so independent raters apply the taxonomy consistently. Agreement with the au- thorsâ intended labels is lower, at 68.5% (Haiku) and 75.9% (Sonnet), and the disagreements are systematic, concentrating at three boundaries. (1) Statefulness is invisible from func- tion: every stateful server (git, puppeteer, playwright, selenium, . . . ) is read as a Tool Orchestrator, because a capability list enumerates actions without revealing server-side session state. (2) Domain logic is invisible: domain adapters (kubernetes, salesforce, shopify, fhir) are split between Tool Orchestrator and Resource Gateway, since vali- dation and business rules do not surface in a function descrip- tion. (3) Read-style tools resemble gateways: retrieval-oriented orchestrators (sentry, notion) are reclassified as Resource Gateways. In contrast to the 97% pilot on architecture-naming descriptions, then, agreement with the intended label is 69â 76% once descriptions are architecture-neutral, and the resid- ual errors concentrate at these three boundaries rather than scattering. Accordingly we treat statefulness and domain-logic as cross-cutting attributes a server may carry alongside its primary structural pattern, rather than as mutually exclusive categories, and we recommend that pattern assignment draw on implementation signals, not a capability list alone. TABLE I MCP TRANSPORT LATENCY. ROWS LABELLED measured ARE END-TO-END LOOPBACK MEASUREMENTS (N = 100 CALLS + 10 WARM-UP). ROWS LABELLED modeled ARE LOOPBACK OVERHEAD PLUS A DOCUMENTED SAME-REGION NETWORK-RTT CALIBRATION; THEY ARE NOT DIRECT MEASUREMENTS. TransportMethodp 50 p 95 p 99 stdio (local)measured 0.01 ms0.02 ms0.02 ms streamable-http (loopback)measured 0.39 ms0.45 ms0.48 ms streamable-http(same-region remote) modeled30.4 ms80.4 ms 180.4 ms Stateful Session Server (re- mote) modeled38.4 ms 100.4 ms 216.4 ms Proxy Aggregator (remote, sin- gle hop) modeled62.4 ms 160.4 ms 308.4 ms B. Transport Latency Table I reports p 50 , p 95 , and p 99 for five MCP transport configurations. Two rows are measured: a minimal JSON- RPC 2.0 echo server exercised over stdio and over loopback streamable-http (HTTP POST to a local http.server), N = 100 calls per transport plus 10 warm-up calls, isolating the protocol overhead from any LLM round-trip. Three rows are modeled for cross-host paths that require a multi-host deployment we did not instrument: each modeled row is the measured loopback overhead plus an explicit network-RTT calibration constant (same-region HTTPS RTT of â30 ms p 50 , â80 ms p 95 , â180 ms p 99 , consistent with typical same- region cloud HTTPS round-trip distributions reported in the MCP Python SDK benchmarks [21] and pipecat integration data [22]), with per-row calibration source documented in the replication package. The Method column makes this distinction explicit on every row; we carry the same distinction into prose claims throughout the paper. The substantive finding: transport overhead is dominated by network RTT, not by the protocol layer. In-host transport (stdio, loopback streamable-http) adds well under a millisec- ond; the gap between stdio and streamable-http is real but irrelevant in any deployment that crosses a host boundary, where the same-region network RTT is two to three orders of magnitude larger than either protocolâs own overhead. The architecturally significant choices are therefore (a) whether the server is co-located with the client at all, and (b) whether downstream fan-out (Proxy Aggregator) adds another network hop, not which transport encoding is used. C. Tool Count vs. Accuracy (Observational) To characterize tool selection accuracy as a function of context size we report observational data from the ANSYR voice AI platformâs production telemetry, Q1 2025. This is not a fresh controlled experiment for this paper but a retrospective analysis of production logs; the per-bucket numbers and prove- nance are released as tool_count_telemetry.csv in the replication package for independent verification. For each tool-count bucket b â 1, 3, 5, 10, 15, 20, 30, 50 we drew N b = 200 production session turns; in production each turn stdio (local) [measured] streamable-http (loopback) [measured] streamable-http (typical remote, same-region) [modeled] Stateful Session Server (remote) [modeled] Proxy Aggregator (remote) [modeled] 10 2 10 1 10 0 10 1 10 2 Latency (ms, log scale) MCP Transport Latency by Configuration p50 p95 p99 Fig. 1. MCP transport latency (p 50 /p 95 /p 99 , log scale) by configuration; row labels indicate measured vs. modeled. 01020304050 Number of Tools in Context 60 70 80 90 100 Tool Selection Accuracy (%) Recommended ( 10 tools) Accuracy vs. Tool Count (N=200 requests per bucket) Claude Haiku 4.5 Claude Sonnet 4 90% threshold 01020304050 Number of Tools in Context 200 300 400 500 600 700 800 Median Latency (ms) Latency vs. Tool Count (ms, wall clock) Claude Haiku 4.5 Claude Sonnet 4 500ms budget Fig. 2. Tool count vs. accuracy and latency (Claude Haiku 4.5 and Claude Sonnet 4; N b = 200 requests per bucket from ANSYR production logs). Shaded region marks the recommended range (â€10 tools per context). was served by either Claude Haiku 4.5 or Claude Sonnet 4 (model determined by the tenant configuration). Ground truth was the tool the human operator confirmed as correct in the post-call quality review (a routine production audit step). Figure 2 shows accuracy and latency; Wilson 95% confidence intervals are within ±4 percentage points across all buckets. Haiku drops below the 90% accuracy threshold between 10 and 15 tools (91% at 10 tools, 87% at 15); Sonnet maintains â„90% up to 20 tools and drops below at 30 tools. At 10 tools, Haiku achieves 91% accuracy at a median 245 ms; Sonnet achieves 95% at 410 ms. The implication for the Resource Gateway and Tool Or- chestrator patterns is direct: when a single MCP server exposes more thanâ10â15 tools, the scoped Proxy Aggregator variant of §IV-D (per-context tool filtering, also called retrieval-over- tools) should be used to partition the tool space so that only the relevant subset is visible in any one context. Plain static merging would make the problem worse rather than better, so the mitigation is selective exposure, not aggregation by itself. Our threshold is the conservative onset of an effect now docu- mented at larger scale: Gan and Sun [20] report tool-selection success above 90% only up toâ30 candidate tools, degrading sharply beyond â100, and Kate et al. [23] measure a 7â85% accuracy drop as the tool catalog grows. Our production data locates where the degradation begins for a latency-constrained voice deployment; the retrieval-based mitigation of [20] is a concrete instance of the Proxy Aggregator partitioning we recommend. Caveats: the data is observational and from one organiza- tionâs production tool surface; results may differ for tool inven- tories that emphasize semantically overlapping tools or tools with deliberately vague descriptions, and the figures cannot be re-derived purely from the released code (the production session logs themselves are not released). VII. CROSS-CUTTING CONCERNS A. Authentication streamable-http transport supports Bearer token auth. Au- thenticate at the transport layer, not inside tool handlers. Scope tokens to specific tool sets. Log all tool calls with caller identity; debugging LLM behavior without call logs is very difficult. B. Error Handling Return tool errors as structured error content where possible, rather than throwing exceptions. This allows the LLM to see the error, reason about whether to retry, and decide whether to escalate to the user. C. Versioning Include a version field in the serverâs initialize re- sponse. Breaking changes to tool schemas should increment the major version; keep old schemas alive during a migration window rather than forcing immediate client updates. D. Observability Log per tool call: tool name, input hash, latency, output size, error code. These logs are the primary debugging surface for LLM misbehavior. VIII. DISCUSSION A. The LSP Parallel MCP mirrors the intent of the Language Server Protocol [7]: decouple a host (editor or LLM client) from a provider (language server or MCP server) so that providers are reusable across hosts. LSP turned language intelligence from editor- specific plugins into a shared ecosystem; whether MCP does the same for LLM capabilities depends in part on whether a pattern vocabulary emerges to guide good implementations, which this paper aims to seed. B. API Design for LLM Clients The patterns above suggest that MCP server design is funda- mentally an API design problem with one unusual constraint: the client reasons about which API to call by reading natural language descriptions, not by consulting documentation. This inverts the usual API design assumption. Precise, information- dense descriptions are necessary, not optional, and directly determine whether the tool is used correctly. Practitioners who treat tool descriptions as documentation comments to be written quickly after the code is working will find their servers underperform. C. Implications for Practitioners and for Maintenance For a practitioner choosing a structure, the catalog reduces to a few decisions. Expose read-mostly backend data as a Resource Gateway with a sanitization layer; encapsulate multi- system workflows as Tool Orchestrators; reach for a Stateful Session Server only when a turn genuinely depends on earlier state, and budget for session reaping when you do; aggregate a fleet with the scoped Proxy Aggregator variant rather than a static merge; and keep any single context under the â10â15- tool accuracy budget of §VI-C. The maintenance-and-evolution view is where the patterns earn their cost. Each is also a seam that localizes change: a Domain-Specific Adapter absorbs upstream API churn so the LLM-facing surface stays stable; a Proxy Aggregator is the single place to version, authenticate, and audit a fleet; a Resource Gateway confines backend schema migrations to one layer. The same patterns carry maintenance liabilities the author inherits: session stores must be reaped or they leak; statefulness is invisible to clients and to the taxonomy itself (§VI-A), so it must be documented explicitly; and tool descriptions are load-bearing artifacts that drift out of sync with behavior unless reviewed like code. In this light the anti-patterns of §V are recurring maintainability smells, and connect directly to the smell catalog of Hasan et al. [17]. For researchers, three questions follow: independent human dual-coding of the derivation corpus at ecosystem scale; a multi-model rater panel beyond two Claude models, to sep- arate genuine taxonomy ambiguity from shared-LLM blind spots; and a predictive study linking pattern choice to mea- sured latency and reliability, which would turn the catalog from a descriptive vocabulary into an empirical instrument. D. Limitations Four limitations bound the contributions of this paper. (1) The derivation corpus is fifteen servers from one organi- zation plus the official public registry; a recent measurement study catalogs >8,000 public MCP servers [18], and a strati- fied replication at that scale (which we did not attempt) could surface patterns beyond this set. (2) The taxonomy was derived through single-coder open coding with secondary verification, not independent dual coding; we mitigate this with a separate held-out inter-rater study (§VI-A, Îș = 0.76, N = 54) but full independent dual coding of the derivation corpus remains future work. (3) The classification corpus consists of synthetic and real-derived server descriptions, not the running servers themselves; classifier accuracy on production servers may differ. (4) Three of the five rows in the transport-latency table are modeled, not measured end-to-end; we explicitly label the methodology per row to avoid overclaiming. E. Threats to Validity Construct validity: the reliability study (§VI-A) uses two independent LLM raters on held-out servers, which mitigates single-rater bias, but both raters are LLMs and may share blind spots; independent human dual-coding remains future work. Internal validity: the modeled transport rows in Table I compose measured loopback overhead with a network-RTT constant; the constant is calibrated against same-region cloud telemetry but a deployment with cross-region or congested- network paths will see substantially different absolute numbers (the relative ordering of configurations is more stable than the absolute values). External validity: all five ANSYR production servers come from one application domain (voice AI for a single industry); patterns may differ in domains with different operational profiles. Conclusion validity: the reliability corpus (N = 54) yields a bootstrap 95% CI on inter-rater Îș of [0.62, 0.88]; while this is âsubstantialâ agreement, the catalogâs coverage of the full design space should not be over-read from a 54-server sample alone. F. Reproducibility Acompletereplicationpackageispublishedat https://github.com/rodriguescarson/mcp-patterns-icsme2026 underanMITlicense.Itcontains:theenumerated derivationcorpus(corpus.json),the54-server reliabilitycorpusandtwo-raterclassificationscript (kappa_eval.py),thetransportbenchmark (transport_bench.py),theclassificationprompt template(prompts/classification_prompt.txt), theobservationaltool-counttelemetry (tool_count_telemetry.csv), and the dependency manifest(requirements.txt).Bothraters (claude-haiku-4-5-20251001 and Claude Sonnet 4) were queried at temperature 0 for determinism. Per-server predictions for both raters, the inter-rater Îș with its bootstrap CI, and each raterâs agreement with the author labels are written to results_kappa.json; raw transport samples to results/transport_measured.json. G. Conflict of Interest Carson Rodrigues is employed by Celabe, the operator of the ANSYR voice AI platform from which the production half of the corpus is drawn. Oysturn Vas is an academic affiliated with the University of Waterloo and has no com- mercial relationship with Celabe or ANSYR. The pattern catalog was derived from a balanced corpus (5 production + 10 public servers); the classification experiment uses synthetic descriptions and abstractions of public servers (no production telemetry is fed to the classifier), and the tool-count study (§VI-C) is openly labelled as observational ANSYR produc- tion telemetry. IX. CONCLUSION This paper catalogued five recurring MCP server archi- tecture patterns (Resource Gateway, Tool Orchestrator, State- ful Session Server, Proxy Aggregator, and Domain-Specific Adapter) along with four anti-patterns and a set of cross- cutting concerns, derived from an enumerated corpus of fif- teen independently developed servers. We supplemented the qualitative description with three quantitative measurements: substantial inter-rater reliability of the taxonomy (Îș = 0.76 across two independent raters on 54 held-out servers, which also localizes three pattern-boundary ambiguities), end-to- end measurement of in-host transport overhead and explicitly modeled estimates for cross-host paths, and a tool-count study identifying â10â15 tools per context as the practical accu- racy boundary for current Haiku-class models. As the MCP ecosystem matures, three directions remain open for future work: independent inter-coder validation of the taxonomy on a larger and more domain-diverse corpus; quantitative evaluation of LLM tool selection accuracy across pattern variants; and security analysis of MCP server attack surfaces, particularly prompt injection via resources. AI DISCLOSURE Per the ICSME Industry Track AI-content disclosure guide- line, we record the following. Claude Sonnet 4.6 (Anthropic) was used as a writing and editing assistant during manuscript preparation; all final text was reviewed and edited by the human authors and we take full responsibility for it. Claude Haiku 4.5 (claude-haiku-4-5-20251001) and Claude Sonnet 4 are the two independent rater subjects of the relia- bility experiment in §VI-A; the prompts and per-call outputs are released with the replication package. The network-RTT calibration constants in §VI-B are taken from the cited prior measurements (MCP Python SDK and pipecat) and are not LLM-derived. No AI system contributed authorship-level in- tellectual content (research questions, pattern definitions, study design, or claims). We did not use AI to generate or alter the figures. REFERENCES [1] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software.Addison-Wesley, 1994. [2] Anthropic, âModel context protocol specification,â November 2024. [Online]. Available: https://modelcontextprotocol.io/specification [3] â, âModel context protocol reference servers,â 2025. [Online]. Available: https://github.com/modelcontextprotocol/servers [4] G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions.Addison-Wesley Pro- fessional, 2003. [5] OpenAI, âFunction calling and other api updates,â 2023. [Online]. Avail- able: https://openai.com/blog/function-calling-and-other-api-updates [6] Anthropic, âTool use (function calling) â anthropic documenta- tion,â 2024. [Online]. Available: https://docs.anthropic.com/en/docs/ build-with-claude/tool-use [7] Microsoft, âLanguage server protocol specification,â 2016. [Online]. Available: https://microsoft.github.io/language-server-protocol/ [8] M. Fowler, Patterns of Enterprise Application Architecture.Addison- Wesley Professional, 2002. [9] R. T. Fielding, âArchitectural styles and the design of network-based software architectures,â Ph.D. dissertation, University of California, Irvine, 2000. [10] O. Hartig and J. P Ì erez, âSemantics and complexity of GraphQL,â in Proc. The Web Conference (W), 2018, p. 1155â1164. [11] T. Schick, J. Dwivedi-Yu, R. Dess ` ı, R. Raileanu, M. Lomeli, L. Zettle- moyer, N. Cancedda, and T. Scialom, âToolformer: Language models can teach themselves to use tools,â in Advances in Neural Informa- tion Processing Systems 36 (NeurIPS 2023), 2023, published version; arXiv:2302.04761; DOI verified on CrossRef. [12] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, âReact: Synergizing reasoning and acting in language models,â 2022. [Online]. Available: https://arxiv.org/abs/2210.03629 [13] S. Gravitas, âAuto-gpt: An autonomous gpt-4 experiment,â 2023. [Online]. Available: https://github.com/Significant-Gravitas/Auto-GPT [14] H. Chase, âLangchain: Building applications with llms through composability,â2022.[Online].Available:https://github.com/ langchain-ai/langchain [15] Anthropic, âIntroducing computer use, a new claude 3.5 sonnet, and claude 3.5 haiku,â 2024. [Online]. Available: https://w.anthropic. com/news/3-5-models-and-computer-use [16] X. Hou, Y. Zhao, S. Wang, and H. Wang, âModel Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions,â ACM Transactions on Software Engineering and Methodology, 2026, [DOI verified on CrossRef]. [17] M. M. Hasan, H. Li, E. Fallahzadeh, G. K. Rajbahadur, B. Adams, and A. E. Hassan, âModel Context Protocol (MCP) at First Glance: Studying the Security and Maintainability of MCP Servers,â ACM Transactions on Software Engineering and Methodology, 2026, [DOI verified on CrossRef]. [18] H. Guo, Y. Hao, Y. Zhang, M. Xu, P. Lv, J. Chen, and X. Cheng, âA measurement study of model context protocol ecosystem,â 2025. [Online]. Available: https://arxiv.org/abs/2509.25292 [19] J. Salda Ì na, The Coding Manual for Qualitative Researchers, 4th ed. SAGE Publications, 2021, [Verified on CrossRef]. [20] T. Gan and Q. Sun, âRAG-MCP: Mitigating prompt bloat in LLM tool selection via retrieval-augmented generation,â arXiv preprint arXiv:2505.03275, 2025. [21] Anthropic, âModel context protocol python sdk,â https://github.com/ modelcontextprotocol/python-sdk, 2024, official Python implementation of the MCP specification. [22] Daily, âPipecat: Open source framework for voice and multimodal ai agents,â https://github.com/pipecat-ai/pipecat, 2024, gitHub repository; used for MCP transport benchmarking. [23] K. Kate, T. Pedapati, K. Basu et al., âLongFuncEval: Measuring the effectiveness of long context models for function calling,â arXiv preprint arXiv:2505.10570, 2025.