Skip to main content
Glama
technophile77

idrive-mcp-server

Download File (EVS)

download_file
Read-only

Download a backed-up file's content to a local disk path, streaming to avoid size limits. Returns the destination path and bytes written.

Instructions

Downloads a backed-up file's actual content, via the EVS-hosted evs/downloadFile endpoint, streaming it straight to a local file at the required destinationPath rather than returning it inline — large files inlined into a single tool response can exceed the MCP stdio transport's message size limit, so this tool always writes to disk and reports back { path, bytesWritten } instead. Use browse_folder or list_files first to discover the path of the file you want. Note: iDrive's Content-Type header on this endpoint is NOT trustworthy for identifying the real file type (it's always text/plain;charset=UTF-8 regardless of actual content) — the downloaded data is an opaque byte stream; use the file's own name/extension (from a prior listing) to infer its type instead. Transparently retries with the alternate Unicode normalization (precomposed NFC vs. decomposed NFD) if path contains accented characters and the first attempt fails to resolve; when that retry is what actually worked, the result includes a sourcePathNormalizedTo field showing the form that succeeded.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesThe folder or file path, in the EVS format: single leading slash plus drive letter, e.g. "/C" for a drive root or "/C/Users/me/Documents" for a deeper path. This endpoint has never been observed handling a bare root path ("/") — use the sibling `list_files` tool first to discover the available drive letters/roots for this device, then pass one of those (prefixed with a leading slash) here.
deviceIdYesThe iDrive device ID the file was backed up from, e.g. as returned by the sibling `list_devices` tool's `device_id` field.
destinationPathYesThe absolute local file path to stream the downloaded content to (its parent directory is created if missing). Always required — this tool never chooses a download location on its own.
Install Server

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses important behavioral details: it always writes to disk rather than returning inline, reports `{ path, bytesWritten }`, performs transparent Unicode normalization retries, and notes that the Content-Type header is unreliable. These are significant behavioral traits not visible from annotations or schema.

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?

The description is long but each sentence contributes: core behavior and rationale, prerequisite usage, a critical caveat about content type, and a non-obvious retry behavior. The key action and outcome are front-loaded before caveats, and nothing feels redundant or filler.

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

Completeness5/5

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

For a tool with no output schema, the description fully explains the return shape. It covers prerequisites, path handling caveats, delivery mechanism, retry behavior, and output semantics. The complexity introduced by the endpoint's quirks is well handled, leaving the agent with sufficient context to call the tool correctly.

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

Parameters4/5

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

The input schema already documents all three parameters at 100%, so the baseline is 3. The description adds extra meaning by explaining when the `path` may be retried under alternate Unicode normalization, emphasizing `destinationPath` is always required and never auto-chosen, and clarifying how to derive the file type. This goes modestly beyond the schema definitions.

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?

The description states a specific action ('Downloads a backed-up file's actual content'), the exact endpoint, and the distinguishing behavior of streaming to a local file. It clearly differentiates this tool from sibling browsing/listing tools by emphasizing it retrieves file content rather than metadata.

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?

It explicitly instructs the agent to use `browse_folder` or `list_files` first to discover the file path, and warns that bare root paths should be resolved via `list_files`. This provides clear when-to-use guidance and routeing to sibling tools, satisfying the criterion for explicit usage direction.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/technophile77/idrive-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server