This is exciting to see! I see that as with current MCP-UI and Apps SDK specs, this covers allowing UI to request tool calls and rerender in a way that keeps the agent in the loop. But does this proposal intentionally not address mechanisms to close the loop in the other direction, to flow related tool call data from subsequent conversational turns back into an already rendered widget? Or is the ability to read (and subscribe to?) resources directly from within a widget intended for this purpose?

Suppose I have a getItemDetails tool that renders a Book widget, and then in a subsequent turn a user utterance triggers a setItemStatus tool which mutates a status field. How should the change be communicated to the widget so it can rerender?

That’s not an MCP limitation is it? (roll your own MCP and chat interface and there’s no issue rendering video or html or whatever), that is a UI of chat bots limitation. You don’t NEED to give the model back text data over MCP - a tool can be triggered and vend auth’d data of any kind to the interface.

What am I missing? Why concretize a general communication/auth protocol spec within one specific usecase?

Fantastic work on this PR.. really sharp update.

Introducing this resource declarations and a bi-directional UI communication model feels like a big step toward unlocking richer and more interactive MCP clients.

One question: how do you envision capability negotiation evolving for UI-enabled resources once multiple client types adopt this pattern?

I'm curiosa whether you see a standardized handshake emerging or if it stays client-specific for now.

That’s not an MCP limitation is it? (roll your own MCP and chat interface and there’s no issue rendering video or html or whatever), that is a UI of chat bots limitation. You don’t NEED to give the model back text data over MCP - a tool can be triggered and vend auth’d data of any kind to the interface.

What am I missing? Why concretize a general communication/auth protocol spec within one specific usecase?

In "base" MCP there is no way to distinguish between what is for the model and what is for the application. The OpenAI Apps SDK worked around this by putting the UI in structured output and the for-model result in regular unstructured / text tool output. But that's actually not standards-compliant (the structured and unstructured output is supposed to be the same as of current spec), and it prevents the use of structured output for other things.

By using metadata it becomes much more explicit what is the tool result and what is the tool app/ui/visualization component. It is important to distinguish between context for the model and for the application. You don't want to send context for the application to the model, as the model doesn't have direct access to the UI (at least not without calling another tool, and that'd be a very roundabout way to accomplish the same thing).

Also, this is an extension, so it is purely additive. It's a great way to let something that is bound to evolve and need continuous adjustments not get bogged down by only being allowed to change with spec versions.

You're right that if you're rolling your own MCP server and client host, then you can already do this using whatever scheme you want - but the beauty of a standardized extension is that we have less risk of ending up with a unique UI / Apps contract per client host.

Ideally as a server author, you'd want your MCP server to be able to render UI to all chat platforms without having to use a different communication convention for each of them. And simply returning the UI resource to the model is not a solution. The model is not an active participant in rendering the UI - that's an application-level concern.

Finally, the whole in-frame messaging part of this extension is non-trivial to design and engineer, so having a standardized way to that is highly valuable. See: https://github.com/modelcontextprotocol/ext-apps/blob/main/specification/draft/apps.mdx#transport-layer

Many questions:

1) Why bring this application implementation into the protocol itself?

This, along with OpenAI's implementation of the Apps SDK, is not bounded by the MCP specification.

@PederHP makes a good point:

this is an extension, so it is purely additive. It's a great way to let something that is bound to evolve and need continuous adjustments not get bogged down by only being allowed to change with spec versions.

Then I would say this should be rejected as a SEP (since it's not apart of the specification) and instead, documented as a "best practice" or "official extension". The docs site already has precedence for this in the roadmap: https://modelcontextprotocol.io/development/roadmap#official-extensions

As MCP has grown, valuable patterns have emerged for specific industries and use cases. Rather than leaving everyone to reinvent the wheel, we’re officially recognizing and documenting the most popular protocol extensions.

If we do bring this through a SEP, it will be bounded by the main MCP specification. If a SEP is the right avenue for this, then I encourage the MCP maintainers to revisit the SEP Guidelines as they clearly state a SEP is for the protocol (maybe we need an "official extension support proposal" avenue?)

I missed this https://github.com/modelcontextprotocol/ext-apps 🤦🏼 - this getting a SEP in modelcontextprotocol/modelcontextprotocol is confusing: we should revisit how these get proposed and evaluated

2) Spec bloat

One of my main worries with bringing this into the main spec is that we continue to over complicate an already bloated and bifurcated specification: I know of no other MCP servers that implement extensions and encouraging official support for this will make server implementors lives harder (vs. encouraging this as a best practice). I would point to the following discussions on how fractured the community is and the difficulty server builders / maintainers have had over the last year:

