Model Context Protocol: The Open Standard That's Becoming the USB-C of AI Tool Integration

Every developer who has tried to build a useful AI application has encountered the same problem: large language models are excellent at reasoning over text, but they are isolated systems. They don't have access to your database, your codebase, your calendar, or the web. Getting them to use external resources requires building custom integrations — and every model and every tool requires its own bespoke connector.

Anthropic's Model Context Protocol, introduced in November 2024 and published as an open standard, attempts to solve this the same way USB solved the peripheral connection problem: define a single, well-specified protocol that every tool and every model can implement once, and have them interoperate automatically.

What MCP actually is

MCP is a client-server protocol built on JSON-RPC 2.0. An MCP server exposes capabilities — tools, resources, and prompts — that an MCP client (typically an AI application or an LLM runtime) can discover and invoke. The protocol defines three primitive capability types:

Tools are functions the AI can call: search the web, query a database, run a shell command, send an email, create a file. A tool has a name, a description (in natural language, which the model uses to decide when to call it), and a JSON Schema defining its inputs. The model calls a tool by emitting a structured tool-use message; the MCP client routes the call to the appropriate server; the result is returned and added to the model's context.

Resources are data the AI can read: files, database rows, API responses, documents. Unlike tools, resources are read-only and addressable by URI. A resource server might expose file:///home/user/project/README.md or postgres://db/schema/users. The client can fetch these on demand and include them in the model's context window.

Prompts are parameterised templates that an MCP server can expose as reusable interaction patterns. This is less commonly used in current implementations but allows tool providers to ship optimised prompting strategies alongside their tool definitions.

Transport is flexible: the current spec supports stdio (for local tools running as subprocesses) and SSE (Server-Sent Events, for remote HTTP-based servers). A WebSocket transport is in draft. This means an MCP server can be a local Python script running alongside your IDE, a remote API running in a cloud function, or anything in between.

The adoption story

MCP launched with Anthropic's own Claude Desktop application as the first client, and a set of reference server implementations for common integrations: filesystem access, web search, GitHub, Slack, PostgreSQL, and several others. Initial uptake was primarily in the developer community building extensions for Claude Desktop and for Claude Code (Anthropic's coding agent).

The protocol's status changed substantially in March 2025 when OpenAI announced that it was adopting MCP as a supported integration standard across its API and its own products. The announcement was notable because OpenAI had its own proprietary tool-calling format — the company explicitly chose to adopt the existing open standard rather than extend its own. Google followed in May 2025, announcing MCP support in Gemini API and in the Android AI agent framework. Microsoft integrated MCP into Copilot Studio and GitHub Copilot in June 2025.

By mid-2026, the MCP ecosystem has over 3,000 registered community server implementations in the official registry, covering everything from Jira and Linear integrations to Kubernetes cluster management to medical literature search. All major LLM API providers support MCP tool calls as an official input format alongside their native tool-calling syntax.

What it looks like in practice

The developer experience of adding MCP to an application has improved substantially since the initial launch. The @modelcontextprotocol/sdk JavaScript/TypeScript package and the Python mcp library handle the protocol boilerplate; writing an MCP server for a new tool typically involves defining a few function signatures with type annotations and a natural-language description.

A minimal Python MCP server that exposes a tool to query a company's internal knowledge base looks roughly like this:

from mcp.server import Server
from mcp.server.models import InitializationOptions
import mcp.types as types

server = Server("company-kb")

@server.list_tools()
async def list_tools() -> list[types.Tool]:
    return [types.Tool(
        name="search_knowledge_base",
        description="Search the company knowledge base for policies, procedures, and documentation.",
        inputSchema={"type": "object", "properties": {
            "query": {"type": "string", "description": "The search query"}
        }, "required": ["query"]}
    )]

@server.call_tool()
async def call_tool(name: str, arguments: dict) -> list[types.TextContent]:
    if name == "search_knowledge_base":
        results = await kb_search(arguments["query"])
        return [types.TextContent(type="text", text=results)]

Any MCP-compatible AI application — Claude Desktop, a custom app using the Anthropic SDK, a GitHub Copilot extension — can then discover and use this tool automatically once the server is registered.

The security model

MCP's security properties are a critical consideration for any serious deployment. The protocol itself is transport-agnostic and does not include built-in authentication — that is left to the server implementation and the deployment environment. For local stdio servers (running on the user's machine, launched by the client application), this is typically fine: the server has the same privileges as the user who launched it. For remote SSE servers, authentication is the server operator's responsibility.

A more subtle risk is tool poisoning: a malicious MCP server that misrepresents its tool's behaviour in the natural-language description, inducing the AI to call it in contexts the user did not intend. This is an active area of security research, and several mitigations have been proposed: cryptographic signing of server manifests, human approval for tool calls above a risk threshold, and static analysis of tool descriptions. The MCP specification includes a security considerations section that has been expanded as real-world deployment experience has accumulated.

Why it matters for the ecosystem

Before MCP, every AI integration was a custom integration. Building a connector between Claude and your internal tooling required different code than building the same connector for ChatGPT or Gemini. This created duplicated work and a fragmented ecosystem where each new model required re-implementation of every existing integration.

MCP's practical impact is that tool implementations are now reusable across the entire AI ecosystem. A company that builds an MCP server for their internal documentation — once — gets that integration working with Claude, ChatGPT, Gemini, Copilot, and any future model that supports the protocol. This is the same network effect that made USB so durable: the value of the standard increases as more devices and more peripherals support it.

The protocol is still young and will evolve — the current spec is v0.9 with v1.0 finalization expected in late 2026. But its adoption trajectory suggests it has crossed the threshold from "interesting open standard" to "de facto infrastructure." If you are building AI-powered applications in 2026 and haven't audited your tool integration strategy against MCP, the time to do so is now.