FDC3, MCP-UI, AG-UI, WebMCP, OpenAI Apps SDK and the intersection of AI and UI

[novavi]

The rise of Agentic AI workflows seem poised to disrupt the way frontend applications are delivered. In particular, many organizations are now starting to look at how MCP-UI and similar approaches can be used to allow chat-based AI workflows to break out of primarily text-based responses and raise the bar on user experience.

I believe it is now incumbent upon us to consider and discuss what this means for the FDC3 Standard. Looking at FDC3 and MCP-UI, the following observations can be made:

• MCP-UI can be used to surface pre-built apps via external urls, and therefore it can support cross-organization workflows (notwithstanding AuthN/AuthZ challenges).
• FDC3 and MCP-UI are complementary.
• Container-agnostic apps can be made to support both FDC3 and MCP-UI.
• There are interesting parallels between the use of MCP-UI with pre-built embedded UIs and the use of FDC3 DA's fdc3.open and fdc3.raiseIntent methods.
• There are also parallels between (a) MCP servers and MCP-UI resources; and (b) data/transactional APIs and frontend components.
  • When selling data/transactional APIs to their customers, companies can also offer FDC3-enabled apps as another option to those customers.
  • Similarly, if companies offer their data/tools via MCP servers to customers, companies could potentially also offer the same data/tools in a richer, visual, interactive form via MCP-UI or similar.
• MCP-UI can also be used to serve dynamically-generated HTML (via the raw HTML option) and to be clear there’s far less of an overlap with FDC3 in those non-deterministic scenarios.
  • The use cases and workflows that FDC3 has been used to solve to date generally need to be deterministic.
• MCP-UI's cross-frame comms mechanism uses a simple postMessage approach.
  • Whilst this makes it straightforward to implement, I believe that for both security and DevEx reasons MCP-UI would benefit from moving towards a standard API that uses a similar async/await pattern and MessageChannel implementation to the one used in FDC3 v2.2's getAgent flow.
  • This is because, for cross-organization scenarios, although an embedded UI must trust the host (chat UI) app, it might not be willing to trust third-party scripts that may be running in the host app window.
  • The key point here is that those third-party scripts could listen in to messages that were sent from embedded UI iframe to the (parent) host app window if a simple postMessage approach was used.

What's interesting to me is how the FDC3 Standard now responds to the rise of Agentic AI workflows:

• Some vendors have already built proprietary integrations between FDC3 implementations and MCP tools.
  • These types of integrations have initially tended to focus on native/installed platforms rather than vanilla web browsers platforms.
  • This innovation is important because (a) standards development without real-world use cases makes little sense; and (b) standards should not stifle innovation.
• If there is no movement with the FDC3 Standard itself in this emerging area though, does this risk:
  • a proliferation of proprietary patterns?
  • complexity for app vendors having to support multiple ways of combining several complementary technologies (if they want to be platform agnostic)?
  • a weakening of FDC3's spirit of openness in the medium- to long-term?
• How does FDC3 continue to evolve at a strong enough pace to stay with the times and remain relevant when adjacent technologies and standards are evolving faster?

It should be borne in mind that advancements in the MCP space (and the AI space more generally) are progressing at a breakneck pace, not least because of the sheer amount of money being thrown at everything AI-related, and the fact that AI solves problems across all industries. Whereas FDC3 has of course been aimed squarely at the financial services sector because it lives within FINOS - even though theoretically it could be used to solve interop problems across all industries. This limits its mindshare and also means it evolves at a slower pace than other standards.

I'm very interested to hear thoughts about this from others in the FDC3 community. As I said, I think this important topic warrants further discussion - whether that's in the Standard Working Group, or even in a discussion group dedicated to this subject.

I have published an article as a way of organizing my initial thoughts on MCP-UI:

Deep Dive into MCP-UI: The Intersection of AI and UI

In that article, I also touch on on the complementary nature of MCP-UI and FDC3. There are of course a growing number of articles from elsewhere on MCP-UI, and I've linked to many of them at the bottom of that article.

[novavi]

I am of course interested in everyone's thoughts, but @kriswest @robmoffat especially interested in yours :)

[novavi]

Not many takers yet then!

I should add that MCP-UI is not the only new protocol to emerge that is likely to disrupt the UI space in general - with consequential impact on FDC3.

AG-UI

AG-UI - which standardizes from comms between chat frontends and AI agents - is largely complementary to MCP-UI. However, there’s appears to be a small amount of overlap for UI integration because AG-UI also supports the interesting concept of Frontend-Defined Tools.

It is possible that companies already using FDC3 might consider using AG-UI Frontend-Defined Tools to invoke FDC3 API methods in their new chat-based AI workflows. In this scenario, certain FDC3 issues could potentially become important. Two issues that spring to mind are:

