MCP stopped being an experiment and became infrastructure: what changes for people who write software

From one vendor's protocol to an industry standard

The Model Context Protocol was introduced by Anthropic in November 2024 as a standardized way to connect AI models to tools and data sources. Its trajectory since then explains why it stopped being a topic for people playing with agents and became an architecture topic:

• In December 2025, Anthropic donated the protocol to the Agentic AI Foundation, under the Linux Foundation — making it a vendor-neutral, community-governed standard rather than one company's format.
• It was adopted by OpenAI, Google DeepMind, and Microsoft, alongside thousands of development teams.
• The ecosystem passed 110 million monthly downloads.
• On more conservative numbers, Stacklok's 2026 report puts 41% of surveyed organizations running MCP servers in production, in limited or broad use.

The 2026 roadmap confirms the direction: stateless transport, server discovery, long-running tasks, enterprise authentication, triggers, streaming, and SDK v2. None of that is experiment vocabulary — it is production integration-layer vocabulary.

What this means in practice for your system

The useful reading is this: your product is going to have two kinds of client — people and agents. And the two things an agent needs from your API are exactly the two things most internal APIs lack.

Descriptions that make sense out of context. An internal API can have an endpoint called POST /v2/proc because everyone on the team knows what it is. An agent does not. A good MCP tool has a name and description that explain when to use it, not just what it does.

Granularity designed for decisions, not for reuse. REST APIs tend to be deliberately generic. Agent tools work better when they are specific: find_order_by_customer beats a query tool with a free-form DSL by a wide margin. Less power, far less room for error.

Errors that teach. A 400 Bad Request with no body is useless to an agent. A message naming the missing field and the expected format lets the agent correct itself on the next attempt.

The security part you cannot defer

Exposing an MCP server means exposing execution surface. Security agencies published guidance on this in 2026, and the practical points are direct:

• Authentication and authorization belong to the server, not the agent. The agent is an untrusted client. If the tool can read any customer's data, it will read any customer's data.
• Destructive operations need explicit confirmation or should simply not be exposed. Delete, transfer, issue, cancel — if it is in the tool list, someone will call it.
• Any text coming back from a tool is untrusted input. Content from a ticket, an email, or a web page may contain instructions aimed at the model. Treating tool output as data rather than command is the same principle we already apply against SQL injection.
• Tool-call logs are audit logs. Who called, with which arguments, on whose behalf. Without that there is no incident investigation.

Where to start without making it the quarter's project

You do not need an "MCP strategy." The cheap path is picking one useful, specific read from your system — order status, a customer's history, items below minimum stock — and exposing only that, read-only, with real authentication.

That slice costs little, creates no meaningful new risk, and answers the question that actually matters: what changes in daily operations when the system's data is one question away? The answer to that should guide what comes next — not the protocol's feature list.