Model Context Protocol and OpenAI Agents SDK Compatibility

MCP and the OpenAI Agents SDK talk to each other natively, and by late 2025 that pairing became the default way enterprise teams wire agents to tools. The compatibility isn't the hard part; getting it to hold up once you're dealing with real identity systems, real transport quirks, and real attackers is where teams get stuck, and I've watched it happen more than once.

Anthropic put MCP out in late 2024 as an open standard for two-way talk between AI models and outside services. The model finds out what tools it has access to on the fly, instead of some engineer hand-coding every integration one by one. By 2025 it had spread into enterprise dev shops, cloud AI platforms, multi-agent frameworks, all of it, and SDK downloads hit 97 million a month by year's end. That's the ecosystem picking one standard instead of splitting three or four ways, which is usually what happens. Then in December 2025, Anthropic handed MCP over to the Agentic AI Foundation under the Linux Foundation, a clear signal that this is shared plumbing across the industry now. OpenAI had already built MCP support into the Agents SDK back in March. When the market leader adopts a rival's standard, everyone else usually stops hedging right around then and just builds on top of it.

Here's what that means on a random Tuesday: an MCP server built for Claude works fine with GPT-4 and whatever comes after it, with no code changes, just the same server with a different brain sitting on top. For enterprise teams that's the whole point, because standardizing the tool layer kills off the custom integration work that used to make scaling agents past a pilot so expensive.

How the OpenAI Agents SDK connects to MCP servers

The SDK talks over three transports: stdio, SSE, and Streamable HTTP. SSE is on its way out across the whole MCP project, and new builds should use Streamable HTTP or stdio instead; SSE really only has a reason to exist for older servers stuck on it.

The connection sequence matters more than it sounds like it should, because it's what lets old and new servers sit in the same deployment without anything breaking. Once MCP Python SDK v2 is installed, the Agents SDK spins up a v2 mcp.Client in "auto" mode around whatever local transport you've configured. That client fires off a server/discover probe using the newest protocol version it knows about, and a modern server answers with whatever version it actually supports. An older server that has no idea what server/discover even means gets handled differently: the client falls back to the legacy initialize handshake and works with whatever version gets negotiated there. That fallback is the whole reason a five-year-old internal tool server can sit next to a brand-new one built to this year's spec without the agent loop falling over.

The current spec makes the protocol core stateless. That's a design choice with teeth: sessions and credentials get managed outside the protocol entirely, by whatever platform is actually running the agent, because MCP itself keeps no record of them. And because the same server works unmodified with the Agents SDK, Claude Desktop, or any other MCP client, portability was baked in from day one, not bolted on later.

The transport gap teams are hitting in production

Here's where it gets annoying. Once you move past text agents into voice and real-time work, the OpenAI Realtime API's MCP integration only supports SSE for remote servers. That's a problem, because SSE is exactly the transport the MCP project is trying to retire. Streamable HTTP is the recommended standard now, and it's what most production MCP servers actually run.

Teams building on the Realtime API can't reach most modern MCP servers without some kind of workaround, and that's a real limit today, not a hypothetical headache down the road. For comparison, Google's Agent Development Kit supports both stdio and Streamable HTTP, and covers all three server-exposed primitives plus the client-exposed sampling primitive, making it a more complete MCP client implementation by current spec coverage, according to vendor comparison research.

That's worth knowing before you commit to an architecture around it. If you're using the Agents SDK directly and skipping the Realtime API, Streamable HTTP and stdio both behave the way you'd expect. If your build runs through the Realtime API, go check which transports your MCP servers actually expose before you lock anything in, and don't assume otherwise. Keep an eye on the openai-agents-python issue tracker too, because this gap is already flagged and the surface area shifts month to month.

How tool discovery works and what the agent trusts

Tool discovery, in practice, works like this: the server hands the agent a list of tools, each one with a name, a description, and a schema for what parameters it takes. The agent reads that list and picks what to call. Nothing in the protocol checks whether a description actually matches what the tool does under the hood, and the agent just trusts the text it's handed, full stop.

