What is the Model Context Protocol?

The boundary MCP creates

An AI application is the host. It creates one MCP client for each MCP server it connects to. The server publishes capabilities; the client speaks the protocol; the host decides what enters model context and what may happen in the product.

flowchart LR
  U[User] --> H[Host: context, policy, consent]
  H --> M[Model]
  H --> C1[MCP client]
  H --> C2[MCP client]
  C1 <-->|JSON-RPC| S1[Issue tracker server]
  C2 <-->|JSON-RPC| S2[Local repository server]
  M -->|proposes use| H
  H -->|validated, authorized call| C1

The word server describes a protocol role, not a deployment location. A local process connected over standard input and output is an MCP server. So is a remote service reached over HTTP.

What travels across the protocol

In protocol revision 2026-07-28, servers can expose three central primitives:

• Tools are named operations with input and output schemas. A client can discover them and request execution.
• Resources are context data an application can list and read, such as file contents or a database schema.
• Prompts are reusable interaction templates a user can choose through the host.

MCP defines how these capabilities are described and exchanged. It does not require the host to give every discovered capability to the model. A host may rename, filter, defer, or omit tools to keep context small and authority narrow.

The wire messages use JSON-RPC 2.0. The standard bindings are newline-delimited messages over stdio for a client-launched process and Streamable HTTP for remote communication. Custom transports are possible, but compatible messages and security properties still need to be defined.

Discovery before use

A client needs to know which protocol revision and capabilities a server supports. Modern MCP requests carry version, client identity, and capabilities in request metadata. A client can call server/discover first, or handle an unsupported-version response and retry with a mutually supported revision.

After discovery, a typical tool path is:

1. tools/list returns the tools currently exposed by one server.
2. The host selects which definitions, if any, become available to the model.
3. The model proposes a tool name and arguments.
4. The host validates and authorizes that exact action.
5. The client sends tools/call; the server returns structured content or an error.
6. The host records the observation and chooses what the model sees next.

This is dynamic: capabilities can differ by server, user, configuration, or time. Caching a tool list therefore needs freshness rules, invalidation, and a safe response when a previously visible tool disappears.

Interoperability does not grant authority

MCP is not the agent loop, the model, or the harness. It does not automatically provide authentication, business authorization, approval UX, sandboxing, least privilege, prompt-injection resistance, idempotency, or trustworthy tool output. Those controls remain responsibilities of the host, server, transport, and surrounding infrastructure.

A schema-compatible call can still target the wrong tenant. A legitimate server can return malicious or stale text. A compromised server can describe a tool deceptively. Connecting a server is therefore an increase in both context supply and possible authority, not merely an installation detail.

The protocol evolves. This article describes revision 2026-07-28; implementations should negotiate versions and consult the current specification rather than infer behaviour from the acronym alone.

Verify protocol and host boundaries

Test at three boundaries. First, use contract tests for discovery, list/read/call methods, schemas, errors, pagination, cancellation, and the exact protocol revisions you support. Second, test the host with fake servers that return duplicate names, changing tool lists, oversized payloads, malformed JSON-RPC, delayed responses, hostile descriptions, and unsupported versions. Third, test policy with deterministic model proposals and prove that discovery never bypasses authorization or approval.

For remote servers, cover authentication expiry, redirects, origin checks, disconnects, retries, partial effects, and lost responses. For stdio, cover process startup, unexpected output, stderr, crash recovery, inherited environment, working-directory scope, and cleanup. Record enough correlation data to connect model proposal, host decision, protocol request, server response, and real-world effect without logging secrets.