claude-code - 💡(How to fix) Fix [FEATURE] Microsoft 365 MCP: Add support for inline images (hostedContents) in Teams channel messages

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

The Microsoft 365 MCP integration cannot retrieve inline images (pasted screenshots) from Teams channel messages, and silently presents the message as if those images do not exist. This is a significant gap because customer feedback threads, bug reports, and design discussions in Teams almost always pair short text with screenshots; the text alone is often unintelligible without them.

Concrete repro against a real channel post containing two pasted screenshots:

1. read_resource on teams:///teams/{teamId}/channels/{channelId}/messages/{messageId} returns the message, but the HTML body has zero <img> tags. The body terminates right where the screenshots should be, then resumes with the next paragraph. attachments is also [] (these are inline pastes, not file attachments, so this is expected; Graph stores them under hostedContents).

2. Probing the corresponding Microsoft Graph sub-resource via read_resource does not work either. Every one of the following silently returns the bare parent message JSON unchanged (no error, no different output):

   • teams:///teams/{teamId}/channels/{channelId}/messages/{id}/hostedContents
   • teams:///teams/{teamId}/channels/{channelId}/messages/{id}/hostedContents/{contentId}
   • teams:///teams/{teamId}/channels/{channelId}/messages/{id}?$expand=hostedContents
   • teams:///teams/{teamId}/channels/{channelId}/messages/{id}?format=full

So the gap is two-layered: the <img> tags carrying the hostedContent IDs are stripped from the body before it reaches the client (so the IDs cannot be discovered), and the sub-resource URI scheme that would let you fetch the binary anyway is not routed.

This is the Teams-side analog of #30533 (which requests email attachment support). Same architectural pattern: the MCP exposes the message text and metadata but not the binary sub-resources Graph supports.

Proposed Solution

Either or both of:

1. Stop stripping <img src="...graph.microsoft.com/.../hostedContents/.../$value"> tags from the returned body.content. At minimum, leave them in place (with the URL) so the client can see that hosted content exists and reference it.

2. Route a hostedContents URI scheme so the binary can be fetched. Mirroring the Graph API:

   • GET /teams/{teamId}/channels/{channelId}/messages/{id}/hostedContents to list
   • GET /teams/{teamId}/channels/{channelId}/messages/{id}/hostedContents/{contentId}/$value to download the binary

   Returning the binary as a base64 image part would let Claude actually view the screenshot.

Alternative Solutions

Asking the user to manually share screenshots from Teams threads works as a fallback today, but it defeats the purpose of the connector for one of its strongest use cases (catching up on team discussions).

Priority

Medium - Notable usability gap for any workflow that involves reviewing Teams threads with screenshots (which, in practice, is a lot of them).

Feature Category

MCP server integration

Use Case Example

Triaging a customer feedback Teams thread where a teammate has reported a UI bug. The post describes the issue in text and includes screenshots showing the broken layout. Without the screenshots, the report is not actionable; the text alone cannot convey what is visually wrong.

Additional Context

Related: #30533 (Outlook email attachments missing). Both seem to share the same underlying gap in how the MCP exposes Graph binary sub-resources.