[Feature Request] Support the MCP Apps extension, enabling MCP servers to show interactive user interfaces

[yurivish]

Is your feature request related to a problem? Please describe.

I would love to add interactive user interfaces to my Go-based MCP servers, but right now it is not possible.

A recent extension (last month) to the MCP protocol enables MCP servers to show interactive user interfaces, such as data visualizations and complex configuration workflows, directly in an MCP host.

Basically, the server provides an HTML page to be used as the UI, and the MCP protocol is extended to enable communication between that UI, the MCP server, and the MCP host. The UI can appear eg. directly inside of a chat conversation with an AI model, and can be used to interactively guide the conversation.

Here is the spec. There is also an official blog post introducing the extension, and an overview of the concept of extensions, and a docs page motivating and explaining the MCP Apps extension.

Describe the solution you'd like

I would love it if I could add rich user interfaces to my Go-based MCP servers. Right now I use JavaScript when I need to build an MCP server with a UI because there is SDK support there.

In terms of what would be required, looking at the spec I see there is a section on Client<>Server Capability Negotiation and another on Server Behavior.

It's hard to say for sure, but it's possible the server support is a relatively small effort, since most of the complexity of the spec is about the client and host.

Describe alternatives you've considered

One alternative is to use JavaScript to build my MCP servers, which I personally find unsatisfying, particularly since it is not possible to do cross-server MCP calls -- meaning that a UI can only programmatically call tools from its own MCP server, and writing the UI in a separate sever/language would be limiting.

Here is a code snippet that shows what a JS-based MCP apps server looks like when implemented using the JS SDK.

Additional context

Thanks for making this package – getting started is so simple and pleasant, and I'm very excited about being able to use Go for MCP servers! I tried to be as accurate as I can in this request, but please forgive me if I've misunderstood anything about the nature of this spec, or if the request is somehow incoherent -- still learning my way around the various protocols involved. Thanks again!

Edit: Claude Code suggests that a minimal change is needed, since most of the complexity is on the side of the host. Relevant snippet:

1. Add Extensions field to ClientCapabilities (protocol.go:192)

 type ClientCapabilities struct {
     // ... existing fields ...
     Elicitation *ElicitationCapabilities `json:"elicitation,omitempty"`
     // Extensions describes protocol extensions that the client supports.
     // Keys are extension URIs (e.g. "io.modelcontextprotocol/ui").
     Extensions map[string]any `json:"extensions,omitempty"`
 }

No clone() update needed -- Experimental map[string]any (line 198) uses the same pattern and is not explicitly
cloned either (cp := *c copies the map header, matching existing convention).

2. Add Extensions field to ServerCapabilities (protocol.go:1300)

type ServerCapabilities struct {
    // ... existing fields ...
    Tools *ToolCapabilities `json:"tools,omitempty"`
    // Extensions describes protocol extensions that the server supports.
    // Keys are extension URIs (e.g. "io.modelcontextprotocol/ui").
    Extensions map[string]any `json:"extensions,omitempty"`
}

Same clone story -- matches Experimental.

[...]

Once the field exists, a Go MCP server can:

1. Set ServerOptions.Capabilities.Extensions["io.modelcontextprotocol/ui"] = map[string]any{}
2. Set Tool.Meta["ui"] = map[string]any{"resourceUri": "ui://server/app.html"} on tools
3. Register a resource at ui://server/app.html with MIME type text/html;profile=mcp-app
4. Check client support via session.InitializeParams().Capabilities.Extensions["io.modelcontextprotocol/ui"]

All of this uses existing SDK primitives -- only the Extensions field is missing today.