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

Annotations cover safety (readOnlyHint, openWorldHint), and the description adds real behavioral context beyond them: the sandbox handshake source, the additional requires and configRequest fields returned, and the miss semantics — UNKNOWN plus a queued probe, with the explicit warning that UNKNOWN never means the server has no tools.

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 core purpose, then usage, then return details. Dense and generally earns its length, though the closing 'it needs a token' framing is slightly rhetorical rather than informational.

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?

No output schema exists, so the description must carry the return contract — and it does, naming tools/parameters/annotations plus requires and configRequest. Combined with the UNKNOWN miss semantics, an agent has everything needed to call and interpret it.

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 coverage is 100% across both parameters, so the schema already documents server and version. The description implies versioning ('before wiring') but adds no format or default semantics beyond what the schema states, 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+resource with scope: returns every tool, its required/optional parameters, and behaviour annotations, read from a live tools/list handshake in a sandbox. This clearly distinguishes it from siblings like capabilities or resolve_surface that would otherwise look similar to an agent.

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?

Gives explicit when-to-use conditions: 'Call before wiring an agent to a server, or when a tool call is failing for reasons the error does not explain.' No named alternative sibling or explicit when-not, so it falls short of a 5.

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