Skip to main content
Glama
technophile77

idrive-mcp-server

Delete File/Folder (EVS) — mutating, destructive

delete_file
Destructive

Delete one or more backed-up files or folders from an iDrive device, moving them to trash for recovery or permanently removing them.

Instructions

MUTATING, DESTRUCTIVE: removes one or more files/folders from a device's live backup, via the EVS-hosted evs/v1/deleteFile endpoint, in a single batch call across all of paths. By default (permanent: false) this moves the path(s) to trash — confirmed live against a real device (see docs/api-map.md's "Live mutation testing" section): the item(s) disappear from browse_folder/list_files listings immediately, and can be undone with the sibling restore_from_trash tool. Setting permanent: true is presumed (NOT independently confirmed — see the permanent parameter's own description) to bypass trash and delete the data with no way to recover it. Always double-check paths before calling this, especially with permanent: true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathsYesOne or more file/folder paths, in the EVS format ("/C/Users/...", same as `browse_folder`'s `path`). Sent as repeated `p` fields in a single request — the response reports a result per path, so a partial failure across multiple paths is visible rather than silent.
deviceIdYesThe iDrive device ID the path(s) were backed up from, e.g. as returned by the sibling `list_devices` tool's `device_id` field.
permanentNoWhen false (default), moves the path(s) to trash (sent on the wire as `trash=yes`) — this is the ONLY behavior of this field that has been confirmed live against a real account (see docs/api-map.md's "Live mutation testing" section): the item disappears from `browse_folder` listings and can be recovered with the sibling `restore_from_trash` tool. When true, sends `trash=no`, which is presumed — from the field's name and the `trash=yes` pattern, NOT independently confirmed — to mean a permanent, non-recoverable delete. Treat `permanent: true` as unverified until you've tested it yourself against a throwaway path; do not rely on it for anything important without doing so first.
Install Server

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, but the description adds substantial behavioral detail: batch deletion across all paths, immediate disappearance from listings, trash-vs-permanent behavior, visible per-path failure reporting, and the unverified nature of permanent deletion. It also explicitly records what was live-confirmed versus merely presumed, exceeding what the annotations provide.

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 dense but purposeful, with the destructive warning front-loaded and every sentence contributing either behavior, confirmation status, or a safety caution. The prose is structured so the most critical constraints appear first, followed by detailed caveats.

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 destructive mutation tool without an output schema, the description covers the critical operational context: trash default, permanent-delete uncertainty, recovery path, partial failure visibility, path format, and a live-testing reference. An agent has what it needs to invoke this safely and interpret broad behavior, even if exact response structure is not specified.

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 schema already covers all three parameters with rich descriptions, and the tool description adds cross-cutting semantics such as 'single batch call across all of paths' and repeated p fields. It doesn't need to explain each parameter further, but the added batch/partial-failure context is genuinely useful.

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 opens with 'MUTATING, DESTRUCTIVE' and states a specific action: 'removes one or more files/folders from a device's live backup' via the named endpoint and batch semantics. It clearly identifies the resource and behavior, and the contrast with the sibling restore_from_trash prevents confusion.

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?

The description explicitly explains default trash behavior, how to recover with restore_from_trash, and cautions to 'Always double-check paths before calling this, especially with permanent: true.' It also warns that permanent:true is unverified and should not be relied on until self-tested, giving an agent clear guardrails for when and how to invoke the tool.

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