list_utils_downloadDownload a file from the operating system by supplying the file token obtained from an active user.
Uses a file token obtained by an active user to retrieve a file from the operating system.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No |
Changes observed during successful MCP inspections.
v3.20.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose an auth-related prerequisite (active user token) and a retrieval operation, which implies a read. However, it does not mention response format, error behavior, or any other side effects, so transparency is only partial.
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 description is a single sentence with no filler and front-loads the action. The phrase 'from the operating system' is imprecise, but overall the structure is efficient and appropriately sized for a simple one-parameter tool.
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?
With no annotations, no output schema, and an optional token parameter, the description leaves important operational details unspecified: how the token is obtained, what happens if token is null, and what the response looks like. It functions as a minimal stub rather than a complete guide for correct invocation.
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?
Schema description coverage is 0%, but the description adds meaning to the token parameter by identifying it as a file token obtained by an active user. It does not clarify token format, how to obtain it, or what happens when the optional token is omitted.
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 states a specific action and resource: retrieve a file using a file token, and adds the prerequisite that the token comes from an active user. However, it does not differentiate this from sibling media/file retrieval tools, and the phrase 'from the operating system' is somewhat vague.
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 the condition for use—having a file token from an active user—but gives no explicit when-to-use guidance and does not contrast this tool with sibling download/file-retrieval endpoints. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.