Complete authorized verification

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

Annotations already declare the non-read-only, non-destructive, open-world profile. The description adds that it acts in an existing browser session and then waits for 'fresh server-validated evidence', which hints at post-action polling/verification. It does not disclose failure behavior, what state is altered, or what happens if authorization is not held.

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?

A single sentence with the action front-loaded and no filler. It is dense with qualifiers ('authorized provider-test or owned-origin'), but it is appropriately sized for the tool.

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?

With three parameters, 33% schema coverage, no output schema, and an open-world non-read-only action, the description leaves too much unspecified. It never explains what 'fresh server-validated evidence' means as a result, nor how poll_ms/timeout_ms govern the wait.

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 33% – only session_id is documented. The description adds nothing about poll_ms or timeout_ms, so their units, defaults, and effect on the wait-for-evidence behavior are undocumented in both schema and description. It fails to compensate for the coverage gap.

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 verb is 'complete' and the object is a challenge within an 'existing browser session', which is a recognizable action. However, the hedged phrasing 'authorized provider-test or owned-origin challenge' obscures that this is a CAPTCHA-solving tool and does nothing to separate it from siblings like captcha_handoff or captcha_resume.

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 authorization boundary ('authorized provider-test or owned-origin') implies when this tool is permitted, which is meaningful usage context. But it names no alternative and gives no condition for choosing it over captcha_handoff, captcha_resume, or captcha_wait, leaving the routing decision to inference.

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