What Is Model Context Protocol (MCP)?

The problem MCP solves

An AI application becomes useful in operations when it can read real data and act through real tools: a ticketing system, a network controller, a hypervisor or a call-control API. Without a standard, every pairing of AI application and system needs its own integration. Model Context Protocol (MCP) is an open protocol that standardises this connection, so a system exposed once through an MCP server can be used by any MCP-capable application.

Architecture: hosts, clients and servers

MCP follows a client-host-server architecture built on JSON-RPC.

• Host: the AI application the user works in. It creates and manages clients, enforces security policies and consent, handles user authorisation decisions and coordinates the model.
• Client: a connector created by the host. Each client talks to exactly one server and keeps the boundary between servers.
• Server: a focused program that exposes a capability, such as access to a file system, a database or a device API. Servers can run locally or as remote services.

One host can run many clients at once, each connected to a different server. A server never sees the whole conversation and cannot see into other servers; the host decides what context each server receives.

What servers expose

• Tools: functions the model can ask to call, each with a name, a description and a JSON Schema for its input. Examples: get_interface_status, list_virtual_machines.
• Resources: data the application can read, identified by URI, such as a configuration file or an inventory record.
• Prompts: reusable, parameterised templates that a user can select.

Clients can offer features back to servers, including sampling (asking the host's model to generate text), elicitation (asking the user for input) and roots (telling the server which locations it may work within). Capabilities are declared explicitly, so each side only uses what the other supports.

How an AI system reaches external infrastructure

A typical tool interaction looks like this:

1. 01DiscoverThe client lists the server's tools (tools/list) and receives their names and input schemas.
2. 02ProposeThe model decides a tool would help and proposes a call with specific arguments.
3. 03CheckThe host applies policy and, where required, asks the user to confirm.
4. 04CallThe client sends tools/call to the server, which calls the underlying API or device.
5. 05ReturnThe structured result goes back to the model, which uses it in its next step or answer.

MCP defines transports for local servers over standard input and output (stdio) and for remote servers over HTTP. The current specification revision (2026-07-28) is stateless at the protocol level: each request carries its own protocol version and client capabilities.

Security and access boundaries

MCP standardises the connection; it does not decide what an AI system is allowed to do. That decision belongs to the host and to the systems behind each server.

• For HTTP transports, the specification uses OAuth 2.1. An MCP server acts as a resource server and must only accept tokens issued for it.
• For stdio servers, credentials come from the local environment rather than the authorisation flow.
• Tool descriptions and tool results come from outside the model and must be treated as untrusted input.
• A tool that can change state needs stronger controls than a read-only tool: narrower permissions, explicit approval and an audit record.