Model Context Protocol (MCP)

The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems through a common client-server interface. MCP servers can expose tools, resources and prompts, allowing compatible clients to discover and use those capabilities.

Anthropic released the protocol as open source in November 2024, and it is now maintained as an open project under the Linux Foundation's project structure. Its designers cite the Language Server Protocol as an inspiration: editors and programming languages once needed a separate integration for each pairing, and a shared protocol let each side implement one interface. MCP aims at the same economy. A team that wraps its ticketing system as an MCP server does that work once, and any compatible application can use it.

This entry describes revision 2026-07-28 of the specification, the current revision when the entry was last reviewed. Earlier revisions differ in ways noted below, and deployed servers and SDKs may still be using them.

Host, client and server

The specification describes three roles.

• The host is the AI application a person actually uses: a chat application, an IDE, a coding agent. It holds the conversation, coordinates the language model, creates and manages clients, and is where consent and security policy are applied.
• A client is a connector inside the host. Each client talks to exactly one server.
• A server provides capabilities. It can be a local process the host launches, communicating over standard input and output, or a remote service reached over HTTP. Either way, the messages are JSON-RPC 2.0.

A host that uses five servers runs five clients. One of the specification's design principles is that a server should not be able to read the whole conversation or see into other servers. The full history stays with the host, and interactions across servers are controlled by the host. That principle determines who can observe what, which matters later in this entry.

In the 2026-07-28 revision the protocol is stateless. Every request is self-contained and carries its protocol version and the client's capabilities in a metadata field. Earlier revisions opened each connection with an initialization handshake and kept a session; the current revision removed both.

What a server can offer

Servers expose three kinds of primitive, and the specification distinguishes them by who decides when each is used.

A server may also return free-text instructions describing how a model should use it. A server that needs something from the user partway through a request can ask for it through elicitation: it replies that input is required, and the client retries the request with the answer. Two older client features, sampling and roots, are marked deprecated in this revision.

The flow of one tool call

Tools are the model-controlled primitive, and the flow below is where MCP meets tool calling.

1. Discovery. The client can call server/discover, which every server must implement, to learn the server's supported protocol versions, its capabilities and its self-reported identity. It calls tools/list to get each tool's name, description and input schema. Tool definitions may include annotations, such as a hint that a tool is read-only or destructive. The specification says annotations are hints and that clients must treat them as untrusted unless the server is trusted.
2. Selection. The host places tool definitions in the model's context. The model either answers in text or emits a tool call.
3. The host decides. The specification says there should always be a human in the loop with the ability to deny tool invocations, and recommends showing tool inputs to the user before the call is sent. How that is done is left to the host.
4. Invocation. The client sends a tools/call request with the tool's name and arguments.
5. Result. The server validates the input, runs the tool and replies. A result carries content, optionally structured content that conforms to a declared output schema, and an isError flag for failures in the tool itself. Problems with the request, such as an unknown tool, come back as protocol errors.
6. Back to the model. The host returns the result to the model, which reads it and chooses its next step.

A request and its result look like this. Request metadata is omitted for brevity.

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "get_ticket",
    "arguments": { "ticket_id": "4812" }
  }
}

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "resultType": "complete",
    "content": [
      { "type": "text", "text": "Ticket 4812. Customer reports login failures since Tuesday. ..." }
    ],
    "isError": false
  }
}

The three parties to this exchange see different things. The host coordinates all of its clients. Each client carries messages for one server.

Six things that are easy to collapse

Because discovery, invocation and results all travel over one connection, it is easy to treat them as one fact. They are six.

• Capability discovery. A tool appears in tools/list. This says the server offers it.
• Authorization to use a capability. The client holds a credential the server accepts for that tool, and the host or user has consented to its use. A server may return a different tool list depending on the authorization presented.
• Appropriateness to the current task. Whether this call, with these arguments, belongs to what the agent was asked to do. MCP does not define a standardized, authoritative declaration of the overall task against which tool invocations are evaluated. A call's arguments can carry task-related information, such as a ticket number, without establishing that relationship.
• Attempted invocation. The client sent the request.
• Returned result. The server replied. A result with isError: false is the server's report.
• Confirmed effect. The system behind the server changed, or did not. Establishing that takes evidence from that system.

A listed tool is not an authorized one, an authorized call is not necessarily an appropriate one, and a returned result is not a confirmed effect.

A connection runs in two directions

Each MCP connection is a way in and a way out.

