MCP Apps: Extending servers with interactive user interfaces

Original Article ↗ Hacker News Discussion ↗

Perceived significance and goals

  • Many see MCP Apps / MCP-UI as a missing piece: a UI layer on top of MCP so non-technical users aren’t stuck in pure chat, and can use buttons, forms, tables, etc.
  • Supporters argue this moves MCP closer to real user workflows, where most users don’t know or care about protocols, just that “the chat helps them get work done.”
  • Others think it could catalyze a new generation of “apps inside chat” for commerce and productivity.

UX benefits and concrete use cases

  • Recurrent theme: current LLM UX is powerful but clunky—lots of copy/paste, weak formatting, poor integrations (e.g., no OAuth flows, API keys in files).
  • Example “killer” flows raised:
    • “Recommend a book; give me a one-click ‘send to Kindle for $4.99’ button.”
    • “Find me a hotel in city X this weekend” → interactive grid of offers with “book now” buttons.
  • Other use cases: dashboards, data tables, embedded charts, game UIs (e.g., Doom), and internal tools that surface richer context to agents.

APIs, determinism, and redundancy concerns

  • Large subthread debates whether MCP is “just APIs/RPC again”: some argue it’s basically OpenAPI/WSDL/REST reinvented with new branding.
  • Others say MCP adds LLM-oriented features (tool discovery, agent-friendly schemas, resources, elicitation) beyond a simple --help or OpenAPI spec.
  • Determinism: people argue over “indeterministic buttons”; consensus is that MCP servers are generally as deterministic as normal REST APIs, and the non-determinism is in the LLM deciding when/how to call them.
  • Token/context cost concerns surface, with references to work showing that code-based tool invocation can massively reduce token usage versus naïve MCP loading.

Lock-in, platforms, and “app store” dynamics

  • Some fear whoever controls the dominant protocol / app SDK becomes the next iOS/Android, with vendor lock-in and “app store” power.
  • Embedding mini-apps inside ChatGPT/Claude is seen by critics as a monopolistic move vs a system agent calling ordinary app APIs.
  • Questions raised: Will Apple/other platforms tolerate an in-chat cross-platform app store? Who curates it for non-technical users?

Standardization, overlap, and ecosystem risks

  • MCP-UI is pitched as an optional extension and a “common place” to converge patterns and avoid proprietary sprawl across vendors.
  • Skeptics worry the MCP surface is already large, implementations barely cover the core, and premature “official” blessing could fragment clients and servers further.
  • Existing or competing specs (AG-UI, Copilot-like markdown UIs, custom frameworks) are cited as evidence of duplication.

Alternatives: CLIs, skills, and LLM-generated UIs

  • Several participants prefer letting agents call CLIs or REST APIs directly (often via “skills”) for better determinism, flexibility, and token efficiency.
  • Some argue we should push toward LLM-generated, bespoke UIs (e.g., via code/markdown blocks) rather than static, server-defined widgets; others respond that models aren’t reliable enough yet for complex dynamic UIs.
  • MCP is framed by some as best for bespoke “context engines” and long-lived services (auth, stateful workflows), not as a universal tool layer.

Broader reflections

  • Comparisons to past waves: Facebook apps, WeChat mini-programs, bot frameworks, and the web itself; some feel the industry is re-deriving old patterns.
  • There’s both excitement about breaking information silos and enabling “conversational commerce,” and unease that human-facing UIs might get subsumed by machine-driven intermediaries.