Skip to main content
Glama
Softeria

Microsoft 365 MCP Server

by Softeria
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

download-bytes

Read-only

Download binary content from Microsoft Graph and return it as base64. Single tool for any binary read: drive file content, mail attachment, profile photo, Teams hosted content, meeting recording.

Instructions

Download binary content from Microsoft Graph and return it as base64. Single tool for any binary read: drive file content, mail attachment, profile photo, Teams hosted content, meeting recording. Returns { contentType, encoding: "base64", contentLength, contentBytes }. For large drive/SharePoint file content, prefer get-download-url, which returns a pre-authenticated URL to stream bytes out-of-band instead of base64 through the agent context. With the server's blob output on, the bytes come back as a file resource instead (capped by the server's download limit); pass fileName to name it.

Input Schema

NameRequiredDescriptionDefault
targetYesRelative Microsoft Graph path starting with "/". Common paths: /drives/{drive-id}/items/{driveItem-id}/content (drive file content); /me/messages/{message-id}/attachments/{attachment-id}/$value (mail attachment, list-mail-attachments returns the IDs); /me/photo/$value or /users/{user-id}/photo/$value (profile photo); /chats/{chat-id}/messages/{chatMessage-id}/hostedContents/{chatMessageHostedContent-id}/$value (Teams chat hosted content, list-chat-message-hosted-contents returns the IDs); /teams/{team-id}/channels/{channel-id}/messages/{chatMessage-id}/hostedContents/{chatMessageHostedContent-id}/$value (Teams channel hosted content). For meeting recordings, use get-meeting-recording-content where available; Microsoft Graph returns authenticated recording bytes, not a pre-authenticated download URL.
fileNameNoName of the file, used as the last segment of the returned resource URI when the server runs with blob output. Optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.166.0
    • addedInput schema / properties / fileName
      Added value: +{
+  "description": "Name of the file, used as the last segment of the returned resource URI when the server runs with blob output. Optional.",
+  "type": "string"
+}
  2. Addedv0.134.4
  3. Removedv0.131.2
  4. Changed1 schema field changedv0.128.1
    • changedInput schema / properties / target / description
      Previous value: -"Relative Microsoft Graph path starting with \"/\". Common paths: /drives/{drive-id}/items/{driveItem-id}/content (drive file content); /me/messages/{message-id}/attachments/{attachment-id}/$value (mail attachment, list-mail-attachments returns the IDs); /me/photo/$value or /users/{user-id}/photo/$value (profile photo); /chats/{chat-id}/messages/{chatMessage-id}/hostedContents/{chatMessageHostedContent-id}/$value (Teams chat hosted content, list-chat-message-hosted-contents returns the IDs); /teams/{team-id}/channels/{channel-id}/messages/{chatMessage-id}/hostedContents/{chatMessageHostedContent-id}/$value (Teams channel hosted content). For meeting recordings (often large), use get-meeting-recording-content which returns a URL for out-of-band download by the client."New value: +"Relative Microsoft Graph path starting with \"/\". Common paths: /drives/{drive-id}/items/{driveItem-id}/content (drive file content); /me/messages/{message-id}/attachments/{attachment-id}/$value (mail attachment, list-mail-attachments returns the IDs); /me/photo/$value or /users/{user-id}/photo/$value (profile photo); /chats/{chat-id}/messages/{chatMessage-id}/hostedContents/{chatMessageHostedContent-id}/$value (Teams chat hosted content, list-chat-message-hosted-contents returns the IDs); /teams/{team-id}/channels/{channel-id}/messages/{chatMessage-id}/hostedContents/{chatMessageHostedContent-id}/$value (Teams channel hosted content). For meeting recordings, use get-meeting-recording-content where available; Microsoft Graph returns authenticated recording bytes, not a pre-authenticated download URL."
  5. Addedv0.114.0
  6. Removedv0.112.2
  7. Addedv0.110.0
  8. Removedv0.108.0
  9. Addedv0.99.1

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds genuinely useful behavior beyond that: the exact return shape, the blob-output mode that returns a file resource (capped by the server download limit), and how fileName affects naming. It stops short of describing auth prerequisites or error conditions, so it is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and coverage, then the return shape, then the sibling alternative, then the blob-output nuance. No sentence is wasted and the most decision-relevant information (what it does and when to prefer the alternative) comes first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully spells out the return fields and the alternative file-resource mode, so an agent knows what to expect. It is complete enough to call correctly, though a note on permissions/auth context for these Graph paths would round it out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already fully documented, including detailed path examples for target and the blob-output role of fileName. The description's mention of fileName ('pass fileName to name it') largely restates what the schema says, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Download) and resource (binary content from Microsoft Graph) and enumerates the concrete binary-read cases it covers (drive file, mail attachment, profile photo, Teams hosted content, meeting recording). It explicitly positions itself as the 'single tool for any binary read,' which distinguishes it from siblings like get-download-url and download-bytes-to-file.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit routing rule: for large drive/SharePoint file content, prefer get-download-url to stream bytes out-of-band; the schema also points to get-meeting-recording-content for recordings. This is a clear when-to-use-this vs when-to-use-alternative statement rather than implied guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools