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

With only readOnlyHint=false and openWorldHint=true supplied, the description does the heavy lifting: it explains the untrusted-registry trust model and prompt-injection caveat, that the response issues a report_token, that a call doubles as a reporting channel via `previous`, and that a miss queues the site/task for indexing. These side effects explain the non-read-only annotation rather than contradicting it.

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 purpose and the call-before-navigating rule are front-loaded, and the safety warning follows immediately. The closing sentences compress a lot of token-reporting mechanics into dense prose, which is efficient but takes careful reading; nothing is truly redundant.

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?

There is no output schema, and the description compensates by describing what comes back (shortcuts, steps, gotchas, success_criteria, report_token). Combined with the miss behavior and the reporting obligation, an agent has everything needed to call this correctly and follow up.

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%, so baseline is 3, but the description adds real meaning: the `report_token` is described as coming from the response of a prior get_playbook, and `previous` is framed as a batching mechanism to report a pending earlier run in the same call. That lifecycle context is not derivable from the schema alone.

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?

"Look up a verified playbook for doing a task on a website before acting" gives a specific verb (look up) and resource (playbook), then enumerates the payload (URL shortcuts, semantic steps, gotchas, success_criteria). It is clearly distinct from get_site_map, list_tasks and submit_trace, and it even names the one sibling it interacts with (submit_trace).

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 timing is explicit and imperative: "Call it before navigating a site for a task." It also covers the alternative path — on a miss, "carry on without a playbook" — and routes the reporting step to submit_trace, so the agent knows the ordering of both calls. Little is left to inference.

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