← Reference · Nestor G Pestelos Jr · Print this page

Artificial Intelligence · Protocols & Standards

Model Context Protocol

Model Context Protocol (MCP) is an open protocol through which AI applications access tools, data, and prompt templates exposed by servers.[1]

Reference entry · last updated 20260909 · Previous version

This entry describes protocol version 2026-07-28. Earlier versions differ in transport, initialization, and client features.[2]

First principles and definitions

A protocol defines the messages that programs exchange. MCP uses JSON-RPC 2.0 to describe requests, results, and errors. A common message format lets an application discover a server's tools and call them without a separate integration for each application. It does not grant access to the underlying system or enforce a security boundary.[1][3]

Host, client, and server

• The host is the AI application. It coordinates the model, user interaction, and access policies.
• A client is the host's protocol component for communicating with a server.
• A server exposes tools, resources, or prompts. It accesses external systems through their own interfaces.

MCP covers the client–server connection; the server's database or service integration can use another protocol.[1]

Features and version changes

The table summarizes features in version 2026-07-28; it is not an exhaustive list of protocol methods. This version replaces the initialization handshake with per-request metadata and capability declarations. Requests for additional client input use multi-round-trip interactions.[2]

Transports

Standard input/output (stdio) connects a client to a local server process using newline-delimited JSON-RPC messages. The client launches the server; standard output carries protocol messages.[3]

Streamable HTTP serves remote clients. In version 2026-07-28, clients send requests by HTTP POST to a single endpoint. Responses can be JSON or request-scoped Server-Sent Events (SSE). There is no standalone GET stream or transport session.[5]

The older HTTP+SSE transport is historical. Earlier Streamable HTTP versions also had GET-stream and session behavior that this version removes.[2][5]

The Language Server Protocol comparison

MCP follows an integration pattern similar to the Language Server Protocol (LSP), which connects editors with language tools.[1][6]

As an illustrative count, connecting M applications to N services can require M × N custom adapters. A shared protocol can reduce the protocol-facing implementations to M + N. This counts interfaces, not engineering effort: authentication, feature support, and service-specific behavior still need implementation.

Consent and security boundaries

The specification calls for explicit user consent before tool use. The tools section recommends human oversight and confirmation interfaces, but it mandates no particular interaction model. Consent and approval policy belong to the host; MCP does not impose a confirmation dialog for every side-effecting call.[1][4]

Roots are not a security boundary. They communicate intended filesystem locations. Filesystem permissions, sandboxing, and checks in the implementation must enforce containment. Running a server in a separate process does not itself provide a sandbox.[7]

Remote implementations must also validate origins and implement access controls appropriate to their deployment. A valid MCP message does not make its contents trusted.[5]

See also

• Agent Harness
• Agents
• Context Engineering
• Fail-Closed
• LLM Gateway
• Plan-Approve-Execute

References

1. Model Context Protocol. Specification, version 2026-07-28.
2. Model Context Protocol. Key changes, version 2026-07-28.
3. Model Context Protocol. Transports.
4. Model Context Protocol. Tools.
5. Model Context Protocol. Streamable HTTP.
6. Microsoft. Language Server Protocol.
7. Model Context Protocol. Client concepts: roots and their limitations.