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

41–50 of 124 posts

Re: MCP Apps: Extending servers with interactive user interfaces

#41

Post by stingraycharles »

notpachet wrote: post #27
stingraycharles wrote: post #14

Earlier quoted context omitted.

Unless the MCP server itself has an LLM call inside of it (rare), the MCP server is pretty deterministic. It’s the AI that invokes it that’s actually indeterministic, but the user is already using that.

> pretty deterministic This is an oxymoron.

I meant “pretty” as in, using a search engine is pretty deterministic, any REST API is deterministic.

MCP servers’ tools are literally just function calls. It’s the LLM MCP client that’s not deterministic, not the MCP server.

Re: MCP Apps: Extending servers with interactive user interfaces

#42

Post by _heimdall »

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.

Re: MCP Apps: Extending servers with interactive user interfaces

#43

Post by Maxious »

meander_water wrote: post #30

We already have AG-UI [0], which has been implemented by frameworks like Microsoft agent framework, pydantic AI and llamaindex. I guess they'll just have to duplicate functionality. Sigh. [0] https://docs.ag-ui.com/introduction

We had AG-UI. I'd say CopilotKit and AssistantUI (YC W25) are now Sherlocked

Re: MCP Apps: Extending servers with interactive user interfaces

#44

Post by hobofan »

notpachet wrote: post #27
stingraycharles wrote: post #14

Earlier quoted context omitted.

Unless the MCP server itself has an LLM call inside of it (rare), the MCP server is pretty deterministic. It’s the AI that invokes it that’s actually indeterministic, but the user is already using that.

> pretty deterministic This is an oxymoron.

No it's not.

In the real world, where it is (at least in our current state of overall programming language tooling, and the existence of physics) intractable to prove all eventualities and absence of side-effects of executed code, determinism is indeed a spectrum.

If we want to be specific here, I would say the "pretty deterministic" is equal to "as deterministic as your typical non-LLM REST API call", which still spans a big range of determinism.

Re: MCP Apps: Extending servers with interactive user interfaces

#45

Post by bradgessler »

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.

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: MCP Apps: Extending servers with interactive user interfaces

#46

Post by somnium_sn »

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 also highlight that this is an optional "extension" to MCP, not a required part of specification. If you are a terminal application, only care about tool calling, etc, you are free to skip this. If you want to enable rich clients, then it might be something to consider implementing.

Re: MCP Apps: Extending servers with interactive user interfaces

#47

Post by hobofan »

_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-describing APIs, as with the advent of LLMs there is now enough of a utility for it. All other pushes into that direction have died out ~10 years ago.

Re: MCP Apps: Extending servers with interactive user interfaces

#48

Post by UltraSane »

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 updateRecord.ts) to understand each tool's interface. This lets the agent load only the definitions it needs for the current task. This reduces the token usage from 150,000 tokens to 2,000 tokens—a time and cost saving of 98.7%.

Re: MCP Apps: Extending servers with interactive user interfaces

#49

Post by somnium_sn »

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.
Post reply on HN