Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP Apps: Extending servers with interactive user interfaces

blog.modelcontextprotocol.io

Post reply on HN
Print view View original

71–80 of 124 posts

Re: MCP Apps: Extending servers with interactive user interfaces

#71

Post by no_circuit »

Yes, it is huge to spread the work out on embedded UIs in chat interfaces. But I think the design direction is going, is exactly the same direction of how Google Assistant, Amazon Alexa, or any of the other assistants work, ifkyk.

The MCP community is just reinventing, but yes, improving, what we've done before in the previous generation: Microsoft Bot Framework, Speaktoit aka Google Dialogflow, Siri App Shortcuts / Spotlight.

And interactive UIs in chats go back at least 20 years, maybe not with an AI agent attached...

The next thing that will be reinvented is the memory/tool combination, aka a world model.

Re: MCP Apps: Extending servers with interactive user interfaces

#72

Post by hobofan »

esafak wrote: post #68
hobofan wrote: post #52

Earlier quoted context omitted.

The article you link (and general movements in that area, like e.g. discussed here[0]) don't advocate for abandoning MCP, just that masquerading MCP usage as code usage makes it more efficient. In that system MCP still provides a valuable role to act as a tool discovery protocol, a role that would have to be filled one way or another unless you are building a system with a set of tools that is known ahead of time. [0…

In that case discovery could be served through `ls` or AGENTS.md, right? So when should you really use MCP?

It sounds like you are viewing MCP servers through a narrow lens of local coding agents.

I'm mostly working with MCP servers in the context of enterprise/organizational usage for connecting internal data sources and workflows/internal APIs through a standardized interface. There is no equivalent of a "ls or AGENTS.md" there, as there is no file system and no shell in those contexts.

Re: MCP Apps: Extending servers with interactive user interfaces

#73

Post by brazukadev »

degamad wrote: post #31
neoden wrote: post #17

Earlier quoted context omitted.

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.

> automatic API discovery and integration So, WSDL?

Yes, WSDL is great for it, now go ahead and convince people. What is your marketing budget?

Re: MCP Apps: Extending servers with interactive user interfaces

#74

Post by esafak »

hobofan wrote: post #72
esafak wrote: post #68

Earlier quoted context omitted.

In that case discovery could be served through `ls` or AGENTS.md, right? So when should you really use MCP?

It sounds like you are viewing MCP servers through a narrow lens of local coding agents. I'm mostly working with MCP servers in the context of enterprise/organizational usage for connecting internal data sources and workflows/internal APIs through a standardized interface. There is no equivalent of a "ls or AGENTS.md" there, as there is no file system and no shell in those contexts.

If there is no file system where do the MCP definitions live and how are the agents aware of them? How are your end users aware of these definitions? There has to be a file somewhere.

Re: MCP Apps: Extending servers with interactive user interfaces

#75

Post by _heimdall »

wild_egg wrote: post #64
_heimdall wrote: post #59

Earlier quoted context omitted.

Correct me if I'm wrong, but I thought OpenAPI was itself an attempt to wedge REST concepts back on top of mostly RPC-based APIs. I.e. add documentation and a standard set of schemas on top of JSON APIs (mostly). I do think the problem is from business concerns, though, and are a clear predictor that MCP will fail. Coming out of the dotcom bubble those left standing wanted to build moats and walls, not APIs that any…

Sadly not. One of the constraints of REST is that the API be completely self-descriptive. If you need out-of-band information like an API spec, then it's basically not RESTful by definition. I'm using a REST API to read your comment and submit my response — I didn't need to reference external HN API docs. The interface here is fully self-describing.

I agree, but don't quite follow how your comment fits in here.

In a REST approach, I'd expect an LLM to need some kind of initial entry point, much like needing the initial URL for the HN home page. From there the LLM should be able to parse and discover possible actions, call those actions, and understand the response only by parsing the results and any schemas provided.

Re: MCP Apps: Extending servers with interactive user interfaces

#76

Post by seunosewa »

WillAdams wrote: post #24

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

You should probably ask the AI to write a script to do the task. Any procedure that needs to be perfect should be done by writing deterministic code.

Re: MCP Apps: Extending servers with interactive user interfaces

#77

Post by kkarpkkarp »

ivape wrote: post #20
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…

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.

> for free like this

for free: not.

but I'm certain the race has just begun: big service providers and online retailers are currently implementing widgets enabling the purchase of their services and goods directly within the ChatGPT or Claude chat windows.

Re: MCP Apps: Extending servers with interactive user interfaces

#79

Post by kkarpkkarp »

mbreese wrote: post #70

I don’t get it. I like MCP as an interface in general, but I don’t understand the use-case they present. For those of you here who like this idea, what is the killer use case? To me, this looks less like UI interactions and more like the MCP equivalent of maintaining state. You start your program and “click” buttons until you get the desired result, maintaining a constant state between interactions. Isn’t that curren…

> For those of you here who like this idea, what is the killer use case?

# 1

- Hey claude, recommend me next book I could read

- sure, what about '1984'? Here is a button to send it directly to your kindle, it will be $4,99.

# 2

- I am looking for the hotel for two in Viena this weekend

- here are some offers and still available (displays grid view generated by mcp ui, handled by booking.com, each item has a button to "book now" directly)

Re: MCP Apps: Extending servers with interactive user interfaces

#80

Post by luigipederzani »

Building MCP Apps (MCP servers with Apps SDK support) is pretty painful right now.

You need to:

1. Spin up a server that returns UI components.

2. Hand-write a bunch of JSON schemas + tool wiring

So we open-sourced a high-level MCP Server SDK that basically lets you have both the MCP server and React components in the same place:

- Every React component you put in your resources/ folder is automatically built and exposed as an MCP resource + tools. No extra registration boilerplate.

- We added a useWidget hook that takes the tool args and maps them directly into your component props, so the agent effectively “knows” what data the widget needs to render. You focus on UI + logic, the SDK handles the plumbing

Docs for that flow here: https://docs.mcp-use.com/typescript/server/creating-apps-sdk...

We also shipped an MCP Inspector to make the dev loop much less painful: you can connect your MCP server, test UI components from tools (with auto-refresh), and debug how it behaves with ChatGPT/agents as you iterate. https://docs.mcp-use.com/inspector/debugging-chatgpt-apps

Both the SDK and the Inspector are open-source, and any contributions are very welcome :)

Those are the repos:

- SDK: https://github.com/mcp-use/mcp-use

- Inspector: https://github.com/mcp-use/mcp-use/tree/main/libraries/types...

Post reply on HN