Model Context Protocol (MCP)

What is Model Context Protocol?

Model Context Protocol (MCP) is an open standard that defines how an AI model connects to external tools, data sources, and systems through a single client-server interface. One integration written to the specification works with any client that speaks it, so each new model does not require new connector code.

The specification was introduced by Anthropic in late 2024 and published openly, which is why implementations now exist across desktop assistants, coding tools, and agent runtimes. Before it, every model-to-system connection was bespoke: N models times M systems produced a separate connector for each pair, and each one aged independently.

How Model Context Protocol works

MCP defines three roles. The host is the application the user talks to. The client lives inside the host and holds one connection per server. The server wraps a system, a CRM, a database, a ticket store, and exposes what that system can do.

A session then runs in a fixed order. The client opens a connection and both sides negotiate capabilities, so neither assumes features the other lacks. The client asks the server to list what it offers, and those descriptions enter the model's context as callable functions. From there the mechanics are ordinary tool calling: the model emits a structured call, the client forwards it as a JSON-RPC request, the server executes against the real system and returns a typed result.

The protocol sits underneath the AI agent framework, which handles planning, memory, and state, and underneath AI agent orchestration, which decides which agent acts on which task. MCP owns transport and discovery. Messages travel over standard input and output for local servers, or over HTTP for remote ones.

Types of MCP servers and primitives

• Tools: Model-invoked functions the server exposes, each carrying a name, a typed argument schema, and a description the model reads at decision time.

• Resources: Read-only data the host pulls into context, addressed by URI, whether that is a file, a customer record, or a query result.

• Prompts: Reusable templates the user selects deliberately, which keeps high-stakes workflows under human initiation.

• Local servers: Processes running on the user's own machine over standard input and output, fast and private, inheriting whatever permissions that machine already grants.

• Remote servers: Shared servers reached over HTTP by many users at once, where authorization and per-user identity become the whole design problem.

Model Context Protocol vs A2A Protocol vs custom API integrations

Teams building agent plumbing meet these three at once, and the names blur badly in vendor material. Model Context Protocol connects one model to the tools and data it needs. A2A Protocol connects one agent to another agent that owns work the first cannot do. Custom API integration connects one application to one system, in code written for that pair alone. MCP standardizes the vertical link between a model and its capabilities, which is the link that had to be rebuilt whenever either end changed.

Pick by the direction of the connection. If a model needs to reach systems, that is MCP. If an agent needs to hand work to another agent, that is A2A. If exactly one pair will ever exist and neither end moves, custom code is still cheaper.

Why Model Context Protocol matters for customer experience

Support automation fails at the seam between knowing and doing. An agent that can quote the refund policy but cannot read the order record produces a confident non-answer, and the customer repeats the whole story to a human. MCP closes that seam by giving the model one way to reach the order system, the subscription record, and the shipping API inside a single turn. The same server backs an agent answering in a web widget and one answering over the WhatsApp Business API, so adding a channel stops meaning adding integrations.

The tradeoff is exposure. A uniform interface makes every connected system reachable by a model that will occasionally reason badly, so scoping moves to the server: what it exposes is what the model can do, and a write action shipped without a confirmation step eventually fires on the wrong account.

How is Model Context Protocol adoption measured?

No conformance registry exists for MCP and no certificate tells you a given server behaves, so measurement happens per server and per deployment. Adoption is easier to place in context than to count directly: the Stanford HAI AI Index reported organizational AI use climbing from 55% in 2023 to 78% in 2024, the growth curve that made hand-written per-model connectors untenable.

What teams actually instrument is narrower. Tool call success rate separates protocol errors from application errors, which matters because a malformed schema and a declined payment both surface to the model as failure. Discovery latency, measured at session start, decides whether the first turn feels slow. Context cost is the quiet one: tool and resource descriptions occupy the same window as conversation history, so a server that advertises everything it can do crowds out what the customer said.

How AI agents change Model Context Protocol deployments

A model that answers questions reads its context once. An agent works in a loop: it calls a tool, reads the result, and chooses the next call from what came back. That loop changes what the protocol has to carry, because a description written for a human integrator becomes the only instruction the model receives at decision time. A tool named update_record with a one-line summary will be called wrongly, and called often.

Two consequences follow. Servers ship descriptions authored for a model reader: explicit preconditions, enumerated arguments, and error strings that state the next valid action. And write operations acquire a confirmation layer, since an autonomous loop retries a failed call, and a retried refund is a second refund. Teams running this in production treat the tool surface as product design, which is the substance of this walkthrough of CRM workflow execution.

What to look for in a Model Context Protocol implementation

Coverage comes first: check whether servers already exist for the systems that hold your answers, or whether you will be writing and maintaining them. Integration surface is next, and it splits by transport, since remote servers need authorization, per-user identity, and audit logging, while local servers inherit the permissions of the machine they run on.

Governance is the axis teams skip. Tool definitions are code that changes model behavior, so they need named owners, review before merge, and versioning. On security, regulated buyers ask for SOC 2 Type II evidence covering wherever the server is hosted, and they ask which identity is recorded against each write.

The constraint that bites late is spec churn. The specification is young and still revising, so a client and a server pinned to different revisions negotiate down to a shared subset, and the symptom looks like a missing feature.

Model Context Protocol and the wider agent stack

MCP and agentic AI describe different layers of one system. Agentic AI is the behavior: planning, deciding, and acting across steps. MCP is one of the interfaces that behavior reaches through, and neither implies the other, since an agent can act through hand-written integrations and an MCP server can serve a model that only performs lookups.

The closest operational neighbor is the ticketing system. Once a server exposes ticket reads and writes, an agent can set status, attach evidence, and post internal notes inside the same conversation it is having.

What does Model Context Protocol mean in plain terms?

MCP stands for Model Context Protocol, and the middle word carries the point: context is both what the model is allowed to know and what it is allowed to touch. Think of it as a standard power socket. Any appliance with the right plug works in any room, and nobody rewires the house to buy a kettle.

Without a socket standard, every appliance arrives with its own wall connection. That was the state of AI integrations before: a company running four models against ten systems maintained forty separate connections, and every model upgrade broke a share of them.

The tradeoff is that a socket hides what sits behind the wall. Once a system is plugged in, the model sees a short description and trusts it, so a server that names a destructive action mildly will have it called casually.

Common Model Context Protocol mistakes

Exposing the entire API surface is the first pattern. Every tool description consumes context, and near-duplicate tools make selection ambiguous, so a server with sixty endpoints produces a model that picks the wrong one and a conversation with no room left for the conversation.

Skipping authorization design is the second. Identity terminates at the server, and a server holding one shared service account grants every user the reach of that account, regardless of what the front end thinks it is enforcing.

Writing tool descriptions for human integrators is the third. The description is the prompt. Prose that assumes a reader who can check the docs becomes an instruction the model follows literally and incorrectly.

The fourth is expecting the protocol to supply judgment. MCP standardizes how a call is made and leaves the decision to make it with the model, so limits belong in the server and in an explicit guardrails layer.