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

61–70 of 124 posts

Re: MCP Apps: Extending servers with interactive user interfaces

#61

Post by andybak »

_heimdall wrote: post #42

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.

We never really implemented REST APIs. We had a bunch of REST-ish APIs.

Anyway - the REST movement served it's purpose - it killed SOAP and forced everyone back to simpler HTTP APIs without tons of over-engineered XML layers so it did well.

Re: MCP Apps: Extending servers with interactive user interfaces

#62

Post by wild_egg »

_heimdall wrote: post #42

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.

LLMs work great with REST so that's always still an option. MCPs have that nice third party plug and play experience but that doesn't mean we all have to build them.

I make tons of little REST APIs for my agents to use and in the AGENTS.md there's just a list of API entry points with descriptions on what they offer. Agents drive them with `curl` and it all works great.

Re: MCP Apps: Extending servers with interactive user interfaces

#63

Post by somnium_sn »

hobofan wrote: post #58
somnium_sn wrote: post #49

Earlier quoted context omitted.

All it means that there is a common place and a recommendation that if you care as a client implementor (e.g. postman, chatgpt and others do), there is a spot to look for a generally accepted way of how to do that instead of increasing amount of proprietary extensions on top of MCP.

> there is a spot to look for a generally accepted way of how to do that I think MCP-UI in it's current state can fill that role very well, and that's not the only lens with which to view a SEP like this. From what I can tell the main thing that this SEP does is put the official blessing of the MCP project on the existing underlying protocol that MCP-UI is already using. I think the better way would be to let MCP-UI…

I appreciate the take. I can certainly see your position.

In my mind what we are doing is building a common place to evolve the pattern. I wouldn’t really call it “standardize”, since in the end in this space adoption matters. (Writing a standard is worth nothing if nobody is using it). I expect MCP apps to evolve and iterate independent from the main spec for a while. You are right, it’s early and premature to say “this is done”. That’s the goal with extensions.

I do believe that I rather have commonalities between a Claude.ai and a ChatGPT as a developer (not sure that’s true if I was mostly looking at it from a product perspective). I also think you will see chat providers iterate on top of it, and mcp apps is more a common core than the full thing one can use on every platform.

Re: MCP Apps: Extending servers with interactive user interfaces

#64

Post by wild_egg »

_heimdall wrote: post #59
hobofan wrote: post #47

Earlier quoted context omitted.

> Had we stuck with REST for the last 20 years we'd be way ahead on that front We are where we are because there (sadly) hasn't been a reasonable business case to advance REST API documentation beyond the point of badly-documented OpenAPI schemas where the main utility is in generating type-safe API wrappers across different programming languages. With MCP, there is at least a name to a new movement to build self-des…

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.

Re: MCP Apps: Extending servers with interactive user interfaces

#65

Post by _heimdall »

andybak wrote: post #61
_heimdall wrote: post #42

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.

We never really implemented REST APIs. We had a bunch of REST-ish APIs. Anyway - the REST movement served it's purpose - it killed SOAP and forced everyone back to simpler HTTP APIs without tons of over-engineered XML layers so it did well.

HTML is an implementation of a REST API, I'm not sure what you mean that we never implemented REST.

SOAP was a pain, XML wasn't doomed though and we didn't need to throw that baby out with the bath water.

Re: MCP Apps: Extending servers with interactive user interfaces

#66

Post by _pdp_ »

_pdp_ wrote: post #60

This is so redundant it is beyond reason. 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 canv…

Also, this is how GitHub Copilot works when rendering UI to preview draft tickets. It is simply a markdown fenced codeblock with some special properties in the language definition.

Not only this approach is more specific to the application where the UI is supposed to render but it also opens the door for the user to customise how the UI should work by adding their own prompts.

The approach that OpenAI has taken is not better - it is simply a mechanism to create some sort of app store - something they have attempted to do many times in the past as well.

Re: MCP Apps: Extending servers with interactive user interfaces

#67

Post by sixtyj »

bradgessler wrote: post #45
CuriouslyC wrote: post #32

Earlier quoted context omitted.

I want to try and understand what you guys see as the win from MCP. It's objectively inferior to code/clis across a ton of dimensions. The main value I see from it is as a single point to "sandbox" what your agents can do, but it seems a little awkward for that use case.

I built https://terminalwire.com around the idea that CLIs are a great way to interact with web applications. Turns out the approach works well for integrating web apps with LLMs. I have a payroll company using it in their stack to replace MCP and they’re reporting lower token usage and a better end result.

Re CLI: In fact it seems to be very similar to command line in AutoCAD (you can do things visually with mouse or choose to draw via CLI). With LLMs it is more sophisticated (intelligent) because you are not limited with set of predefined commands.

I am waiting for Excel CLI…

Re: MCP Apps: Extending servers with interactive user interfaces

#68

Post by esafak »

hobofan wrote: post #52
UltraSane wrote: post #48

Hasn't even Anthropic admitted that MCP is very wasteful of context? Having the LLM write code to call and API can use 98% less tokens. 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…

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?

Re: MCP Apps: Extending servers with interactive user interfaces

#70

Post by mbreese »

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 currently possible if you passed through something like a session-id back to the LLM?

Am I missing something? I’m struggling to see what a UI makes possible that the current workflow does not.

I also generally see/use MCP in terms of remote access to programs through servers. Perhaps that’s where I’m getting lost. Is this exclusively something for local MCP?

Post reply on HN