OpenAI Adopts MCP: A De Facto Standard Crosses Vendor Lines
On March 26, 2025, OpenAI announced support for Anthropic's Model Context Protocol across its products, starting with the Agents SDK. We examine what the protocol standardizes, what it deliberately leaves open, why cross-vendor convergence changes integration strategy, and what the simultaneous specification revision means for remote MCP servers.
The N Times M Integration Problem
Every AI assistant that acts on external systems needs connectors: to ticketing systems, databases, source control, internal APIs. Before a shared protocol existed, each model vendor defined its own tool-calling interface, and each interface required its own adapters. The cost was quadratic: N clients times M systems meant N times M custom integrations, each with its own schema, error handling, and maintenance burden. Integration effort, not model quality, became the bottleneck for agentic systems.
Anthropic open-sourced the Model Context Protocol (MCP) on November 25, 2024 to collapse this cost to N plus M. A system exposes one MCP server; a client implements the protocol once and can talk to every server. Block, Apollo, Zed, Replit, Codeium, and Sourcegraph adopted early. One structural weakness remained: the largest model vendor did not support the protocol of its closest competitor.
What OpenAI Announced on March 26
On March 26, 2025, OpenAI CEO Sam Altman announced MCP support across OpenAI products: "People love MCP and we are excited to add support across our products." Support shipped the same day in the open-source Agents SDK. Support for the ChatGPT desktop app and the Responses API was announced as coming soon, without a date. OpenAI said it will share more details in the coming months.
The scope is precise. An agent built on the Agents SDK can consume any existing MCP server today, local or remote, without modification. ChatGPT itself cannot yet. Governance of the protocol remains with the open-source project that Anthropic maintains. OpenAI committed to a standard it does not control. That is the notable part: the decision trades control for ecosystem access, and it signals that the protocol layer is no longer a competitive surface.
What MCP Standardizes
MCP is a client-server protocol over JSON-RPC 2.0. A server exposes three primitives: tools, which are functions the model may invoke; resources, which are data the client may read; and prompts, which are reusable templates. Client and server negotiate capabilities at initialization. Transports are pluggable: stdio for local child processes, HTTP-based transports for remote servers. The protocol is bidirectional: servers can also request completions from the client through sampling, though few clients implement it today.
Equally important is what MCP does not standardize. It says nothing about model behavior, tool quality, orchestration, memory, or agent-to-agent communication. It is a wiring standard. The closest analogy is the Language Server Protocol: one server implementation per data source, instead of one implementation per client, with the protocol deliberately thin in between.
Convergence Changes the Build Calculus
A protocol becomes a standard when its author's largest competitor adopts it. The Language Server Protocol crossed that line when editors beyond Visual Studio Code implemented it; MCP crossed it this week. The sequence since November shows how quickly convergence happened, and how dense the final week was:
For integration strategy the consequence is concrete. One MCP server wrapped around an internal system now serves Claude, agents built on OpenAI's SDK, Copilot Studio, and MCP-capable development tools from a single codebase. The tool layer becomes vendor-neutral. Model lock-in does not disappear — prompts, evaluations, and cost profiles remain vendor-specific — but connector code stops being a switching cost. We now default to MCP servers for new integrations and keep direct API calls for latency-critical paths.
| Date | Event |
|---|---|
| Nov 25 2024 | Anthropic open-sources MCP with SDKs and reference servers |
| Mar 19 2025 | Microsoft announces MCP support in Copilot Studio |
| Mar 25 2025 | Cloudflare enables deployment of remote MCP servers |
| Mar 26 2025 | MCP spec revision 2025-03-26: Streamable HTTP and OAuth 2.1 |
| Mar 26 2025 | OpenAI ships MCP support in the Agents SDK |
What MCP Does Not Solve
Convergence on transport does not resolve the hard problems. Tool descriptions and tool results are untrusted input to the model. Prompt injection through a malicious or compromised server remains an open problem, and no protocol can fix it. The specification is explicit that MCP "cannot enforce these security principles at the protocol level" and delegates consent flows, authorization, and access control to implementors.
There is also no central registry; server discovery is manual. There is no standard for versioning tool semantics, no service-level mechanism, no billing model — and until March 26 there was no authorization framework at all. Anyone treating an MCP server as a production API must add authentication, auditing, rate limiting, and monitoring. The protocol supplies none of it.
Remote Servers on the Horizon
Most MCP servers today run locally over stdio, launched by a desktop client. That model does not scale beyond developer machines. The specification revision published on March 26 targets exactly this limitation: Streamable HTTP replaces the previous HTTP-plus-SSE transport, allowing stateless plain-HTTP servers with an optional upgrade to server-sent events, and a new OAuth 2.1-based authorization framework defines how remote clients obtain delegated access.
Infrastructure moved first. On March 25, Cloudflare shipped support for deploying remote MCP servers on its Workers platform, including an OAuth provider library and mcp-remote, an adapter that connects local-only clients to remote servers. Remote MCP changes the operating model: a server stops being a process on a developer machine and becomes a hosted, authenticated, multi-tenant service with uptime obligations.
Outlook From Late March 2025
Our expectations, stated on the day of the announcement so they can be checked later. The remaining large model vendors will adopt MCP within months; a protocol backed by the two leading providers is unlikely to be displaced. Server registries and discovery mechanisms will emerge, fragmented at first. A managed hosting category for remote MCP servers will form around the new transport. Security tooling will lag adoption, and the first prominent MCP-related incident will accelerate it.
The strategic conclusion is not speculative. Wrap internal systems as MCP servers now, keep business logic out of the protocol layer, and treat client support as a commodity that vendors provide. Convergence rewards organizations that own well-defined servers, not organizations that own connectors. The connector era of AI integration ended this week; the server era has a specification, an authorization model, and — since March 26 — every major client.
Sources
- Anthropic: Introducing the Model Context Protocol (Nov 25 2024)
- TechCrunch: OpenAI adopts rival Anthropic's standard for connecting AI models to data (Mar 26 2025)
- Model Context Protocol Specification 2025-03-26: Key Changes (Mar 26 2025)
- Cloudflare: Build and deploy Remote Model Context Protocol servers (Mar 25 2025)
- OpenAI Agents SDK: Model Context Protocol documentation (Mar 26 2025)