Home › Claude Ecosystem Guides

The Model Context Protocol (MCP), Explained

The Model Context Protocol (MCP) is an open standard that lets an AI application connect to external tools, data sources, and prompts through one common interface instead of a separate integration for each service.

Last reviewed: 2026-09-04 · Українською

The problem: an integration for every pairing

Before MCP, wiring an AI assistant into your systems meant writing bespoke glue for each combination. Connecting one app to your database, your ticketing system, and your file store took three custom integrations; connecting a second app repeated all three. The effort grew as the number of apps times the number of systems, and almost none of it was reusable.

MCP replaces that with a single contract. It is often described as a standard port for AI integrations: you write one server that exposes your data or actions, and any compatible application can talk to it without knowing your internals. The many-to-many explosion collapses into something manageable — build the connector once, reuse it everywhere.

The client-server model

MCP is built on a clean split between two roles. An MCP client lives inside an AI application — a desktop assistant, a coding agent, or a backend service calling the API. An MCP server is a small program you or a vendor runs that wraps a specific capability: a Git repository, a database, a search index, a calendar.

The client discovers what a server offers and relays those capabilities to the model; the server does the actual work when asked. Because the boundary is standardized, a server written by someone who has never seen your app still works with it, and a single client can hold connections to many servers at once. This is the same decoupling that let web browsers talk to any web server — the value is in the shared protocol, not any one implementation.

Tools, resources, and prompts

An MCP server can expose three distinct kinds of capability, and the difference matters when you design one:

• Tools are actions the model can invoke — create a ticket, run a query, send a message. They can change state and are the server-side counterpart of function calling.
• Resources are read-only context the application can load into the model — a file's contents, a table's rows, a document. They inform without acting.
• Prompts are reusable, parameterized templates a server offers — a curated way to ask for a code review or a summary, so good phrasing ships with the integration instead of being reinvented per user.

Keeping actions, data, and templates as separate categories lets a host application present each appropriately: a tool needs a permission check, a resource needs a picker, a prompt needs a menu entry.

How Claude connects to MCP servers

Claude reaches MCP servers through several surfaces. In a desktop app you register a server in a local configuration file; in an agentic coding tool you add it to that tool's settings; and over the API a connector lets a server-side call reach an MCP endpoint. In every case the model itself does not open sockets — the surrounding client manages the connection, authentication, and permission boundaries.

A concrete example: point a client at a Git MCP server and ask, "summarize the changes since the last release." The client lists the server's tools, the model chooses to read the commit log, the server returns it as a resource, and Claude writes the summary from real data. Swap in a database server and the same assistant now answers questions about your tables — no new model, no new app code, just a different server behind the same protocol.

Where MCP sits among the building blocks

MCP is not a replacement for tool use — it is a delivery mechanism for it. Underneath, the model still receives tool definitions and emits tool-use requests; MCP standardizes how those definitions arrive and how the results flow back, so any client and any server interoperate. Think of tool use as the language and MCP as the shared port that carries it between programs.

That distinction is why MCP scales an ecosystem rather than a single app. Once a capability is exposed as an MCP server, every compatible assistant gains it at once, and every new assistant inherits the entire catalog of existing servers on day one. The protocol turns integrations from private, per-app work into a shared, growing commons.

Frequently asked

Is MCP specific to Claude?

No. MCP is an open protocol, so any application or model vendor can implement a client or server. Claude connects to MCP servers, but the standard is designed to be shared across the wider AI ecosystem.

What is the difference between an MCP tool and a resource?

A tool is an action the model can invoke that may change state, like creating a record. A resource is read-only context, like a file or a set of rows, that the application loads to inform the model without performing an action.

Do I need MCP to give Claude tools?

No. You can define tools directly in an API call. MCP becomes worthwhile when you want those tools packaged as a reusable server that many applications can share, rather than re-declared inside each one.

Continue in this track