Model Context Protocol (MCP)

Compass

An open way of exposing tools and data to a model, so an integration is declared once rather than per application.

What is the Model Context Protocol?

The Model Context Protocol is an open specification for exposing tools and data sources to a model through a uniform interface. A capability is described once by a server, and any client speaking the protocol can then use it. It replaces a bespoke integration per application with a single declared contract.

Also called: MCP

Why MCP matters at the fifth integration rather than the first

An engineering lead asks what MCP actually saves, and the honest answer is nothing at all on the first connection. The cost appears when a second assistant needs the same systems, and a third needs most of them again, at which point an organisation is maintaining one integration several times over in slightly different states. A declared server collapses that into one implementation with one place to change an entitlement. The governance consequence is larger than the engineering one, because a tool surface declared in one place can be inventoried.

  • An integration declared once is governed once rather than per calling application.
  • A protocol boundary makes the tool surface available to an inventory.
  • Clients and servers are replaceable independently, which contains vendor exposure.
  • Permission checks live with the server rather than scattered across callers.

How the Model Context Protocol works

  • A server exposes its capabilities with a schema describing each input and output.
  • The client discovers those capabilities at connection time rather than by configuration.
  • The model is presented with the declared capabilities as available actions.
  • A selected capability is invoked with arguments validated against the declared schema.
  • The server enforces entitlement and quota before touching the underlying system.
  • Each invocation is recorded with its arguments and its caller for later inspection.

How the Model Context Protocol is evaluated

An MCP deployment is judged on what the protocol boundary actually enforces. Examine the following across every server in production:

  • share of capabilities with a complete and validated input schema
  • entitlement checks enforced server side rather than assumed by the client
  • invocation logging completeness, including arguments and caller identity
  • error rate from schema mismatches between client and server versions
  • time required to add a new client against an existing server

Limitations, risks and common failure modes

  • A server exposes a broad capability because narrowing it required more thought.
  • Entitlement is checked by the client, so a second client inherits none of it.
  • Schema changes are deployed without versioning, which breaks callers silently.
  • The protocol is adopted for discovery while audit logging is left for later.

Related terms

Function callingThe implementation of tool calling, where the model emits a structured request matching a declared signature.Context windowThe amount of text a model can consider at once, which bounds how much evidence an answer can rest on.Browser automationDriving a web application the way a person would, through its pages rather than its backend.System of recordThe authoritative source for a given fact, which an AI layer must agree with rather than compete against.Tool callingA model invoking a defined capability, which is the point at which answering becomes acting.Context engineeringDeciding what a model should have in front of it for a given task, which has largely displaced prompt wording as the discipline that matters.

All 315 terms