fix(core): keep unsupported MCP media out of tool attachments - #57640

Fixes #54798
Fixes #52448

Problem

MCP tool calls stored every non-text result as a tool attachment with whatever media type the server declared. A Jira attachment arriving as text/markdown or text/x-patch, or a .parquet file, ended up as a file item that no provider route can send. The next request failed before it left the client:

Anthropic Messages does not support media type text/markdown

That attachment stays in history, so every later turn in the session failed the same way.

Every other path (the read tool, webfetch, user attachments) only ever sends PNG, JPEG, GIF, WebP and PDF. The MCP tool path was the only one with no filter.

Change

MCP tool results now follow the same rule as the read tool:

for each media part in an MCP tool result:
  png, jpeg, gif, webp, pdf   -> file attachment (unchanged)
  text types (md, patch, json) -> decoded and sent as text
                                  "[Resource file:///README.md (text/markdown)]\n..."
  anything else               -> written to tool-output/, model gets
                                  "[Binary resource file:///data.parquet (application/vnd.apache.parquet, 4 bytes) saved to <path>]"

• ToolOutput.save(bytes, extension) writes to the same tool-output/ folder as truncated output, with the same tool_<id> names, so the existing 7 day cleanup removes these files too.
• MCP resource blobs now carry their uri so the note can name the resource.
• read_mcp_resource uses the same image/PDF allowlist, so image/svg+xml and other image types no longer get attached.
• isTextual moved from webfetch into Mime so both callers share it.

 McpTool execute
   mcp.callTool
-  every media part -> { type: "file", mime: <server mime> }
+  toContent(part)
+    allowlisted media -> file
+    text media        -> text
+    other media       -> ToolOutput.save -> text note

Out of scope

• Recovering automatically when a provider rejects an attachment that we do send (a corrupt PDF, for example).
• read_mcp_resource still returns non-image blobs as base64 in its structured output.
• Sessions that already have one of these attachments in history are not repaired; they still need a revert past the tool call.
• Third-party plugin tools can still return arbitrary file types.

Verification

• bun test test/mcp.test.ts (new case for decoded text and saved binaries)
• bun run test in packages/core: only the shell parity failures that also fail on clean dev
• bun run check
• The reproduction script from a tool result with a file type other than image or PDF makes every later request in the session fail #54798 (mock Anthropic endpoint, MCP tool returning a markdown blob and a PNG): both turns fail on the current release and succeed on this branch.

Added by the opencode bot (AI-generated).

Related: #55271