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

Annotations already establish the safety profile (writable, non-destructive, closed-world), so the description only needs to add beyond that. It contributes two useful facts — the restore is an exact subtree (fidelity/all-or-nothing flavor) and the retention deadline gate — but omits what happens after the deadline, whether the original parent location is recreated, and how name collisions are handled.

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

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

A single sentence of eleven words, front-loaded with the verb and resource and free of filler. For a mutating, idempotency-keyed operation it is terse to the point of being thin, which keeps it just under the top mark.

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

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 no explanation, and annotations cover the safety story. What is missing is failure-mode context for a deadline-gated mutation: what an agent should do if the deadline has passed, whether a partial subtree can be restored, and confirmation that the idempotency key governs retry behavior on this call.

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

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

With 50% schema coverage, folderId carries no schema description at all; 'the exact archived folder subtree' partially compensates by implying folderId is the subtree root. The idempotencyKey is fully documented in the schema, so the description adds nothing there. Baseline for mid coverage with marginal added meaning is a 3.

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

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

Specifies a concrete verb (restore) and a precise scope (archived folder subtree plus its sheets), which implicitly distinguishes it from the single-item sheets_restore and version-oriented siblings such as sheets_restore_version. It never names an alternative, so an agent must infer the differentiation rather than being told it.

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

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

The only usage signal is the temporal constraint 'before its retention deadline', which is a validity condition rather than guidance on when to choose this over sheets_restore, sheets_restore_version, or sheets_restart_version_restore. No prerequisites, no exclusions, and no alternative routing are provided.

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