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

Annotations already declare openWorldHint=true and destructiveHint=true, but the description adds real behavioral value beyond them: secrets are resolved by the egress proxy so "a server never holds the value", and "servers keep to the sandbox's network rules". It also distinguishes expiring vs permanent (public) URLs. It stops short of what stop actually tears down.

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?

Dense but front-loaded: the core purpose leads, then actions are covered in a compact sequence of clauses. The semicolon-heavy packing is efficient, though the final sentence bundles two unrelated facts (secret resolution and network rules) somewhat awkwardly.

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 multi-action tool with six parameters and no output schema, the description covers the return shape of start and get but gives little on catalog or stop, and omits the semantics of replace and port entirely. It is adequate to invoke the common paths but leaves several parameters and one action under-specified.

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 only 17%, so the description must carry the load; it clarifies the action dimension and the meaning of public (URLs that never expire), but leaves replace, port, and options unspecified in both schema and prose. The secrets mapping it explains is already documented in the schema, so it adds limited net value.

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?

Starts with a concrete verb+resource ("Run well-known MCP servers in a sandbox") and then enumerates the four actions (catalog/start/get/stop), so an agent can tell exactly what this does and distinguish it from runtime_sandboxes_create and runtime_sandboxes_exec. The catalog examples (GitHub, Postgres, Playwright, filesystem, fetch, git, Notion) make the scope unambiguous.

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 per-action context (catalog to list, start to provision, get to inspect, stop to end) and notes that public URLs are configured "once", which is genuine routing guidance. It also points the secret flow at the sibling runtime_secrets. What it lacks is an explicit when-not or a contrast with alternatives like runtime_sandboxes_exec for custom servers.

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