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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds real behavioral context: 'secret keeps the key out of the sandbox' (credential handling via the egress proxy) and 'What was written stays in the bucket' (unmount does not delete remote data). These are useful disclosures beyond the structured fields, though permission/rate-limit details are absent.

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?

Front-loaded with the resource statement, then compact per-action signatures. Dense and mostly waste-free, though the parentheses-style signatures are terse enough that some clarity is traded for brevity.

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 an 11-parameter, multi-action tool with no output schema, the description covers all three actions and even summarizes the list() return ('each mount and whether it is mounted now'). Combined with 82% schema coverage, it is largely complete, with only cross-tool guidance missing.

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 82%, so the schema already documents nearly all parameters including endpoint, provider enum, and secret. The description largely restates the mount parameter list with optional markers, adding little beyond what the schema provides; baseline 3 applies when the schema does the heavy lifting.

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 names a specific resource (S3/R2/GCS bucket mounts in a running sandbox) and decomposes the tool into three clearly labeled operations (mount/list/unmount) with signatures. It is easily distinguished from siblings like runtime_volumes or runtime_sandboxes_files_manage.

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?

Each action's purpose is spelled out via its signature, giving clear context for when each applies. However, it never states when to prefer this over alternatives such as runtime_volumes or the files tools, so the routing decision is left implicit.

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