nex_captcha_apply_result

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

Beyond the sparse annotations, the description discloses cost ('Free'), a hard five-minute url/sitekey binding window, restart behavior, polling cadence, and the important caveat that application does not prove website acceptance. The readOnlyHint=false value sits in mild tension with the 'query' framing, but the description's explicit list of non-actions (no code execution, no permission changes, no submit) resolves the ambiguity rather than contradicting it. What's missing is the response shape for non-SUCCEEDED states and what an expired binding looks like.

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 lead is correctly front-loaded with purpose, but the remainder is a dense run-on that packs preconditions, negatives, polling advice, and caveats into one stream with no structural separation. Nearly every clause is substantive, yet the parenthetical timings and mid-sentence negatives make it harder to parse than it needs to be. Light segmentation would make the same content more scannable without losing information.

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, so the description must describe the return payload, and it only says apply.javascript is returned on success without indicating the fields present on pending, failed, or expired tasks. The preconditions, cost, and lifecycle constraints are otherwise unusually complete for a four-parameter tool. The missing failure/return detail is the main completeness gap.

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 carries the full semantic load, and it does cover all four parameters: id as an existing local task id, url and websiteKey as the original binding from a purchase in this process, and selector as an optional value from the current page. The gap is that no format or typing detail is added (integer id, URI url) and 'websiteKey' is never defined outright. Given the 0% coverage baseline, adding meaning for all four parameters is a real contribution.

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 and resource: query an existing NexCaptcha local task id and return apply.javascript only on SUCCEEDED with a supported TOKEN result. The negative clause ('Never creates or repurchases a task') cleanly separates it from the purchase path. It stops short of naming the closest sibling, nex_captcha_query, so an agent must still infer which of the two query surfaces applies.

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 concrete when-to-use conditions (task must have SUCCEEDED with a documented supported TOKEN result) and an explicit when-not (after a restart, reconcile the existing record instead of buying again). It also supplies an operational cadence ('Repeat pending queries every 3–5 seconds') and a precondition on the selector coming from the current page. It never names an alternative tool for the ambiguous cases, so routing is clear only against buy, not against siblings like nex_browser_captcha_complete.

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