[BUG] claude.ai visualize MCP app — widget renders then tool call fails with HTTP 400

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

What's Wrong?

All calls to the visualize MCP app (show_widget and read_me tools, backed by claudemcpcontent.com) fail with HTTP 400 and an empty error body.

The distinctive failure mode: the widget visibly renders in the chat for a brief moment, then disappears as the tool call is marked errored. The rendering pipeline clearly accepts and processes the HTML — something fails at the response completion stage.

This is distinct from #34820, which reports DNS-level unreachability of claudemcpcontent.com. Here, the domain is reachable and rendering works; the failure is post-render.

What Should Happen?

What Should Happen?

• visualize:read_me returns the requested module's format reference
• visualize:show_widget renders the provided HTML inline and the tool call completes successfully

Error Messages/Logs

## Error Messages/Logs


Tool call failed: 400


No error body is returned — the 400 response is empty. The lack of any error detail is itself a bug; clients have no actionable information about the failure.

Steps to Reproduce

Steps to Reproduce

1. Open a conversation on claude.ai (web or desktop app) with the visualize MCP app available.
2. Ask Claude to call visualize:read_me with:

``json
{"modules": ["interactive"], "platform": "desktop"}
``
→ tool call fails with HTTP 400.

1. Ask Claude to call visualize:show_widget with:

``json
{
"title": "diagnostic_minimal",
"loading_messages": ["Testing"],
"widget_code": "<p style=\"color:green;font-size:24px;\">Widget is alive.</p>"
}
``
→ widget briefly renders in chat, then disappears as the tool call errors with 400.

1. Retry with styled HTML (fonts, padding, nested divs) — same render-then-fail pattern, reproduced on retry.

Key evidence from step 3: The widget visually renders with correct fonts and layout before it is torn down. This means:

1. The request reached the rendering service
2. The rendering service successfully processed the HTML
3. The widget was streamed to the client and displayed
4. Something in the response completion / acknowledgment stage failed
5. The client removed the displayed widget on 400

This narrows the bug to a post-render completion layer — not payload validation, not the rendering pipeline itself, not DNS/connectivity.

Diagnostic reasoning

Three test calls were made, all failing identically:

1. read_me with only enum params — rules out malformed user payload
2. show_widget with minimal HTML — rules out payload-shape issues
3. show_widget with styled HTML (run twice) — confirmed render-then-fail

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.119 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Environment

• Platform: claude.ai web interface + desktop app (both reproduce)
• OS: macOS (M4 Max MacBook)
• Network: claudemcpcontent.com resolves and is reachable; no ad blockers affecting it
• Tested: 2026-04-24

Related

• #34820 — claudemcpcontent.com unreachable (2026-03-16). Different failure mode (DNS-level) but same infrastructure. Still open, labeled invalid.
• Status page correlation: An MCP Apps incident on claude.ai was marked resolved at 02:09 UTC on 2026-04-23 — ~24 hours before these tests. This may be a partial regression or related failure surface not addressed by that fix. April 2026 shows a high rate of MCP/connector infrastructure incidents (Apr 9, Apr 13, Apr 23).

Suggested triage direction

Based on the render-then-fail evidence:

1. Response completion handshake between the visualize MCP server and the claude.ai client
2. Timeout or post-render validation step rejecting successful renders
3. Gateway/load-balancer 400 generated after rendering completes
4. Changes deployed on/shortly before 2026-04-23 to the MCP Apps stack, especially partial fixes from the Apr 23 02:09 UTC incident

Workarounds

• Retry the call (intermittent success plausible, unconfirmed)
• For static content, fall back to HTML artifacts (different rendering pipeline)