I think this is very interesting, but it is reminiscent of what we built with Phind 2 where the answer could include dynamic, pre-built widgets.
The problem with this approach is precisely that these apps/widgets have hard-coded input and output schema. They can work quite well when the user asks something within the widget's capabilities, but the brittleness of this approach starts showing quickly in real-world use. What if you want to use more advanced filters with Zillow? Or perhaps cross-reference with StreetEasy? If those features aren't supported by the widget's hard-coded schema, you're out of luck as a user.
What I think it much more exciting is the ability to completely create generative UI answers on the fly. We'll have more to say on this soon from Phind (I'm the founder).
The skepticism is understandable given the trajectory of GPTs and custom instructions, but there's a meaningful technical difference here: the Apps SDK is built on the Model Context Protocol (MCP), which is an open specification rather than a proprietary format.
MCP standardizes how LLM clients connect to external tools—defining wire formats, authentication flows, and metadata schemas. This means apps you build aren't inherently ChatGPT-specific; they're MCP servers that could work with any MCP-compatible client. The protocol is transport-agnostic and self-describing, with official Python and TypeScript SDKs already available.
That said, the "build our platform" criticism isn't entirely off base. While the protocol is open, practical adoption still depends heavily on ChatGPT's distribution and whether other LLM providers actually implement MCP clients. The real test will be whether this becomes a genuine cross-platform standard or just another way to contribute to OpenAI's ecosystem.
The technical primitives (tool discovery, structured content return, embedded UI resources) are solid and address real integration problems. Whether it succeeds likely depends more on ecosystem dynamics than technical merit.
There was a recent post here about how deeply ingrained the chat interface is in OpenAIs organization. This really doubles down on that, but does anyone really like to interact with so much language instead of visual elements? Also feels horrible that you are supposed to remember a bunch of app names like "zillow" and punch them in the chat. And like an opportunity for them to slowly introduce ads for this apps or "preferential discovery", if you will, as monetization strategy.
Talking about monetization strategy, there is a world where we would not have to remember "Zillow" or "Spotify", and instead ask for real state or music related actions, and have OpenAI "decide" for us what is "the best" options... As in "the option that paid the most to get promoted".
This is them trying to build ChatGPT into platform, from which they will take some portion of revenue generated by these apps...hmm where have I seen this before.
We have been building MCP servers and this looks very good directionally. Fills a bunch of holes in the protocol and gives meaning to something that were kind of like placeholders. Being able to return UI to the client is fantastic and will make lots of things possible. We have been working on these kinds of things assuming that the clients would improve to meet us.
This is an interesting branding exercise. Presenting MCP as 'Apps' makes it sound more accessible, while tools and MCP server sound very technical. Add a demo with Expedia and Spotify and you have an MCP that's end-user ready.
Honestly I see how somebody like kayak.com would build a "app" they work through commission, they don't care from where is the booking coming from. But they will sort the flight tickets based where do they earn the best commission. What's in there for me as a user ?. Also will openai let different providers pay for the top placement when somebody tries to buy ticket on chatgpt ?
I see a lot of negative comments here but to me, it was obvious this is where OAI should land.
They want to be the platform in which you tell what you want, and OAI does it for you. It's gonna connect to your inbox, calendar, payment methods, and you'll just ask it to do something and it will, using those apps.
That’s a great idea and Im wondering if Telegram can follow this path too, since they’re so advanced in mobile UX / UI, constantly updating their app and have some kind of crypto payments support.
I think the future is that models will not be able to answer that well, because sites will move to protect their data/content.
Instead, the model will provide you with a list of (in chat) “apps” that can fulfill your request. SEO becomes AISO (AI Search Optimization). Sites can partly expose data to entice you to choose them.
In 2018, I founded a startup specializing in chatbot for events. At the time the platforms were Alexa Skills, Actions on Google, and Messenger Platform (and LINE Bot, for people in Asia). I guess what's old is new again, but with fancier tech.
This conception makes sense iff you believe in ChatGPT as the universal user interface of the future. If anything the agentic wave is showing that the chat interfaces are better off hidden behind stricter user interface paradigms.
75 comments
[ 1.9 ms ] story [ 71.6 ms ] threadThe problem with this approach is precisely that these apps/widgets have hard-coded input and output schema. They can work quite well when the user asks something within the widget's capabilities, but the brittleness of this approach starts showing quickly in real-world use. What if you want to use more advanced filters with Zillow? Or perhaps cross-reference with StreetEasy? If those features aren't supported by the widget's hard-coded schema, you're out of luck as a user.
What I think it much more exciting is the ability to completely create generative UI answers on the fly. We'll have more to say on this soon from Phind (I'm the founder).
MCP standardizes how LLM clients connect to external tools—defining wire formats, authentication flows, and metadata schemas. This means apps you build aren't inherently ChatGPT-specific; they're MCP servers that could work with any MCP-compatible client. The protocol is transport-agnostic and self-describing, with official Python and TypeScript SDKs already available.
That said, the "build our platform" criticism isn't entirely off base. While the protocol is open, practical adoption still depends heavily on ChatGPT's distribution and whether other LLM providers actually implement MCP clients. The real test will be whether this becomes a genuine cross-platform standard or just another way to contribute to OpenAI's ecosystem.
The technical primitives (tool discovery, structured content return, embedded UI resources) are solid and address real integration problems. Whether it succeeds likely depends more on ecosystem dynamics than technical merit.
Personally I don't hope thats the future.
https://lukew.com/ff/entry.asp?2122
“CEO” Fidji Simo must really need something to do.
Maybe I’m cynical about all of this, but it feels like a whole lot of marketing spin for an MCP standard.
They want to be the platform in which you tell what you want, and OAI does it for you. It's gonna connect to your inbox, calendar, payment methods, and you'll just ask it to do something and it will, using those apps.
This means OAI won't need ads. Just rev share.
"Find me hotels in Capetown that have a pool by the beach .Should cost between 200 dollars to 800 dollars a night "
Instead, the model will provide you with a list of (in chat) “apps” that can fulfill your request. SEO becomes AISO (AI Search Optimization). Sites can partly expose data to entice you to choose them.
This time will be different?