• stateless vs. stateful: SEP-1442: Make MCP Stateless (by default) #1442
• HTTP streamable: [RFC] Replace HTTP+SSE with new "Streamable HTTP" transport #206
• Various authorization discussions, now removing DCR as a "must" in favor of client metadata URLs: SEP-991: Enable URL-based Client Registration using OAuth Client ID Metadata Documents #991

3) JSON RPC _meta for non-llm context window content for/from tools

My main criticism of this SEP and OpenAI's Apps SDK, is that it uses the free _meta object field in the JSON RPC requests and responses for defining critical UI/App/Implementation layer logic that is not intended for the LLM. This, to me, smells like we're trying to fit a round peg through a square hole: MCP was originally designed as a relatively simple protocol for lite-weight agentic "discovery" of tools and resources to populate the context window with the necessary tool schemas, tool results, resource data, etc.

If the metadata is intended for the tool, it should be in the tool request. If the tool is providing specific implementation details, it should be in the tool response. Therefore, why not hoist metadata into the tool specification and codify that it is specifically intended for non-LLM context from the tool call/result?

export interface CallToolRequest extends Request {
  method: "tools/call";
  params: {
    name: string;
    arguments?: { [key: string]: unknown };
    metadata?: { [key: string]: unknown };
  };
}

export interface CallToolResult extends Result {
  content: ContentBlock[];
  structuredContent?: { [key: string]: unknown };
  metadata?: { [key: string]: unknown };
  isError?: boolean;
}

I know this would have additional benefits outside of this extension proposal but loops me back to question 1 and 2 since it would require core spec changes.

4) Where is the room for community discourse?

Dropping a blog post in conjunction with OpenAI the day this SEP is posted / accepted feels like it's a done deal (while some of the discourse I've read is generally negative / confused: https://news.ycombinator.com/item?id=46020502). As someone who works at a very small vendor providing MCP capabilities, I often feel very out of the loop on these sorts of big decisions: I'm not a fan of Discord since there is just sooo much going on in there and it seems these big decisions just come down from the mount without community feedback.

Regarding ui/message and

Host SHOULD add the message to the conversation thread, preserving the specified role.

To me this seems like something that SHOULD require a user approval. Giving the server the ability to inject arbitrary messages into the conversation without user approval seems like a problematic pattern. I know there is an increased reliance on trusting the server, but there may also be non-malicious cases where the user simply does not want the inject message for whatever reason.

This is exciting to see! I see that as with current MCP-UI and Apps SDK specs, this covers allowing UI to request tool calls and rerender in a way that keeps the agent in the loop. But does this proposal intentionally not address mechanisms to close the loop in the other direction, to flow related tool call data from subsequent conversational turns back into an already rendered widget? Or is the ability to read (and subscribe to?) resources directly from within a widget intended for this purpose?

Suppose I have a getItemDetails tool that renders a Book widget, and then in a subsequent turn a user utterance triggers a setItemStatus tool which mutates a status field. How should the change be communicated to the widget so it can rerender?

@adamesque Great use case! Currently, the SEP doesn't explicitly address that flow, but it does support patterns that enable it. For example -

• A Host may choose to update an existing Guest UI with new tool input/output rather than re-render it based on arbitrary conditions (e.g., matching tool + display mode). This part may need more structure (though I can see cases where hosts would want to handle it differently). The tool's inputs/outputs can mirror the updated state either by contacting the MCP server (e.g., by calling a compatible tool that now includes the updated data) or locally (e.g., by having the agent append the new data to the existing data).
• Guest UIs can query their backend for external updates (e.g., via tool call, resource read, or directly given CSP config)

It's likely a common use case that requires clarification and guidance. However, I'm not sure that the MVP should enforce specific behavior at this point. We can definitely discuss it.

Fantastic work on this PR.. really sharp update.

Introducing this resource declarations and a bi-directional UI communication model feels like a big step toward unlocking richer and more interactive MCP clients.

One question: how do you envision capability negotiation evolving for UI-enabled resources once multiple client types adopt this pattern?

I'm curiosa whether you see a standardized handshake emerging or if it stays client-specific for now.

@adriannoes Host<>UI capability negotiation is implemented in the SDK and mentioned in the spec as part of the ui/initialization handshake (see hostCapabilities), but I now see that the internal structure is omitted. Thanks for catching it! I'll update it tomorrow.

We'd love to hear your feedback! I'll note that we need to review the internal structure and ensure it includes the fields we need for the MVP.

Regarding ui/message and

