Current status as of June 30, 2026: OpenAI's Apps SDK is built on Anthropic's Model Context Protocol (MCP), the two largest U.S. AI labs now share a wire format for how AI clients connect to external tools and resources. Per the OpenAI Apps SDK documentation and the Apps SDK MCP server concepts guide, OpenAI now advises developers to use the MCP Apps standard keys and bridge for new ChatGPT Apps. The practical implication: a tool or resource that works with one MCP-compliant client works with the others.
Quick facts
What happened
The single most consequential infrastructure shift of 2026 — quieter than a model launch, larger than any individual benchmark — is that OpenAI's Apps SDK is built on Anthropic's Model Context Protocol (MCP). The two largest U.S. AI labs now share a wire format for how AI clients connect to external tools and resources.
Per the OpenAI Apps SDK documentation and the Apps SDK MCP server concepts guide, OpenAI now advises developers to use the MCP Apps standard keys and bridge for new ChatGPT Apps, reserving ChatGPT extensions only for behaviors not covered by the shared specification. The practical implication: a tool or resource that works with one MCP-compliant client works with the others.
For an enterprise team building agentic apps, this is the moment the integration layer stops being a per-vendor engineering project and becomes a standard protocol stack.
All standards references below are cross-checked against Anthropic's MCP specification, OpenAI's Apps SDK guides, and the Context Studios MCP ecosystem analysis.
What MCP actually standardizes
MCP, originally introduced by Anthropic in late 2024, is an open specification for how large language model clients connect to external tools and resources. The 2026 version of the spec standardizes four things:
1. Tool invocation. MCP defines the wire format for an LLM client to discover a tool, send a structured request to the tool, receive a structured result, and surface the result back into the model context. The tool definitions use JSON Schema for input/output contracts, and the protocol is transport-agnostic — it works over stdio, HTTP, and Server-Sent Events.
2. Resource exposure. MCP defines how an LLM client can list and read structured resources from an MCP server. A resource is anything the model can reference — files, database rows, API responses, structured documents. The protocol specifies the resource URI scheme, the metadata format, and the read semantics.
3. Authentication. MCP includes a standard authentication layer. Tools and resources can be gated by OAuth 2.0, API keys, or custom token schemes, with the protocol specifying how credentials are negotiated and refreshed. For enterprise IT teams, this is the part that matters most: MCP makes the auth story portable across vendors.
4. UI metadata for tools. MCP defines a standard metadata envelope (`_meta.ui.resourceUri`) for linking a tool to a UI resource. This is the part that makes the OpenAI Apps SDK possible — the wire format lets an MCP server return not just a tool result but a UI widget that renders inline in the chat surface.
What MCP does *not* standardize:
- Orchestration. MCP does not define how an agent plans, sequences, or retries tool calls. Each client (ChatGPT, Claude, Cursor) implements its own orchestration layer.
- Governance. MCP does not define who can invoke which tool, or how usage is audited, or how rate limits are negotiated across organizations. These are policy decisions, not protocol decisions.
- State management. MCP is stateless per request. Long-running agent loops are the client's responsibility, not the protocol's.
For an enterprise team, the protocol-vs-policy split is the critical one. MCP gives you the wire format. Governance, audit logging, and rate limits are still your problem.
What the OpenAI Apps SDK adds on top
The OpenAI Apps SDK is a developer framework for building ChatGPT-native apps — applications that operate directly inside ChatGPT conversations, with both the logic and the interface defined in the SDK. It is the consumer-facing surface for what MCP defines on the protocol layer.
The Apps SDK is in preview as of June 2026 and ships these capabilities:
- Apps in ChatGPT. A developer can define an app whose tool calls and UI components both surface inside the ChatGPT conversation. The app gets a discoverable surface area in the ChatGPT app directory.
- MCP server integration. Apps are MCP servers. They list tools (with JSON Schema contracts), accept tool calls from ChatGPT based on user intent, and return components that render inline.
- UI widget rendering. Apps can return structured UI widgets (cards, forms, tables, interactive components) that render inline in the chat surface. The widgets are synchronized with the conversation, so users interact with live data without leaving the chat.
- Tool result envelope. The Apps SDK preserves the canonical MCP tool result envelope in `toolResponseMetadata`, which means tools can return structured results that downstream tools in the same agent loop can consume without re-parsing.
- Server instructions during initialization. MCP servers can return server-level instructions that initialize the model with the server's capabilities, conventions, and usage hints.
- Output schema examples. Improved `outputSchema` examples for structured content, which makes tool discovery and validation more reliable.
The most consequential change for an enterprise team is the `_meta.ui.resourceUri` standard. This is the field that links an MCP tool to a UI resource. Before the Apps SDK, UI was per-vendor (ChatGPT had its own widget format, Claude had its own, etc.). With `_meta.ui.resourceUri`, the UI binding is part of the MCP wire format. An app built against the Apps SDK can carry its UI binding into any other MCP-compliant client.
The cross-vendor convergence, in one chart
The 2026 agentic-app ecosystem now has three large U.S. AI labs and a handful of major platforms sharing a wire format:
Per the Context Studios MCP ecosystem analysis, the protocol saw significant updates in February and March 2026, with releases including TypeScript SDK v1.27.1, Python SDK v1.26, and OpenAI's Agents SDK v0.12.x with MCP integration. The pace of standardization is faster than any individual model release.
For an enterprise IT team building agentic apps, the practical implication is that a tool or resource built once against the MCP spec runs on ChatGPT, Claude, Gemini, Copilot, and Cursor without per-vendor engineering. The integration layer has converged.
What this changes for the engineering team
Three operational shifts for the team building agentic apps in 2026:
1. The integration layer is now commodity. In 2024, building an agentic app meant per-vendor integration: a custom plugin format for ChatGPT, a custom tools API for Claude, a custom extensions API for Gemini. In 2026, an MCP server is the integration layer for all of them. The cost of going from "works in Claude" to "works in ChatGPT, Claude, Gemini, and Copilot" is now measured in days, not months.
2. The orchestration layer is the new moat. If the wire format is shared, the orchestration logic — how an agent plans, sequences tool calls, recovers from failures, retries, and produces structured output — is where vendor differentiation lives. ChatGPT's Apps SDK and Claude's tool-use APIs handle orchestration differently, and that difference is what you pay for.
3. Governance and audit are still your problem. MCP does not standardize who can invoke which tool, how usage is logged, or how rate limits are enforced across organizations. An enterprise team deploying MCP-based apps in production still needs its own governance layer — audit logging, RBAC, tool allowlists, rate limits, and observability. These are not protocol features. They are product features you build on top of the protocol.
What this changes for the user
For the user of an MCP-compliant app, the practical implication is that the same tool surface appears consistently across vendors. A calendar tool built against MCP shows up in ChatGPT, Claude, and Gemini with the same tool calls and the same UI components.
For an enterprise IT team rolling out AI assistants to staff, this is operationally meaningful:
- Tool consolidation. A team can standardize on a small set of MCP-compliant tools (calendar, CRM, ticket system, internal docs) and have them work across ChatGPT, Claude, and Gemini without per-vendor integration.
- Audit consistency. Logs from MCP tool invocations follow the same wire format regardless of client. A single audit pipeline can ingest MCP logs from ChatGPT, Claude, and Gemini without per-vendor log parsing.
- Vendor portability. Switching a team's default AI assistant from ChatGPT to Claude (or vice versa) no longer requires re-integrating every tool. The tool layer is portable.
What changed since the last update
Compared to the 2024–2025 agent-tool landscape:
- Wire format. MCP is now shared between OpenAI and Anthropic — the two largest vendors.
- UI binding. The `_meta.ui.resourceUri` standard turns UI binding into part of the protocol, not a per-vendor format.
- SDK convergence. OpenAI's Agents SDK v0.12.x added MCP integration; Cursor and Microsoft added native MCP support.
What it means
For enterprise engineering teams, MCP is the wire format that makes the AI agent layer look like the web in 1996 — standardized, portable, rapidly converging. The interesting work in 2026 is no longer the wire format; it is the governance, audit, and operational layer that sits on top of it. For enterprise teams, that is the right place to spend engineering time.
FAQ
Is OpenAI's Apps SDK the same as MCP? Not exactly. The Apps SDK is OpenAI's developer framework for ChatGPT-native apps. It is *built on* MCP — every ChatGPT App is an MCP server. The Apps SDK adds ChatGPT-specific UI rendering, app directory surface, and ChatGPT-aware tool formatting on top of the MCP wire format.
Can an MCP server built for Claude work in ChatGPT? Yes. Per the OpenAI Apps SDK documentation, any MCP-compliant tool or resource can be surfaced in ChatGPT via the Apps SDK. The UI metadata standard (`_meta.ui.resourceUri`) lets MCP servers carry their UI bindings across MCP-compliant clients.
Does Google support MCP? Yes. Per the MCP ecosystem analysis, Google supports MCP-compatible client APIs in Gemini. The integration is not as deep as Anthropic or OpenAI's, but the wire format works.
What does MCP NOT do? MCP does not standardize orchestration (planning, sequencing, retries), governance (who can invoke which tool, audit logging, rate limits), or state management (long-running agent loops). These remain per-vendor or per-deployment decisions.
Should I build a new agentic app on MCP? For most enterprise use cases, yes. The cost of going from "works in Claude" to "works in ChatGPT, Claude, Gemini, and Copilot" via MCP is days rather than months. The investment in MCP now compounds as more vendors adopt.
Sources checked
- OpenAI Apps SDK — Build with the Apps SDK — official OpenAI developer documentation
- OpenAI — Apps SDK MCP server concepts — MCP server implementation guide
- Anthropic — Model Context Protocol specification — canonical MCP spec
- Microsoft — Unleashing the power of Model Context Protocol — Microsoft's MCP integration pattern via Agents SDK
- Context Studios — MCP ecosystem in 2026, what the v1.27 release actually tells us — independent ecosystem analysis
- Tollbit — How the OpenAI Apps SDK works — Apps SDK mechanics, including tool discovery and UI rendering
- Sunpeak — ChatGPT Apps, what I wish I knew — practitioner notes from production deployments
- Skywork — OpenAI Apps SDK + ChatGPT integration — integration patterns for non-MCP-native tools
For a Different Kind of Audience
If your agentic workload runs in the cloud and the tool layer can be standardized on MCP, the wire format is no longer the bottleneck. If your workload is "a sensitive conversation that cannot leave the device, with a tool layer that also runs locally," a different deployment is required. See the luxury phones with on-device AI assistants guide for hardware designed for more local, private workflows.
