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

With empty annotations, the description carries the full behavioral burden and does disclose meaningful traits: the operation is paid in USDC, subject to spend caps, and will refuse disallowed uses. This goes beyond the schema and helps agents anticipate cost and refusal behavior. It does not cover failure modes or outputs, but the disclosed behavior is substantial.

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 a single, front-loaded sentence that communicates payment, context, policy limits, and refusal behavior without filler. Every clause adds information relevant to invocation decisions. This is concise and well structured.

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?

This is a paid, policy-restricted tool with seven parameters and no output schema, so the description needs to cover operational details like which parameters apply per CAPTCHA kind and what the solve result looks like. The current description covers cost and policy but omits these invocation-critical details. It is not complete enough for an agent to confidently construct a correct request.

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 43%, so the description should compensate by explaining parameters or their relationships, but it does not. It mentions purpose restrictions but not how to populate kind, websiteURL, imageBase64, websiteKey, or tenantId, nor how these interact for different CAPTCHA types. The agent is left to infer parameter semantics from the sparse schema.

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 uses the specific verb 'solve' with the resource 'CAPTCHA' and adds the context 'for agents mid-task,' making the core function clear. It is distinguishable from the sibling tools listed, which cover quoting, spend status, issue reporting, and page unlocking. It stops short of an explicit sibling comparison, but the function is unambiguous.

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 explicit usage context: it is for mid-task CAPTCHA solving, subject to spend caps and AUP, and restricted to allowlisted purposes. It names clear exclusions by refusing login, signup, and payment abuse. It does not name sibling alternatives or say when to use get_quote first, but the conditions for use are mostly explicit.

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