The OpenAI Responses API now supports Model Context Protocol! You can connect our models to any remote MCP server with just a few lines of code. In order to best support the ecosystem and contribute to this developing standard, OpenAI has also joined the steering committee for MCP.
Image generation is now available as a tool with the Responses API. Stream previews of images as they’re being generated, and enable multi-turn edits to granularly refine images step-by-step.
Code Interpreter now works in the Responses API for data analysis, math, coding, and deep image understanding (“thinking with images”). OpenAI o3 and o4-mini have improved on benchmarks like Humanity’s Last Exam using this tool in their chain-of-thought!
File search is now supported with reasoning models to pull relevant chunks from documents, search across up to two vector stores, and apply attribute filtering with arrays.
We’re also adding three new features to the Responses API:
Amazing updates, OpenAI Team! Can we use the MCP server for stdio or should we run a local SSE server as a remote server to execute our local functions?
When OpenAI introduced the Responses API (March 2025), they clearly stated it represents the future direction for building AI agents, and all upcoming advanced features—such as MCP integration—would exclusively be released via this API. The Chat Completions API continues to be supported, but new capabilities requiring built-in tool integration won’t be added there.
“The Chat Completions API is an industry standard for building AI applications, and we intend to continue supporting this API indefinitely.”
Hardly compatible with what you just wrote, imho?
And there is more:
“The Chat Completions API remains our most widely used API. We’ll continue supporting it with new models and capabilities. If you don’t need built-in tools for your application, you can confidently continue using Chat Completions.”
This is irrelevant. MCP servers are nothing to do with “built-in” tools! They are remote tools and that’s kind of the point!
Completions is the industry standard.
MCP is also becoming an industry standard.
So what would be the logic of supporting one industry standard (“indefinitely”) without support for a corresponding one?
(NB Any move to de facto “proprietarise” the API is not a good move imho and it would concern me even more if you are forced into giving OpenAI more discretion over token expenditure for obvious reasons.)
Fair points. You’re right that MCP involves remote tools, not built-in. My earlier statement was indeed too strong.
What I meant is that OpenAI introduces new integrations first via Responses, and then later, if possible, to Completions. It’s common practice, similar to how new OpenAI features often appear first in Python SDKs before they’re ported to C# and other languages.
There’s no official statement yet on MCP support coming to Completions, but given industry adoption, it’s indeed plausible they might support it later.
They seem pretty set on forcing people over to the Responses API, despite the fact that it’s not backwards compatible and everyone is forced to rework their systems.
Not the first time they’ve done that
Likely not the last either - Hence why there’s so much resistance in switching
Backwards compatibility should be at the fore-front of their minds when they’re making these new systems… sadly it’s not. They just expect everyone to switch their systems up every 12 months I guess. ¯\_(ツ)_/¯
No one is being forced to move to Responses. So I’m not really sure what you mean.
I think the bigger issue is how OpenAI tends to act very impulsively. Examples that come to mind are Assistants (which are not technically deprecated yet, but are basically deprecated anyways,) the “marketing” name of literally anything they’ve ever launched, and gpt-4.5. They also frequently announce things that aren’t even available yet.
There’s a difference between a rapidly evolving technology and just lacking plans and commitment. OpenAI is hurting itself by rushing and then failing to futureproof. We have three completely different APIs to call flagships because all of them have major weaknesses.
MCP is a tool advertising and servicing API that a server can run;
A MCP client retrieves lists of tools, can subscribe to tool specification updates, and can place them into AI context for use as typical tool calls.
OpenAI: MCP as an internal tool provided on the Responses endpoint has OpenAI making the setup connection and placing tools for you, based on your URL and auth and which tools are to be employed. The tool calls are not serviced by you; they are run against the remote internet server by the internal tool call iterator in the same way that web search loops internally until done.
Nothing stops you from adding your own MCP onto Chat Completions or to Responses as a function call. import mcp and then subscribe, cache, use them as functions. It might even be a way for you to abstract functions of your own from chatbots, or an opportunity to serve MCP as an authenticated service.
o1-pro is insanely expensive and carries around o3 levels of performance. There is no reason to be using it unless you hate money.
codex-mini-latest
I can’t get this thing to work in Responses.
But this isn’t all to say there aren’t issues here. As mentioned:
We have three completely different APIs to call flagships because all of them have major weaknesses.
If you use Responses, you’re missing logprobs and stop sequences. If you use Chat Completions, you’re missing o1-pro and tools. If you use Assistants, you have to poll for the output.
What OpenAI should have done is just make one meta API that does everything they need. What they have instead is a massive spaghetti monster.
Thought experiment: vision ability is offered on the return.
How long before the image you paid for gets an AI “I’d better edit out the naughty bits” automatically for another internal edits call, or “I can’t let the user have their image”…
Is the code interpreter functionality going to be supported in Azure anytime soon? right now the container functionality is not implemented (running: container = client.containers.create(name=“test-container”) throws an error).
fo real tho, can yawl like… add a few things to your orchestrator ( MCP ) because like… im trying to do cool stuff for video games in my delusion and the things i want your system to do isnt ready for me to do , please help… i know what im talking about … i can get to 50-100 agents with schema enforcement and auto gen but why cant i force tool interactions like i want, and i REALLLLLLLLLLY dont want to have to build my own sooo like please help
why cant i link the CI to ID to packet dumps through orchestraion via server but i can locally? it makes NO Sense and its vexxing me hardcore - dad!!!
on top of that why cant i use pydantics properly like especially once im using more than 50 ?
or is it my code, because im been realllllllllllllly trying to figure it out 1.66 do i have to add a timeout?
oh ..
i figured it out… you have to put the organization name in the asych banner - Can you enable packet tracking on agents and let me use ace tools for 22 minutes, please. because making my own debugger would take time and i really wanna be friends!!!
New features for the responses API are great, but can you please consider the much-requested configuration of “prev_response_id” to allow for reduced conversation history length? Thanks!