In. Tool descriptions, server instructions, resources, prompts and tool results are all text or data that can end up in the model's context, and everything in the context can influence what the model does next. A tool description shapes when the model reaches for the tool. A resource or a tool result may contain content written by a third party: a web page, a customer's message, a code comment. This is the path by which prompt injection can reach an agent through an otherwise well-behaved server. The specification addresses it directly: annotations are untrusted by default, clients should validate tool results before passing them to the model, and the prompts section requires implementations to validate prompt inputs and outputs carefully, to guard against injection and unauthorized access to resources.

Out. A tools/call sends a name and arguments to a system outside the host. The arguments can carry data drawn from anywhere in the model's context, and the call can create, change, send or delete something. The specification's guidance here is equally direct: show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration, and prompt for confirmation on sensitive operations.

The benefit of the protocol and the width of this surface have the same source. Interoperability means a host can gain a new capability by adding a server, with no custom integration. It also means each added server is one more source of text the model will read and one more destination its requests can reach. Servers are isolated from each other by design. The place where they meet is the host's model context.

An example: one connection influences another

The following scenario is illustrative. The protocol messages are sketched, not captured from a live system.

A support engineer's assistant is connected to two MCP servers: tickets, for the ticketing system, and crm, for customer records. The engineer asks it to summarize ticket 4812 for the on-call engineer.

1. The model calls get_ticket on the tickets server. The result includes the customer's own words: a description of login failures, followed by a note asking for the email address on the account to be changed.
2. Having read that note, the model emits a second call: update_customer on the crm server, with the customer's identifier and the new email address.

Consider what each party observed. The tickets server saw a read of one ticket and served it correctly. The crm server saw a well-formed request to update a record, presented with a valid token whose scopes allow writes. Neither server did anything wrong, and neither had a way to see that the second call followed from text returned by the first. The host held both halves.

Whether the update was appropriate depends on something the protocol does not establish: the engineer asked for a summary. The ticket number in the first call's arguments relates to that task, but no message states the task in a form that the second call could be evaluated against. The update may even be what the customer wants. It is still not what the assistant was asked to do, and an instruction that arrives inside a ticket has not been verified as coming from the account's owner.

Several existing controls bear on this. A host that asks for confirmation before write operations would put the second call in front of the engineer. A token requested with minimal scopes for the task would not have included write access to customer records. The crm system may have its own checks on email changes. Which of these exist in a given deployment is a matter of how the host, the servers and the systems behind them were built.

Authorization and security in the specification

MCP's security provisions fall into three groups.

Consent and control. The specification's stated principles are that users must consent to and understand data access and operations, that hosts must obtain explicit consent before exposing user data to a server and before invoking any tool, and that users should understand what a tool does before authorizing it. It also says plainly that the protocol cannot enforce these principles at the protocol level, and places the responsibility on implementors.

Authorization. Authorization is optional. Where a server is reached over HTTP, the specification defines a flow based on OAuth 2.1. The MCP server acts as a resource server, the client as an OAuth client, and a separate authorization server issues tokens. Servers publish metadata so clients can discover the authorization server. Tokens are bound to the server they were issued for: a server must validate that a token was issued for it, must not accept other tokens, and must not pass a client's token through to a downstream API. When a call arrives with a token whose scope is insufficient, the specification says the server should respond with a 403 status and a challenge naming the scopes the operation requires. It likewise says servers should indicate required scopes when first challenging a client. Together these let a client request more access only when an operation needs it. Servers launched locally over standard input and output take credentials from their environment instead.

Security guidance. The project's security best practices document describes specific attacks and mitigations, including the confused deputy problem, token passthrough, server-side request forgery and compromise of local servers. It also recommends scope minimization: start with a minimal set of scopes and elevate on demand. Elicitation has its own rule: a server must not use a form to request secrets such as passwords or API keys.

These provisions answer who the client is acting for, whether it may reach this server, and which operations its credentials permit. They do not attempt to answer whether a permitted call suits the task at hand. That is outside the protocol's scope, not a shortcoming of it.

Relating an MCP operation to an objective

The host side of an MCP connection is an execution boundary: the point where a model's request is about to become a tools/call that reaches a real system. It is a natural place to ask the question the protocol leaves to others.

If an agent's objective and declared scope have been stated before it acts, each attempted MCP operation can be compared with that statement as it is attempted: which server it targets, what kind of operation it is, and whether either falls outside what the task authorized. Doing so while the agent runs is runtime governance. It draws on a declared intent, a reference that MCP does not itself define, and it produces governance evidence: what was declared, what was attempted, and what the evaluation found.