Host SHOULD add the message to the conversation thread, preserving the specified role.

To me this seems like something that SHOULD require a user approval. Giving the server the ability to inject arbitrary messages into the conversation without user approval seems like a problematic pattern. I know there is an increased reliance on trusting the server, but there may also be non-malicious cases where the user simply does not want the inject message for whatever reason.

@PederHP It came up, and it's definitely worth further discussion. I think it warrants a thread in #ui-cwg.

@idosal I noticed in the proposal the use of the media type text/html+mcp. I would like to suggest an alternative, but before I do I want to explain why the proposed name is not a good choice.

Media Type suffixes (+json, etc) are intended to communicate an underlying format that the new media type is based on. e.g. image/svg+xml indicates that content can be processed as xml.
+mcp is not itself a format with any kind of syntax and semantics. It is a protocol. I also don't think the intent here is to suggest that the text/html is something other than HTML text. By definition, text/html+mcp isn't text/html, it is something else.

If in the future there was a decision to try and register this media type, it is highly unlikely that the registration would be allowed. I say this as one of IANA's media type reviewers.

However, I think I have a proposal that would address your needs and only slightly bend the rules.

This specification https://datatracker.ietf.org/doc/html/rfc6906#section-3.1 (which is just Informational so doesn't carry any IETF approval) proposes the use of the profile parameter as way of layering additional semantics/constraints onto an existing media type.

My suggestion is to use this:

text/html;profile=mcp

Media type parameters are a commonly used construct. HTML technically only allows the charset parameter, but with some creative license, adding the profile parameter is not likely to cause any problems.

From rfc6909,

In this case, a profile is the appropriate mechanism to
signal that the original semantics and processing model of the media
type still apply, but that an additional processing model can be used
to extract additional semantics.

This is ideal because it allows the content to still be treated like text/html but you have the clear indicator that the HTML is intended to be processed using MCP semantics.

Should the profile maybe be mcp-app and not just mcp? It's more specific.

Agent-Driven UI Navigation

Question: Would it make sense to document "UI control" patterns alongside MCP Apps? Many complex applications (network visualization, CAD tools, enterprise dashboards, ...) might benefit from agent-guided navigation beyond embedded widgets. I believe the two patterns are complementary.

Background:
We have built an MCP server that controls a network visualization application via WebSocket bridge. Key difference from MCP Apps:

• MCP Apps: Embed tool result widgets in chat (charts, forms, interactive outputs)
• Our approach: Remote control of existing full-featured applications/UI (navigation, filtering, context preservation)

Potential synergy:

• MCP Apps widget displays summary (in our case e.g. "5 critical network devices found")
• User clicks device in widget
• Widget uses ui/open-link with deep-link URL including preserved context
• Full application opens at exact view (device highlighted on topology map, current network/snapshot maintained)

This combines MCP Apps' inline interactivity with full application depth. Widgets act as gateways to rich, stateful exploration.

@glen-84 I don't have much visibility into what the range of values could be for the profile. I think mcp-app is fine too.

Thanks for the thoughtful feedback, @darrelmiller! Really appreciate the insight, especially given your experience with IANA.

I agree that text/html+mcp isn't semantically correct - we chose it pragmatically since the MIME type serves as an identifier to trigger the MCP Apps protocol, also it's simple and easy to remember.

The profile parameter is interesting, but adds parsing complexity since we'd need to normalize all valid permutations (text/html;profile=mcp, text/html; profile=mcp, text/html;profile="mcp", text/html ; profile=mcp, etc.) for what's essentially a lookup key.

Does that tradeoff make sense given the use case, or do you think the profile approach is still worth it?

It would be very useful to have a way to push context to the host application without necessarily triggering a user message. Something like ui/notifications/context-update that the host accumulates and injects as system context or a specially-marked message when the user next interacts.

Consider an MCP App that tracks some activity, like a build/release dashboard. We want the app to be able to push user interactions (like when the user triggers a new build or deployment via the UI) or when state changes (a deployment changed from in-progress to done). Doing this with ui/message gets very spammy and also requires careful prompt engineering so the model doesn't get confused and thinks the state update was written by the user. And we might not want to trigger a new inference loop for performance / cost reasons. Even if the application has an approval flow, I think it might feel intrusive and annoying to users if Apps trigger conversational turns regularly - or even at all.

By adding a sort of context buffer for the server / ui to push to we leave it up to the host how to handle these concerns, which I think is a good pattern, and allows this extension to be useful in a variety of contexts from autonomous agents to conversational AI on a variety of device form factors.

I'll open a thread on Discord for this as well.

