[RFC] UI Component Integration in MCP Responses

[olaservo]

Problem Statement

Currently, MCP interactions are limited to text, images, and audio responses. This creates a significant limitation for building rich, interactive user experiences with MCP servers. The community has expressed strong interest in enabling UI components within tool responses to support complex workflows, forms, interactive data visualization, and guided user interactions.

Specific Implementation Challenges

1. Limited Interaction Patterns: Current MCP responses cannot support interactive forms, buttons, tables with sorting/filtering, or multi-step workflows
2. Custom DSL Proliferation: Developers are creating ad-hoc solutions like JSONSchema-based forms or notification systems, leading to inconsistent approaches
3. Breaking MCP Contract: Workarounds often require stepping outside the MCP protocol, reducing interoperability
4. Developer Experience: Building meaningful interactive flows requires duplicating logic across tools and frontends

Real-World Use Cases

• Interactive dashboards for system monitoring
• Dynamic forms for data collection and validation
• Step-by-step guided workflows
• Rich data visualization with user controls
• Multi-step approval processes

Current State

A community member (idosal) has developed a working implementation:

• Library: @mcp-ui/client (experimental, community-maintained)
• URI Scheme: ui:// and ui-app:// for embedded resources
• Implementation: Fork of MCP Inspector with UI rendering capabilities

Interests vs Positions

Community Interests

• Security: Ensure UI rendering doesn't introduce XSS or injection vulnerabilities
• Interoperability: Maintain MCP protocol compatibility across implementations
• Developer Experience: Provide rich, interactive capabilities without breaking existing patterns
• Standards: Establish consistent approaches rather than fragmented solutions
• Innovation: Enable new categories of MCP applications and use cases

Current Positions Being Advocated

• Official integration into MCP Inspector (rejected)
• Community fork maintenance approach (current)
• Plugin architecture for extensibility (proposed)
• Protocol-level UI support (under consideration)

Related Work

• Original PR Discussion: feat: support UI in Tool responses modelcontextprotocol/inspector#413
• Community Implementation: @mcp-ui/client library
• Fork Maintenance: ui-inspector community fork
• Protocol Discussion: Referenced in modelcontextprotocol/discussions/287

---

Sources: Discord, original Inspector PR discussion

[Joffref]

@olaservo Definitely something that's needed. I was drafting #34, and we’ll need some sort of UI or flow for user consent. While it could technically be done entirely through an API, it feels like handling an MCP interaction outside of MCP.

[idosal]

Yes! Let's make this happen. Thanks for formalizing it @olaservo

[tadasant]

One more thought w.r.t. deliverables: I think it'd be interesting to document "how the ui:// scheme works" so that, in theory, someone could build another SDK (e.g. in another language) or just leverage the scheme without an SDK. That scheme could be documented on the modelcontextprotocol-community org, and if people have ideas for other schemes we could create a library of Resource schemes over time.

[idosal]

One more thought w.r.t. deliverables: I think it'd be interesting to document "how the ui:// scheme works" so that, in theory, someone could build another SDK (e.g. in another language) or just leverage the scheme without an SDK. That scheme could be documented on the modelcontextprotocol-community org, and if people have ideas for other schemes we could create a library of Resource schemes over time.

100%. There's a description in mcp-ui exactly for that purpose but it's pretty basic. I'll formalize it soon and update here.

[tadasant]

If you're up for it, thinking through how to present generically the "library of URI schemes" and basically introduce ui:// as the first example would be awesome

[connor4312]

For image and audio types, we support mimeType on the data, though there may late be some generic "binary" types. Do we need extra client capabilities beyond the existing mimeType in order for clients to develop rich UI for editor data? It's possible that as a client I might have multiple ways (or my own extensions) to render given data. Versus just a generic "UI" scheme a mimetype would give me more specific ways to match on data.

[sambhav]

Note that https://github.com/ag-ui-protocol/ag-UI exists. Something to consider or take inspiration from at the very least (at least the events)

[liady]

We should definitely consider a way for the server to return different results or generic results, depending on the client's capabilities.
Even maybe something similar to mobile apps - where the basic UI building blocks are defined, and work well in every implementation.
The UI itself should probably be rendered by the client, but defined by the server