Microsoft 365 connector: `read_resource` can't return binary email attachments

Description

When reading an Outlook attachment through the claude.ai Microsoft 365 connector, read_resource on an attachment URI (mail:///messages/{id}/attachments/{id}) only returns metadata for any non-text file:

{"note":"Binary attachment — content cannot be returned inline. Open the message in Outlook to download the file.",
 "attachment":{"name":"<letter>.asice","contentType":"application/octet-stream","size":169920}}

So Claude can find an email but can't read its actual content when that content is in an attachment. This is common with formal or regulatory mail. Estonian authorities, for example, send letters as signed ASiC-E (.asice) containers, and the cover email just says "see attached". Claude Code could read the file easily if it were on disk (.asice is a ZIP containing a PDF), but the connector gives it no way to get the bytes.

Expected

Any one of these would work:

• An option to save an attachment into the session's working or attachments directory and return the local path.
• Base64 content for attachments under a size limit.
• Server-side text extraction for common document types, as is already done for PDF and Office files in SharePoint/OneDrive file:/// reads. That could extend to PDFs nested inside ZIP-based containers such as .asice or .zip.

Workaround today

Download the attachment by hand in Outlook and pass Claude the path, or use another tool.

Environment

Claude Code (Opus 5.5), macOS, claude.ai Microsoft 365 connector.

Related: #62184 (similar binary-attachment limitation in the Zoho Mail connector).

🤖 Generated with Claude Code