Most useful AI applications eventually need more than a model call. They need to read files, query databases, inspect logs, call internal APIs, create tickets, update code, or pull in the right context at the right moment.

The Model Context Protocol (MCP) standardizes how an AI application connects to those external systems.

The language model does not usually speak MCP directly. The application around the model does. That application, called the host, runs one or more MCP clients, connects them to MCP servers, translates server capabilities into the model provider's tool format, and decides when approval or policy checks are required.

That distinction matters. MCP is not a reasoning framework, an agent runtime, or a replacement for function calling. It is an integration protocol for exposing tools, resources, and prompts to AI applications in a consistent way.

Before MCP, each AI product had to build its own integration layer. A coding assistant needed a GitHub wrapper, a filesystem wrapper, a database wrapper, a Slack wrapper, and so on. Another assistant needed its own versions of the same integrations. The tool code, schema format, authentication path, approval flow, and error handling were all application-specific.

That creates an N x M integration problem: N AI applications multiplied by M external systems.

MCP changes the shape of the work. A team can expose a capability once as an MCP server. An AI application can implement MCP client support once, then connect to compatible servers without writing a custom adapter for each integration.

Compatibility is not automatic. Clients still differ in transport support, authentication support, approval UX, and feature coverage. But MCP gives both sides a shared contract.

Three apps connecting to three systems without MCP can mean nine custom integrations. With MCP, the work becomes closer to three client implementations and three server implementations. At ten apps and twenty systems, that is the difference between 200 custom adapters and about 30 protocol-facing implementations.

MCP was introduced by Anthropic in late 2024 and is now an open protocol maintained through the Model Context Protocol project. It is not tied to Claude or to any specific model provider. The specification is versioned, and production systems should treat the spec version as part of their compatibility surface.

MCP defines three roles: host, client, and server. They are easy to mix up at first, so keep the boundary clear.

Host

The host is the AI application the user interacts with: a desktop assistant, an IDE extension, a CLI agent, or your own product. It owns the conversation, model calls, user interface, and safety policy. The host is responsible for:

A single host usually manages multiple MCP clients. For example, a coding assistant might maintain separate clients for filesystem access, GitHub, package documentation, and a database schema server.

Client

The client is the protocol handler inside the host. In the standard architecture, one client manages one connection to one MCP server. Its job is intentionally narrow:

The one-client-per-server pattern keeps failures and permissions easier to reason about. If one server crashes or becomes unresponsive, the host can degrade that connection without tearing down every other integration.

Server

The server exposes the external capability. It may wrap a local command, a SaaS API, a database, a document store, an internal service, or a workflow. Servers expose capabilities through MCP primitives:

Servers can run locally as subprocesses of the host, or remotely behind an HTTP endpoint. Good servers usually have a clear domain boundary: one server for GitHub, one for database metadata, one for incident-management operations. A server that exposes every internal system through one huge tool surface is harder to secure, test, and explain to the model.

How a Request Flows

When a user asks a question that requires external data, here is the full sequence:

This is the normal tool-calling loop, with a standardized protocol between the application and the external capability. The model may propose a tool call. The host still decides how to expose tools, whether to require approval, and how to route the request.

MCP servers expose three main server-side primitives: resources, tools, and prompts. Each one has a different purpose. If you model every capability as a tool, you often end up with a server that is harder to secure and harder for the model to use well.

Resources: Exposing Data

Resources are data the client can read and provide as context. Think of them as documents with stable URIs. A filesystem server might expose files. A database server might expose schemas. An API documentation server might expose endpoint specs.

Resources are identified by URIs, like file:///home/user/notes.txt or db://products/schema. Clients can list available resources, read their contents, and optionally subscribe to changes (for resources that update over time).

Resources are meant to be read-oriented and side-effect-free. Reading a resource should not modify business state. That makes resources safer to preload, cache, display in a picker, or include in model context under host control.

Tools: Performing Actions

Tools are callable operations. They might search files, execute a query, send a message, create a pull request, or run a calculation. Each tool has a name, description, and input schema.

Tools are model-visible and may have side effects. Writing a file, sending an email, or deleting a record should be modeled as a tool, not a resource. Hosts should show which tools are available and require confirmation for sensitive operations. The protocol can describe the capability; the host enforces the product policy.

Prompts: Reusable Templates

