MCP tool returning unsupported image type (SVG) causes unrecoverable session crash

Resolved 💬 3 comments Opened Feb 24, 2026 by blwfish Closed Feb 25, 2026

Description

When an MCP server tool returns ImageContent with image/svg+xml mime type, the API returns a 400 error and the session cannot recover. The error repeats on every retry, effectively killing the conversation.

API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Could not process image"},"request_id":"req_011CYTTgQKFZwccyVbCcggVo"}

This happened 4 times in a row before I figured out the cause and worked around it.

Root Cause

A KiCad MCP server tool (generate_pcb_thumbnail) was returning an ImageContent object with base64-encoded SVG data. The Claude API vision endpoint only supports PNG/JPEG/GIF/WebP, so it rejects the SVG with a 400. Claude Code doesn't handle this gracefully — it just retries the same tool call, hitting the same error repeatedly.

Expected Behavior

Claude Code should handle unsupported image types from MCP tools gracefully:

  1. Don't crash the session — catch the 400 and surface it as a tool error message, not a fatal API error
  2. Don't retry the same failing call — if the API rejects the image content, retrying won't help
  3. Ideally, validate MCP ImageContent mime types before sending to the API — reject unsupported types early with a clear error like "MCP tool returned unsupported image type: image/svg+xml"

Workaround

Changed the MCP tool to return a plain dict with the file path instead of ImageContent. The SVG file is still generated on disk; callers can read it separately if needed.

Environment

  • Claude Code (CLI)
  • macOS
  • KiCad MCP server (custom, using FastMCP + mcp.types.ImageContent)

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