@antonpk1 I am contractually bound to say you should not use a media type that is not registered and is structurally invalid. :-)

However, I do understand your concern over adding unnecessary complexity. There are two mitigations:

One is that there are lots of parsing libraries that do make some of that normalization go away. Especially now that Structured Fields are a thing. https://www.rfc-editor.org/rfc/rfc9651.html

The other is that you are free to mandate that people use the exact string text/html;profile=mcp. It is a few more characters but it would be functionally equivalent to text/html+mcp as a lookup value and compliant with media type syntax.

You do what you think is right for your community, but I will say that from experience, complying with existing standards does generally provide long term benefits, especially when the cost to do so is low.

It's likely a common use case that requires clarification and guidance. However, I'm not sure that the MVP should enforce specific behavior at this point. We can definitely discuss it.

@idosal I think it's worth a discussion — in my mind, without explicitly addressing this, we're not able to "close the agentic loop" for UI, where agents that render UI can not only see the information presented but collaborate on / assist with it. We've seen the need for more formal patterns around this at Indeed.

A Host may choose to update an existing Guest UI with new tool input/output rather than re-render it based on arbitrary conditions (e.g., matching tool + display mode). This part may need more structure (though I can see cases where hosts would want to handle it differently). The tool's inputs/outputs can mirror the updated state either by contacting the MCP server (e.g., by calling a compatible tool that now includes the updated data) or locally (e.g., by having the agent append the new data to the existing data).

Agree that more structure would be helpful b/c as currently written I don't believe this spec is clear enough around subsequent host-initiated update mechanisms — if it's permissible for the host to supply tool-result updates not- requested by the UI during the interactive phase, it would be good to include it there. It's possible some sort of widget or resource key should be returned in tool result meta if tool call data is intended to be merged into an existing widget.

Guest UIs can query their backend for external updates (e.g., via tool call, resource read, or directly given CSP config)

I think unless the intent is to poll (or subscribe), the spec doesn't describe the Host -> Guest events that should trigger these updates to ensure the UI stays in sync with model data as conversation-initiated tool calls occur. Generally I would prefer other mechanisms than a "please refetch" message.

One other piece that has come up in internal discussions at Indeed is that this spec doesn't provide a mechanism similar to Apps SDK widget state. Without this, it's unclear how a guest UI can communicate:

• ephemeral things like selection state in a way the model can interpret (user selects an item and then utters "tell me more about this" h/t @mihalik)
• which data beyond the initial tool call result the host should supply if the underlying view/page is reloaded in order to restore the guest UI

The first could probably be achieved via a tool call and might only need a recommendation, but the second seems fairly important since the spec does provide for interactive phase UI-initiated tool calls that can result in UI updates. Currently a widget would have to wait for both initialization and at a minimum ui/tool-input to then make a request to its own backend to get a last-saved state snapshot (if one exists).

Specifying such a backend is well outside the scope of a spec like this but feels some part should discuss the reload flow. Otherwise I think it's likely unsophisticated implementors will build out-of-the-box broken experiences.

Finally, the spec includes displayMode in the HostContext interface but doesn't define a guest -> host message to request a different displayMode. Is that an intentional omission?

Thanks!

@idosal @liady - thoughts on closing this, given the recent progress? @pja-ant is tracking a more generic extension definition in #2133.

@idosal @liady - thoughts on closing this, given the recent progress? @pja-ant is tracking a more generic extension definition in #2133.

I think it'd be valuable to merge this to maintain the context gathered here. It's also the PR everyone links to, so marking it as "Closed" might cause confusion.

Regarding the change itself, the idea was to add MCP Apps to the website as described in SEP-1724, but I can easily change it to whatever makes sense now.

MCP servers provide gated access to a potentially encapsulated dataset. The encapsulation here means that the user might not have any obvious other ways to interact with it.

When a human is using an AI assistant, it can be useful to provide a way to visualize or interact with that data. This UI is not linked to any single tool call but is associated with the MCP server as a whole and the dataset it represents.

As an example, I have a file server that exposes all the usual file-handling tools to an MCP agent. These tools work as normal, and the LLM can interact with them as expected.

I want to provide the user with an interactive file browser that reuses a combination of the existing MCP tools into a more human-friendly experience.

I suggest we consider categorizing a UI resource as a standalone entry point, an application on its own, which is not tied to a particular tool. For example:

{
  "uri": "ui://application/file-browser",
  "type": "application",
  "mime": "text/html+mcp"
}

Because it is entirely optional and only aides a human user, it can be safely ignored by tools that do not support these UIs or are fully automated anyway.