What is the Model Context Protocol?

In November 2024, Anthropic published the Model Context Protocol — an open standard for connecting AI agents to external tools and data sources. The announcement attracted significant attention, but the specification itself is relatively short and easy to misread if you approach it as just another AI feature. MCP is not a feature. It is a communication standard, and its implications for how software is built and exposed are significant.

This article explains what MCP is at a technical level, why it was created, how it differs from prior approaches like function calling and plugins, and what it means for teams that build and operate APIs. If you already understand the protocol and want to see how to expose your APIs as MCP tools, read the companion post on going from API to MCP tool in five minutes. This post is the foundation.

The Problem MCP Solves

AI language models are powerful text processors but they are stateless — they do not have access to your database, your internal APIs, the current time, or any information beyond their training data. Making them useful for real tasks requires giving them access to external systems. The question is: how?

Before MCP, the dominant pattern was model-specific function calling. You define a set of functions in a schema format specific to the model you are using — OpenAI has one format, Anthropic has another — and pass them with each request. The model can “call” a function by outputting a structured JSON object that matches the schema, and your application code handles the actual execution. This works but has a fundamental problem: every model has its own schema format, every integration has to be re-implemented per model, and nothing is reusable across agent frameworks.

MCP solves this with a standard protocol layer. Instead of defining tools inline in the model API request, you run an MCP server — a process that exposes tools, resources, and prompts via a standard wire protocol. Any MCP-compatible client (Claude Desktop, a custom agent, a CI pipeline) can connect to any MCP server and discover and invoke its capabilities, without either side knowing anything about the other's implementation details.

The Architecture: Clients, Servers, and the Protocol

MCP defines three roles: hosts, clients, and servers.

The wire protocol itself is JSON-RPC 2.0 over one of two transports. The stdio transport is used for local servers: the host spawns the server as a subprocess and communicates over stdin/stdout. The HTTP + SSE transport is used for remote servers: the client connects to an HTTP endpoint, sends requests as POST, and receives responses and server-initiated notifications via Server-Sent Events.

When a client connects to a server, it performs a capability negotiation: the server declares what protocol version it supports and which capabilities it exposes (tools, resources, prompts, sampling). The client records this and uses it to decide what interactions are possible. This negotiation happens once at connection time and is cached for the session lifetime.

Tools, Resources, and Prompts

MCP defines three primitives that servers can expose:

Tools are functions the AI agent can call to perform actions or retrieve information. Each tool has a name, a description, and an input schema (JSON Schema). When the agent calls a tool, it passes a JSON object matching the schema; the server executes the tool and returns a result. Tools are the primitive that most teams encounter first, and they map directly to API endpoints, database queries, or any programmatic action.

Resources are data sources the agent can read — files, database records, API responses that should be read lazily rather than fetched eagerly. Resources are identified by URIs and can be listed and read by the client. They support subscriptions: the server can push notifications when a resource changes, allowing the agent to stay current without polling.

Prompts are reusable prompt templates that the server can expose. Users can invoke them directly through the host interface. A prompt template might package up a complex multi-step task into a single named operation that the user can invoke with a few parameters — “generate a weekly summary report for customer X” backed by a prompt that fetches data, formats it, and asks the model to summarise it.

Most MCP implementations today focus on tools. Resources and prompts are well-specified in the protocol but less commonly implemented in production servers.

How MCP Differs from Function Calling

Function calling and MCP are solving related but distinct problems. Function calling is a feature of a specific model API — it lets you pass tool definitions to a model inference request and have the model output structured calls to those tools. MCP is a protocol for discovering and invoking tools from a remote server, independent of which model is being used.

The practical differences matter:

• Portability: An MCP server built for Claude works with any MCP-compatible client without modification. A function-calling integration built for GPT-4 requires rewriting the tool definitions to work with Claude, Gemini, or any other model.
• Separation of concerns: With function calling, tool definitions live in the application code that calls the model. With MCP, tool definitions live in the MCP server — they are discovered dynamically at connection time, not hardcoded in the calling application. This means the set of available tools can change without deploying a new version of the host application.
• Tooling ecosystem: The MCP ecosystem is growing rapidly — there are MCP servers for file systems, databases, GitHub, Slack, and hundreds of other services. Any MCP client can connect to any of these servers. With function calling, every integration is bespoke.
• Security model: MCP defines how authentication between clients and servers should work, including support for OAuth 2.0 for user-facing authorisation flows. Function calling has no authentication model — it is handled outside the function-calling protocol, in the application wrapper.

