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

The description directly contradicts the idempotentHint annotation. Annotations declare idempotentHint: false, but the description explicitly claims 'Idempotent: an already-running sandbox is returned (existing: true), never doubled.' This is a serious inconsistency that could mislead the agent about repeated calls. Per the rule, score 1 and flag as annotation contradiction.

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?

The description is dense but well-organized: it starts with the core purpose, then cost, idempotency, requirements, and error handling. Each sentence carries value, though it is longer than strictly necessary. The structure is effective with the main action first.

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?

The description covers many operational aspects: cost, idempotency claim, required parameter, error code (429), and the relationship to sandbox_exec. However, the idempotency contradiction makes the information unreliable; an agent cannot trust whether repeated calls are safe. This undermines completeness. Without the contradiction it would be a 5, but the incorrect claim reduces reliability.

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?

Schema description coverage is 50% (browser is documented, wallet_address is not). The description compensates for the undocumented wallet_address by stating 'Needs wallet_address; anon works.' It also reinforces the browser cost, though that's already in the schema. This adds meaningful guidance beyond the schema.

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 clearly states the tool's function: 'Start the user's session sandbox', identifies the resource (a sandbox) and explains its purpose ('isolated cloud shell — the safe place to test untrusted tools'). It distinguishes itself from sibling tools like sandbox_exec by noting that exec runs work inside it, and from sandbox_status/stop implicitly by focusing on the start action.

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 description gives clear context: it is for starting a sandbox, it mentions the cost and the need to confirm with the user unless explicitly requested. It implies that sandbox_exec is for running work inside the started sandbox, but does not explicitly name alternatives like sandbox_status or sandbox_stop. It does not state when NOT to use it (e.g., if the sandbox is already running, though it says idempotent, but that's contradicted by annotations).

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