Model Context Protocol (MCP)

On this page

Three roles

A host is the AI application the person is using. A client is the connector inside that host. A server exposes resources, prompts and tools that the client can list and invoke.

The separation matters because the model never reaches the outside world directly. It proposes a call; the application executes it. That boundary is where argument validation, permission checks and approval belong.

What it standardises, and what it does not

MCP supplies	The buyer still supplies
A common way to list and invoke tools	Whether this server is trusted for this job
Input schemas and structured results	Server-side validation of what the model proposed
Capability negotiation and versioning	A pinned server identity and version
Optional OAuth-based authorisation	The policy deciding whether the action is permitted

The specification is explicit that consent and human control sit with the host and client, and that the protocol cannot enforce those principles at the protocol level. A registry listing or a familiar tool name is discovery evidence, not an approval.

Reading it in the market

MCP has become a common way to describe tools, which is why connector catalogues and registries grew quickly around it. Those counts measure published supply. They do not measure how often independent customers invoke a server, whether the work was accepted, or whether the route is safe in a particular deployment.