MCP

MCP (Model Context Protocol) is an open protocol for connecting LLM applications to external context and capabilities. It standardizes message formats and interaction patterns so a host can discover and use tools, resources, and prompts exposed by independent servers. The current 2026-07-28 specification uses JSON-RPC 2.0 messages, stateless self-contained requests, and per-request metadata and capabilities.

The host-client-server model

The host is the AI application that owns the conversation, model integration, user interface, and security policy. It creates and manages MCP clients. Each client communicates with exactly one server, keeping one server connection's messages and permissions separate from another's. A server provides focused capabilities and can run as a local process or as a remote service.

This separation is important. An MCP server should receive only the context needed for the operation. The host remains responsible for deciding what conversation data to share, which servers are enabled, and whether a requested action needs user approval. MCP is an interoperability layer, not permission to expose an entire application or filesystem.

Resources, prompts, and tools

MCP organizes server capabilities into three primary primitives:

• Resources provide context or data identified by a URI, such as a file, database schema, ticket, or document.
• Prompts provide reusable messages or workflows that a user can select and supply with arguments.
• Tools provide executable functions that a model can ask the host to invoke, such as searching a repository, querying a database, or creating a ticket.

The common interaction model gives each primitive a different control boundary: resources are application-driven, prompts are user-driven, and tools are model-invokable. Hosts can still add their own approval flows and interfaces. A tool that reads data is not automatically safe, and a tool that writes data should be treated as a privileged operation.

Discovery and request flow

A host first decides which server to connect to and creates a client for it. The client discovers the server's capabilities, then lists available tools, resources, or prompts. When the model needs a capability, the client sends a JSON-RPC request such as tools/call, resources/read, or prompts/get with structured arguments. The server returns text, structured content, resource contents, an input-required result, or a protocol error.

Capabilities prevent clients from assuming that every server supports every feature. A server that exposes tools must advertise tool support, and clients must respect the capabilities returned by the server. List operations can be paginated or cached, so a production client should handle cursors and freshness metadata instead of assuming that one response is complete forever.

Transports and versions

MCP keeps protocol semantics separate from the transport. The standard local transport is stdio, where the client launches a subprocess and exchanges newline-delimited JSON-RPC messages. The standard remote transport is Streamable HTTP, where messages are sent to an MCP endpoint and replies arrive as JSON or a request-scoped Server-Sent Events stream.

Earlier MCP revisions used an initialize handshake and connection-scoped sessions. The 2026-07-28 revision uses self-contained requests with protocol metadata carried per request. Clients and servers that support more than one revision need an explicit compatibility strategy; a client should not assume that examples written for an older revision work unchanged.

MCP is not an API replacement

An API exposes a contract for a program or service. MCP is an agent-facing protocol for discovering context and capabilities and representing their use in a model-aware workflow. An MCP server may call one or more ordinary APIs behind the scenes, while presenting a smaller, safer set of model-facing tools and resources. MCP therefore complements APIs rather than replacing them.

Security and trust boundaries

MCP can reach files, databases, business systems, and arbitrary code, so the protocol expands the consequences of a bad tool description or an overpowered credential. Hosts should require explicit consent for sensitive data access and tool execution, use least-privilege credentials, validate arguments, enforce authorization at the server, isolate local processes, protect secrets, and log important actions. Tool descriptions and returned content should be treated as untrusted input unless the server and source are trusted.

Remote deployments also need transport security, authentication, origin or host validation where applicable, rate limits, timeouts, and audit trails. MCP provides message conventions; it does not make an integration safe by itself.

Example

An IDE host can connect to a repository MCP server. The server exposes project documentation as resources, a code-search function as a tool, and a review checklist as a prompt. The host shows the user what is available, sends only the relevant repository context, asks for approval before a write operation, and returns the tool result to the model as structured context.

The core idea

MCP standardizes how an AI application discovers, receives, and invokes external capabilities. Its value is the shared boundary between hosts, clients, and servers; its safety still depends on the host's consent, authorization, isolation, and validation decisions.