What Is the Model Context Protocol (MCP), and Why Does Everyone Mention It?

Imagine it is Tuesday at the Lagos fabric shop from the first post. The owner likes the order-checking agent from the last post, and now wants it to read the courier company’s tracking system, the shop’s accounts and the shared stock spreadsheet. Each of those is a different piece of software. Does someone have to write a new connection for every one, and again for every AI application the shop might try? That is the problem the Model Context Protocol was made to ease.

(This is an illustrative scene, not a real business.)

What is the Model Context Protocol?

The Model Context Protocol (MCP) is a shared set of rules for connecting an AI application to outside systems. A protocol is an agreed way for two programs to talk to each other. MCP’s own introduction, as of October 2026, calls it “an open-source standard for connecting AI applications to external systems”. It adds: “Think of MCP like a USB-C port for AI applications.”

The comparison is useful. A USB-C port lets one charger, screen or drive work with many devices, because the plug and the rules are the same. In our reading, MCP aims to do the same for tools and data: build the connection once, and many AI applications can use it.

Why was MCP created?

Every connection used to be custom work. Anthropic’s announcement of 25 November 2024 put the problem this way: “Every new data source requires its own custom implementation, making truly connected systems difficult to scale.” MCP, it said, was “a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol”.

The previous post showed that a tool is described to the model by a name, a description and an input schema, and that the developer’s code usually runs it. According to the announcement, each new data source needed its own custom implementation. In our reading, that meant each AI application also needed its own glue code to use a tool. The announcement named David Soria Parra and Justin Spahr-Summers as MCP’s creators at Anthropic.

How does MCP work?

MCP uses three roles. The architecture page, as of October 2026, defines them:

• The host is the AI application, such as Claude Code or Claude Desktop. It coordinates the clients.
• A client is a component the host creates to keep one connection open. The host creates “one MCP client for each MCP server”.
• A server is a program that offers tools or data. It can run on your own computer or on someone else’s.

An MCP server here is not a special kind of computer. It is any program that follows the MCP rules and offers things the AI application can use.

Illustrative example. The shop’s chat assistant is the host. It opens one client for a made-up courier server and another for a made-up stock-sheet server. The courier’s developers wrote their server once. If the shop later switches to a different AI application that supports MCP, the same courier server can be connected there too.

Behind the scenes, the messages use JSON-RPC 2.0, a standard format for one program to ask another to run a named operation and send back a reply. The docs describe two ways to carry the messages. The stdio transport (short for standard input and output) is for programs on the same machine. The Streamable HTTP transport is for remote servers over the web. A transport is the channel the messages travel through.

What can an MCP server offer?

As of October 2026, MCP’s documentation says a server can offer three kinds of thing, which it calls primitives:

• Tools: “Executable functions that AI applications can invoke to perform actions”, such as a database query or an API call.
• Resources: “Data sources that provide contextual information to AI applications”, such as file contents or database records.
• Prompts: “Reusable templates that help structure interactions with language models”.

A client can ask a server what it has. The docs show the tools/list request for discovering tools and the tools/call request for running one. Because the list is requested rather than hard-coded, a server can change what it offers without every application being rewritten.

Illustrative example. The courier’s server might offer a tool called track_parcel, a resource holding the depot opening hours, and a prompt template for writing a delay notice. Those names are made up.

How is this different from the function calling in the last post?

They work at different levels. Function calling is how the model asks for a tool. MCP is how the application finds and reaches tools in the first place. In our reading, an application connects to an MCP server, lists its tools, and then passes their descriptions to the model exactly as it would with tools you wrote yourself. The model asks for a tool in its usual structured way, and the application sends that request on to the right server.

So MCP does not replace the tool round trip from the fifth post. It changes where the tools come from.

Who runs MCP today?

As of October 2026, MCP is hosted by a foundation rather than by Anthropic alone. On 9 December 2025 Anthropic announced it was donating MCP to the Agentic AI Foundation (AAIF), “a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI”. The Linux Foundation is a non-profit that hosts open-source projects. The announcement said the project’s governance model “will remain unchanged: the project’s maintainers will continue to prioritize community input and transparent decision-making.” The foundation’s own projects page, as of 13 October 2026, lists the Model Context Protocol among the projects it hosts.

The protocol is also versioned by date. As of October 2026, the project’s versioning page says “The current protocol version is 2026-07-28.” Earlier versions are dated too, such as 2025-11-25. If you read a tutorial, check its version, because the details of MCP have changed over time.

Do OpenAI and Anthropic support MCP?

Yes, with differences. As of October 2026, OpenAI’s documentation says its models can use remote MCP servers as tools. Anthropic offers an MCP connector in its API, behind a beta header, which is a setting you add to a request to switch on a feature that is still being tested. As of October 2026, Anthropic’s page says that, of the MCP specification’s features, “only tool calls are currently supported”, and that local stdio servers cannot be connected directly through the connector. So a feature you read about in the MCP documentation may not be available in every product. Check the vendor’s page for the one you use.

What are the risks of using MCP?

Connecting a server means trusting it. As of October 2026, OpenAI’s documentation describes several risks. Three worth knowing:

• Hidden instructions. OpenAI’s documentation warns that “Malicious MCP servers may include hidden instructions (prompt injections) designed to make OpenAI models behave unexpectedly.” A prompt injection is text placed where a model will read it, written to make the model do something its owner did not intend. This post covers what MCP’s own documentation and OpenAI say; we have not tested any server.
• Changing behaviour. OpenAI also notes: “MCP servers may update tool behavior unexpectedly”.
• Data leaving your control. Servers may request data you would rather not share. OpenAI’s MCP tool in its Responses API “defaults to requiring approvals of each MCP tool call being made”, and it recommends logging what is sent.

As of October 2026, MCP’s documentation says tools are “model-controlled, meaning AI models can discover and invoke them automatically”, and suggests that applications add approval dialogs for individual tool runs, permission settings for pre-approved safe operations, and activity logs. That matches the advice from earlier in this series: keep a person approving risky actions. In our reading, a sensible rule for the shop is to connect only servers from sources it knows, read-only first, and to approve anything that sends a message or changes a record.

What to remember

• MCP is an open standard that lets an AI application connect to tools and data the same way each time. Build the connection once, and many applications can use it.
• A host (the AI application) opens a client for each server. A server offers tools, resources and prompts.
• Connecting a server means trusting it. Use trusted servers, check the version and the vendor’s support, and keep a person approving risky actions.

If the shop wanted to add a language model to its own software, our LLM integration guide covers API patterns. To revisit earlier posts, see How Do AI Agents Use Tools and Call Functions? and How Does an AI Agent Actually Work, Step by Step?.

Next in the series: how AI agents remember things, and what a context window is.