Prompts are reusable prompt templates that a server offers to clients. A code review server might provide a "review this pull request" prompt. A database server might provide an "optimize this query" prompt with a useful diagnostic sequence.

Prompts are usually user-controlled. They are often exposed as slash commands, menu items, or workflow templates. They shape how the model approaches a task; they do not execute work by themselves.

Comparing the Primitives

In practice, many servers start with tools because tool calls are easy to wire into a model loop. Mature servers usually add resources for stable context and prompts for common workflows.

Every MCP message is a JSON-RPC 2.0 message. JSON-RPC is a lightweight format for requests, responses, and one-way notifications. The transport does not change the message format; it only changes how those messages travel between client and server.

The MCP specification defines two standard transports: stdio and Streamable HTTP. The JSON-RPC messages are the same in both.

stdio: Local Communication

With stdio transport, the MCP server runs as a child process of the host application. The client starts the server process and communicates with it by writing JSON-RPC messages to the server's standard input and reading responses from its standard output.

This is the simplest transport. There is no port to expose and no remote authentication flow to configure. The server starts when the host starts and stops when the host stops. It is a good fit for local tools: filesystem access, local database queries, CLI utilities, and developer-machine workflows.

The downside is that stdio servers are tied to a single host process. You cannot share a stdio server across multiple users or applications. If the host restarts, the server restarts too, losing any in-memory state.

Streamable HTTP: Remote Communication

With Streamable HTTP, the server runs as an independent HTTP service. The server exposes a single MCP endpoint that accepts POST requests for JSON-RPC messages. It can also use GET and Server-Sent Events (SSE) for server-to-client streaming, progress updates, and notifications.

Streamable HTTP enables several patterns that stdio cannot support:

The trade-off is operational complexity. You need a URL, TLS, origin validation, authorization, session handling, timeouts, and observability. For many local tools, that overhead is unnecessary.

Choosing a Transport

A common pattern is to develop a server locally over stdio, then expose the same capability over Streamable HTTP when it needs to be shared. The tool and resource definitions often stay the same, but production deployment adds authentication, authorization, logging, rate limiting, and health checks.

MCP is both a specification and an ecosystem of SDKs, clients, servers, registries, and hosted gateway products. The ecosystem moves quickly, so treat compatibility as something to verify, not assume.

Existing MCP Clients

Several AI applications support MCP as clients or hosts. Exact support varies by version, transport, and configuration:

When you build an MCP server well, you can often reuse it across multiple hosts. In practice, you still test against the clients your users care about. Some clients support only stdio, some support remote servers, some have different approval UX, and authenticated remote MCP is still an area where implementations vary.

Existing MCP Servers

The ecosystem includes official, vendor, and community servers covering common integration points:

MCP Registries

As the number of servers grows, discovery and governance become their own problems. Registries and private catalogs help teams publish approved servers, document configuration, track ownership, and prevent users from installing arbitrary code from search results.

A registry is not only a marketplace. In an enterprise setting, it is often a control point: which servers are approved, who owns them, which scopes they require, what data they can access, and which clients are allowed to connect.

This is still an active area of the ecosystem. For production deployments, prefer curated internal registries or allowlists over open-ended dynamic installation.

Function calling and MCP can look like competing answers to the same problem. They are not. They sit at different layers of the stack and often work together.

Function Calling: The Mechanism

Function calling is a model API mechanism. You provide tool descriptions to the model, the model returns a structured request to call one of them, and your application executes the call. Without another integration layer, those tool definitions live inside your application.

MCP: The Protocol

MCP is the protocol by which tools, resources, and prompts are discovered, described, and accessed across application boundaries. It standardizes how a host connects to a capability provider.

The common integration pattern is: discover MCP tools, convert their schemas into the model provider's tool format, send them to the model, then dispatch the model's tool request back through MCP. The model does not need to know MCP exists. The host handles translation and policy.

What MCP Adds Beyond Function Calling

When to Use Which

Use plain function calling when you have a small number of tools tightly coupled to your application. A chatbot with three custom tools that will never be reused elsewhere probably does not need MCP.

Use MCP when tools should be reusable across applications, when another team owns the integration, when you want to connect to existing servers, or when discovery and capability negotiation matter. MCP becomes more valuable as the number of applications and tool providers grows.

In many production systems, you will use both. Some tools are MCP servers because they are shared and standardized. Others are inline function definitions because they are app-specific and lightweight. The two approaches coexist.