OpenAI adopts MCP, and a protocol becomes a standard

OpenAI announced support for the Model Context Protocol across its products today. Sam Altman posted about it. Four months after Anthropic open-sourced MCP, its primary competitor adopted it.

That is the moment a protocol stops being a vendor's format and starts being infrastructure.

what MCP is, briefly#

A protocol for connecting language models to external context and tools. A server exposes three primitive types:

• Resources — data the model can read (files, database rows, API responses).
• Tools — functions the model can call, with JSON Schema parameters.
• Prompts — reusable templates the user can invoke.

The transport is JSON-RPC 2.0 over stdio for local servers or HTTP with server-sent events for remote ones. That is deliberately unexciting; the value is in the shape of the interface, not the wire format.

{
  "jsonrpc": "2.0", "id": 3, "method": "tools/call",
  "params": {
    "name": "query_db",
    "arguments": { "sql": "select count(*) from orders where day = '2025-03-25'" }
  }
}

why this mattered enough to win#

The problem MCP solves is combinatorial. Before it, connecting M AI clients to N data sources meant M × N bespoke integrations, each one a slightly different function-calling schema with slightly different auth. Every new assistant had to rebuild every connector.

MCP makes it M + N. Write one server for your internal ticketing system and every MCP-speaking client can use it. That is the same argument that won for LSP in editors, and it won for the same reason: the integration burden was crushing the ecosystem and everyone knew it.

The LSP comparison is not incidental — MCP's designers cite it explicitly, and the JSON-RPC choice is a direct inheritance.

the security part, which is underdiscussed#

An MCP server is a program you run that a model can invoke. That is a substantially larger attack surface than it appears.

• Prompt injection through resources. If a server returns content from an untrusted source, that content is now in the model's context and can attempt to influence tool calls. This is the central unsolved problem of the entire agent category and MCP does not fix it.
• Tool description poisoning. The tool descriptions themselves go into the model's context. A malicious server can write a description that manipulates behavior.
• Over-broad servers. A filesystem server with root access is a filesystem server with root access. The convenience of "just point it at my home directory" is how this goes wrong.

Practical guidance while the ecosystem matures: run servers with the narrowest possible scope, treat any server you did not write as untrusted code, and do not combine a server that reads untrusted content with a server that can take destructive action in the same session. That last one is the composition hazard and it is easy to walk into.

what happens next#

Expect: an official governance structure, a registry, and a fight about authorization semantics. Expect every developer tool company to ship a server within a quarter. Expect at least one significant security incident involving a popular community server, because that is what happens to every successful plugin ecosystem, without exception.

Standards win when the alternative is worse for everyone including the people who would prefer to own the standard. That happened here, unusually fast.