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

111–120 of 124 posts

Re: MCP Apps: Extending servers with interactive user interfaces

#111

Post by UltraSane »

hobofan wrote: post #109
UltraSane wrote: post #105

Earlier quoted context omitted.

How is that different then an OpenAPI definition?

It conceptually isn't that far from OpenAPI defintions, but MCP do make certain affordances for making consumptions by LLMs easier. But it certainly also differs by how they are typically consumed. In what software do you just provide your consuming client just an OpenAPI schema URL to be retrieved at runtime? In my experience, none.

https://github.com/OpenAPITools/openapi-generator

You can also have an LLM generate a client from an OpenAPI spec

Re: MCP Apps: Extending servers with interactive user interfaces

#112

Post by mcpeepants »

james_marks wrote: post #108
troupo wrote: post #104

Earlier quoted context omitted.

> MCP is not just providing an API It does just provide an API. Your client may have a way to talk to some software via MCP protocol. You know, like a client can talk to a server exposing an endpoint via an API. > And it does so in a standard way so that my client is available across AI providers. As in: it's an API on a port with a schema that a certain subset of software understands. > What’s the alternative? Provi…

Perhaps confusingly, I’m referring to MCP as the sum of the protocol, a server adhering to the protocol, and clients adding support (e.g. “Connectors”). The combination of these things turns into an ecosystem.

MCP is a Protocol. The server and the clients are just that. It truly is a rebranding of “API” seemingly just because it’s for a specific purpose. Not that there’s anything wrong with that… call it whatever. But I don’t understand the need to sell it as something else entirely. It is quite literally a reinvention of RPC.

Re: MCP Apps: Extending servers with interactive user interfaces

#113

Post by prescriptivist »

vidarh wrote: post #93
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…

MCP has already drastically lost utility already thanks to skills - for most things it is easier to just hand the model a CLI that it can run. I'd imagine the same thing will happen here: It will prove more flexible to not push the model (and user) towards a UI that may not match what the user is trying to accomplish. To me this seems like something I categorically don't want unless it is purely advisory.

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 GitHub itself). If you have an MCP server that Claude feeds a SHA into and gets back a bespoke, organized payload that adds relevant context to its decision making process (such as a unified view of CI, diffs, et. al), then MCP is a win.

MCP shines as a bespoke context engine and fails as a thin API translation layer, basically. And the beauty/elegance is you can use AI to build these context engines.

Re: MCP Apps: Extending servers with interactive user interfaces

#115

Post by electric_muse »

vidarh wrote: post #93
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…

MCP has already drastically lost utility already thanks to skills - for most things it is easier to just hand the model a CLI that it can run. I'd imagine the same thing will happen here: It will prove more flexible to not push the model (and user) towards a UI that may not match what the user is trying to accomplish. To me this seems like something I categorically don't want unless it is purely advisory.

There are important contexts outside of machines you control where installing or running cli commands isn’t possible. In those cases, skills won’t help, but MCP will.

Re: MCP Apps: Extending servers with interactive user interfaces

#116

Post by throwup238 »

prescriptivist wrote: post #113
vidarh wrote: post #93

Earlier quoted context omitted.

MCP has already drastically lost utility already thanks to skills - for most things it is easier to just hand the model a CLI that it can run. I'd imagine the same thing will happen here: It will prove more flexible to not push the model (and user) towards a UI that may not match what the user is trying to accomplish. To me this seems like something I categorically don't want unless it is purely advisory.

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…

Exactly. The way it’s mostly been used so far is a poor abstraction over stuff you can just put in the context and have the agent run commands.

It really shines in custom implementations coupled to projects. I’ve got a QT desktop app and my mcp server allows the agents to run the app in headless mode, take screenshots, execute code like in Playwright, inspect widget trees, send clicks/text/etc with only six tools and a thousand tokens or so of instructions. Took an hour to build with Claude Code and now it can run acceptance tests before committing them to code end to end tests.

Re: MCP Apps: Extending servers with interactive user interfaces

#117

Post by felipeerias »

prescriptivist wrote: post #113
vidarh wrote: post #93

Earlier quoted context omitted.

MCP has already drastically lost utility already thanks to skills - for most things it is easier to just hand the model a CLI that it can run. I'd imagine the same thing will happen here: It will prove more flexible to not push the model (and user) towards a UI that may not match what the user is trying to accomplish. To me this seems like something I categorically don't want unless it is purely advisory.

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.

Re: MCP Apps: Extending servers with interactive user interfaces

#118

Post by troupo »

james_marks wrote: post #108
troupo wrote: post #104

Earlier quoted context omitted.

> MCP is not just providing an API It does just provide an API. Your client may have a way to talk to some software via MCP protocol. You know, like a client can talk to a server exposing an endpoint via an API. > And it does so in a standard way so that my client is available across AI providers. As in: it's an API on a port with a schema that a certain subset of software understands. > What’s the alternative? Provi…

Perhaps confusingly, I’m referring to MCP as the sum of the protocol, a server adhering to the protocol, and clients adding support (e.g. “Connectors”). The combination of these things turns into an ecosystem.

> I’m referring to MCP as the sum of the protocol, a server adhering to the protocol, and clients adding support (e.g. “Connectors”).

Why?

Do you refer to REST APIs or GraphQL as a whole? There are servers "adhering to the protocol" and "clients adding support" for these.

These are literally APIs.

Re: MCP Apps: Extending servers with interactive user interfaces

#119

Post by wild_egg »

_heimdall wrote: post #75
wild_egg wrote: post #64

Earlier quoted context omitted.

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.

To be honest, I think I meant to put that reply on a different comment.

In any case, we're on the same page about REST. OpenAPI was mentioned though and I don't think that's ever actually compatible with that type of usage.

I don't think I've ever encountered an API following OpenAPI that was completely self describing and could be discovered and navigated from a single entry URL. They're always paired with some swagger docs or other external content. That instantly makes them not RESTful.

But you're totally right that my comment didn't fit. Might have meant it for the grandparent comment? Not sure.

Re: MCP Apps: Extending servers with interactive user interfaces

#120

Post by vidarh »

electric_muse wrote: post #115
vidarh wrote: post #93

Earlier quoted context omitted.

MCP has already drastically lost utility already thanks to skills - for most things it is easier to just hand the model a CLI that it can run. I'd imagine the same thing will happen here: It will prove more flexible to not push the model (and user) towards a UI that may not match what the user is trying to accomplish. To me this seems like something I categorically don't want unless it is purely advisory.

There are important contexts outside of machines you control where installing or running cli commands isn’t possible. In those cases, skills won’t help, but MCP will.

Hence why I said drastically, rather than totally. There are still a few edge cases where it is worthwhile, but they are small and shrinking, especially with services providing UI's with VM's/containers for the model to use increasingly being a thing.
Post reply on HN