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?
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?
I personally don’t see why developers should just add tons of functionality to any model for free like this. Some of these MCPs are pretty good, and I was a little shocked how much functionality developers released for free to drop into something like Claude. Either developers are stupid or there really is no market yet.
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.
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.
MCP is incredibly vibe-coded. We know how to make APIs. We know how to make two-way communications. And yet "let's invent new terminology that makes little sense and awkward workarounds on top of unidirectional protocols and call it the best thing since sliced cheese".
What is indeterministic about MCP servers? Most of them follow fairly simple rules, eg an MCP server to interact with Slack gives pretty deterministic responses to requests.
Or are you confusing the LLM / MCP client invoking the tools being non-deterministic?
MCP is already deterministic. What's huge about it is that it has automatic API discovery and integration built-in. It's a bit rough yet but I think we will only see how it's getting improved more and more.
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.
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.
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”
The apps are LLM agnostic, so all MCP apps will be portable. Economically, this means developers don’t have convince users to pay $20 a month, these users are already paying that. Devs just have to convince users to buy the app on the platform.
I don’t see this being the future state. We’d be talking about a world where any and all apps exist inside of fucking ChatGPT and that just sounds ridiculous.
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?
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?
Unless the MCP server itself has an LLM call inside of it (rare), the MCP server is pretty deterministic. It’s the AI that invokes it that’s actually indeterministic, but the user is already using that.
The end state of the ai bullshit hustle is knowledge workers sitting at a desk with a screen and a single button, where they judiciously hammer said button, asking for more AI output
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?
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?
I personally don’t see why developers should just add tons of functionality to any model for free like this. Some of these MCPs are pretty good, and I was a little shocked how much functionality developers released for free to drop into something like Claude. Either developers are stupid or there really is no market yet.
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.
Can we edit the submission title to match what's in the actual article? Not just because I'm annoyed at how transparently Gen Z the HN title is...
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 wonder how long it'll take you to figure out that you're trying to reinvent deterministic APIs.
Or just APIs in general.
MCP is incredibly vibe-coded. We know how to make APIs. We know how to make two-way communications. And yet "let's invent new terminology that makes little sense and awkward workarounds on top of unidirectional protocols and call it the best thing since sliced cheese".
What is indeterministic about MCP servers? Most of them follow fairly simple rules, eg an MCP server to interact with Slack gives pretty deterministic responses to requests.
Or are you confusing the LLM / MCP client invoking the tools being non-deterministic?
MCP is already deterministic. What's huge about it is that it has automatic API discovery and integration built-in. It's a bit rough yet but I think we will only see how it's getting improved more and more.
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.
Ah, yes, please add more security vulnerabilities to all apps, so I can tell a chat bot to tap a button for me!
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.
Original title: MCP Apps: Extending servers with interactive user interfaces
The post title is quite editorialized.
Correct, the title should be changed.
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”
The apps are LLM agnostic, so all MCP apps will be portable. Economically, this means developers don’t have convince users to pay $20 a month, these users are already paying that. Devs just have to convince users to buy the app on the platform.
I don’t see this being the future state. We’d be talking about a world where any and all apps exist inside of fucking ChatGPT and that just sounds ridiculous.
Am I missing something or is this essentially same as GPT Apps that have been introduced a while ago and have been discussed 10000 times.
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?
Looks like OpenAI, Anthropic, and the MCP-UI team actually worked together on a common standard for MCP Apps: https://blog.modelcontextprotocol.io/posts/2025-11-21-mcp-ap...
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?
Who wants a button that has indeterministic actions?
Unless the MCP server itself has an LLM call inside of it (rare), the MCP server is pretty deterministic. It’s the AI that invokes it that’s actually indeterministic, but the user is already using that.
The popularity of slot machines suggests there is a market
Calling it... Vibe clicking
The end state of the ai bullshit hustle is knowledge workers sitting at a desk with a screen and a single button, where they judiciously hammer said button, asking for more AI output