Model Context Protocol (MCP)

Quick Answer

MCP, the Model Context Protocol, is an open standard for connecting AI models to tools, data, and systems through one consistent interface. A server exposes capabilities, the model acts as a client that discovers and calls them. It replaces the tangle of custom one-off integrations that previously connected every model to every system.

What is MCP?

MCP standardizes the connection between an AI system and the things it needs to do real work. The common analogy is a universal port: one interface, many devices, no bespoke wiring per device.

The architecture has three roles worth knowing by name, because they are where the design decisions live:

Server: Wraps a system, a database, a file store, an API, a SaaS product, and exposes specific capabilities through the protocol.

Client: The AI application that discovers what a server offers and calls it.

Transport: The connection between them, which can be local to a machine or remote over the network.

The practical shift is in integration count. Connecting three assistants to four internal systems used to mean up to twelve custom connectors, each with its own auth and error handling.

With a standard, it means four servers that any compliant client can use. The integration work moves from N×M to N+M, which is the entire economic argument.

Why MCP Matters Now

last reviewed: June 2026

Agents are bounded by what they can reach. The reasoning can be excellent and still useless if the agent cannot query the shipping system it is reasoning about. Tool access was the practical bottleneck on most deployments, and MCP has become the default answer to it, with adoption across the major model providers and a fast-growing ecosystem of ready-made servers through 2025 and 2026.

The second-order effect matters more than the convenience. When access becomes standard, the constraint stops being "can we connect it" and becomes "should we, and on what terms."

That moves the hard problem from integration engineering to access governance, and most teams have not noticed the move yet.

How MCP Works

A session runs in three stages:

1. Discovery: The client asks a server what it offers. Servers expose three kinds of things: tools the model can call, resources it can read, and prompts, which are reusable task templates.
2. Invocation: The model decides a tool is needed, the client sends the call, the server executes it against the underlying system and returns the result.
3. Composition: Results flow back into the model's context, it reasons over them, and the loop continues.

The design property to internalize: capability is defined at the server, not the model. The server decides what is exposed, with what parameters, under what permissions. Swap the model next year and the access layer stands.

Swap the underlying database and the client never notices. That separation is what makes the standard durable, and it is also exactly where control has to be engineered, because a permissive server is permissive for every client that connects to it.

Benefits of MCP

1. Build once reuse everywhere: A server written for your CRM serves every AI application you run, current and future.
2. Integration cost collapses: N+M connectors instead of N×M, and the maintenance burden shrinks with it.
3. Model portability: The access layer survives model swaps, so vendor choice stops being an integration decision.
4. Central control point: Permissions live at the server, one place to define and audit, instead of scattered across a dozen custom integrations.
5. A ready ecosystem: Common systems already have maintained servers, so much of the connective work is assembly rather than construction.

Where MCP Is Used

1. Agent tool access: Giving agents controlled reach into databases, ticketing, CRMs, and internal APIs.
2. Knowledge connectivity: Assistants reading from document stores and wikis without custom retrieval plumbing per source.
3. Development workflows: Coding agents reaching repos, issue trackers, and CI systems through one layer.
4. Product portfolios: Several AI products sharing one integration layer instead of each maintaining its own.

Common Mistakes With MCP

1. Over-exposing because it is easy: A server that wraps the whole database when the agent needs three queries has created permanent risk for temporary convenience.
2. Trusting third-party servers blindly: A community server is code running with access to your systems. Unvetted, it is a supply-chain risk with a friendly name.
3. Auth as an afterthought: The protocol standardizes connection, not judgment. Skipping scoped credentials because connection got simple is exactly backwards.
4. No call-level logging: If you cannot answer what the agent accessed, when, and with what parameters, an incident is unfalsifiable. You will not know whether data left, only that it could have.
5. Prompt-injection blindness: Content an agent reads through one server can carry instructions that trigger actions through another. Read paths and write paths need separating, because combined they turn a malicious document into a command.

When You Should Not Use MCP

If the need is one fixed API call in a deterministic flow, a direct integration is simpler and there is nothing to standardize. Protocols pay for themselves through reuse, and a one-off with no reuse ahead just adds a layer.

If you cannot yet vet, scope, and log access, connecting faster is the wrong next move. A standard that makes granting access trivial is only an asset after you have decided what should be granted, by whom, and with what audit trail. Governance first, plumbing second.