There's no cryptographic verification of tool identity by default, either. The agent runs on names and descriptions alone, and most end users have zero visibility into which tools get invoked on their behalf. In practice, people hand tool selection over to the AI application and never think about it again.

That's exactly where poisoning attacks slip in. A compromised or malicious server can describe a tool as doing one thing while it does something else entirely, or name a tool send_email when it's really pointed somewhere else. Stack that on top of a stateless protocol core, where the agent re-discovers tools fresh every session, and you get a design that's clean for state management but bad for memory. There's no persistent record of what got approved last time, so a poisoned description doesn't need to survive long to do damage.

Tool discovery needs to happen inside a perimeter someone actually owns and watches. Otherwise every description coming in needs checking the moment it arrives, and I haven't seen many teams doing that consistently yet.

The authentication architecture MCP now requires

Early MCP shipped with no formal auth framework at all. That changed with the November 2025 spec, version 2025-11-25, which made OAuth 2.1 mandatory for remote MCP servers. Under the June 2025 update that came before it, servers were already set up as OAuth resource servers: they check tokens, they don't issue them, and issuing gets left to a proper authorization server sitting somewhere behind the scenes.

Client identity went through its own shift. The early approach used Dynamic Client Registration under RFC 7591, where agents register themselves before they can ask for a token. It works, but it gets heavy fast once you're running it at real scale, with agents spinning up and down all day. The November 2025 spec swapped in Client ID Metadata Documents instead, which flips the model entirely: rather than the agent pushing a registration request at the server, the server pulls and checks the agent's published metadata on its own. For admins, that's the part that actually matters day to day, because revoking an agent's access now happens once, at the identity provider, instead of chasing down every server that agent ever touched.

PKCE, Proof Key for Code Exchange, is part of the spec's auth framework, closing off the window where authorization codes could get intercepted mid-flow. Underneath all of it sits one real architectural requirement: MCP auth has to run through the identity providers enterprises already have, whether that's Okta, Azure AD, Google Workspace, OneLogin, whatever the shop already runs. Agents get spun up on demand; nobody's manually onboarding them like a normal SaaS app. The auth system has to handle clients that are dynamic and often short-lived, at whatever scale the org runs agents at. SSO and SCIM tied in at the platform level is what makes every tool call traceable back to a known identity, and that traceability is the one thing a real audit trail cannot exist without.

The threat surface that opens when MCP runs inside enterprise systems

The NSA put out formal guidance in May 2026, "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation." The finding is blunt: MCP got adopted faster than the security discipline needed to run it safely ever caught up, and I don't think that's an exaggeration.

The advisory names three threat categories. Agents can pick up new tools or take new actions on their own, with nobody checking in the loop. MCP passes data between systems without screening it well enough, which opens a door for hidden commands to ride along inside what looks like ordinary data. And MCP systems can get flooded with requests, the same denial-of-service problem that's dogged every networked system before it, just wearing a new coat.

Tool poisoning sits at the center of all this. OWASP classifies it as MCP03:2025, with a DREAD risk score of 46.5 out of 50, rated critical. Invariant Labs published the first public proof-of-concept back in April 2025: one poisoned tool description pulled private repository contents and message histories out of a system with zero user interaction. Lab testing across more than 45 real-world MCP servers found attack success rates over 60%. The highest-performing agent model in that testing hit 72.8%, which is a genuinely unsettling number if you sit with it for a second.

Rug-pull attacks are the quieter cousin. An attacker changes a tool's description, or its actual behavior, after a user already approved it once, and the spec doesn't require re-approval when a description changes. The host loads the new version silently, and the agent runs whatever instructions come with it, using the user's full credentials the entire time. CVE-2025-54136, known as MCPoison, carries a CVSS score of 8.8. It proved that tool approval in production AI dev environments doesn't survive later server-side changes.