Governance in this sense is not the same thing as blocking. It supplies the reference, the evaluation and the record. Responses to a finding are a separate matter and can range from nothing, to a flag for later review, to a confirmation prompt, to refusal. Where a restriction is enforced also matters. A check in one host governs the agents that run in that host. A remote MCP server can be called by any client with a valid token, so a restriction that must hold for every caller belongs at the server, the authorization server or the system behind them. Effective enforcement sits at the boundaries where the consequential action can occur, and for an MCP deployment there is usually more than one.

One implementation: Sentience Governor

Sentience Governor is one implementation of runtime governance, and MCP is one of the places it attaches. Its Claude Code integration receives MCP tool calls through Claude Code's hooks, and a Python wrapper is available for MCP clients. It also uses MCP in the other direction: Governor's own tools, including the one an agent uses to declare its intent, are served through an MCP server. Its current implementation observes, evaluates, flags and records. It does not block, approve or modify calls; enforcement is a separate capability in the broader governance architecture.

The record below replays the scenario above. It is genuine Sentience Governor output, generated by feeding representative Claude Code hook payloads for two MCP servers named tickets and crm into the released Claude Code integration. No MCP server was running, no tool executed and no ticket or customer record exists. The payloads were supplied in a fixed order and were not chosen by a live model, so the record shows what Governor records and evaluates, not how an agent behaves. The session's objective was declared as "Summarize support ticket 4812 for the on-call engineer" with a scope of tickets. Envelope metadata is omitted, and findings are described in words.

The event for the second call:

{
  "event_type": "SCOPE_ASSERTED",
  "pass_through": true,
  "payload": {
    "tool_id": "mcp__crm__update_customer",
    "operation_type": "WRITE",
    "asserted_permissions": ["write"],
    "target_system": "crm"
  }
}

The finding was made at the attempt, and the call was passed through. The update was marked as outside the declared scope before any tool would have run, and pass_through is true on every event.

The record holds structure, not content. The ticket text, the new email address and the customer identifier appear nowhere in it. What it does show is order: context entered from tickets, and the next action was a write attempt on a system the declared scope did not include. It cannot show that the first caused the second. Establishing that would take the content, which an observability trace that captures payloads may hold.

The limits are visible. add_comment was recorded as a read. In this integration the operation type is inferred from keywords in the tool's name, such as "update", "create" or "delete", and a name with none of them is treated as a read. MCP tool annotations are not consulted. The target is the server's name as the host exposes it. And the 20-token result from crm means a result came back, not that a customer record changed.

Governor sees MCP traffic only in hosts where it is instrumented. It does not observe other hosts, the server side of a connection, or the systems behind a server.

Often confused with

Tool calling and function calling. Function calling and tool calling name the model-side mechanism: a model emits a structured request and an application acts on it. MCP is one way tools reach the application that offers them to the model. An agent can call tools with no protocol involved, and MCP remains useful without tool calling, through resources and prompts.

The agent-to-agent (A2A) protocol. The A2A protocol is an open standard for communication between agents, which may be built by different vendors on different frameworks. MCP connects an application to tools and data. The two are complementary, and A2A's own documentation describes them that way.

An API. An MCP server may wrap an existing API, or it may expose other functionality, local or remote: files on the user's machine, a database, a command-line tool, a computation of its own. In each case the protocol adds uniform discovery, descriptions a model can read, and a common invocation format. Where an API sits behind the server, it still does the work and applies its own access control.

An MCP server. An MCP server is one component that implements the protocol. The protocol is the agreement between components.

Skills. A skill is a packaged set of instructions and supporting files that an agent loads for a kind of task. A skill can include scripts, and it can direct the agent to use tools or reach external systems, including through MCP servers. What it is not is the client-server protocol itself: a skill describes how to do something, and MCP defines how an application discovers and invokes capabilities a server offers. The two can be combined, and the specification's list of extensions includes work on delivering skills through MCP.

The harness. The agent harness is the software that runs the model's loop, routes tool calls and manages context. An MCP host is often part of a harness. MCP defines how that software talks to servers, not how it runs the agent.

Where the concept stops

MCP standardizes a connection: how capabilities are discovered, how they are invoked, how results come back, and how a client is authorized to reach a server over HTTP. It does not address whether a server's descriptions are accurate, whether a particular call belongs to the task in hand, or whether the effect a result reports took place. Those remain with the host, with the people who decide which servers to connect, with human approval where it is used, and with the systems at the far end of each call, including their own authorization and records. Each agent action that crosses an MCP connection is a request, and the protocol carries it faithfully in both directions.