Model Context Protocol (MCP): Architecture, JSON-RPC Primitives, Host-Client-Server Topology, and Standardization in AI Agents

Before the introduction of standardized integration protocols, connecting Large Language Models (LLMs) to external data stores, business applications, and local developer environments required bespoke glue code. Every agent framework maintained custom integrations for databases, web APIs, and file systems, creating an $M \times N$ integration matrix where $M$ model hosts each implemented unique connectors for $N$ tools.

In November 2024, Anthropic published the Model Context Protocol (MCP), an open standard designed to resolve this fragmentation. Modeled after the architectural success of Microsoft's Language Server Protocol (LSP) in development environments, MCP standardizes how AI applications discover, invoke, and inspect external tools and context providers.

Architectural Topology: Hosts, Clients, and Servers

The MCP specification decouples integration responsibilities across three distinct architectural layers:

1. Hosts: End-user applications that orchestrate LLM workflows and run the primary model interface. Examples include desktop assistants, integrated development environments (IDEs), and autonomous agent frameworks. The host manages user permissions, controls application state, and decides when to query attached servers.
2. Clients: Protocol-level connectors embedded inside the host application. A client maintains an isolated, bidirectional 1:1 connection with a single MCP server, handles session lifecycle negotiation, and serializes requests.
3. Servers: Lightweight programs that expose specific capabilities, structured datasets, or executable tools to clients through standardized message schemas. Servers run either locally alongside the host or remotely as network services.

This hub-and-spoke separation ensures that model applications do not need custom drivers for every data warehouse, API, or local utility. Instead, tool authors build a single MCP server that functions across any compliant host.

Transport Mechanisms

MCP operates over two primary transport layers, exchanging JSON-RPC 2.0 messages:

• Standard Input/Output (stdio): Used for local server processes launched directly as child processes by the host. The client communicates via standard input (stdin) and standard output (stdout), with process logging routed over standard error (stderr). This provides low latency, minimal network attack surface, and process isolation.
• Server-Sent Events (SSE) over HTTP: Used for remote, distributed, or containerized servers. The client opens an HTTP GET connection to receive real-time streaming events from the server over SSE, while issuing commands and sending JSON-RPC payloads back to the server using discrete HTTP POST requests.

Core Protocol Primitives

MCP divides capabilities into distinct primitives categorized by whether they are exposed by the server to supply context or offered by the client to support execution:

Server-Exposed Primitives

• Tools: Executable routines that an LLM can invoke to perform external side effects or retrieve real-time computation results. Tools are exposed with JSON Schema definitions describing their arguments. Discovery is handled via tools/list, and execution occurs through tools/call.
• Resources: Passive, read-only data sources that provide contextual knowledge without side effects, analogous to GET endpoints or static files. Identified by uniform resource identifiers (URIs), resources can be listed via resources/list, read via resources/read, and watched for updates using subscription notifications (resources/subscribe).
• Prompts: Pre-configured prompt templates, workflows, and behavioral guidelines exposed by the server. Hosts retrieve available templates via prompts/list and instantiate them with arguments using prompts/get.

Client-Exposed Primitives

• Roots: Directory boundaries and file paths exposed by the client to inform servers of authorized operational boundaries. Servers use roots/list to inspect accessible workspace paths without violating host filesystem sandboxes.
• Sampling: An advanced client capability that allows an MCP server to request an LLM completion back from the host application via sampling/createMessage. This enables multi-step server-side workflows where a tool requires intermediate model reasoning while preserving host-level token budgeting and privacy guardrails.

Lifecycle and Capability Negotiation

Connections begin with an explicit handshake to establish compatibility:

1. Initialization: The client sends an initialize request specifying its supported protocol version and client capabilities.
2. Negotiation: The server responds with its supported protocol version, server capabilities (such as tools, resources, logging, or prompt support), and server implementation metadata.
3. Confirmation: The client issues an initialized notification to confirm session establishment.
4. Heartbeat and Termination: Periodic ping requests verify connection liveness. Connections close cleanly via standard transport termination or process exit.

Security Boundaries and Human Gating

Because tools can trigger state-altering operations, MCP establishes strict boundaries for security and data control:

• Explicit User Consent: Hosts are required by the specification to gate tool execution behind explicit user confirmation or bounded policies.
• Resource Privacy: Servers cannot inspect files or environment variables beyond the roots explicitly provided during initialization.
• Stateless Framing: Requests carry self-contained metadata, enabling auditing and policy enforcement at proxy and gateway boundaries.

Sources

• Anthropic: Introducing the Model Context Protocol
• Model Context Protocol Specification
• InfoQ: Anthropic Publishes Model Context Protocol Specification for LLM App Integration
• PromptLayer: What is MCP? Claude Anthropic's Model Context Protocol