checkpoint_restore

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds that every stored frame and metadata is verified during restore, which is genuine behavioral context. However, it never states what existing scene/model state is overwritten or lost by a whole-model restore, which is exactly the information an agent needs before confirming a destructive call.

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 front-loaded sentence with no filler, which is appropriate in size. The density is slightly counterproductive, though, because the compression comes from unexplained domain jargon rather than from precision.

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?

With no output schema and an undocumented parameter, the description should cover what a successful restore returns or confirms (the 'verify' step implies a result worth describing). For a destructive whole-model operation surrounded by checkpoint_create/status/release siblings, the definition leaves too much of the lifecycle implicit.

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?

There is one parameter with 0% schema description coverage, so the description carries the full burden and says nothing about checkpoint_id. It does not say where the id comes from (presumably checkpoint_create or checkpoint_status), what format it takes, or what happens if the id is unknown or stale.

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?

The verb+resource ('Restore a ... checkpoint') is identifiable, but the qualifiers 'managed whole-model' and 'native identities remain supported' are jargon that an agent cannot resolve from the text. Nothing distinguishes it from the many competing restore siblings (pose_restore, subtree_restore, recovery_restore, character_pose_restore).

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?

'when native identities remain supported' is the only conditional, and it is too vague to act on without outside knowledge. No explicit when-not, no prerequisites, and no guidance on which sibling to pick when a full-model checkpoint is not the right recovery path.

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