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

81–90 of 124 posts

Re: MCP Apps: Extending servers with interactive user interfaces

#81

Post by hobofan »

esafak wrote: post #74
hobofan wrote: post #72

Earlier quoted context omitted.

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.

> where do the MCP definitions

What concretely do you mean be definitions?

If you mean the configuration of the entry points similar to a .mcp.json for Claude Code, they can exist in any form, but ultimately, that only contains the endpoints of MCP servers (the entry points for discovery for each of the MCP servers).

If you mean the definitions of what tools are part of what MCP server (= the meat of what is involved in tool calling), those definitions are part of the MCP server and are only retrieved at runtime.

> how are the agents aware of them

Same as in Claude Code, the agent (= the control loop for the LLM) contacts the list of MCP endpoints, gathers all of the available tools on each MCP server, and then exposes those tools to the LLM (and handles the interactions between LLM and MCP server).

> There has to be a file somewhere.

Not in any way that's meaningful for an `ls` operation.

Re: MCP Apps: Extending servers with interactive user interfaces

#82

Post by zeroimpl »

wild_egg wrote: post #62
_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.

Doesn’t that force you to give the Agent some generic code execution environment, or does everybody already do that anyways?

Re: MCP Apps: Extending servers with interactive user interfaces

#83

Post by debugnik »

cube2222 wrote: post #55
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 agen…

You don't need a shell to run executables either.

Re: MCP Apps: Extending servers with interactive user interfaces

#84

Post by adidoit »

It's very interesting of course at a natural move for aggregation. I'd love to see Stratechery / Ben Thompson's take on this.

From my perspective the challenges for vendors and SaaS providers are [1] discovery [2] monetization [3] disintermediation

I think it's less of a concern if you're Shopify or those large companies that have existing brand moats.

But if you're a startup, I don't think MCP as a channel is a clear-cut decision. Maybe you can get distribution but monetization is not defined.

Also I'm sure the model providers will capture usage data and could easily disintermediate you , especially if your startup is just a narrow set of prompts and a UX over a specific workflow.

The Reforge guys have been talking about a channel shift and this being it but until incentives are clear I'm not sure this is it yet. Maybe an evolution of this.

I'm building an AI coach for job seekers / early stage professionals (Socratify) and while I'd love more distribution from MCP UI integration I think at this point risk is higher than reward...

Re: MCP Apps: Extending servers with interactive user interfaces

#85

Post by greatgib »

When you think about that, without AI, simple automation could do most of what we would need if app and webapp providers would have been to provide interface. Were instead the big fight was to prevent scraping and to get your info in any other way than being forced to use the crappy app. Like for banking.

Re: MCP Apps: Extending servers with interactive user interfaces

#86

Post by WillAdams »

seunosewa wrote: post #76
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.

The task is renaming scans of checks (with the barcode/bank account info obscured by a pen) --- the checks are of varying sizes, placement is not exact, the placement and formatting of the information on the check is essentially random, and many of them are (poorly) handwritten).

The LLM is working well enough for my needs (and I'm using a locked-down computer which installing/running development environments/scripts on is awkward), and it's a marked improvement over the previous technique of opening 50 files at a time, noting the Invoice ID, closing the file, typing the Invoice ID as a name, then quitting Adobe Acrobat and re-launching it for the next 50 (if that was not done, eventually Acrobat would reach a state where it would close a file and despite the name having been typed, not save it), then using a .bat file made using concatenation in an Excel column.

It would be nice if it were perfect, but each check has to be manually entered, and the filename updated to match the entry by hand.

Re: MCP Apps: Extending servers with interactive user interfaces

#87

Post by woleium »

greatgib wrote: post #85

When you think about that, without AI, simple automation could do most of what we would need if app and webapp providers would have been to provide interface. Were instead the big fight was to prevent scraping and to get your info in any other way than being forced to use the crappy app. Like for banking.

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

Re: MCP Apps: Extending servers with interactive user interfaces

#88

Post by c-hendricks »

CuriouslyC wrote: post #32
felixrieseberg wrote: post #11

Disclosure: I work at Anthropic, have worked on MCP I also think this is pretty big. I think a problem we collectively have right now is that getting MCP closer to real user flows is pretty hard and requires a lot of handholding. Ideally, most users of MCP wouldn't even know that MCP is a thing - the same way your average user of the web has no idea about DNS/HTTP/WebSockets. They just know that the browser helps the…

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.

LLMs are used outside of programming though. It's much easier to hook up a HTTP MCP than it is to install and update a CLI on the execs machines.

Re: MCP Apps: Extending servers with interactive user interfaces

#89

Post by mbreese »

kkarpkkarp wrote: post #79
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 t…

Thank you for this.

So, basically -- it's a method for the MCP Server to display a UI element to the user allowing the user to perform some kind of action. Current, this UI will be an HTML iframe.

I think I got confused by their barchart example. I thought this would have been just as easily supported by the MCP server sending back a PNG/PDF of a barchart for the main interface to display (I also generally think of barcharts as static content). But, the idea of adding specific user interaction elements (buttons) helps to make the concept more clear to me.

Re: MCP Apps: Extending servers with interactive user interfaces

#90

Post by Yodan2025 »

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…

test how much data from a file they actually see.. its not unlimited// build a deterministic output ie. 2 of 5 chunks received, send chunk 3
Post reply on HN