Sistava

What is Model Context Protocol?

Also called MCP.

Model Context Protocol is an open standard that defines how AI applications connect to external tools and data sources. It specifies a client and server architecture in which servers expose capabilities such as callable tools, readable resources, and reusable prompts, and clients consume them over a common message format. It was originally published by Anthropic and is developed openly as a public specification.

Communication follows the JSON-RPC 2.0 message convention. A host application runs one client per connected server, and each server advertises what it offers during an initialization handshake. Servers commonly run either as a local subprocess that exchanges messages over standard input and output, or as a remote HTTP service. The specification is versioned by dated revisions, so implementations negotiate a version that both sides support.

Before a shared standard existed, every AI application wrote bespoke glue for every system it wanted to reach, so the number of integrations grew with the number of applications multiplied by the number of systems. A common protocol turns that into one server per system, reusable by any compliant client. That economics is why an ecosystem formed quickly around servers for file systems, databases, issue trackers, and hosted software products.

A frequent misconception is that the protocol makes a model smarter or replaces an API. It does neither. It is a description and transport layer that tells a client what exists and how to call it, while the underlying system still enforces its own permissions and limits. Another mistake is treating whatever a server returns as trusted instruction, rather than as data that may contain text aimed at steering the model.

It sits alongside, not against, function calling. The model still emits a structured call, and the protocol standardizes where that call travels and how results return. It also differs from agent to agent protocols, which coordinate independent agents as peers rather than exposing tools and data to a single host application.

Key points

In practice

A team wants their assistant to answer questions about open support tickets. Instead of writing custom code inside the assistant, they run a server that exposes two tools, one that searches tickets and one that reads a single ticket. Any compliant application can now connect to that server, see the two tools described in plain language, and call them. Swapping the assistant for a different one requires no change to the server.

Related terms

Back to the AI Glossary