rollback

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

No annotations are provided, so the description carries the burden of behavioral disclosure. 'Restore a snapshot' signals a state-changing operation, and 'demo sandbox' scopes its blast radius, which is helpful. However, it doesn't disclose whether the restore is reversible, destructive to current sandbox state, or requires specific permissions. A state-changing tool with no annotation coverage could do more, though the 'demo sandbox' caveat adds meaningful context.

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, focused sentence that names the action, the resource type, and the deployment context. Zero filler, no redundancy, every word earns its place. This is appropriately concise for a tool with one parameter.

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?

This is a state-changing, destructive-ish operation (restoring a snapshot) with no annotations, no output schema, and no param detail. For a mutation tool with a sibling (safe_exec), the description is thin. It doesn't explain what happens to current sandbox state, whether assets are wiped, or what the expected outcome is on success. Given its complexity as a restore operation, more detail is warranted.

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 only one parameter (snapshot_id) at 0% schema description coverage, the description doesn't mention the parameter at all. However, the schema title 'Snapshot Id' is reasonably self-explanatory given the tool is about restoring snapshots. The description adds little beyond the schema, but the single-parameter schema is simple enough that a baseline of 3 seems fair — though there's no info on format (UUID? name? custom format?) for snapshot_id.

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 description states 'Restore a TripWire snapshot in the configured demo sandbox' — a verb+resource with a scoping qualifier ('demo sandbox'). It's clear enough about the primary action but doesn't elaborate on what 'restore' entails (overwrites current state? creates new resources?). It doesn't explicitly distinguish from the sibling tool safe_exec, though the distinct purpose is evident.

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?

No guidance on when to use this tool versus safe_exec. The description implies a demo-sandbox context but offers no exclusions, prerequisites, or alternatives. Given the sibling relationship with safe_exec, explicit guidance on when rollback vs safe_exec is appropriate would be valuable but is absent.

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