Function calling and MCP are not mutually exclusive. Under the hood, a host like Claude Desktop translates MCP tool calls into model-specific function calls when communicating with the model. MCP is the external-facing interface; the model's own function-calling mechanism is the internal implementation detail.

OAuth and Authentication in MCP

Remote MCP servers (those using the HTTP + SSE transport) can require authentication before a client can connect and discover tools. The protocol specifies OAuth 2.0 as the authentication mechanism, with support for dynamic client registration — a client that has never connected to a server before can register itself automatically and begin the OAuth flow without pre-configuration.

The OAuth flow for MCP works as follows: when a client attempts to connect to a protected server and receives a 401 response, it looks for the authorization server metadata at a well-known discovery endpoint. It registers itself as a new OAuth client (if it has no existing registration), then redirects the user to the authorization endpoint. After the user authenticates and authorises access, the client exchanges the authorization code for an access token and uses it on subsequent requests to the MCP server.

This flow supports two common patterns for API teams:

Session management is an important practical concern. The MCP protocol itself does not define session lifetime — it is determined by the OAuth access token expiry. If you use a short-lived token (the default for many OAuth configurations is 1 hour), the client will need to re-authenticate every hour. For automated workflows and background agents, this is disruptive. Configure token lifetimes to match the usage pattern: short sessions for interactive use cases where security is paramount, longer sessions (days or weeks) for automation pipelines where the interruption is unacceptable.

The MCP Ecosystem in 2026

In the eighteen months since the specification was published, the MCP ecosystem has grown substantially. Claude Desktop supports MCP natively. The open-source mcp-remote package lets any MCP client connect to remote HTTP servers that implement the protocol. There are hundreds of published MCP servers covering file systems, databases, version control systems, communication tools, and external APIs.

The pattern of adoption resembles the early years of REST. There is a period where the standard is defined and the tooling is being built. Then a period where early adopters implement it and share learnings. Then the point where it becomes an expected capability — something customers ask for, something that differentiates products that support it from those that don't.

We are in the second phase. AI agent use is accelerating and MCP is the de facto interoperability standard. Teams that have exposed their APIs via MCP are already seeing AI agents use them in ways the teams did not explicitly design for — Claude independently composing multiple tool calls to answer complex questions, agents using APIs in automated pipelines the human team had not envisioned. This is the value of a standard: you build the capability once, and the use cases emerge organically.

What This Means for API-First Teams

If your team builds and operates APIs, MCP is a new distribution channel for your capabilities. Your API documentation, your OpenAPI spec, your Postman collection — these already contain the information needed to generate MCP tool definitions. The question is whether you expose that information in a way that AI agents can consume.

Teams that do this well gain two advantages. First, their APIs become accessible to AI-powered workflows without integration work on the consumer side — any MCP-compatible agent can discover and use the tools without the consumer team writing wrapper code. Second, they gain visibility into how AI agents use their APIs — which tools are called most frequently, which parameters are most commonly used, where calls fail.

The implication for API design is significant. APIs have historically been designed for human-readable documentation and SDK consumption. MCP changes the primary consumer to an AI agent that reads tool descriptions at connection time and uses them to make real-time decisions about which tools to call. This shifts the importance of description quality: a tool with a precise, accurate description will be used correctly and frequently. A tool with a vague or misleading description will be called at the wrong times or not at all.

Description quality is the new API documentation quality. Teams that invest in clear, accurate tool descriptions — the same investment they would make in good OpenAPI operation descriptions — will see better AI agent behaviour on their tools.

The Right Architecture for MCP Exposure

Directly exposing internal microservices as MCP tools is possible but rarely the right architecture. Internal services are designed for service-to-service communication — their interfaces are shaped by implementation constraints, not by the needs of an AI agent consumer. Exposing them directly means every service change can break tool definitions, every internal field appears in the tool schema regardless of relevance, and authentication must be handled per-service.

The better architecture uses an orchestration layer between internal services and the MCP server. The orchestration layer:

• Composes multiple service calls into single, coherent tool operations
• Handles authentication with internal services, so AI agents never need service-specific credentials
• Transforms response shapes to expose only the fields relevant to AI agent use cases
• Provides the right level of abstraction — “get product with inventory status” as one tool, rather than separate “get product” and “get inventory” tools that the agent must manually compose
• Insulates internal service changes from the tool interface — the MCP tool contract is stable even as the underlying implementation evolves

This is the same argument for using an API orchestration layer for other consumers — BFF layers, API gateways — applied to the AI agent use case. The orchestration layer is the right place to define what your services “look like” to the consumer, regardless of what they look like internally.