Get task result (poll to completion)

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

With no annotations provided, the description carries the full burden and delivers: blocking behavior, the 2s minimum interval clamp tied to the ERROR_TOO_MUCH_REQUESTS rejection, the 120-poll cap per task, timeout semantics, error raising on solve failures, and the critical UA-binding warning for token reuse. This exceeds what even typical annotations would supply.

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 description is long but every section earns its place: purpose, behavior, return format, a critical operational warning, and error handling. The IMPORTANT callout is front-loaded appropriately after the core mechanics. Slightly verbose, but the density of useful information justifies the length.

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?

Given a polling tool with no output schema, 0% param coverage, and no annotations, the description covers return dict structure, per-captcha solution shape variance, error conditions, timeout recovery, and proxy troubleshooting. There is no meaningful gap that would prevent an agent from invoking this correctly.

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 0%, so the description must compensate, and it largely does: poll_interval_seconds is explained with its clamping rule, timeout_seconds is explained in both behavior and troubleshooting context, and task_id is implied through the create_task flow. It doesn't state explicit types or defaults for the numbers, but the behavioral context is meaningful.

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 opens with a specific verb+resource+goal: 'Poll a task to completion and return its solution', and immediately positions it as 'the usual way to collect a result after create_task'. It distinguishes itself from the sibling get_task_result by framing itself as the blocking/polling variant and explicitly noting it returns the same ready dict.

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?

It states when to use it ('the usual way to collect a result after create_task') and gives actionable failure guidance (increase timeout, check proxy, re-create task). It references the sibling get_task_result as the source of the return-shape details, though it stops short of an explicit 'use get_task_result instead when you only want one poll' exclusion.

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