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

51–60 of 124 posts

Re: MCP Apps: Extending servers with interactive user interfaces

#51

Post by EagnaIonat »

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?

WSDL just told you what API was there and create the interface for you in code.

It actually never tried to figure out what API call you actually needed based on what the user asked and how to handle it in real time.

I mean it could, but WSDL was already superseded by REST.

Re: MCP Apps: Extending servers with interactive user interfaces

#52

Post by hobofan »

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]: https://news.ycombinator.com/item?id=45917182

Re: MCP Apps: Extending servers with interactive user interfaces

#54

Post by brazukadev »

baq wrote: post #50

What’s the difference between an MCP server and a command line executable (which curl is also one)? A good ——help or openapi spec…?

MCP defines other useful things like Resources, Elicitation, Sampling, prompts which are model/agent-specific, there is nothing in openai or a "good --help" that could match that.

If you don't see this as useful, that is ok, but it is not the same as a command line executable.

Re: MCP Apps: Extending servers with interactive user interfaces

#55

Post by cube2222 »

baq wrote: post #50

What’s the difference between an MCP server and a command line executable (which curl is also one)? A good ——help or openapi spec…?

vs executable - don’t need a full shell environment to run it

vs openapi - there’s some more advanced agent-specific concepts in MCP, but primarily, I would say, it’s convention and optimizing for the client. Existing openapi specs will often have not great descriptions, or be a huge mess, or just be huge. Making an MCP server requires you to rethink the UX and tools to be optimized for the access patterns of an agent, and also makes you test it with them.

That said, Claude Skills[0] is something more in the vein of cli with —help (really, with a markdown guide), embracing what is already there with a bit of instructions, as opposed to building from scratch.

My personal opinion, having built multiple MCP servers, is that long-term they will not be the primary approach to tools, and that skills for instance are a better approach for most use-cases. But they do have their use-cases.

[0]: https://www.claude.com/blog/skills

Re: MCP Apps: Extending servers with interactive user interfaces

#57

Post by bradgessler »

michaelbuckbee wrote: post #38

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.

I built https://terminalwire.com to make it easier for more web applications to ship CLIs like gh. Are there any web services like GH that you use in your workflow that don’t have decent AI integration that would benefit from a CLI interface?

Re: MCP Apps: Extending servers with interactive user interfaces

#58

Post by hobofan »

somnium_sn wrote: post #49
hobofan wrote: post #33

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, a…

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 and competing implementations cook for a little bit longer, rather than trying to get an officially sanctioned extension out the door and then iterate on that, which will cause a lot more churn.

For a non-trivial feature like this, I would expect an SEP that highlights more alternative usage scenarios and potentially operates on a more technology agonistic layer (e.g. it's very JS+iframe bound, so what about mobile or terminal UIs?), similar to the main MCP spec. Especially given the backdrop of the main MCP specification, which feels much more well-rounded and throughly considered (though in a few areas still incomplete), this SEP does not seem to meet the same bar.

Reading that from the perspective of someone that builds a LLM Chat UI[0] (and aims to be able to maintain that long-term) that heavily builds on MCP as an interoperability concept, reading what is proposed here and seeing how prescriptive it is in many aspects does not spark a lot of joy.

[0]: https://erato.chat

---

EDIT: From what I can tell I'm replying to one of the co-creators of MCP. So let me just ask quite directly: Do you think that the risk of proprietary sprawl in terms of MCP-UI alternatives is currently greater than prematurely standardizing a potentially incomplete version?

Re: MCP Apps: Extending servers with interactive user interfaces

#59

Post by _heimdall »

hobofan wrote: post #47
_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.

> 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 third party could easily discover and use. The need for REST only shows up when a new player makes a move to effectively gobble up the role of being the gate keeper to the internet. With scale other companies will follow, but begrudgingly and only for a short while.

Re: MCP Apps: Extending servers with interactive user interfaces

#60

Post by _pdp_ »

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 canvas thing works (both chtgpt and claude) when rendering documents on the side.

Post reply on HN