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.

[kziemski]

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 i would list out this project separately to WebMCP but in a similar vein given the project started as a fork to the original idea, its mentioned in the articles
At the moment they are relying on their chrome extension to facilitate the bridge but after speaking with them i think they're pursuing alternatives for a fallback. it is mentioned in the newstack article
but buried further down with some weird framing about fake tension on competing projects

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

[nileshtrivedi]

Some positive news from Apps SDK discord :

[kriswest]

The uni-directional.natute of the communication is interesting. I understand why they'd want to avoid creating a second channel of communication with the Agent, which is after all built and trained to respond to language... To do something else I assume you'd need a transformer architecture ready to receive other input types? Or to convert responses into language to feed back. However, subsequent responses would be then naturally be new UI, rather than updating or interacting with the one previously returned? Perhaps generating new UIs that can issue interop messages to interact with a UI from a previous response is a way to handle that?

I take your point about subagent and multiple.UIs within a single window/ai chat @novavi. It is relevant to this use case.

[robmoffat]

Remind me - is this on the agenda for the meeting this afternoon?

As @novavi points out, there is a huge amount going on in this space - and lots of churn - so I think the thing I am interested in is the "desktop experience": how does any of this impact the idea of a bunch of disparate apps on the user's desktop, all relaying information to that user? i.e. the core use-case of FDC3. Can we "do better" at solving the core use case of FDC3 by incorporating / integrating any of this stuff? Anyway, that's just me and what I'm thinking about wrt to this project right now.

[novavi]

@robmoffat Yes it was due to be on the agenda for the next Use Cases and Workflows meeting.

@mistryvinay Is the next meeting in fact today, I couldn't seen an Issue raised for it?

[mistryvinay]

Just raised now #1698

…

