Skip to main content
Glama

drive_restore

Restore a deleted Google Drive item from Trash to its original folder using its name, listing index, or occurrence.

Instructions

Restore an item from the Trash to its original folder.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoExact name of the item in the Trash.
indexNoIndex from the last listing of the Trash (drive.open section=trash).
occurrenceNoWhich item when several share the name (0 = first).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/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. It states the state transition (Trash to original folder), but does not disclose permission requirements, what happens if the original folder no longer exists, conflict behavior for duplicate names, or whether the restore is reversible. This is minimal disclosure for a mutation tool.

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 a single front-loaded sentence with no wasted words. It states the action and source/destination clearly.

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

Completeness3/5

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

The schema fully documents the three optional selectors, so an agent can construct calls. However, with no annotations and no output schema, edge cases such as missing original folders or failures remain undocumented, leaving the definition only minimally complete for a mutation tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no parameter-level guidance beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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 uses a specific verb ('Restore') and resource ('item from the Trash to its original folder'), making the operation clear. The phrase 'from the Trash' implicitly distinguishes it from sibling tools like drive_trash, drive_delete_forever, and drive_empty_trash.

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

Usage Guidelines3/5

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

The description implies when to use the tool by referring to items in the Trash, but it does not explicitly state when to choose it over alternatives such as drive_delete_forever or drive_empty_trash. No exclusions or prerequisites are given.

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

Deploy Server

Other Tools