Pause sandbox

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

With destructiveHint=true and idempotentHint=true already declared, the description adds real substance: stored-state-only billing, exemption from the running-sandbox limit, a 2-minute wait ceiling, and the reversibility path via sandbox_resume. It does not say what happens if pausing exceeds the 2-minute window or how in-flight exec sessions are treated, which leaves the main operational edge case unresolved.

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?

Four short sentences, each carrying distinct information: what it does, cost implications, timing limit, and reversal. Front-loaded with the action and no filler.

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?

For a one-parameter mutating tool with annotations and no output schema, the description covers cost, limits, latency, and undo. The only meaningful gap is post-timeout behavior (error vs. eventual completion), which an agent would want before relying on the 2-minute guarantee.

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 a single parameter with 100% schema coverage, including a pattern, length bounds, and a description pointing at sandbox_create/sandbox_list as sources. The prose adds nothing about sandboxId, so baseline 3 applies.

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?

States a specific verb chain ('save memory, processes and files, and stop it') against a specific resource (sandbox), which precisely separates it from sandbox_resume (the inverse) and sandbox_snapshot (which saves state but does not stop the sandbox). An agent can route correctly from the first sentence alone.

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 closing sentence 'Undo with sandbox_resume' gives the explicit inverse operation, and the cost/limit sentence implies when pausing is preferable to deleting. It stops short of naming when to prefer sandbox_snapshot or sandbox_delete over pausing, so the alternative routing is only partial.

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