Background

People have been talking about UI in MCP for a long time. The core question: how can MCP servers return rich, interactive experiences instead of just text?

We've been experimenting with MCP-UI, which Goose currently supports as an experimental feature. It's been a useful proving ground, and the community has built some interesting things with it.

Now there's MCP Apps—a draft extension to the MCP spec that takes a more formalized approach to the same problem. This is where the ecosystem is heading, and we want Goose to support it.

Our Approach

We're going to start simple: build the most barebones implementation possible that lets people experiment.

The goal isn't to ship a polished, feature-complete implementation on day one. It's to get something working that:

1. Declares the right capabilities during MCP initialization
2. Discovers tools that return MCP App resources
3. Renders the HTML content in a sandboxed iframe
4. Handles the basic message relay between the UI and the MCP server

This gives extension authors a way to start building and testing MCP Apps with Goose, even while the spec is still in draft.

From there, we'll iterate—following the standard as it develops and incorporating elements from the official MCP Apps SDK as they become available.

Active exploration:

• Goose apps #5633
• Implement MCP Apps #6039

What About MCP-UI?

No immediate deprecation. The MCP-UI server SDK provides an adapter that lets server authors support both formats with minimal effort. Once MCP Apps is officially accepted as an MCP extension, we'll communicate a deprecation timeline for MCP-UI.

Future Possibilities

This is where things get interesting.

The MCP Apps spec opens the door to capabilities beyond what we're implementing initially—things like camera access, sensors, and other device capabilities that hosts could expose to apps.

But the bigger picture is what happens when MCP Apps exist outside the conversation. Imagine:

• Persistent app windows that live alongside your chat, updating in real-time as context changes
• Vibe coding for UIs—describing what you want and having Goose generate and iterate on MCP App interfaces on the fly
• Apps that span sessions—dashboards, monitoring tools, or workspaces that persist and evolve

We're not building any of that yet. But getting the foundation right now means we'll be ready when the spec and ecosystem mature.

What are you excited to build with MCP Apps? Any concerns about the approach? Let us know.