The Architecture of Model Context Protocol: Deconstructing Hosts, Clients, and Contextual Adapters

2026-09-15 · by bixzell

When engineering teams first introduce generative AI into production systems, the architecture typically begins with an intuitive goal: build an AI-powered agent or support assistant capable of answering user questions using live operational data.

Soon, the reality of enterprise infrastructure sets in. An e-commerce support assistant cannot function in a vacuum. To answer “Where is my shipment?”, it needs access to an order database containing millions of customer records. To answer “Do you have this jacket in navy blue?”, it must query an Elasticsearch product catalog with hundreds of thousands of SKUs. When the customer requests a cancellation, it must authenticate with a payment processor API like Stripe and notify internal teams via messaging webhooks.

Without a standardized protocol, building this workflow requires custom integration code for every single service. The problem compounds rapidly:

[Claude 3.7] ──┐
[GPT-4o]     ──┼──▶ [Custom Glue Code] ──▶ [PostgreSQL, Elasticsearch, Stripe, Slack]
[Gemini 2.5] ──┘

If your platform supports three models and connects to five operational services, your team maintains 15 distinct, brittle integration layers—each with bespoke authentication, divergent error-handling semantics, and proprietary schema definitions. Swapping a model or adding a data source triggers a painful refactor across the entire codebase.

This is the classic $M \times N$ integration bottleneck. The Model Context Protocol (MCP) was designed to reduce this complexity to $M + N$ by introducing an open, standardized communication boundary between cognitive models and operational infrastructure.

Reference Implementation:modelcontextprotocol/servers—⭐

The official repository of reference MCP servers, covering filesystem access, relational databases, Git providers, and web scrapers.

Why Standard REST APIs Fail Large Language Models

A frequent question from systems architects is: “We have spent fifteen years standardizing on HTTP REST APIs. Why can’t language models simply invoke existing REST endpoints directly?”

The answer lies in the fundamental difference between machine-to-machine interfaces and cognitive model interfaces:

APIs are designed for programmatic parsers, not token-constrained attention windows. Consider querying the status of a service inside a container orchestrator like Kubernetes. A standard GET /api/v1/namespaces/default/pods/service-a returns hundreds of lines of nested JSON metadata: volume mounts, scheduling tolerances, condition timestamps, UID hashes, and container restart counters. A software engineer writes code to extract status.phase. But an LLM must ingest all 8 KB of raw JSON into its prompt context. The model must spend reasoning cycles sifting signal from noise, dramatically elevating both token burn and the risk of hallucination.
MCP serves as a Contextual Normalizer. An MCP server sitting in front of that infrastructure API acts as an intelligent adapter. It consumes the upstream REST payload and translates it from “API-speak” into “AI-speak”:
```
{
  "status": "healthy",
  "ready_replicas": "3/3",
  "restarts": 0,
  "uptime": "4 hours 12 minutes"
}
```
The LLM receives exactly the high-signal context required to formulate an answer, preserving its attention budget for user logic.
MCP is not an API replacement—it is glue code elimination. An MCP server does not replace your PostgreSQL instance, your Stripe billing engine, or your Kubernetes API. It replaces the thousands of lines of fragile parsing, formatting, and prompt-stuffing glue code that developers traditionally write to bridge models with those endpoints.

[!NOTE] An MCP server cannot grant capabilities that the underlying system forbids. If a database user role is read-only, exposing it through MCP will not permit writes. MCP is a protocol wrapper, strictly bounded by the underlying API contracts.

The Tripartite Architecture: Host, Client, and Server

The MCP specification defines three distinct architectural tiers, separating presentation, network mediation, and tool execution.

┌──────────────────────────────────────────────────────────┐
│ MCP Host (Application Layer)                            │
│  - User Interface & Chat History                         │
│  - LLM Orchestration & Prompt Assembly                  │
│                                                          │
│   ┌──────────────────────────────────────────────────┐   │
│   │ MCP Client (Protocol Driver)                     │   │
│   │  - Discovery via `tools/list`                    │   │
│   │  - Transport Management (stdio / HTTP)           │   │
│   │  - Security Sandbox & Permission Gate            │   │
│   └───────────────▲──────────────────────────────────┘   │
└───────────────────┼──────────────────────────────────────┘
                    │ JSON-RPC 2.0 (stdio / Streamable HTTP)
┌───────────────────▼──────────────────────────────────────┐
│ MCP Server (Capability Provider)                         │
│  - Exposes: Tools, Resources, Prompts                    │
│  - Internal Secret Storage (DB Passwords, API Keys)     │
│  - Upstream Execution (SQL, REST, RPC, Filesystem)       │
└──────────────────────────────────────────────────────────┘

1. The MCP Host (Application Boundary)

The Host is the primary application interacting with the human user or higher-level business process. Examples include:

Desktop developer environments like Cursor or Claude Desktop.
Custom enterprise backends (e.g., an internal FastAPI or Next.js customer support system).

The Host owns conversational memory, executes prompt templates, invokes the LLM API, and makes high-level decisions about which tool calls are permitted. Crucially, the LLM never directly connects to MCP servers; the Host acts as the strict orchestrator.

2. The MCP Client (Protocol Boundary)

