Building and customizing solutions using Microsoft 365 Copilot APIs and tools
Treat this as a Microsoft 365 Copilot federated-connector host limitation or defect and open a Microsoft support case; do not base64-decode the payload before returning it, because your current CallToolResult already has the expected single-encoded MCP image representation.
Answers
- Is this a known issue?
It is not currently documented as a known Microsoft 365 Copilot extensibility issue. The published known-issues page does not list MCP image blocks being converted to text or encoded twice ^1^. There is an open report for the same general failure mode in GitHub Copilot for Eclipse—an MCP image result reaches the model as base64 text rather than image input—but that concerns a different Copilot client and does not establish Microsoft 365 Copilot behavior ^2^. - Are image content blocks supported in federated-connector tool results?
The current custom federated-connector documentation confirms that these connectors invoke tools exposed by an MCP server, but it does not explicitly documentimageas a supported model-visible tool-result content type ^3^. Therefore, image-block support for this specific route cannot currently be confirmed from the published contract. Copilot Studio accepting the same response establishes that the server produces a usable result for that client. It does not guarantee that the Microsoft 365 Copilot federated-connector host implements the same content-type handling.
Recommended next action
Submit a Microsoft 365 support case with:
- Tenant and connector identifiers, but no credentials or image contents containing sensitive data.
- UTC timestamps for two minimal reproductions.
- The prompt and resulting Copilot response.
- The raw MCP response captured at the server boundary.
- HTTP response headers and Streamable HTTP transport details.
- A tiny synthetic PNG rather than production data.
- The comparison result from Copilot Studio.
- These byte/string checkpoints:
- PNG bytes begin
89 50 4E 47 0D 0A 1A 0A. - The server’s single-base64 value begins
iVBORw0KGgo. - Copilot-observed text begins
aVZCT1J3ME....
- PNG bytes begin
- Payload sizes before encoding, after the required MCP encoding, and as observed by the model.
- Confirmation that a text-only result from the same tool succeeds.
Ask support to confirm:
- Whether
content[].type: "image"is supported for custom federated connector tool results. - Whether the connector pipeline serializes
dataas ordinary text before constructing model input. - Whether this behavior has an incident or bug ID.
- Whether any supported capability declaration is required for multimodal tool output.
Safe interim workaround
Until Microsoft confirms support, avoid returning image base64 through this connector:
- Return a concise text description, OCR output, or extracted metadata in the model-visible
content. - Keep the binary in your source system and return a stable identifier or access-controlled reference for retrieval outside model vision.
- Limit the tool to one small result and paginate collections to avoid the observed payload expansion and timeouts.
For MCP apps with widgets—not necessarily the same custom federated-connector path—Microsoft recommends separating model-visible summaries from UI-only data: put concise information in content and widget-specific data in _meta. It also warns against excessively large content or structuredContent responses ^4^. This may provide a presentation workaround, but it does not make the image available to the model’s vision input.
Do not return raw PNG bytes in the JSON data field or pre-decode the required base64. That would make the MCP response invalid rather than compensate reliably for client-side handling.
References