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

With no annotations, the description takes on the full burden of behavioral disclosure. It explains the return value, the polling flow, and warns against a real failure mode with inline base64. It does not cover auth or rate limits, but the core behavioral traits are well transmitted.

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 the essential return/poll info is front-loaded, and the detailed example about the 9-image failure earns its place by preventing a subtle but costly mistake. It is verbose but structured and purposeful.

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?

For a tool with two parameters and no output schema, this description covers both input modes, points to external docs for required fields, and explains the follow-up polling. It does not document error cases, but an agent can invoke it correctly without missing critical context.

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%, yet the description fully compensates: task must include type and required fields, task_file is a filesystem path to a JSON task object, and exactly one of the two must be provided. This transforms two opaque parameters into clear, usable instructions.

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 and resource: 'Submit a captcha task; returns taskId. Poll with get_task_result.' This clearly states what the tool does and how it differs from the sibling result-polling tools.

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 explicitly says when to use task_file instead of task, mandates looking up required params in the docs, and requires exactly one of task or task_file. This is actionable when-to guidance, not just a vague hint.

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

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

With no annotations, the description carries the full burden. It discloses important behavioral traits: the UA must be current Windows-OS, stale values cause ERROR_WRONG_USERAGENT, and the solution may return its own UA that should be reused. This is substantial context beyond a simple getter.

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 front-loaded with the core purpose and then uses a numbered list to explain the fingerprint-consistency workflow. Every sentence adds useful guidance without redundancy.

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?

For a parameterless utility, the description is complete: it covers what the tool returns, why freshness matters, how to apply the value, and how to handle the UA returned in the solution. No output schema exists, but the description sufficiently explains the expected value and usage.

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 tool has zero parameters, so the baseline is 4. The description adds meaning by explaining how the returned value should be used, although parameter-level detail is irrelevant here.

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?

Description clearly states the tool fetches a current, real-world Windows User-Agent string from CapMonster's service. This is a specific verb+resource and is clearly distinct from the sibling tools like get_balance or create_task.

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?

Provides explicit guidance on when to use the tool: before starting a solve, and to re-fetch rather than reuse stale UAs. It gives concrete context for using the value consistently across the solve, though it does not explicitly rule out alternative tools or mention cases where it should not be used.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the purpose without mentioning authentication requirements, potential errors, or the return format. Since there is no output schema, the agent is left to infer what the balance response 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 description is a single, clear sentence with no redundancy. It is appropriately front-loaded and efficient.

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?

The tool is simple with no parameters and no output schema. The description tells the agent what it does, which is largely sufficient for a trivial getter. However, it does not specify the return value format, which is a minor gap given the lack of an output schema.

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 tool has zero parameters, and the schema description coverage is 100% (trivially empty). The description adds no parameter information, but none is needed. Per the rubric, a zero-parameter tool earns a baseline of 4.

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 clearly states the action ('Get') and the specific resource ('CapMonster account balance'). It is distinct from sibling tools, which focus on tasks, user agent, or documentation.

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 implies this tool is used to check the account balance, but it does not provide explicit guidance on when to use it versus alternatives or mention any prerequisites. For a simple getter with no parameters, this is adequate but not explicit.

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

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

With no annotations provided, the description fully discloses key behavior: it returns text, restricts allowed URL domains, describes section matching semantics, and details chunked paging with headers and continuation offsets. This is particularly strong for a tool with zero annotation support.

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 contributes distinct operational value: purpose, source selection, URL restriction, section jumping, and paging. Formatting with headers, bullets, and code literals makes it skimmable, and the most important advice is front-loaded.

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?

For a 4-parameter tool with no output schema and no annotations, this description is complete. It covers how to find URLs, what input each parameter expects, how to navigate large pages, and how to handle pagination. An agent has everything needed to call it correctly and interpret the response.

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 0%, so the description carries full responsibility for parameter meaning. It thoroughly explains url (with domain restriction and source index), section (case-insensitive substring matching), and limit/offset (chunked paging behavior and continuation instructions). All four parameters are richly documented.

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 and resource: 'Fetch a CapMonster documentation page by its URL and return its text.' This clearly distinguishes get_docs from sibling API tools like create_task or get_balance, as it is explicitly a documentation fetcher rather than a captcha operation.

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 gives explicit guidance on when to use the tool: 'Use this to read a captcha type's docs' and directs the agent to pick the URL from the llms.txt index. It also provides concrete selection rules for section-based extraction versus paging, covering both common and edge-case usage.

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

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

