Skip to main content
Glama

Restore Sheet

sheet.restore
Idempotent

Bring back a deleted sheet with its rows, views, forms, dashboards, workflows and task records, in the place it was deleted from. Its workflows come back turned off: tell the user, who turns them on again.

Input Schema

NameRequiredDescriptionDefault
sheetIdYes

Output Schema

NameRequiredDescriptionDefault
noteNo
tasksYes
sheetIdYes
restoredYes
workflowsYes
dashboardsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare the safety profile (not read-only, not destructive, idempotent); the description goes well beyond that by disclosing that the full descendant object graph is restored, that placement returns to the original location, and critically that workflows return disabled and the user must be told to re-enable them. That disabled-workflow side effect is a non-obvious behavioral trait an agent could not derive from structured fields.

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 sentences, both earning their place: the first front-loads the restore scope and placement, the second delivers the one operational caveat. No filler or restatement of the title.

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?

With an output schema present, return values need no explanation, and the description covers the side effects that matter. The only real gap is that it says nothing about failure conditions or what happens if the sheet was never deleted or the ID is invalid.

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?

Schema description coverage is 0% — sheetId appears only as an untyped-by-name integer with numeric bounds and no prose. The description never mentions the parameter at all, so it does not compensate for the coverage gap; an agent gets no confirmation that this must be the ID of an already-deleted sheet rather than any sheet.

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?

States a specific verb ('bring back') and resource ('a deleted sheet'), and enumerates exactly what comes back with it (rows, views, forms, dashboards, workflows, task records). This makes it unmistakably distinct from sheet.create, sheet.delete, and the restore siblings for other resource types.

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?

The phrase 'a deleted sheet' sets the clear precondition for use and implicitly excludes live sheets, and the closing instruction tells the agent what to do after the call. What's missing is guidance on when restore is not appropriate (e.g., the sheet ID doesn't exist or was never deleted) or which sibling recovery tool to use for non-sheet objects.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources