icloud-mcp

icloud_restore

Restore an item from iCloud Drive trash by name so deleted files return to their original location.

Instructions

Restore an item from the trash by name.

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": {
      "name": "<name>"
    },
    "name": "icloud_restore"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 17, 2026

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden and says almost nothing: it does not disclose permissions required, whether restoring to the original location can overwrite or collide with an existing item, or what happens when multiple items share the same name. 'Restore' implies a state mutation but no behavioral detail is given.

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

Conciseness4/5

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

One short, front-loaded sentence with zero filler; appropriately sized. It is efficient but borders on under-specified rather than genuinely concise-and-complete.

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

Completeness2/5

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

An output schema exists so return values need not be described, but for an unannotated mutation tool the description omits the things an agent actually needs: target disambiguation, failure modes (item not in trash, name not found), and any permission or irreversibility notes.

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

Parameters2/5

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

The single parameter has 0% schema description coverage and is only titled 'Name'. The phrase 'by name' confirms the lookup key is a name rather than an ID, but adds nothing about case sensitivity, path qualification, or how duplicate names are disambiguated — the ambiguity most likely to cause a wrong invocation.

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

Purpose4/5

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

States a specific verb (restore) and resource (an item from the trash), which cleanly separates it from siblings like icloud_trash, icloud_list_trash, and icloud_delete-style tools. It doesn't explicitly name a sibling, so it stops short of the 5 mark.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance or mention of alternatives; the agent must infer that this applies only to items already in the trash (vs icloud_list_trash for viewing, or icloud_move for relocation). No prerequisites or preconditions are stated.

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

Deploy Server