suggesting a new primitive for mcp-ui: Bidirectional UI ↔ Agent Events

[Idan-Levin]

Im proposing a new primitive for agent-UI coordination: event-driven, bidirectional communication between the UI and the agent runtime.

The current implementation, MCP-UI only allows UI → agent communication. Once the UI sends an event, the agent can respond only by re-rendering a new HtmlResourceBlock.

That is fine for static flows but painful for applications that need more input from the agent side during runtime. For example identity check, or tokens fetches.

Supported use cases can be using an agent wallet that fetches a payment token, or oAuth credentials (without handling the logic within the iframe re-rendering and opening new windows).

@idosal @liady would love to hear your thoughts.

[liady]

Thanks @Idan-Levin ! Yes, this is something we were thinking about as well. mcp-ui, as you mentioned, supports messages being sent to the agent, and the agents decides what to do next.
We were thinking about the other direction as well. (messages that go into the iframe). However we don't want to eventually create two parallel user interaction streams - one that exists in the conversation level, and one that exists in the agent-iframe communication level. The latter is also not persisted and is not saved in the context of the conversation.
I agree that for transient cases (like passing a token) this can be relevant. We need to define whether we want:

1. The UI asks for information, the agent returns it (similar to elicitation)
2. The UI sends messages out, the agent can send unrelated messages in
3. There's a channel between the UI and the agent where a parallel "conversation" happens.

As said - each has its pros and cons. We would love to hear your use case to come up with a solution.
Thanks again for using and proposing!

[Idan-Levin]

Thanks for the quick reply. Let me clarify the intent and the scope:

Why I’m asking for a response channel:

• Use case: UI needs a one‑off datum from the agent (payment network token, OAuth access token, session identity) before it can compose the next conversation‑level tool call.
• Pain today: We fake it by opening a new window or forcing a re‑render. Latency is high and the UX is problematic. It will also create UX fragmentation as agents embed more MCP‑UIs, each spins up its own auth or wallet pop‑up. That creates inconsistent micro‑flows and multiple sources of truth for identity/payment.
• Single source of truth – keeping sensitive state (tokens, identities) in the agent runtime and letting the UI request it on demand gives us one authoritative place for security and compliance, instead of duplicating logic in every iframe.

It is not:

• second human conversation
• place to run business logic within the iframe
• something that must be persisted as user‑visible history.

Think of it as an ephemeral RPC inside the same interaction, similar to a browser asking the OS for a file handle.

Proposed model (aligns with your option 1)

1. UI emits mcp-ui-event with requestId.
2. Agent runtime fetches the sensitive data.
3. Agent posts back a single mcp-ui-response with the same requestId.
4. UI immediately uses the payload to craft the real MCP tool call, which is persisted in the conversation.

No other messages flow on this channel unless the UI explicitly asks again. That keeps the stream deterministic and avoids the “two conversations” problem.

Agent may log a conversation message like agent.wallet.token_fetched if the data is worth surfacing later (for the context issue).

Curious to hear your thoughts. Happy to iterate.