`content` field in tool results is not forwarded to the model when widget is rendered

[evanfen-c3]

Summary

When a tool returns both content and structuredContent with a widget (openai/outputTemplate), the content field is not forwarded to the model. Only structuredContent is passed (as a raw JSON code block), causing the model to miss any info included in content.

Expected Behavior

Per the MCP server documentation:

content – optional narration (Markdown or plaintext) for the model's response.

The widget reads those payloads through window.openai.toolOutput and window.openai.toolResponseMetadata, while the model only sees structuredContent/content.

The model should receive both structuredContent and content, allowing developers to provide a short narration text (e.g., "Found 14 products") that guides the model's response.

Actual Behavior

When a widget renders:

1. structuredContent is passed to the model as a content_type: "code" block with language: "json"
2. content is not present in the model's context
3. _meta is correctly forwarded to tool_response_metadata
4. A hidden system message is added: "The tool included embedded UI which has been displayed to the user"

The model then sees the full raw JSON from structuredContent and attempts to summarize it, echoing data (titles, prices, URLs, descriptions) that is already displayed in the widget UI.

Reproduction

MCP Server returns:
return {
content: [{ type: "text", text: "Found 14 products for "jackets"." }],
structuredContent: { products: [...], searches: [...], brand: {...} },
_meta: { apiBaseUrl: "...", subject: null },
};Verified via MCP Inspector:

• "Unstructured Content" shows: "Found 14 products for "jackets"."
• This confirms the server IS sending content

Captured ChatGPT SSE stream (/backend-api/f/conversation):

• Tool response message has content.content_type: "code" with content.text containing only structuredContent fields
• No trace of the content array text
• _meta appears in metadata.chatgpt_sdk.tool_response_metadata (proving MCP response is received)

Impact

• Model loses the content field, which can have important information

Environment

• @modelcontextprotocol/sdk: 1.12.1
• Transport: StreamableHTTPServerTransport
• Tool has openai/outputTemplate set (widget renders)

Questions

1. Is this intentional behavior when a widget is rendered?
2. If so, the documentation should clarify that content is ignored when openai/outputTemplate is set
3. If not, can this be fixed so content reaches the model alongside structuredContent?

[sjkoo1989-hanwha]

Similar Issue: #136

[victorpoluceno]

I see a similar problem. In my case, it only happens in 5.2 thinking mode. Results from the first tool call appear to be hidden from the model, prompting a second call to view the results. I also noticed that this is flaky; sometimes it works, sometimes it does not.

[hadarge]

A related observation from an MCP Apps (@modelcontextprotocol/ext-apps) client, in case it helps localise this — it may be the same root cause seen from a different consumer.

Observed 2026-08-01 on chatgpt.com (web).

This issue is about content not reaching the model when a widget is rendered. We see content also failing to reach the widget, but only on rehydration:

• Live tool call — the widget receives the full result, content intact. Fine.
• After a page refresh / reopening the conversation — the replayed result still has a content array with a text block, but that block parses to an empty object ({}). structuredContent is present and likewise empty. No _meta on the replayed result.

So content is not merely un-forwarded to the model — on the rehydration path it appears to be emptied in the stored result itself, which is what the widget then receives.

If the widget-rendering path strips content in one place, that could plausibly explain both symptoms: the model not seeing it live, and the widget not seeing it on replay.

Cross-referencing #195, which tracks the rehydration symptom. Reproduced on two unrelated connectors with different widgets; the same connectors behave correctly in another MCP Apps host.