MCP (Model Context Protocol): Definition, How It Works, and Examples

An AI agent that can only talk to itself isn't much use. To act for real, it has to read your files, query your databases, write into your tools. MCP is the protocol built to standardize that connection, instead of reinventing it for every new tool.

Detailed definition

The protocol's official site defines it this way: MCP is "an open standard for connecting AI applications to external systems," giving them access to data sources (local files, databases), tools (search engines, calculators), and workflows (specialized prompts). Its own documentation sums up the idea with a simple image: MCP is like a USB-C port for AI applications, a standardized connector rather than a different cable for every device.

The protocol was announced by Anthropic on November 25, 2024. The announcement describes the problem MCP set out to solve: AI assistants remained isolated from critical data, with every new source requiring a custom implementation, which created an integration problem that multiplied with every new tool and every new model. Anthropic released the specification, SDKs, and a repository of reference MCP servers for tools like Google Drive, Slack, GitHub, Git, or Postgres at the same time. See Anthropic's announcement.

IBM offers a complementary technical phrasing: MCP is "a standardization layer that allows AI applications to communicate effectively with external services, such as tools, databases, or predefined prompt templates." That description highlights a point often overlooked: MCP doesn't tell an agent when to use a tool, or how to orchestrate several steps. It only standardizes how the tool describes and connects itself. See IBM's MCP page.

How it works

MCP follows a client-server architecture with three roles, described in detail by the official documentation and echoed by Microsoft in its .NET docs. The MCP host is the AI application itself, such as an assistant or a code editor. It creates a dedicated MCP client for each service it connects to. Each client maintains a connection with an MCP server, the program that actually exposes data or actions. An MCP server can run locally on the user's machine, or remotely on the tool provider's servers.

In practice, an MCP server exposes three types of elements: tools (actions the agent can trigger, such as querying a database or sending a message), resources (browsable data, such as a file's contents), and prompts (reusable request templates). The client first queries the server to find out what it offers, then can call a specific tool with specific arguments, a mechanism close to the one described in our tool calling entry.

This is exactly where sources diverge on MCP's exact scope. IBM and Microsoft agree that MCP doesn't replace tool calling: that mechanism remains underneath, the one by which a model actually requests that an action be executed. What MCP adds is a common way to describe and discover these tools, independent of the model provider, where every provider previously imposed its own call format. Likewise, MCP doesn't replace classic APIs: Microsoft's .NET docs note that an MCP server "can provide an abstraction on top of a REST API" to expose business data to a model. MCP is therefore a common facade laid over existing APIs, not a technology that renders them useless.

An MCP server can also expose a document base to query before answering, a use that directly overlaps with the RAG principle: search a reliable source first, then generate the answer from what was found.

A concrete example from Atako

Atako's Standard plan lists "Atako MCP" among its included features, alongside integrations, observability, and BYOK, on the pricing page. An API key generated from account settings is used, among other things, to connect external MCP clients to the platform.

The rest of the precise implementation, which servers, exactly which tools are exposed, isn't publicly documented at this time. It's better to stay factual on this point rather than guess at a tool list or a launch date.

Common mistakes

First mistake: believing MCP is an entirely new mechanism that would replace tool calling. That's not the case, MCP standardizes tool description and discovery, but the call itself remains a classic function call, produced by the model.

Second mistake: assuming an "MCP server" necessarily means some large remote machine. The official documentation clearly distinguishes local servers, which run on the user's computer and communicate locally, from remote servers, hosted by the tool provider and reachable over HTTP.

Third mistake: confusing MCP with a security guarantee in itself. The protocol standardizes how a model discovers and calls a tool, it doesn't decide the permissions granted to that tool on its behalf. On a serious platform, that decision remains a separate layer, independent of whichever connection protocol is used.

Fourth mistake: assuming every tool connected to an agent necessarily goes through MCP. Many agents, including those using integrations like GitHub or Slack, call actions through classic tool calling with no dedicated MCP server involved. Atako doesn't publicly document the details of the tools exposed by its own MCP: MCP remains one connection option among others, not a mandatory path for giving an agent tools.

Going further

MCP established itself fairly quickly as a standard backed by a broad ecosystem: the official documentation lists applications like Claude and code editors like Visual Studio Code and Cursor among compatible MCP clients. To understand the related building blocks of this protocol, head to the full glossary, with the entries tool calling, RAG, and BYOK, all mechanisms for connection or configuration on the model side.