MCP Apps: Extending servers with interactive user interfaces • Hacker News Board

Re: MCP Apps: Extending servers with interactive user interfaces

#121

Post by nsonha » Mon, Nov 24, 2025, 9:51 AM UTC

mindwok wrote: post #18

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 th…

> 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.

Re: MCP Apps: Extending servers with interactive user interfaces

#122

Post by debugnik » Mon, Nov 24, 2025, 4:34 PM UTC

tyfon wrote: post #92

woleium wrote: post #87

Earlier quoted context omitted.

many banks have api access now, but maybe only for business accounts?

In Europe we have the PSD2 open banking [1] directive which essentially gives developers a standard api access to banking operations on behalf of a user. It is a requirement for banks to implement this and the FSA will be on your neck if you are not compliant with the standard. [1] https://finance.ec.europa.eu/regulation-and-supervision/fina...

To access that API you need a license as an authorised third-party provider (TPP), don't you? So in practice it is only for businesses capable of pushing through the bureaucracy.

Re: MCP Apps: Extending servers with interactive user interfaces

#123

Post by swiftlyTyped » Tue, Nov 25, 2025, 12:24 AM UTC

meander_water wrote: post #30

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. Sigh. [0] https://docs.ag-ui.com/introduction

AG-UI is compatible with both MCP-UI and other declarative UI specs.

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.

Re: MCP Apps: Extending servers with interactive user interfaces

#124

Post by prescriptivist » Tue, Nov 25, 2025, 3:44 AM UTC

felipeerias wrote: post #117

prescriptivist wrote: post #113

Earlier quoted context omitted.

MCPs as a thin layer over existing APIs has lost utility. Custom MCPs for teams that reduces redundant thinking/token consumption and provides more useful context for the agent and decreases mean time to decision making is where MCPs shine. Something as simple as correlating a git SHA to a CI build takes 10s of seconds and some number of tokens if Claude is utilizing skills (making API calls to the CI server and GitH…

In your example, you could achieve a similar outcome with a skill that included a custom command-line tool and a brief description of how to use it. MCPs are specially well suited for cases that need a permanent instance running alongside the coding agent, for example to handle authentication or some long-lived service that is too cumbersome to launch every time the tool is called.

I mention mean-time to decision making and that's one of the rationales for the mcp. A skill could call a script that does the same thing -- but at that point aren't we just splitting hairs? We are both talking about automated repetitive thinking + actions that the agent takes? And if the skill requires authentication, you have to encode passing that auth into the prompt. MCP servers can just read tokens from the filesystem at call time and don't require thinking at all.