Honestly, I think the biggest friction for MCP adoption has been how un-userfriendly it is. It’s great for devs, but not the average users. Users don't always want to chat, sometimes they just want to click a button or adjust a slider. This feels like the answer to that problem.
Full disclosure, I'm partial here because of our work at https://usefractal.dev. We were early adopters when MCP first came out, but we always felt like something was missing. We kept wishing for a UI layer on top, and everyone says it's gonna take forever for the industry to adopt, maybe months, maybe years.
I cannot believe the adoption comes so quickly. I think this is gonna be huge. What do you guys think?
You are touching on an important point. Basically OpenAI and others provide a lot of poorly integrated tools and components. You can build nice things with those but you have to deal with a lot of issues and it's a non trivial amount of work that even they aren't doing apparently. Even such a simple thing as triggering an OAuth signin to get access to models is not part of SDKs. Most developer tools require configuring API keys in some file instead. No normal user is ever going to do that,.
Things like ChatGPT are remarkably limited from a UX/UI point of view. The product can do amazing things but the UI is nothing special. The mac version currently has a bug where option+shift+1 opens a chat window but doesn't give it focus. When I do that from vs code it adds the editor window. But it's completely blind to any browser tab on which I do that. I'm sure there are good reasons for all that. But it strikes me a bit as a work in progress that a good product owner would spot.
With apps some of the more powerful capabilities (llms driving UIs directly, doing things in agentic loops, tool and API usage) are going to require much deeper integrations than are currently there. We get hints of what is possible and nice technology demos. But it's still hard to build more complicated workflows around this. Unless you build your own applications.
We've been staring at this from the point of view of automating some highly tedious stuff that we currently do in our company manually. For example, working with chat GPT seems to involve a lot of copy paste and manually doing things that it can't really do by itself. Even something as simple as working on a document it will do alright work on the text but then make a complete mess of the formatting. I spend an hour a few days ago iterating on a document where I was basically just fixing bullets and headers. Most alternatives I've tried aren't any better at this.
None of this seems particularly hard; it's just a lot of integration work that just hasn't happened yet. We have a bunch of lego bricks, not a lot of fully mature solutions. MCP isn't a full solution, it's a pretty lego brick. Mostly even OpenAI and Anthropic aren't getting around to doing much more than simplistic technology demos with their own stuff. IMHO their product teams are a lot less remarkable than their AI teams.
I dont think people realize how important this is.
If one of the vendors manages to get their protocol to become the target platform (eg oai and app sdk), that is essentially their vendor lock in to become the next iOS/Android.
Private API’s or EEE strategies are gonna be something to keep an eye for and i wish regulators would step in to prevent them before its too late.
While they're at it, they might as well check if their answers end with a yes/no question, and, if so, offer a "yes" button so that i can answer yes with a single click.
> If you want a focused comparison next - for example, benchmarks on coding/math, token-cost examples for a typical session, or API usage differences - I can produce a compact table with sources and numbers.
--> can be answered with yes, so please add a yes button. A no button is not needed.
Disclosure: I work at Anthropic, have worked on MCP
I also think this is pretty big. I think a problem we collectively have right now is that getting MCP closer to real user flows is pretty hard and requires a lot of handholding. Ideally, most users of MCP wouldn't even know that MCP is a thing - the same way your average user of the web has no idea about DNS/HTTP/WebSockets. They just know that the browser helps them look at puppy pictures, connect with friends, or get some work done.
I think this is a meaningful step in the direction of getting more people who'll never know or care about MCP to get value out of MCP.
I'm not sure I get why we need something specific like MCP-UI? why wouldn't "just another tool" do exactly the same?
Eg you present a "display-graph-chart" tool as a MCP tool, and the agent calls it, it doesn't need to adhere to any protocol except the basic existing MCP protocol, and the UI that's used to interact with the agent would know the best presentation (show it as an embedded HTML graph if in a web ui, show it as a ascii chart if in a terminal, etc)?
Is the idea just to standardize the "output format" of the tool so that any agent UI could display stuff in the same way? so that one tool could work with any agent display?
It'll be interesting to see how this goes, but my first impression is that it's actually not where we want to go. One of the cool things about MCP (or even just tool calling) is that the LLM on top of a tool provides a highly flexible and dynamic interface to traditionally static tools.
I love being able to type "make an iptables rule that opens 443" instead of having to dig out the man page and remember how to do that. IMO the next natural extension of this is giving the LLM more capability to generate user interfaces so I can interact with stuff exactly bespoke to my task.
This on the other hand seems the other way round, it's like bolting a static interface onto the LLM, which could defeat the purpose of the LLM interface layer in the first place right?
> giving the LLM more capability to generate user interfaces
This is not dissimilar to the argument that "MCP needs not exist, just tell llm to run commands and curl". Well, llm can do those, and generate user interfaces. It's just they don't work reliably (maybe ever, depending on how you define "reliable").
I guess as engineers we can do some work and create stopgap solutions or we can all sit and wait for someone else (who? when?) to make AGIs in which everything just magically works, reliably.
An, the dream, a cross platform App Store you can install apps into any client application that supports MCP, but is open, free and agentic.
It’s basically a “web App Store” and we side step the existing app stores (and their content guidelines, security restrictions and billing requirements) because it’s all done via a mega app (the MCP client).
How could it go wrong?
If only someone had done this before, we wouldnt be stuck in Apples, etc’s walled gardens…
Seriously though; honest question: this is literally circumventing platform requirements to use the platform app stores. How do you imagine this is going to be allowed?
Is ChatGPT really big enough they can pull the “we’re gonna do it, watcha gonna do?” to Apple?
Who’s going to curate this app store so non technical users (the explicitly stated audience) can discover these MCP apps?
It feels like MCP itself; half baked. Overly ambitious. “We’ll figure the details out later”
I skimmed over this, but did I see a reference sandbox implementation? And then basically the chat UI interacts with that with postMessage (and receiving) and forwards tool calls to the MCP server. Does it also forward tool calls the MCP server doesn't handle to the host backend?
What I am imagining is something like a meta UI tool call that just creates a menu. The whole MCP server's purpose might be to add this menu creation capability to the chat user interface. But what you are selecting from isn't known ahead of time, it's the input to the UI.
When they select something I assume it would output a tool call like menuItemSelected('option B'). I suppose if you want your server to do anything specific with this then you would have to handle that in the particular server. But I guess you could also just have a tool call that just sends the inputs to the agent. This could make for what is a very slow to respond but extremely flexible overall UX.
I guess this is not the intended use, but suppose you give your agent generic MCP UI tools for showing any menu, showing any data table, showing a form, etc. So the inputSchemas would be somehow (if this is possible) quite loosely defined.
I guess the purpose is probably more about not having to go through the LLM rather than giving it the ability to dynamically put up UI elements that it has to react to individual interactions with.
But maybe one of the inputs to the dataTable are the query parameters for its data, and the table has a refresh button. Maybe another input is the URI for the details form MCP UI that slides over when you click a row.
Maybe there is an MCP UI for Layout what allows you to embed other MCP UIs in a specific structure.
This might not make sense, but I am wondering if I can use MCP Apps as an alternative to always building custom MindRoot plugins (my Python/web components agentic app framework) to provide unique web pages and UI for each client's agentic application.
I think I may have gotten the MCP Apps and MCP UI a bit conflated here so I probably need to read it again.
How reliable are the processes which these things run?
I'm processing thousands of files using Copilot, and even 20 at a time, it usually skips a couple, and sometimes, when skipping, it merges the data from one file to the next, not applying anything to the second file, other times it completely applies the data parsed from one file to the second --- not a big deal since I'm reviewing each operation manually, but the only reason the error rate is acceptable is the files are so inconsistent that normal techniques weren't working.
Is there an equivalent to "double-keying" where two different LLMs process the same input and it only moves forward if both match perfectly?
IMO this is not where we want to go. The future is you have a system agent that interact with all your apps via API, and websites are real-time so you can see what your agent is doing as you do it it. We don't need more rigging for this future, just better API support.
Trying to create custom agent APIs to embed apps in chat is a very "monopolist frontier lab" thing to try and do.
We already have AG-UI [0], which has been implemented by frameworks like Microsoft agent framework, pydantic AI and llamaindex. I guess they'll just have to duplicate functionality.
I am a pretty big proponent of MCP, and I think this at least for now is not a move in a good direction.
The whole surface of the MCP specification is already pretty big, and barely any server implements anything beyond the core parts.
With elicitation there was already a lightweight version of this in place in the standard, and I'm not sure I've ever encountered a server or client implementation of it in the wild, and elicitation is an order of magnitude simpler to integrate on a conceptional level.
I fear that this has a significant risk of splintering the MCP ecosystem further (it's already pretty strained due to the transport protocol iterations), and there isn't really a reason to create a official extension (yet), that may worst case also require multiple iterations to get things right.
My fear is that even for consumer apps, MCP (or successor) will outgrow UIs, becoming the only way to interact with an app or certain feature - placing machines wholly in the center instead of humans. Human software should retain the understandability and atomicity of each step taken.
In my current personal development workflow with Claude Code, I've switched entirely to using CLI tools and scripts over MCP as the experience is much more deterministic and flexible.
A great example is Github, it's a significantly better dev experience having CC call out to the gh cli for actions than trying to invoke the MCP.
If only we as an industry hadn't abandoned REST APIs none of this would be necessary.
We've known for decades that its useful for APIs to be self documented and for responses to use schemas to define the shape of the data.
XML can be verbose and I understand why people preferred JSON for ease use. Had we stuck with REST for the last 20 years we'd be way ahead on that front, though, both in syntax and tooling.
The agent discovers tools by exploring the filesystem: listing the ./servers/ directory to find available servers (like google-drive and salesforce), then reading the specific tool files it needs (like getDocument.ts and updateRecord.ts) to understand each tool's interface. This lets the agent load only the definitions it needs for the current task. This reduces the token usage from 150,000 tokens to 2,000 tokens—a time and cost saving of 98.7%.
Given LLMs can generate code complex frontend code, why is so difficult for Antropic / OpenAI to prompt their chat applications to create UI on the fly that matches 100% their Chat applications?
I know this is possible because this is how we do it.
The LLM generates some text that we know how to interpret and we render it on the screen.
Besides, this is exactly how their canvas thing works (both chtgpt and claude) when rendering documents on the side.
Meta note: I really detest authors using cryptobro terminology “A dropped” and “B is huge” for anything technical. It immediately smells of script kiddies or their latest reincarnation.
38 comments
[ 3.2 ms ] story [ 47.8 ms ] threadHonestly, I think the biggest friction for MCP adoption has been how un-userfriendly it is. It’s great for devs, but not the average users. Users don't always want to chat, sometimes they just want to click a button or adjust a slider. This feels like the answer to that problem.
Full disclosure, I'm partial here because of our work at https://usefractal.dev. We were early adopters when MCP first came out, but we always felt like something was missing. We kept wishing for a UI layer on top, and everyone says it's gonna take forever for the industry to adopt, maybe months, maybe years.
I cannot believe the adoption comes so quickly. I think this is gonna be huge. What do you guys think?
Things like ChatGPT are remarkably limited from a UX/UI point of view. The product can do amazing things but the UI is nothing special. The mac version currently has a bug where option+shift+1 opens a chat window but doesn't give it focus. When I do that from vs code it adds the editor window. But it's completely blind to any browser tab on which I do that. I'm sure there are good reasons for all that. But it strikes me a bit as a work in progress that a good product owner would spot.
With apps some of the more powerful capabilities (llms driving UIs directly, doing things in agentic loops, tool and API usage) are going to require much deeper integrations than are currently there. We get hints of what is possible and nice technology demos. But it's still hard to build more complicated workflows around this. Unless you build your own applications.
We've been staring at this from the point of view of automating some highly tedious stuff that we currently do in our company manually. For example, working with chat GPT seems to involve a lot of copy paste and manually doing things that it can't really do by itself. Even something as simple as working on a document it will do alright work on the text but then make a complete mess of the formatting. I spend an hour a few days ago iterating on a document where I was basically just fixing bullets and headers. Most alternatives I've tried aren't any better at this.
None of this seems particularly hard; it's just a lot of integration work that just hasn't happened yet. We have a bunch of lego bricks, not a lot of fully mature solutions. MCP isn't a full solution, it's a pretty lego brick. Mostly even OpenAI and Anthropic aren't getting around to doing much more than simplistic technology demos with their own stuff. IMHO their product teams are a lot less remarkable than their AI teams.
If one of the vendors manages to get their protocol to become the target platform (eg oai and app sdk), that is essentially their vendor lock in to become the next iOS/Android.
Private API’s or EEE strategies are gonna be something to keep an eye for and i wish regulators would step in to prevent them before its too late.
> If you want a focused comparison next - for example, benchmarks on coding/math, token-cost examples for a typical session, or API usage differences - I can produce a compact table with sources and numbers.
--> can be answered with yes, so please add a yes button. A no button is not needed.
The post title is quite editorialized.
I also think this is pretty big. I think a problem we collectively have right now is that getting MCP closer to real user flows is pretty hard and requires a lot of handholding. Ideally, most users of MCP wouldn't even know that MCP is a thing - the same way your average user of the web has no idea about DNS/HTTP/WebSockets. They just know that the browser helps them look at puppy pictures, connect with friends, or get some work done.
I think this is a meaningful step in the direction of getting more people who'll never know or care about MCP to get value out of MCP.
Eg you present a "display-graph-chart" tool as a MCP tool, and the agent calls it, it doesn't need to adhere to any protocol except the basic existing MCP protocol, and the UI that's used to interact with the agent would know the best presentation (show it as an embedded HTML graph if in a web ui, show it as a ascii chart if in a terminal, etc)?
Is the idea just to standardize the "output format" of the tool so that any agent UI could display stuff in the same way? so that one tool could work with any agent display?
I love being able to type "make an iptables rule that opens 443" instead of having to dig out the man page and remember how to do that. IMO the next natural extension of this is giving the LLM more capability to generate user interfaces so I can interact with stuff exactly bespoke to my task.
This on the other hand seems the other way round, it's like bolting a static interface onto the LLM, which could defeat the purpose of the LLM interface layer in the first place right?
This is not dissimilar to the argument that "MCP needs not exist, just tell llm to run commands and curl". Well, llm can do those, and generate user interfaces. It's just they don't work reliably (maybe ever, depending on how you define "reliable").
I guess as engineers we can do some work and create stopgap solutions or we can all sit and wait for someone else (who? when?) to make AGIs in which everything just magically works, reliably.
It’s basically a “web App Store” and we side step the existing app stores (and their content guidelines, security restrictions and billing requirements) because it’s all done via a mega app (the MCP client).
How could it go wrong?
If only someone had done this before, we wouldnt be stuck in Apples, etc’s walled gardens…
Seriously though; honest question: this is literally circumventing platform requirements to use the platform app stores. How do you imagine this is going to be allowed?
Is ChatGPT really big enough they can pull the “we’re gonna do it, watcha gonna do?” to Apple?
Who’s going to curate this app store so non technical users (the explicitly stated audience) can discover these MCP apps?
It feels like MCP itself; half baked. Overly ambitious. “We’ll figure the details out later”
What I am imagining is something like a meta UI tool call that just creates a menu. The whole MCP server's purpose might be to add this menu creation capability to the chat user interface. But what you are selecting from isn't known ahead of time, it's the input to the UI.
When they select something I assume it would output a tool call like menuItemSelected('option B'). I suppose if you want your server to do anything specific with this then you would have to handle that in the particular server. But I guess you could also just have a tool call that just sends the inputs to the agent. This could make for what is a very slow to respond but extremely flexible overall UX.
I guess this is not the intended use, but suppose you give your agent generic MCP UI tools for showing any menu, showing any data table, showing a form, etc. So the inputSchemas would be somehow (if this is possible) quite loosely defined.
I guess the purpose is probably more about not having to go through the LLM rather than giving it the ability to dynamically put up UI elements that it has to react to individual interactions with.
But maybe one of the inputs to the dataTable are the query parameters for its data, and the table has a refresh button. Maybe another input is the URI for the details form MCP UI that slides over when you click a row.
Maybe there is an MCP UI for Layout what allows you to embed other MCP UIs in a specific structure.
This might not make sense, but I am wondering if I can use MCP Apps as an alternative to always building custom MindRoot plugins (my Python/web components agentic app framework) to provide unique web pages and UI for each client's agentic application.
I think I may have gotten the MCP Apps and MCP UI a bit conflated here so I probably need to read it again.
I'm processing thousands of files using Copilot, and even 20 at a time, it usually skips a couple, and sometimes, when skipping, it merges the data from one file to the next, not applying anything to the second file, other times it completely applies the data parsed from one file to the second --- not a big deal since I'm reviewing each operation manually, but the only reason the error rate is acceptable is the files are so inconsistent that normal techniques weren't working.
Is there an equivalent to "double-keying" where two different LLMs process the same input and it only moves forward if both match perfectly?
Trying to create custom agent APIs to embed apps in chat is a very "monopolist frontier lab" thing to try and do.
Sigh.
[0] https://docs.ag-ui.com/introduction
AG-UI is built to support agentic behavior in your application, more similar to the Vercel AI SDK but horizontal and standardized.
MCP-UI helps external apps and APIs pass UI to applications, really well suited for use cases like Shopify stores inside of ChatGPT.
The whole surface of the MCP specification is already pretty big, and barely any server implements anything beyond the core parts.
With elicitation there was already a lightweight version of this in place in the standard, and I'm not sure I've ever encountered a server or client implementation of it in the wild, and elicitation is an order of magnitude simpler to integrate on a conceptional level.
I fear that this has a significant risk of splintering the MCP ecosystem further (it's already pretty strained due to the transport protocol iterations), and there isn't really a reason to create a official extension (yet), that may worst case also require multiple iterations to get things right.
A great example is Github, it's a significantly better dev experience having CC call out to the gh cli for actions than trying to invoke the MCP.
We've known for decades that its useful for APIs to be self documented and for responses to use schemas to define the shape of the data.
XML can be verbose and I understand why people preferred JSON for ease use. Had we stuck with REST for the last 20 years we'd be way ahead on that front, though, both in syntax and tooling.
https://www.anthropic.com/engineering/code-execution-with-mc...
The agent discovers tools by exploring the filesystem: listing the ./servers/ directory to find available servers (like google-drive and salesforce), then reading the specific tool files it needs (like getDocument.ts and updateRecord.ts) to understand each tool's interface. This lets the agent load only the definitions it needs for the current task. This reduces the token usage from 150,000 tokens to 2,000 tokens—a time and cost saving of 98.7%.
0. https://marketplace.openship.org
2015 WeChat mini program
...
2025 MCP-UI
I'm tired.
Given LLMs can generate code complex frontend code, why is so difficult for Antropic / OpenAI to prompt their chat applications to create UI on the fly that matches 100% their Chat applications?
I know this is possible because this is how we do it.
The LLM generates some text that we know how to interpret and we render it on the screen.
Besides, this is exactly how their canvas thing works (both chtgpt and claude) when rendering documents on the side.