Clarify host behavior for rendering an MCP App view when the tool result is an error (isError: true)

[fredericbarthelet]

Summary

The spec defines how a host renders a view once a tool with a ui.resourceUri returns, but it doesn't say what a host should do when that tool call returns an error result (isError: true). Hosts are diverging, and I'd like a recommendation (ideally normative) so implementations stay consistent.

• ChatGPT unmount the view iframe (it was already mounted when the output was received)
• Claude doesn't mount the view iframe
• Goose keep the iframe mounted and proceed with rendering as usual. The isError value is not accessible from the view.

What the spec covers today

The ui/notifications/tool-result notification and the rendering flow describe the success path (result.content / structuredContent are forwarded to the view). There's ui/notifications/tool-cancelled for cancellation, but nothing addresses a completed tool call whose result has isError: true, e.g.:

{
  "content": [{ "type": "text", "text": "My custom error message returned from tool" }],
  "isError": true,
}

Questions

• When a tool result has isError: true, should the host skip rendering the view and fall back to the normal error/text presentation?
• If the view is still rendered, should the host deliver the error via ui/notifications/tool-result (with isError preserved), via a distinct signal, or not at all? If the same notification is used, how to access the isError boolean?

[harijoe]

Thanks Fred for writing this up, that's definitely a blind spot of the spec right now.

The way I see it, an error result is mostly meant for the model, not the user. Most of the time it's a missing or invalid argument, and the model can just fix it and call the tool again. That loop works fine with plain text, but if the host mounts a view in the middle of it you end up with an empty or broken widget sitting there while the model retries. Not ideal.

I think this also answers the pre-mounted case. What ChatGPT does by pre-mounting before the result arrives seems to be just a latency trick for now as it takes ages to load the widget.

One thing I'm less sure about: some views might legitimately want to handle their own errors, like a form that re-renders with the invalid field highlighted. Maybe that deserves an opt-in later (the server declares its view handles errors + isError preserved in ui/notifications/tool-result), but I'd settle the default first.