On Thu, 6 Nov 2025 at 09:52, Derek Novavi ***@***.***> wrote: *novavi* left a comment (finos/FDC3#1669) <https://urldefense.com/v3/__https://github.com/finos/FDC3/issues/1669*issuecomment-3496248454__;Iw!!JrOaqOcUag!IeGmDoMf3HgBaOQcmlfaQ_-m65B0CpIIe1pRNBJzgTvr1h_YYPNgD6Ju96F1Vb1h1HgSUvGo_iDQFTOvNo-3fzV_$> @robmoffat <https://urldefense.com/v3/__https://github.com/robmoffat__;!!JrOaqOcUag!IeGmDoMf3HgBaOQcmlfaQ_-m65B0CpIIe1pRNBJzgTvr1h_YYPNgD6Ju96F1Vb1h1HgSUvGo_iDQFTOvNgEZP89A$> Yes it was due to be on the agenda for the next Use Cases and Workflows meeting. @mistryvinay <https://urldefense.com/v3/__https://github.com/mistryvinay__;!!JrOaqOcUag!IeGmDoMf3HgBaOQcmlfaQ_-m65B0CpIIe1pRNBJzgTvr1h_YYPNgD6Ju96F1Vb1h1HgSUvGo_iDQFTOvNg_9P_dQ$> Is the next meeting in fact today, I couldn't seen an Issue raised for it? — Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https://github.com/finos/FDC3/issues/1669*issuecomment-3496248454__;Iw!!JrOaqOcUag!IeGmDoMf3HgBaOQcmlfaQ_-m65B0CpIIe1pRNBJzgTvr1h_YYPNgD6Ju96F1Vb1h1HgSUvGo_iDQFTOvNo-3fzV_$>, or unsubscribe <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AEJG4F2H3PZ5CDJOO7HX2ZD33MK4RAVCNFSM6AAAAACHEYV6W6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIOJWGI2DQNBVGQ__;!!JrOaqOcUag!IeGmDoMf3HgBaOQcmlfaQ_-m65B0CpIIe1pRNBJzgTvr1h_YYPNgD6Ju96F1Vb1h1HgSUvGo_iDQFTOvNjBb7eD-$> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- *Vinay Mistry* Senior Partnership Specialist *Partner Success* Symphony Communication Services UK Ltd. 12th Floor 135 Bishopsgate London EC2M 3TP symphony.com ***@***.*** phone: +44 20 3868 0040 mobile: +44 7956 528587 *See you at one of our next Symphony events* <https://symphony.com/events> Symphony <http://www.symphony.com/> is a cloud-based, secure communications & workflow platform designed to exchange high-value content, improve workplace productivity & connect users to their communities while maintaining regulatory compliance. *Download Symphony on iTunes App Store Now: *Download iOS <https://tracking.cirrusinsight.com/7311c63d-9441-43c0-a3a0-acd784543117/symphony-com-blog-item-symphony-for-iphone-is-here-finally-a-byod-solution-that-works> Download Android <https://symphony.com/download/android>

[novavi]

However, subsequent responses would be then naturally be new UI, rather than updating or interacting with the one previously returned? Perhaps generating new UIs that can issue interop messages to interact with a UI from a previous response is a way to handle that?

@kriswest Yes, that would certainly be one way to handle it within the constraints of the current architecture. Of course it would be far more elegant if there was support to target tool calls at previously-returned UIs.

But I would note that in both scenarios you'd really need a concept of instanceIds for the UIs (like we have in FDC3 apps) and these instanceIds would need to be generated and available at the agent level in order for subsequent responses to be able to use them effectively...

[novavi]

Just raised now #1698

Nice one - thanks @mistryvinay !

[kriswest]

@robmoffat one thing that I think MCP-UI (and similar frameworks for rendering UI in agent's response window) does is to create multiple UIs within that one window (which is something we don't yet support well). The question is, should they all be the AI? or should they be entities in their own right (disparate apps that can communicate with each other as well as other apps)?

You might want to pop apps out of the chat onto the desktop... I suppose one way to handle that would be for the AI to just go ahead and spawn them using raiseIntent or open (render a UI that just says its doing that and runs the API call, OR give the user a button to do it). That would go well with issuing other broadcasts or raiseIntents directly from the UI - but varies from what was intended with MCP-UI. Perhaps FDC3 can offer an entirely different way of interacting with UIs (by exposing what can be invoked and why to the AI agent and then having it do so through FDC3 rather than rendering UI components with context itself?

i also like the idea of apps being able to raise queries with the AI through intents - is that as simple as forwarding a prompt (with attached FDC3 context if useful)? Its easy enough to provide instructions (in a prompt/persistent context) for handling or generating FDC3 context objects...

[novavi]

@novavi i would list out this project separately to WebMCP but in a similar vein given the project started as a fork to the original idea, its mentioned in the articles
At the moment they are relying on their chrome extension to facilitate the bridge but after speaking with them i think they're pursuing alternatives for a fallback. it is mentioned in the newstack article
but buried further down with some weird framing about fake tension on competing projects

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

Thanks @kziemski fair point - and worth calling out and discussing / exploring.

A Chrome Extensions seem like a valid way to explore a new idea in a reference implementation, but impractical for adoption within large enterprises for infosec reasons. So would be interesting to know what options they're looking at for fallback.

[novavi]

Some positive news from Apps SDK discord :

Thanks @nileshtrivedi - great context

[kriswest]

@novavi

the proposal to allow fdc3.open / fdc3.raiseIntent to support hints or callback handlers. This is to allow apps to be opened within the same window (as opposed to 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 commonly a key objective.

Couldn't you just raise an intent to the AI window, allowing it render whatever it wants (has been trained to) in response to the request, which could in turn use interop (or allow the user to initiate interop) with other apps on the desktop? I.e. does it make more sense to think of the AI as platform hosting multiple UIs OR is it better to consider the AI an app in its own right (but one that could respond to many intents and can render in weird and wonderful ways)? The latter fits better with FDC3 today (but would need a few more intents and contexts maybe?) - it perhaps also fits better with the unidirectional nature of MCP-UI - the UI generated are ephemeral and not persistent entities in their own right - if you want those it could spawn them with a raised intent!

[kriswest]

P.S. I get that MCP-UI currently isolates UIs i iframes, and hence, they can work as independent apps from FDC3's perspective (we don't currently need sub agents) but we do need some form of identity for them that way. However, I'm questioning whether that brings any advantage over consider 'the AI' to be the app.

In Capital Markets use cases, I can't quite see the AI chat replacing all other UI any time soon, as it perhaps could in some other domains. So I think its a case of figuring out how FDC3 can facilitate its participation as part of a "bunch of disparate apps on the user's desktop, all relaying information to that user", as Rob put it.

[novavi]

does it make more sense to think of the AI as platform hosting multiple UIs OR is it better to consider the AI an app in its own right

@kriswest I actually think both of the above are probably valid scenarios

[novavi]

we don't currently need sub agents

@kriswest Well this is an interesting point. Both MCP-UI and OpenAI's Apps SDK are particularly well suited to cross-vendor AI / UI integration. But I think as this space evolves further, there will be lots of demand to use similar techniques on a single-vendor basis. In those scenarios, mounting UIs in iframes becomes not just unnecessary but also likely a hindrance.

I would concede those scenarios are not currently supported by MCP-UI (interestingly, I believe even if you use the RemoteDOM option where the UI content is rendered inline within the main window, MCP-UI's client library actually creates a hidden iframe as a sibling of the UI content containing some JavaScript). But other (non-MCP-UI) AI approaches such as AG-UI Frontend-Defined Tools can be used for single-vendor scenarios to avoid the iframe, and if there was to be any crossover / integration with FDC3 for these scenario, FDC3 sub-agents would then likely be quite useful.

In Capital Markets use cases, I can't quite see the AI chat replacing all other UI any time soon

Yes, I agree completely! And I do struggle when I hear people say they think all their UIs will be replaced with a chat interface :)

I see AI more as augmenting UIs. This means conversational interfaces in some scenarios. But in many other scenarios it might mean something like an r.h.s. sidebar containing a chat-based interface as an additive change to a dashboard - allowing additional ways of interacting with individual apps, with groups of apps, and with the dashboard as a whole. This is where the AI / FDC3 crossover becomes interesting. Are the apps extended to support both FDC3 and (future-state) WebMCP? And/or are there scenarios where the response to a prompt needs to be translated to an FDC3 broadcast or intent?

[kriswest]

@novavi I'm going to convert this issue to a discussion (assuming you don't object). We can then raise some concrete requests as issues to move things forward.

[novavi]

@novavi I'm going to convert this issue to a discussion (assuming you don't object). We can then raise some concrete requests as issues to move things forward.

Thanks @kriswest - makes sense. Actually, I was pleasantly surprised to see the group discussing immediately raising some concrete requests last week. And I'm sure we can use this discussion thread to debate and weigh up what additional concrete requests are needed to better enable FDC3 support new AI workflows...

[novavi]

@kriswest Related to this discussion, I put together a small embryonic library called MCP-FDC3 yesterday, to help test out new ways in which FDC3 and MCP could potentially be used together in AI workflows.

Unlike MCP-UI - which serves a fresh instance of an app in response to every user prompt - the pattern supported by MCP-FDC3 allows an MCP server tool to trigger events in existing (already-running) instances of apps in a frontend platform by automatically invoking FDC API methods.

The library is still very early and incomplete, but please see the following post / article for details of MCP-FDC3 and link to repo:

https://www.linkedin.com/posts/novavi_happy-to-share-mcp-fdc3-an-embryonic-library-activity-7394191908664737792-m3R2/

In the article I've also listed out many of the challenges I've uncovered when looking at how best to support AI / FDC3 integration (in particular, with fdc3.open and fdc3.raiseIntent). Happy to discuss further with anyone as and when...