No annotations are provided, so the description carries the full burden. The verb 'list' implies a read-only operation with no side effects, but this is not explicitly stated. It also doesn't mention authentication, rate limits, or response format. For a trivial list tool, the gap is minor, but there is no proactive disclosure.

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 one concise sentence, front-loaded with the action and resource. The phrase 'sourced from the OpenAPI spec' adds provenance but is not essential; it could be trimmed without loss, yet overall it remains efficient.

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?

For a zero-parameter, no-output-schema tool, the description adequately conveys that it returns a list of supported task types. It doesn't specify the exact format of the list, but the purpose is clear enough for an agent to understand what the tool provides. No critical information is missing for basic invocation.

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 tool has zero parameters, so a baseline of 4 is appropriate. The description adds no parameter information, but none is needed. The schema already fully documents an empty object.

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 clearly states a specific verb ('List') and resource ('captcha task types supported by CapMonster'). It is easily distinguished from siblings like get_balance or create_task, so there is no ambiguity about what the tool does.

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 implies usage: an agent would call this to discover which task types are supported before creating tasks. However, it does not explicitly state when to use it or mention alternatives, nor does it give exclusions. It's implied rather than explicit.

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

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

With no annotations present, the description carries the full behavioral burden and meets it: it discloses the exact return keys (all_parameters, required, description, solution), that nested objects are expanded, and that the flat required list under-reports variant-specific requirements. It also warns that the flat list is a starting point, not the whole contract.

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 front-loaded with the core purpose, then uses a scannable bullet list for return values and a clearly marked warning about limitations. Every sentence adds needed operational context, with no filler or repetition of schema details.

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 one undocumented parameter, no annotations, and no output schema, the description is complete: it explains what to pass, what will be returned, how to interpret the required list, and where to go for further confirmation. Nothing essential for calling this tool correctly is missing.

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 input schema only defines task_type as a string with no description, so schema coverage is 0%. The description compensates strongly by giving concrete examples of valid values ('RecaptchaV2Task', 'TurnstileTask', 'DataDome', 'altcha', 'HUNT') and by explaining that both top-level type names and CustomTask class names are accepted.

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 states a specific verb and resource: 'Return the parameters for a CapMonster task type, from the live OpenAPI spec.' It also clarifies the input (top-level type name or CustomTask class name) and distinguishes itself from related tools like get_supported_tasks and get_docs.

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 gives explicit sequencing: 'Use after get_supported_tasks() to look up what fields a task needs.' It also tells the agent when to switch to get_docs, i.e., when the description field mentions variants/options/modes or when the agent is unsure about per-variant fields.

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

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

With no annotations, the description carries the full disclosure burden and does so thoroughly: it explains the processing vs ready statuses, retry timing, rate limits, 5-minute expiry, ERROR_NO_SUCH_CAPCHA_ID, raw solution shape, and userAgent binding. This far exceeds what a typical description provides.

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: usage guidance, status returns, rate limits, expiry, solution shape, and UA binding are all relevant. It is front-loaded with the single-poll distinction and structured with bullets for easy scanning.

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?

Despite having no output schema and no annotations, the description gives a complete picture: return values, polling cadence, storage lifetime, error behavior, solution extraction pointers, and UA reuse instructions. An agent has enough context to call the tool correctly and interpret its result.

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 has 0% description coverage, so the description must compensate for the task_id parameter, but it never mentions task_id, where it comes from, or its format. The parameter name is self-explanatory, but the description adds no semantic value beyond the 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 opens with a specific verb and resource: 'Fetch a task result ONCE (a single poll).' It clearly distinguishes itself from the sibling get_task_result_wait by emphasizing single-poll behavior, leaving no ambiguity about what the tool does.

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 explicitly says to prefer get_task_result_wait and to use this tool only when driving the poll loop manually. This direct alternative guidance removes any guesswork about when to choose this tool over its siblings.

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

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.