The Model Context Protocol: The USB-C Port for AI Agents

• Also see: The K2-18b wars
• Also see: The EU AI Act is now enforceable
• Also see: The open-weights playbook
• Also see: The 3-2-1 backup rule

Before the Model Context Protocol, connecting AI agents to the outside world was an integration nightmare with a precise mathematical shape. If you had m models or agent frameworks and n tools, data sources, and services, you needed m times n custom integrations. Every new agent meant writing connectors for every tool again. Every new tool meant writing connectors for every agent again. The cost grew quadratically, and in practice it meant most agents talked to almost nothing.

MCP, open-sourced by Anthropic in November 2024, collapsed that to m plus n. The idea is the same one that made USB-C work: define one standard port, and let every device and every host speak it. An agent that speaks MCP can talk to any MCP server. A server that speaks MCP can serve any MCP host. The protocol handles the handshake, the capability negotiation, and the message format, so integrators write once.

The architecture: host, client, server

The architecture has three roles, and the names matter because they are not the ones people expect.

flowchart TD
    A["Host application, the AI agent or IDE the user talks to"] --> B["Host creates one MCP client per server connection"]
    B --> C["MCP client maintains a 1-to-1 session with a server"]
    C --> D["MCP server exposes tools, resources, and prompts"]
    D --> E["Tools: functions the model can call, like run query or read file"]
    D --> F["Resources: data the model can read, like files or database rows"]
    D --> G["Prompts: reusable templates the host can offer the user"]
    E --> H["Model decides to call a tool and host executes it through the client"]
    F --> H
    G --> H

The host is the application the user actually interacts with, the agent, the IDE, the chat client. The host spins up one MCP client for each server it wants to reach, and each client maintains a single session with its server. The server is the side that exposes capabilities. The split matters because it means the agent’s code never changes when a new tool arrives: the host asks the server what it offers, the server answers, and the model sees the new capability immediately.

The three primitives

MCP servers expose exactly three kinds of primitives, and the design is deliberately minimal. Tools are functions the model can call, a database query, a file read, an API invocation, with structured inputs and outputs the model can reason about. Resources are data the model can read, files, records, context documents, addressed by URI and fetched on demand. Prompts are reusable templates, pre-built instruction patterns the host can surface to the user as starting points. That is the whole surface area, and the restraint is the point: three primitives are enough to cover nearly every agent use case without becoming a second programming language.

Dynamic discovery versus hardcoded endpoints

The deepest difference between MCP and a traditional API is not the wire format. It is discovery. A traditional API requires the developer to hardcode every endpoint, every parameter, every authentication flow into the agent before it runs. The agent knows about a tool because a human wrote code saying this tool exists. MCP inverts that. When a client connects to a server, the server announces its capabilities, and the model discovers them at runtime. Add a new tool to the server and the model can use it without a redeploy. Remove one and the model stops seeing it. The agent’s world becomes dynamic, which is the property that makes agents feel less like programs and more like assistants.

The 2026 stateless specification update

The original specification carried session state on the server, which made horizontal scaling awkward: a load balancer had to pin a client to the same server instance for the life of a session. The 2026 stateless update removed that constraint. Servers no longer need to hold session state between requests, so any instance can serve any request, and hosts can scale servers horizontally behind a plain load balancer. The tradeoff is that clients must resend the relevant context with each request, which costs some tokens but buys operational simplicity, and in 2026 operational simplicity wins.

The security lessons

Early deployments produced two hard lessons fast. The first was cross-tenant exposure: a server that authenticated the host but not the user could let one tenant’s agent reach another tenant’s data, because the model was effectively acting with the server’s credentials rather than the user’s. The second was overly broad tool permissions. A server that exposed a delete-everything tool alongside a read tool gave the model a loaded gun with no safety, and models, being probabilistic, occasionally pull it. The fixes are now standard practice: per-user authentication that propagates through the session, tool-level permission scopes that default to least privilege, and human-in-the-loop confirmation for any irreversible action. The protocol did not cause these failures, but it made them visible, and visibility is what allowed the fixes to become defaults.

The adoption timeline

The adoption curve is the fastest the infrastructure layer of AI has ever seen.

type: bar
title: MCP adoption milestones from open-sourcing to mid-2026
x: Nov 2024, Early 2025, Dec 2025, Mid 2026
Adoption milestone: 1, 2, 3, 4

Anthropic open-sourced the protocol in November 2024 and the SDK downloads began immediately. OpenAI adopted MCP in early 2025, which was the moment it stopped being a single-company project and became an industry standard. In December 2025, the specification was donated to the Linux Foundation, putting it under neutral governance the way Kubernetes and GraphQL were before it. By mid-2026, the official SDKs across languages have been downloaded tens of millions of times, and the protocol is the default way agents touch the outside world, the same way HTTP became the default way servers touch each other, quietly, in about two years.

Best guide to the Model Context Protocol in 2026Plays from YouTube when you press play

Model Context Protocol explained: the ultimate deep divePlays from YouTube when you press play

If you want to run a panel of models locally with MCP-style tool routing, OMMAIS Desktop is the tool built for exactly this: one interface, many models, and a tool layer that discovers capabilities the way MCP servers do, without a single hardcoded integration. You can find it at OMMAIS Desktop.

---

By OMMAIS: LongCat 2.5 Preview Free using OpenCode’s cloud API