Normalising renderData payload

[yannj-fr]

To ensure consistency and maximize compatibility across implementations, I propose a standardized structure for the renderData object — so that no one encounters unexpected issues.

At the moment, most implementations follow the example from the client SDK (https://mcpui.dev/guide/client/resource-renderer) and only handle theme information.

I suggest defining a structured payload that clients must implement.

The data would be organized into three main objects:
• mcp — data exchanged with the MCP server
• host — information provided by the host to the iframe
• iframe — details specific to the rendering iframe

The mcp payload would include:
• toolInput — the object sent in the MCP call
• toolOutput — the response object returned by the tool call (including text and structuredContent)
• toolName — the name of the invoked tool

The host payload would include:
• theme — the interface theme
• user-agent — the host application’s user agent
• model — the model used for the MCP call

The iframe payload would include:
• size — the effective size of the iframe (height, width)
• engine — the rendering engine used for the UI (e.g., mcp-ui/uiresourcerenderer)
• display_mode — the display mode of the iframe (e.g. fullscreen, inline...)

[infoxicator]

Yeah I think this is a good idea for organisation purposes but how do we implement it without making a breaking change?

I need to add toolInput output name and metadata for the chatGTP sdk support

[yannj-fr]

Actually no one did really implement rendered data (nor goose, librechat or nanobot) so I believe this is the right moment

[infoxicator]

I did implement iframeRenderData and I think @kentcdodds also relies on it for some implementations, We will probably have to keep supporting it in a backward compatible way while adding the new object

[yannj-fr]

Well then let just define reserved keys, state the behavior and let other patterns be free

[infoxicator]

I like this idea, working on a PR and let's. discuss it to see how it looks. Currently I don't like the fact that I have to pass all of this stuff to htmlRenderProps:

htmlProps={{
                style: {
                  minHeight: '0px',
                  height: '400px',
                },
                autoResizeIframe: { height: true, width: false },
                proxy: pm.config.get('__WP_MCP_UI_PROXY_URL__'),
                iframeRenderData: selectedEvent.payload.data?.structuredContent,
                toolInput: {},
                toolName: selectedEvent?.payload?.toolName,
                toolResponseMetadata: selectedEvent?.payload?.data?._meta,
              }}

https://github.com/infoxicator/mcp-ui/blob/feature/skybridge-client/sdks/typescript/client/src/components/HTMLResourceRenderer.tsx#L13

[liady]

@infoxicator I agree, perhaps we should at least separate data flow props and UI specific props.
btw as for backwards compatibility - if we're making a major change we should also consider renaming it, I think HTML props is not a good name anymore

[infoxicator]

@idosal @liady @yannj-fr this is what it looks like let me know thoughts infoxicator#2

[yannj-fr]

Obselete discussion, cf
https://github.com/modelcontextprotocol/ext-apps/

[idosal]

Thanks @yannj-fr!

These are now addressed in SEP-1865:

• The Host sends its context to the UI when the UI is ready and whenever it changes, similar to the pattern in MCP-UI and MCP.
• The Host sends the tool inputs result to the UI, similar to the pattern in AppsSDK.
  • Inputs: ui/notifications/tool-input (complete result) and ui/notifications/tool-input (streaming) after the UI is ready.
  • Results: ui/notifications/tool-result (complete result) after the Tool call returns.
    See the full lifecycle for context.