Model Context Protocol (MCP)

Model Context Protocol (MCP) is an open protocol for connecting AI applications to systems that provide external data or capabilities.

Without a common interface, each application has to implement its own integrations for filesystems, GitHub, databases, browsers, and other services. MCP standardizes the communication between the application and those integrations.

The model does not connect directly to the MCP server. The host remains in between, deciding which capabilities are exposed to the model, which content enters context, and which operations are allowed to execute.

Host, client, and server

An MCP integration has three main pieces:

• The host is the application where the user works, such as an IDE, a coding agent, or another application that embeds a model.
• The client lives inside the host and implements the client side of the protocol.
• The server exposes capabilities or data through MCP.

A host can connect to multiple servers and will usually maintain a logical client for each one.

The server can be a local process launched by the host or a remote service. In both cases, the model sees its capabilities through the host. Using MCP does not give the server direct access to the LLM.

MCP standardizes the interface between applications and servers, but it does not replace the harness. Tool selection, context construction, approval policies, and sandboxing still depend on the system using MCP.

Tools, resources, and prompts

Much of what a server exposes is organized around three primitives. A useful way to distinguish them is by who controls their use.

Tools

A tool represents an operation the model can request.

A server might expose search_repository, read_issue, or create_ticket. The definition includes a name and an input schema, usually with a description and, when useful, an output schema.

The client discovers those definitions and the host can present them to the model as available tools. If the model selects one, MCP carries the call to the server and returns the result.

The mechanics are the same as for a tool wired directly into a harness. The model requests an operation and another layer executes it. MCP standardizes the interface used to connect that capability.

Tools can include annotations such as readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. They describe expected properties of the operation and can help a client decide how to present it or when to ask for confirmation.

They are hints, not security controls. A client should not assume that an annotation from an untrusted server accurately describes what the tool will do.

Resources

A resource exposes information that the application can read and provide to the model.

It is identified by a URI and can represent a file, configuration, documentation, or data obtained from another service.

At the protocol level, a tool offers an operation chosen by the model while a resource offers data managed by the application. The code behind the server may be complex in both cases, but the control visible to the client is different.

Prompts

A prompt is a reusable template that the server makes available to the user.

It can appear in the host as an action, menu entry, or equivalent command. When the user selects it, the client asks the server for the rendered messages and adds them to the conversation.

It is different from persistent project instructions. The user chooses when to invoke an MCP prompt, while files such as AGENTS.md depend on the harness’s own instruction mechanism.

Tool call flow

Assume an MCP server exposes a tool named search_repository.

The server may call an API, query a database, read the filesystem, or run any other logic it implements.

An MCP tool therefore does not necessarily describe the technology behind it. The protocol defines the interface visible from the host.

Transports

The same interface can be used with local or remote servers.

stdio

With stdio, the host launches a local process and communicates with it through standard input and output.

This is common for integrations that need to work with the same machine as the agent, such as development tools, filesystems, local databases, or installed utilities.

The configuration mechanism used to launch that process is not part of MCP. Files such as mcp.json, mcpServers blocks, and product-specific configuration screens belong to the host that implements them.

Streamable HTTP

Streamable HTTP allows the server to run as a network-accessible service.

The client talks to an MCP endpoint instead of launching a local process. This model fits shared integrations, SaaS services, and servers deployed independently from the machine running the host.

The usual remote-service boundaries also apply here, including networking, TLS, authentication, authorization, availability, and the credentials used to reach downstream systems.

The HTTP+SSE transport used by earlier protocol versions is deprecated. Streamable HTTP is the current HTTP transport.

Versions and lifecycle

MCP has evolved quickly, and some existing documentation describes an older lifecycle.

The stable 2026-07-28 revision has no initialize handshake or protocol-level sessions. Each request is self-contained and carries the required version, client, and capability information. A client can use server/discover to inspect server support first, but it is not a required step before every operation.

A stateless protocol core does not require the application itself to be stateless. Servers can keep state through jobs, identifiers, persistent data, or explicit handles passed between calls.

Modern SDKs can support both generations. Two working MCP integrations can therefore show different traffic and lifecycle behavior depending on the protocol version in use.

Authorization

Connecting a tool does not mean the caller has authority to perform the operation behind it.

For HTTP transports, MCP defines an OAuth-based authorization model, but authorization is optional. When it is used, the credential presented to the server can limit the capabilities available to that client.

The server may then use another identity to communicate with the downstream system.

For example, a GitHub MCP server can receive a properly authorized request from the host and then use a credential to query GitHub. The final effect depends on the host policy and the permissions attached to that credential.

The full chain can be viewed as:

model → host → MCP client → MCP server → external service

Allowing a tool in the host does not grant additional permissions to the external account. Effective authority depends on the whole chain.

Security

MCP makes it easier to connect capabilities from different systems to the same agent. That introduces additional trust boundaries.

Local servers

A server launched through stdio may be software installed from an external package or repository.

If the process can reach the user’s home directory, environment variables, cloud credentials, or local sockets, its real capability can be much broader than the tools it advertises.

Reviewing the tool list is not the same as reviewing what the process implementing those tools can do. A local MCP server is also an executable dependency.

Tool definitions and context

Names, descriptions, schemas, and other metadata help the model decide when and how to use a tool.

That metadata can also influence the model’s decisions.

A malicious server can hide instructions in tool definitions in an attempt to change how the agent uses that tool or other available capabilities. This pattern is commonly called tool poisoning.

Trust does not end when the server is installed. If its definitions change later, a previously reviewed integration can start presenting different behavior. When that change takes advantage of previously established trust, the pattern is commonly described as a rug pull.

Annotations can describe the expected risk profile of a tool, but they still come from the server. They do not replace policy enforced by the host or runtime.

Results and resources

Content returned by a tool or read from a resource may come from external sources.

A web search, email, or repository tool can retrieve text controlled by third parties. When that result enters model context, the same boundary seen in indirect prompt injection appears again. The agent needs to process the data, but the data should not gain authority to decide which other actions are executed.

Trusting the MCP server does not mean trusting all content retrieved by that server.

Permissions

The impact of a manipulated decision depends on the capabilities behind it.

A mail server with read-only access has a different blast radius from the same server using an account that can send messages, delete content, or change mailbox rules.

Scopes, host policy, human approval, and permissions on the external identity operate at different layers. MCP provides mechanisms for exposing and authorizing capabilities, but the final authority still depends on the credentials and controls around the operation.

Composition matters as well. One server may provide access to sensitive data while another provides Internet communication or command execution. The agent’s effective capability comes from the combination of available paths, not from evaluating each server in isolation.

What to review

When adding or assessing an MCP integration, it is useful to answer these questions:

• Is the server a local process or a remote service?
• What code executes, and with which permissions?
• Which tools, resources, and prompts does it expose?
• Which metadata and results can enter model context?
• Which credentials does the server use, and what authority do they carry?
• Can one capability produce the same effect as another that appears restricted?
• Can the server’s catalog or behavior change after it has been approved?
• Which controls does the host apply before executing an action?
• Which external content can return to the model after a call?

MCP defines how the pieces connect. Trust, permissions, and isolation depend on how those pieces are deployed and combined.

References

• Model Context Protocol — Specification 2026-07-28
• Model Context Protocol — Server features
• Model Context Protocol — Tools
• Model Context Protocol — Resources
• Model Context Protocol — Transports
• Model Context Protocol — Authorization
• Model Context Protocol — The 2026-07-28 Specification
• Model Context Protocol — Tool Annotations as Risk Vocabulary
• OWASP — MCP Security Cheat Sheet
• OWASP — MCP Top 10