What is MCP (Model Context Protocol)?

MCP stands for Model Context Protocol, a standard Anthropic published as open source on November 25, 2024. It solves a very specific problem: before MCP, connecting a language model to an external data source (a database, a calendar, a booking system) required writing a separate integration for every combination of model and system. MCP replaces those custom integrations with a common protocol: any AI application that speaks MCP can connect to any server that also speaks it, without specific code for each pair.

The comparison MCP's own documentation uses is the USB-C port: just as that connector standardized how one electronic device plugs into another, MCP standardizes how any AI application connects to any external system, regardless of who built either side.

MCP shouldn't be confused with an AI crawler or an AI agent. A crawler like GPTBot roams web pages passively to gather training or indexing content. An AI agent carries out a specific task in real time, at a user's request. MCP is different from both: it's the structured technical interface through which a model accesses external data and tools, regardless of whether an agent is executing a task or a crawler is reading content behind it.

MCP follows a client-server architecture. An AI application, called an MCP host (for example Claude Desktop or a code editor), creates one MCP client for each server it connects to. Each client maintains a dedicated connection to its corresponding server, and a single host can have several clients active at once, one for each external system it currently works with, much like a browser keeps a separate connection open for every tab.

The protocol is organized into two layers. The data layer defines the message structure using JSON-RPC 2.0, the same format many other remote exchange protocols use, and includes three core primitives a server can offer: tools, which are executable functions such as querying a database; resources, which are context data such as a file's contents; and prompts, which are reusable templates for structuring an interaction. The transport layer defines how those messages travel: through standard input and output when the server runs locally, or over HTTP with server-sent events when it runs remotely.

A client discovers what a server offers through a list-type request, such as tools/list, and only afterward executes a specific tool through a call-type request, tools/call. The server can also notify the client when what it offers changes, through notifications, so the client doesn't have to keep asking whether something has changed in the meantime, which saves a noticeable number of requests when tool lists change often.

On December 9, 2025, Anthropic transferred MCP's governance to the Agentic AI Foundation, a directed fund within the Linux Foundation founded together with Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. The project's maintainers continue to prioritize community input and transparent decision-making, according to Anthropic's own announcement.

The decision that hinges on this is how a company with structured data (a product catalog, a booking system, a CRM) plans for an AI model to access it. Without a common protocol, every integration with every model is a separate project that has to be maintained on its own whenever either side changes. With MCP, exposing that data as an MCP server makes it accessible to any compatible AI application, without repeating the integration work for each one.

The scale of the shift is already measurable: according to Anthropic's own December 2025 announcement, there are more than 10,000 active public MCP servers and more than 97 million monthly SDK downloads across Python and TypeScript. With governance now outside Anthropic and inside a neutral foundation, MCP is shaping up to be a shared infrastructure layer rather than a single vendor's tool, which meaningfully reduces the risk of betting on a standard that depends solely on one company's business decisions and could shift along with its priorities.

For a business with its own data (bookings, inventory, real-time prices), the relevant question is no longer just whether an AI model can read its public content, but whether it can act on its systems through an MCP server: checking availability, starting a booking, updating a record. That's the line between being a cited source of information and being a system an AI assistant can operate directly and actively, rather than just read passively.

• Before building your own MCP server, check the official repository of reference servers: the system you want to connect may already have one maintained by the community.
• Expose only the tools a model genuinely needs, not your entire internal API: every additional tool is one more action a model could invoke unexpectedly.
• Use HTTP transport with OAuth authentication for remote servers, not fixed credentials hard-coded into the source.
• Document every tool with a clear description of when to use it and when not to, because the model decides whether to invoke it based on that description.
• Review the call logs for your MCP server the same way you'd review a public API's logs: it's a new access surface.
• Keep up with the protocol version changes published by the Agentic AI Foundation, which has governed MCP since December 2025.

• Treating an MCP server as an internal API with no access control, when it's actually exposed to any model that connects.
• Confusing MCP with an AI agent: MCP is the connection interface, not the program that decides which task to run.
• Building an MCP server from scratch for a system that already has a community-maintained reference server.
• Exposing dozens of generic tools instead of a few well-described ones, which raises the odds the model invokes the wrong one.