Model Context Protocol (MCP)

Last verified: June 2026· definition

The Model Context Protocol (MCP) defines a common way for an AI client — like Claude Code or Cursor — to discover and call tools, read resources, and use prompts from an external server. Instead of every application re-implementing tool integrations, an MCP server exposes a system once and any MCP-capable client can use it.

In practice, an MCP server wraps a system such as a database, an observability platform, or an issue tracker, and presents its capabilities as typed tools. A well-built server adds authentication, scoped access, and audit logging so agents can act against company infrastructure safely.

MCP matters because it turns one-off integrations into reusable, governed infrastructure: build the server once, and every agent and developer on your team can use it under the same controls.

Build once, use from any client

The problem MCP addresses is combinatorial. Before a shared protocol, connecting each AI client to each internal system meant a bespoke integration per pair, so adding a client meant rebuilding every integration. An MCP server exposes a system once through a standard interface and any MCP-capable client can use it. The value grows with the number of clients and systems, which is why it matters more to organisations with several tools in use than to an individual developer.

The protocol is the easy part

Implementing MCP is straightforward; designing what to expose is not. A server generated by mapping each API endpoint to a tool technically conforms and works poorly, because an agent facing dozens of overlapping thin tools cannot reliably choose between them. The work that determines whether a server is useful is deciding on a small number of task-shaped tools that correspond to what someone would actually want done.

Governance is what makes it safe

Because MCP servers let agents act against real systems, they are where authentication, scoped authorisation, and audit logging need to live. Permissions must be enforced by the server using identity from the authenticated session rather than from model-supplied arguments, since anything the model can set can be influenced by content it has read. A server without these is a functioning integration and an unacceptable production dependency.

Local and remote servers are different products

A server running locally over stdio for a single developer has modest requirements. One serving customers remotely needs OAuth, multi-tenant isolation, rate limiting, versioning, uptime commitments, and observability. Both are MCP servers and the engineering involved differs by an order of magnitude, so it is worth being explicit about which you are building before estimating the work.

Common misconceptions

MythMCP replaces function calling.
RealityThey sit at different layers. MCP is a portable protocol for exposing tools; the model still invokes them through its own function-calling mechanism. MCP adds reuse across clients, not a different way for models to call things.
MythWrapping an API in MCP is enough.
RealityEndpoint-per-tool mapping produces a large set of overlapping tools that agents select between poorly. Tool design, not protocol conformance, determines whether the server is usable.
MythMCP servers are only for developer tools.
RealityThe same protocol is how a product exposes its capabilities to customers’ agents. That use has substantially heavier requirements around auth, tenancy, and operations.

Frequently asked questions

What problem does MCP actually solve?

The integration explosion. Without a shared protocol, every AI client needs a custom connector to every system, so the work scales with clients multiplied by systems and each new client means rebuilding everything. MCP makes it additive: expose a system once and any compliant client can use it. It also gives you one place to enforce authentication, scoping, and audit logging rather than repeating that per integration.

Do I need MCP if I already use function calling?

Not for a single application with one model provider, where function calling alone is simpler. MCP earns its place when the same capability needs to be available from multiple clients, when you want one governed access path to internal systems, or when you are exposing capabilities to agents outside your own application. It is about portability and centralised control rather than about how the model invokes tools.

What makes a good MCP server?

A small number of task-shaped tools rather than a mirror of your API surface, descriptions that state when each tool applies rather than only what it does, permissions enforced server-side from authenticated identity, approval requirements on destructive operations, and per-call logging. The design work sits almost entirely in tool selection and authorisation; the protocol implementation is routine by comparison.

Go deeper

MCP