Skip to main content
Glama
Claude File Manager MCP

Claude File Manager MCP

by sadd11

Restore from the trash

restore_path

Restores a deleted file or folder from the trash to its original location using an id from list_trash or a delete response. Optionally overwrites an occupied path.

Instructions

Restores a file or folder from the trash to its original location. Get the id from list_trash or from the delete_path response.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "restore_path"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesTrash entry id
overwriteNoReplace the item if the original path is occupied

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the key trait that the item returns to its original location, but it says nothing about permissions required, what happens when the original parent directory no longer exists, or whether the operation is reversible. The overwrite semantics are handled by the schema rather than the description.

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?

Two short sentences with zero filler, and the primary action is stated before the id-provenance hint. Every clause earns its place.

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?

For a simple two-parameter mutation with no output schema, the definition covers purpose and id sourcing adequately. It leaves minor gaps around return values and failure conditions, but nothing that would cause an agent to call it incorrectly.

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?

Schema coverage is 100%, so both parameters are already documented and a baseline of 3 applies. The description earns slightly more by telling the agent where the otherwise opaque 'Trash entry id' comes from, which is meaning the schema does not provide.

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 gives a specific verb (restores) and resource (file or folder) along with the destination (original location) and source (the trash). An agent can distinguish this from siblings such as delete_path or move_path without opening any schema.

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

Usage Guidelines4/5

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

It supplies the prerequisite routing information an agent actually needs: obtain the id from list_trash or from the delete_path response. It stops short of stating exclusions, such as what to do when the original path is occupied instead of overwriting, so it is clear context rather than full when/when-not guidance.

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