claude-code - 💡(How to fix) Fix [BUG] claude.ai visualize MCP app — widget renders then tool call fails with HTTP 400 [1 comments, 2 participants]

TrudosKudos · 2026-04-24T22:25:32Z

[claude-code] Preflight Checklist - x I have searched existing issues https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abu… ## Fix / Workaround ## Workarounds ### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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 ```shell ## 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. 3. Ask Claude to call `visualize:show_widget` with: ```json { "title": "diagnostic_minimal", "loading_messages": ["Testing"], "widget_code": " Widget is alive. " } ``` → widget briefly renders in chat, then disappears as the tool call errors with 400. 4. 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)

Error Message

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.

Error Messages/Logs

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.

Code Example

## 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.

---

{"modules": ["interactive"], "platform": "desktop"}

---

{
     "title": "diagnostic_minimal",
     "loading_messages": ["Testing"],
     "widget_code": "<p style=\"color:green;font-size:24px;\">Widget is alive.</p>"
   }

Preflight Checklist

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

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?

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

Open a conversation on claude.ai (web or desktop app) with the visualize MCP app available.
Ask Claude to call visualize:read_me with:
```
{"modules": ["interactive"], "platform": "desktop"}
```
→ tool call fails with HTTP 400.

Ask Claude to call visualize:show_widget with:

{
  "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.

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:

The request reached the rendering service
The rendering service successfully processed the HTML
The widget was streamed to the client and displayed
Something in the response completion / acknowledgment stage failed
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:

read_me with only enum params — rules out malformed user payload
show_widget with minimal HTML — rules out payload-shape issues
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

#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:

Response completion handshake between the visualize MCP server and the claude.ai client
Timeout or post-render validation step rejecting successful renders
Gateway/load-balancer 400 generated after rendering completes
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)

extent analysis

TL;DR

Investigate the response completion handshake between the visualize MCP server and the claude.ai client for potential issues causing the 400 error after successful rendering.

Guidance

Review the MCP Apps stack changes deployed on or shortly before 2026-04-23, especially those related to the Apr 23 02:09 UTC incident, to identify potential causes of the regression.
Inspect the gateway/load-balancer configuration for any rules or settings that might generate a 400 error after rendering completes.
Consider implementing additional logging or monitoring to capture more detailed error information, as the current empty 400 response body lacks actionable insights.
Test the visualize MCP app with different types of content and rendering scenarios to see if the issue is specific to certain cases or if it's a more general problem.

Example

No specific code snippet can be provided without more information about the implementation details of the visualize MCP app and the claude.ai client. However, an example of how to add logging for error responses in a hypothetical API call might look like:

import logging

# ...

try:
    response = requests.post('https://claudemcpcontent.com/visualize', json=data)
    response.raise_for_status()
except requests.exceptions.HTTPError as err:
    logging.error(f'HTTP error: {err}')
    # Additional logging or error handling code here

Notes

The issue seems to be related to a regression introduced in a recent update, and the exact cause is still unclear. Further investigation and debugging are necessary to determine the root cause and develop a fix.

Recommendation

Apply a workaround, such as retrying the call or falling back to HTML artifacts for static content, until the root cause of the issue can be identified and addressed. This is because the problem appears to be related to a regression and may require changes to the MCP Apps stack or the visualize MCP app itself.

claude-code - 💡(How to fix) Fix [BUG] claude.ai visualize MCP app — widget renders then tool call fails with HTTP 400 [1 comments, 2 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Error Messages/Logs

Error Messages/Logs

Fix Action

Fix / Workaround

Workarounds

Code Example

Preflight Checklist

What's Wrong?

What's Wrong?

What Should Happen?

What Should Happen?

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

Diagnostic reasoning

Claude Model

Is this a regression?

Last Working Version

Claude Code Version

Platform

Operating System

Terminal/Shell

Additional Information

Environment

Related

Suggested triage direction

Workarounds

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

Still need to ship something?

RELATED_DISCOVERY

TRENDING