Start an async unlock job

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

With no annotations provided, the description is the primary source of behavioral transparency. It discloses that the tool is asynchronous and returns a response_id that must be used later, which are key non-synchronous behaviors. However, it does not mention other important behaviors such as potential costs, rate limits, or any side effects. Given the lack of annotations, this is adequate but not rich, hence a 3.

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 exceptionally concise: two sentences that front-load the action ('Start an asynchronous Web Unlocker request') and follow with the critical output information. There is no filler, and every sentence adds value by explaining the async nature and the subsequent retrieval step.

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?

While the description clearly outlines the async lifecycle, it is incomplete for selection and invocation. The lack of annotation coverage and output schema, combined with zero parameter semantics, leaves significant gaps. The tool has four parameters, and the description fails to explain any of them, making it difficult for an agent to construct a correct request beyond the obvious 'url'. The description covers the high-level flow but not the details necessary for full contextual understanding.

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?

The schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It does not mention any of the four parameters (url, zone, country, data_format) or provide additional context beyond the schema's basic types. The agent would have no semantic guidance on what zone or country represent or how data_format affects output, making parameter understanding heavily reliant on 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?

The description starts with 'Start an asynchronous Web Unlocker request' which clearly states the tool's action and resource. It differentiates from siblings by specifying 'asynchronous' and 'slow/heavy pages', and explicitly mentions returning a response_id for later retrieval via unlocker_get_async_result, distinguishing it from synchronous counterparts.

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 provides a clear usage context: 'for slow/heavy pages', implying it is the appropriate choice for such cases. It also instructs the user to later pass the returned response_id to unlocker_get_async_result, outlining the complete workflow. However, it does not explicitly name alternatives like unlocker_scrape or state when not to use this tool, so it falls just 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.