Model Context Protocol (MCP)

What is Model Context Protocol (MCP)?

Model Context Protocol is a client-server protocol for context exchange between AI applications and external systems. It standardizes messages for capabilities such as tools, resources, and prompts, but it does not control how an AI application uses a model or its context.

Why it matters

Model Context Protocol gives applications one protocol for discovering and using many external capabilities. Dynamic discovery also creates trust, identity, and authorization boundaries that each implementation must secure.

How it works

1. The current protocol is stateless. Each request carries its protocol version and client capabilities.
2. A client may call server/discover for server capabilities before it reads resources or invokes tools.
3. The client reads resources or invokes tools over a supported transport, with transport authorization when configured.
4. The host manages one client for each server. A local server can use stdio, while a remote server can use Streamable HTTP, and each server can expose tools, resources, and prompts.
5. Clients declare capabilities on every request, and an optional server/discover call returns server capabilities for upfront discovery. In version 2026-07-28, roots and sampling are deprecated, while elicitation remains available through InputRequiredResult.

Example

An IDE host connects to one server for source control and another for incident data. The host lists each server's tools and invokes only the tool needed for the user task.

Pomerium boundary

Pomerium can sit between remote clients and internal Model Context Protocol servers that use Streamable HTTP. It can authenticate supported requests, apply route and tool policy, and manage documented upstream OAuth flows. Pomerium logs authorization decisions, and operators can add Model Context Protocol fields for the method, tool name, and parameters. It does not mediate a local stdio connection.

Limits and non-claims

• Model Context Protocol does not define an agent runtime, planner, or model behavior.
• Authorization is optional and transport-specific. Local stdio deployments use a different credential model.
• Protocol conformance does not prove that a server, tool, or result is safe.
• Pomerium protects Model Context Protocol servers that use Streamable HTTP through a Pomerium route. It does not secure local stdio connections, the model runtime, tool code, or traffic that bypasses the route.

Evaluation checklist

• Can you separate the host, client, server, tool, model, credential, and target application?
• Which HTTP authorization ends at the server, and which tool resource action needs another decision?
• Can local stdio, prompt content, tool code, credential custody, or a direct target bypass MCP controls?