Embedded within the Host is one or more MCP Clients. The Client is a protocol driver library (such as the TypeScript or Python SDK) that:

Connects to MCP servers across supported transports.
Performs runtime capability negotiation (tools/list, resources/list).
Serializes and deserializes JSON-RPC 2.0 messages.
Maintains security boundaries by intercepting requests before execution.

3. The MCP Server (Execution Boundary)

The Server is a standalone, lightweight service exposing dedicated domain capabilities. It can run as a local child process communicating over standard I/O (stdio), or as an independent microservice over HTTP with Server-Sent Events (SSE) or Streamable HTTP.

The Server translates incoming protocol requests (tools/call) into concrete operations against its target systems.

The Request-Response Lifecycle in Action

To understand how these components cooperate, consider what happens when a user asks: “Has order 89241 shipped yet, and can I get a refund if it is delayed?”

User             Host / Client                 LLM                  MCP Server (DB/Stripe)
 │                    │                         │                             │
 │ 1. "Where is #89241?"                        │                             │
 ├───────────────────▶│                         │                             │
 │                    │ 2. Prompt + Tool Schemas│                             │
 │                    ├────────────────────────▶│                             │
 │                    │                         │                             │
 │                    │ 3. Intent: call query_order(id=89241)                 │
 │                    │◀────────────────────────┤                             │
 │                    │                                                       │
 │                    │ 4. JSON-RPC tools/call: query_order                   │
 │                    ├──────────────────────────────────────────────────────▶│
 │                    │ 5. Returns: {status: "delayed", carrier: "FedEx"}     │
 │                    │◀──────────────────────────────────────────────────────┤
 │                    │                                                       │
 │                    │ 6. Feed Tool Output into Context                      │
 │                    ├────────────────────────▶│                             │
 │                    │ 7. "Order #89241 is delayed with FedEx."              │
 │                    │◀────────────────────────┤                             │
 │ 8. Final Answer    │                         │                             │
 │◀───────────────────┤                         │                             │

Dynamic Tool Discovery: During initialization, the MCP Client calls tools/list on all connected servers. The PostgreSQL server advertises query_order, while the Stripe server advertises process_refund, each complete with a strict JSON Schema describing parameters and constraints.
Intent Declaration: The Host passes the user’s prompt alongside the discovered tool schemas to the model. The model does not execute code directly; it emits a structured intent block declaring its desire to invoke query_order with {"order_id": "89241"}.
Host-Mediated Invocation: The Host evaluates the intent, checks permissions, and dispatches a tools/call JSON-RPC request to the database MCP server.
Context Injection: The MCP server executes the SQL query against PostgreSQL and returns a compact JSON summary. The Host appends this result to the prompt context and prompts the model again.
Contextual Continuity for Follow-ups: When the user immediately follows up with “Please cancel it and refund the charge,” the word “it” refers to order 89241. Because the Host preserves the conversation thread and prior tool outputs, the model recognizes the entity reference without requiring a redundant database lookup and dispatches process_refund.

Security Boundaries: Keeping Credentials Out of the Attention Window

One of the most consequential architectural advantages of MCP is credential isolation.

In naive function-calling setups, developers frequently pass database credentials, API tokens, or high-privilege bearer headers into runtime environments where prompts or subagents might accidentally expose them. If an untrusted prompt injection occurs, an agent with access to raw API keys might exfiltrate them.

Under MCP:

Secrets reside strictly within the MCP Server process. The database password, AWS credentials, and Stripe secret key live as environment variables or secret-manager mounts inside the server container.
The LLM never observes credentials. The model only receives the public parameter schema (order_id: string) and the sanitized output payload.
Auditability at the transport layer: Because all operations travel as structured JSON-RPC messages (tools/call), enterprise gateways can log every invocation, run real-time policy checks (e.g., blocking any refund exceeding $500 without secondary approval), and terminate suspect sessions before destructive actions execute.

Architectural Tradeoffs: Micro-Servers vs. Gateway Aggregators

When planning an enterprise MCP footprint, engineering teams face a key topology decision: should every internal service have its own isolated MCP server, or should tools be grouped into an aggregator gateway?

Dimension	Dedicated Micro-Servers	Aggregator / Gateway Pattern
Process Isolation	High (each server runs as an independent container or process)	Shared (one process aggregates multiple upstream APIs)
Operational Overhead	Higher (managing 10 distinct server instances and ports)	Lower (single deployment, single health check endpoint)
Security Surface	Fine-grained token scopes per server	Centralized policy enforcement, single audit bottleneck
Token Footprint	Host must register tools across multiple clients	Gateway can implement progressive tool filtering
Best Suited For	Disparate third-party SaaS tools (Slack, GitHub, Sentry)	Cohesive internal enterprise domains (billing, inventory, analytics)

For large organizations, the Gateway Aggregator pattern is emerging as the preferred architecture. A single internal MCP service wraps multiple backend microservices, validates authorization tokens via OAuth 2.1 / mTLS, and exposes a unified, curated set of tools to employee agents.

Next Steps

To explore MCP implementations and connect real tools to your AI development environment:

Read our hands-on guide to Building a TypeScript MCP Server from Scratch.
Learn how stateless Streamable HTTP replaced legacy sessions in the 2026 protocol update.
Browse community implementations in our Full MCP Server Directory.