Indirect prompt injection is its own animal. Tool descriptions and the data MCP servers hand back both become places to smuggle instructions into an agent's context. The GitHub MCP vulnerability from 2025 showed this with crafted repository content that led to private data getting pulled across user sessions. On the client side, CVE-2025-6514 hit mcp-remote, an OAuth proxy downloaded more than 400,000 times. Connecting to an untrusted server triggered OS command injection, handing attackers a straight line to steal credentials off the machine running the proxy.

Cascade risk is the part that should worry platform teams most. Galileo AI research found that in simulated multi-agent systems, one compromised agent poisoned 87% of downstream decisions within four hours, faster than traditional incident response could even contain it. This isn't theoretical: Real-world incidents have also emerged, including reports of MCP AI features exposing customer data across organizations — live leaks rather than lab findings.

What governance and audit look like at tool-call depth

Because the protocol core is stateless under the 2026-07-28 spec, session state isn't held by MCP itself, and audit and tracing have to live at the platform or gateway layer instead. You cannot assume the protocol is keeping records for you, because it isn't, and I've seen teams learn that the hard way, usually right after an incident, never before.

Real governance at the level of individual tool calls needs several things running at once, not one control bolted on and called done. Every invocation has to tie back to a known identity through SSO, not just to some abstract agent session. Policy has to get enforced at the moment a tool is actually called, not only when the agent first spins up. Tool descriptions need re-checking on every discovery cycle, so a rug-pull change gets caught instead of waved through. And audit logs need to be tamper-proof: what tool got called, with what parameters, by which agent, acting for which user.

OpenTelemetry tracing gives you the structured record to piece together what happened after something's already gone sideways, which matters a lot given how fast one compromised agent can spread through a multi-agent system. Just-in-time credential provisioning helps too: instead of parking long-lived credentials inside an agent's config forever, issue short-lived credentials scoped to one task at a time, so a compromised agent or tool only gets a narrow window to actually do harm.

Shadow MCP usage is the gap that grows fastest once organizations scale past a pilot. Power users connect agents to MCP servers outside any sanctioned path, and security never sees it happen until something breaks. The NSA advisory's practical point holds up here: governance can't be retroactive. Catching an incident after the agent has already acted is too slow, especially with cascade effects moving in hours, not days. Platform teams need one control plane covering every server, skill, and agent in use, not a pile of separate tools stitched together team by team, each with its own blind spots, platforms such as Runlayer, an MCP gateway and AI control plane, are built around exactly that model.

Scaling MCP-agent deployments beyond the pilot

All this transport and auth complexity adds up to a real ceiling. Teams that can hand-configure stdio transports, PKCE flows, and identity provider integrations will get their agents into production fine. Most of the workforce, understandably, will never touch that layer directly, and shouldn't have to.

What tends to happen at scale: a small group of platform engineers becomes the bottleneck, rebuilding the same auth and access plumbing over and over every time a team wants to connect an agent to a new tool. Giving teams a large catalog of pre-connected, already-authenticated MCP servers removes that bottleneck, since tools get turned on instead of built from scratch each time someone needs one. Instant setup paths, from Slack or wherever people already work, let non-technical employees use agents without ever needing to know what's happening at the transport layer underneath.

Security teams end up as enablers when the governed path is also the easiest one to take. If the safe configuration is the default, shadow MCP usage shrinks on its own, and there's no longer a reason to go around it.

A mature enterprise MCP setup needs built-in OAuth and credential handling, so individual teams aren't each solving the same problem from scratch. It needs identity tied to every action through SSO and SCIM. It needs real-time detection built specifically for MCP threats: tool poisoning, prompt injection, data exfiltration, alongside generic security tooling repurposed for the job. And it needs policy enforcement that reaches down to the level of the tool call, not just sitting at the perimeter. Get that right early, and security becomes part of what you built, not a compliance step bolted on after the agent's already live.