• the proposal to allow fdc3.open / fdc3.raiseIntent to support hints or callback handlers. This is to allow apps to be opened in new iframes within the same window (as opposed to simply spawning secondary windows). Clearly one would expect embedded UIs in chat-based AI workflows to be rendered in the main window, since surfacing context inline and avoiding context switching is one objective.
• the FDC3 Sub-agents proposal. to allow apps to be hosted in the same window/DOM, allowing greater hosting optionality in addition to the existing iframe / secondary window support. Note that for cross-vendor AI/UI integration and for single-vendor AI with generative UI, iframes will always be required for security reasons (just like in classic FDC3 workflows). However, for single-vendor AI with pre-built UIs, iframes are quite likely more of a hindrance than a preference (just like when wanting to use FDC3 in pre-existing vanilla web-based platforms / micro-frontend containers).

However, it should be borne in mind that companies outside the financial services sector using AG-UI Frontend-Defined Tools would of course look for other (non-FDC3) solutions to standardize tool definitions. Hence it seems likely that before long those other patterns / technologies will also be on the table for potential adoption by financial services companies.

WebMCP

WebMCP allows app developers to expose their web app functionality as tools, allowing invocation by AI agents. This is effectively means web apps can act as MCP servers implementing tools on the client-side instead of in the backend, and makes interaction between AI agents and web apps more intentional. Some details on WebMCP can be seen here:

• How WebMCP Lets Developers Control AI Agents With JavaScript
• AI agents and the web - A proposal to keep developers in the loop
• WebMCP

As with MCP-UI and AG-UI, the prospect of WebMCP is also very likely to have implications for FDC3.

Although I originally opened this FDC3 issue specifically to discuss the impact of MCP-UI, it would be instructive to consider the much wider issue of all new related / overlapping standards and technologies, and how FDC3 fits in / evolves / responds to the rise of AI workflows more broadly. Hence I’m going to update the title of the issue now :)

[novavi]

Update:

OpenAI Apps SDK

Relevant to this discussion, there’s now yet another solution in the AI/UI integration space in the form of OpenAI Apps SDK. Here’s a post I put together outlining some of the implications of the OpenAI announcement:

The rapidly evolving AI / UI integration landscape is now really heating up

And the links below are worth following to learn more.

Videos:

• Kent C. Dodds - OpenAI’s Apps SDK Bring Jarvis Closer. All Built on MCP!
• OpenAI - Apps in ChatGPT

Articles and docs:

• Ars Technica - OpenAI wants to make ChatGPT into a universal app frontend
• OpenAI - Apps SDK
• OpenAI - Build a custom UX

[robmoffat]

I should be able to devote some proper headspace to this after OSFF 🙄

[novavi]

I should be able to devote some proper headspace to this after OSFF 🙄

Thanks @robmoffat - let’s catch up after OSFF then 👍

[robmoffat]

Discussing with someone right now - the idea of supplying context back to the LLM via FDC3 contexts is a good one. At the moment, MCP doesn't support async comms back.

[novavi]

Discussing with someone right now - the idea of supplying context back to the LLM via FDC3 contexts is a good one.

Thanks @robmoffat - very interesting. I can certainly see scenarios where an FDC3 context could be used in such a workflow. Potentially also scenarios with UI components crafted so they can be integrated in both existing FDC3-based dashboards and also in new (separate) AI workflows. And even blended dashboards which also have a chat sidebar to offer an additional mechanism for controlling them.

At the moment, MCP doesn't support async comms back.

Yes, you're absolutely right. At the moment with MCP-UI, you can make embedded UIs raise events to the (parent) chat UI hosting them, triggering a fresh prompt to the agent, which in turn allows the agent to then decide what to do next. The current limitation of MCP-UI in this area are that comms are unidirectional. Hence:

1. It means a fresh prompt
2. The agent then serves a fresh embedded UI instance (existing embedded UI instance cannot receive anything from the agent)

This is significantly different to how FDC3 works, where an app instance remains alive and can listen for subsequent intents / contexts.

Plenty to discuss here!

[novavi]

See also a bit of discussion on the unidirectional nature of the MCP-UI comms on this comment on the modelcontextprotocol-community UI RFC:

modelcontextprotocol-community/working-groups#35 (comment)

[kziemski]

https://meet.modelcontextprotocol.io/2025/10/financial-services-interest-group-fsig-bi-weekly-meeting-Moab1mPlM6Yu

[kziemski]

fyi i'm also introducing something that can reverse the model.
its going to be slog to get it into the spec.
i will probably do it as a transport.

[kziemski]

Discussing with someone right now - the idea of supplying context back to the LLM via FDC3 contexts is a good one. At the moment, MCP doesn't support async comms back.

sampling would be the closest

[robmoffat]

fyi i'm also introducing something that can reverse the model. its going to be slog to get it into the spec. i will probably do it as a transport.

https://docs.mcp-b.ai/advanced

so... you need a chrome extension? I don't know what a TabClientTransport is

[kziemski]

sry I didn't separate my statement about what i was building from the link to the competing solution to the WebMCP proposal listed above by Derek.