Download OneDrive File

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully states that output is base64 and that the MCP response is limited to 10 MB, which is critical for size expectations. However, it does not mention permissions, read-only status, or failure behavior on missing/invalid item IDs, leaving room for more transparency.

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

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

The core behavior and the 10 MB limitation are stated in the first two sentences, keeping the most important information front-loaded. The third sentence with Chinese intent alternatives is somewhat extra but serves multilingual intent recognition without being verbose. Overall the description is compact and free of unnecessary filler.

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

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

For a single-parameter download tool with no output schema, the description explains the return format (base64), the key constraint (10 MB), and the resource type (OneDrive file), which is enough for invocation. It does not cover error handling or large-file alternatives, but the simplicity of the tool makes this acceptable.

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

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

The schema fully documents the only parameter itemId as 'File item ID', giving 100% schema coverage. The description does not add additional parameter-level meaning or format guidance beyond what the schema already provides. The baseline of 3 is appropriate since the schema carries the parameter semantics.

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

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

The description opens with 'Download a OneDrive file' – a specific verb and resource – and further clarifies it returns base64 bytes. This distinguishes it from metadata tools like drive_get_item and from sharepoint_download_file by scoping to OneDrive. The added Chinese intent examples reinforce the purpose.

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

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

The description implies usage for downloading file content, but it does not explicitly state when to prefer this tool over siblings like drive_get_item or sharepoint_download_file. It also does not mention exclusions such as files larger than 10 MB being unsuitable. The Chinese intent mapping offers some context but no tool-selection boundary.

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