[BUG] Models connected via extension cannot access images returned by MCP tools

[yinhx3]

When using the extension to connect a model, image responses from MCP tools (e.g., chrome-devtools-mcp screenshots) are not visible to the model. The same MCP tool output works correctly when using Copilot's built-in model.

Steps to reproduce:

1. Configure an MCP server that returns images, for example chrome-devtools-mcp

2. In a chat, invoke the MCP tool to take a screenshot:

Use the Chrome DevTools MCP to take a screenshot of the current page.

3. Observe the model's response.

Expected behavior:

The model should be able to see and describe the screenshot content, as Copilot's built-in model does.

Actual behavior:

• With Copilot's built-in model: the model correctly describes the screenshot.
• With a model connected via the extension: the model reports that no image is visible, or asks the user to provide the image again.

Additional context:

When the same image is uploaded directly through the chat input (for example, pasted as an attachment), the Kimi K2.7 Code model recognizes and describes it correctly. This confirms the model itself is capable of vision, and the problem is specifically with how MCP tool image results are passed to the model.

[ltmoerdani]

Thanks for the detailed report @yinhx3, really helpful breakdown — especially the note that paste-from-input worked. That pinned it down to the tool-result path immediately.

Root cause was in our message serializer. When VS Code hands us a tool result from an MCP server, image bytes come through as a LanguageModelDataPart nested inside LanguageModelToolResultPart.content. Our convertMessage() only ran partToText() over those entries, which has a catch-all return "" for anything it doesn't recognize. Image fell into that catch-all, so the model literally got an empty tool message.

Pasted attachments worked because they arrive as top-level parts in message.content, where there's a separate handler that explicitly checks part.mimeType.startsWith("image/"). Tool results never hit that branch.

Fix is in #79. Summary:

• convertMessage() now walks part.content and emits a multimodal array (text + image_url parts) on the tool message when an image is present. Text-only tool results are unchanged.
• Wired through all four transports: chat-completions (native), Anthropic (tool_result.content: AnthropicContentBlock[]), Google Gemini (functionResponse.parts: [{inlineData}]).
• Responses API can't carry images in function_call_output (API limit, string only), so on that transport the image degrades to a placeholder note. Only gpt-5-codex is affected today.

One thing worth flagging: while testing with chrome-devtools-mcp I hit a separate issue where agent screenshot loops can balloon the payload to 4MB+ and the upstream returns 400 Upstream request failed. Added a 1MB per-image size cap with an actionable placeholder so the model still knows an image was returned. Not strictly part of your bug, but it'll bite anyone using MCP screenshot tools in a loop.

Should merge in the next release. If you want to test before then, the dev build from the PR branch works — let me know if you hit anything.