EveryInfra

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

Beyond the annotations' safety profile, the description discloses billing behavior (per-tier pricing, per-element billing for multi-target arrays, rows_per_unit), failure semantics ("failed calls and empty results leave no final charge ... anything reserved is restored"), and pagination mechanics (next_page_token/page_token, repeated tokens on rows, page_size_varies). This is substantial behavioral context an agent cannot derive from structured fields.

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 core purpose and pricing lead the paragraph, so it is front-loaded, and for a paid meta-dispatch tool most clauses (billing, pagination, async) earn their place. It is nonetheless a single dense run-on passage where pagination and billing clauses compete for attention, which slightly hurts scannability.

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?

With no output schema, the description carries the return-value burden, and it does explain the async job_id path and next_page_token pagination, plus the discovery prerequisite. It does not describe the general shape of the structured JSON response or error behavior, so it is nearly complete but leaves some gaps for a tool with nested params.

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 100%, so the baseline is 3, but the description adds real meaning: it explains mode=async's return (job_id), and contextualizes params such as limit, billing-relevant multi-target arrays, and page_token sourcing from next_page_token. However, the schema properties themselves are only lightly annotated, so some param meaning still relies on the catalog lookup it recommends.

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 concrete verb+resource ("Call any EveryInfra data capability and get structured JSON") and implicitly distinguishes itself from the discovery and async-read siblings by routing to everyinfra_list_capabilities and everyinfra_get_job. The opening sentence partly echoes the title ("Call a data capability"), so it is clear but not maximally differentiated on its own terms.

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 gives an explicit prerequisite ("Check platform/action, required params and max_limit or page_size with everyinfra_list_capabilities first") and an explicit alternative path ("for slow tasks or large limits pass mode=async ... read the result with everyinfra_get_job"). The sync-vs-async condition is stated outright, leaving nothing to inference.

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 annotations only covering safety hints, the description carries the operational burden well: exact billing behavior (free for topped-up accounts, nothing deducted), tiered rate limits by cumulative top-up, the ai_topup_required error, and the 45,000-character ceiling with a recovery instruction. This is precisely the beyond-annotation context an agent needs.

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?

Front-loaded with the core capability, then limits, billing, and use cases in single-sentence units. Dense but nearly every clause carries operational information — no filler, though the pricing parenthetical is slightly heavy.

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 no output schema, the description covers errors, limits, rate limits, cost, and use cases. The only real gap is an explicit statement of the return shape, though 'OpenAI-compatible' implies the response envelope.

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 100%, so baseline is 3; the description adds the message-length constraint (45,000 characters total) and points to GET /api/v1/models for valid model names, which is meaning beyond the schema's inline enum text.

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?

Names the specific capability — OpenAI-compatible text completions with multi-turn history — and enumerates concrete jobs (summaries, translation, sentiment labels, topic classification, structured extraction). No sibling in the list does text generation, so the resource boundary is unmistakable.

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 positive usage context ('Good for cleaning collected data: summaries, translation, sentiment labels...') and failure-driven guidance ('split long documents into several calls' on input_too_large). It does not name an alternative tool or state when NOT to use it, which keeps it 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.

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

Well beyond the annotations, it discloses that any account key works, nothing is charged, retries are idempotent, and the same capability plus error code within 24 hours merges into the existing ticket. It also covers the secret-hygiene constraint (never include API keys or passwords; label IDs so a bare long ID isn't read as a secret) and the response channel and latency (24/7, first reply ~10 minutes, replies in-ticket plus owner email).

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?

Purpose and consent are front-loaded and almost every sentence carries operational information. It is a single very dense block, though, and details like the REST path duplicate what the schema and sibling tool cover — close to overloaded, but not padded with filler.

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 7-parameter mutation tool with no output schema, the description supplies everything an agent needs: what it returns, when not to use it, consent requirements, retry/merge semantics, and where to follow up. Nothing material is left to inference.

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 100%, so the baseline is 3; the description mostly restates what the schema already documents (subject is one line, description carries what/when/error/expected). It adds only marginal value, such as advising that other IDs be written with a label so a bare long ID isn't mistaken for a secret. Idempotency and category behavior are already covered by the schema text.

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 — 'Open a ticket with EveryInfra's human support team' — and names the return value (ticket number plus a link the account owner can open). It is clearly distinguishable from siblings such as everyinfra_get_ticket (progress/replies) and everyinfra_call_api (the failing call itself).

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 explicit triggers (calls keep failing or return wrong/missing data, top-up/charge/refund, requesting a new platform, capability or field) and an explicit exclusion (errors whose fault is the request or account need a fix or the user, not a ticket), plus a pointer to the error's support field for a ready draft. It also states the consent prerequisite (ask the user first) and names everyinfra_get_ticket as the follow-up path.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts: the call is free, any key works regardless of scope, and the rate_limit figures are aggregate-across-keys versus per-key. With no output schema, the enumerated return fields carry real weight.

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?

Front-loaded with the one-line purpose and cost/safety claim before the return inventory, which is the right order. The structured bullet list is efficient, though the discount line packs nested parenthetical definitions (rate, threshold_usd, gap_usd) that read more densely than the rest.

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?

No output schema exists, and the description fully compensates by naming every returned field group and its sub-fields, including nested structures like bonus_expiring and per-key vs aggregate usage. An agent knows exactly what it will receive without a trial call.

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?

There are zero parameters, so the baseline is 4 and no semantic burden exists. The description correctly avoids inventing inputs and instead concentrates on outputs.

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+resource: 'Read the account behind this API key', and immediately scopes it ('Free, read-only, any key works'). The bulleted return inventory further separates it from siblings like everyinfra_call_api or everyinfra_get_job, which are action/result oriented rather than account-state oriented.

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?

'Check the balance before a batch of paid calls' gives a concrete trigger for invocation, and 'every paid call's billing also carries balance_after_usd' explains the relationship to paid usage. It stops short of naming explicit alternatives or when-not-to-use conditions, so it lands at 4 rather than 5.

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?

Goes well beyond the readOnlyHint/destructiveHint annotations by disclosing that the call is free and exempt from the per-minute limit, that only same-API-key jobs are visible, and what each terminal/non-terminal status means. It also warns explicitly not to resubmit on submit_unknown and tells the agent to follow next_action.

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?

Front-loads what the tool does and its cost profile, then packs status-specific guidance into a compact semicolon-separated paragraph. Every clause is actionable and earns its place.

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?

With no output schema, the description carries the full return-shape burden and does so: results rows, next_page_token for paged actions, error.reason, error.charged, and next_action. An agent has enough to call the tool and interpret all meaningful responses.

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 single job_id parameter has 100% schema description coverage, and the description adds only the provenance context that it comes from everyinfra_call_api(mode=async). With the schema already documenting the parameter, the baseline 3 is appropriate.

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 (Read) and resource (a job), and ties it directly to the originating tool by naming everyinfra_call_api(mode=async). This clearly distinguishes it from siblings like everyinfra_call_api, everyinfra_requests, or everyinfra_usage.

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?

Explicitly says when to call based on job status: retry later for submitting/running/finalizing, stop for succeeded, inspect error.reason/charged for failed, and do not resubmit for submit_unknown. This turns the tool into a complete polling protocol rather than leaving the agent to infer behavior.

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?

Annotations already say readOnly and non-destructive, but the description adds consequential detail the annotations cannot: a 100-message cap, a permission model that differs between self-opened and account tickets, deterministic "ticket_not_found" for wrong numbers, and no cost. It also names the equivalent REST endpoint, giving a precise mental model of the operation.

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?

Front-loaded with what is returned and when to call it; the parameter format, permissions, and error behavior follow in logical order. Nearly every clause earns its place, though the "Free; the same result as GET..." tail is optional garnish.

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?

With no output schema, the description carries the burden of describing returns and does so concretely (status, next steps, latest 100 messages). For a single-parameter read tool, nothing an agent needs in order to call it 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?

Schema coverage is 100% and the schema already documents ticket_id as "#N in the console and emails." The description still adds value by clarifying it must be a plain integer without the # and by stating the failure mode for any other number. That is genuine added meaning, though it partly restates 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?

States a specific verb and resource ("Read one support ticket") and immediately enumerates the payload: status, what happens next, and the latest 100 messages including support replies. An agent can distinguish it from everyinfra_create_ticket and everyinfra_list_requests without opening any schema.

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 explicit triggers: "Use it after everyinfra_create_ticket to check progress, or when the user asks whether support has answered." It also defines the access boundary — the key that opened the ticket can read it, others need "support:read" — which tells the agent when this call will fail versus succeed.

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?

Beyond the readOnly/non-destructive annotations it states there are no side effects ('creates no order and charges nothing'), the cost profile ('Free'), and the auth scope ('Any key can use it'), plus a known failure mode. It also names the two returned fields, which matters since no output schema exists.

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?

Five short sentences, front-loaded with what is returned and followed by when to call it and what it costs. Every sentence carries either a return detail, a trigger, or a constraint.

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?

With no output schema and no parameters, the description is the only place to learn the return fields and failure modes, and it covers both. An agent has everything needed to call it and interpret the response 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?

The tool takes zero parameters, so there is no argument semantics to explain and the description does not need to compensate for anything. It spends the space on return values instead, which is the only useful detail available.

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?

It gives a precise verb plus resource and even names the exact values returned ('url', 'balance_usd'), so there is no ambiguity about what the tool does. It implicitly separates itself from purchasing tools by stating it creates no order, though it never names a specific sibling such as everyinfra_create_ticket for billing escalation.

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 lists concrete trigger conditions (a call failing with quota_exhausted or ai_topup_required, or the user asking how to add funds) and a negative case (accounts whose service provider handles top-ups return topup_unavailable). This is explicit when-to-use guidance, not inference.

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?

Annotations already declare read-only/non-destructive/non-open-world, and the description adds useful context beyond them: it is free, it is data-collection only, and it returns platform/action, required and optional params, row limits (max_limit vs page_size), price, allowed values, and field meanings. There is no output schema, so this return-content disclosure carries real weight.

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?

Front-loaded and dense with useful information; every clause is relevant. It is slightly cramped, with a long parenthetical and a multi-clause second sentence that could be broken up, but there is no filler.

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 one-param discovery tool with no output schema, it covers what is returned, when to call it, cost, parameter effects, and how it differs from everyinfra_call_api and everyinfra_chat. Nothing material for correct invocation 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?

Schema coverage is 100% and already documents the optional platform param with examples. The description still adds value by explaining the effect of supplying it (you additionally get allowed values, returned fields, and their meanings), which goes beyond the schema text.

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 ('List EveryInfra's data platforms and capabilities') and quantifies scope (106 platforms / 573 capabilities). It explicitly separates itself from both key siblings: it must be called before everyinfra_call_api and is not for chat (everyinfra_chat).

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 an explicit sequencing rule ('Use it before everyinfra_call_api') and an explicit exclusion ('for AI chat use everyinfra_chat'). The conditional use of the platform param ('Pass a platform to also get allowed values...') is also spelled out.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: the result is described structurally (name/params/solution shape) and the cost note "Free" is a useful behavioral signal. It does not cover pagination or rate limits, so it lands at 4 rather than 5.

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 leads are front-loaded (what it lists, when to call it) and the sentence earns its place, but the long parenthetical enumerating solution shapes (token / cookie / text / number / fields / points...) is dense and slightly list-heavy for a description.

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?

No output schema exists, so the description carries the burden of describing return values, and it does: the three things returned and the taxonomy of solution shapes are spelled out. Nothing an agent needs to call this 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?

Schema coverage is 100% with a single optional filter that the schema itself documents with examples (turnstile / recaptcha_v2 / cloudflare_challenge). The description adds no syntax or format detail for the param, so the baseline 3 is correct.

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 ("List the 52 CAPTCHA and bot-challenge types EveryInfra solves"), and explicitly distinguishes itself from the sibling everyinfra_solve_captcha by naming it as the downstream consumer. An agent can tell exactly what this returns.

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 explicit sequencing guidance: "Call it before everyinfra_solve_captcha" and explains the payoff (type name, params, and solution shape). This names the alternative tool and the condition that selects it, leaving nothing to inference.

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?

Annotations already declare readOnly/destructive=false, so the bar is lower; the description still adds real value by disclosing the required 'requests:read' permission, how default vs product-line-limited keys differ, and that lookups include the charge's final state and any async job. It stops short of describing pagination behavior beyond what the schema shows.

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?

Front-loads purpose and the two modes before the permission note; every sentence carries information. The permission explanation is somewhat long but is actionable for an agent that might otherwise hit an auth failure.

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?

With no output schema, the description enumerates the returned fields, both lookup modes, the charge-state semantics, and the auth prerequisite, leaving nothing an agent needs to call it 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 100%, so the baseline is 3, but the description adds meaning: it clarifies that request_id is the X-Request-Id of any call and that the other params are ignored when it's given, plus what failed_only filters. This genuinely enriches the schema descriptions.

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 ('the account's call records, newest first') and enumerates the returned fields, so an agent knows exactly what this yields versus sibling tools like everyinfra_call_api or everyinfra_list_capabilities.

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?

Clearly explains the two modes: passing request_id selects a single-call lookup, and failed_only=true restricts to failures. It gives clear context for each path but does not explicitly name a competing sibling or state when not to use this tool.

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?

Annotations declare readOnlyHint=false and destructiveHint=true, and the description adds real context beyond them: searches are billed ('failed or empty searches leave no final charge, anything reserved is restored'), harvest is long-running ('tens of seconds to minutes'), semantic mode=deep is slower and costs more, and read auto-retries other fetch paths. It does not explain why the tool is flagged destructive/readOnly=false beyond the reservation/refund note, so a small gap remains.

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?

Front-loaded with the core sentence before the dispatch list, and each indented line carries one sub-tool with only the discriminating detail. Despite its length the text is dense with necessary routing information for 17 sub-tools, and the trailing warning is placed where it is read last but remembered.

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?

With no output schema the description needn't explain returns, and it does cover routing, cost/latency caveats and safety implications. The one real gap is that `params` is an untyped nested object, so the agent has no authoritative schema for each sub-tool's arguments and must infer them from inline hints.

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 100%, so the `tool` enum and `params` object are nominally documented, but `params` is a free-form object ('The tool's params') with no per-sub-tool schema. The description compensates by naming concrete params inline (full, kind=patents, mode=deep, q/num in the example, and web's site/region/time-window/paging), adding meaning the schema lacks — though coverage of all 17 sub-tool param sets is incomplete.

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 opening sentence names the specific verb+resource (search and retrieve sources) and immediately discloses the dispatch mechanism ('17 tools, chosen with `tool`'), then enumerates every one with a distinct one-line purpose. An agent can distinguish crawl vs map vs harvest vs read without opening any other schema, and the tool is clearly separated from the account/billing/key siblings.

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?

Nearly every sub-tool line carries an explicit use/don't-use rule: 'use it only when crawl cannot get the data' (harvest), 'the opposite direction of media' (lens), 'something keyword search cannot do' (similar), 'use crosscheck to assert a specific fact'. The final warning line names the alternative tool for a concrete condition, which is exactly the when-to-use guidance an agent needs.

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?

Adds substantial context beyond the annotations: a cost range, billing semantics ('charged per successful solve', per-token for castle, no final charge on failure with reservation restored), and a proxy/IP-binding caveat for certain types. It stops short of describing latency, polling, or what the returned solution looks like, so it is not fully complete.

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?

Front-loaded with the core action, then pricing, then usage conditions and prerequisite. The pricing range is a bit dense but each clause carries operational information; no filler sentences.

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?

Covers cost model, failure billing, per-type param discovery, and the proxy caveat for a tool with nested params and no output schema. Only gap is that it does not hint at whether solving is synchronous or job-based (a sibling everyinfra_get_job exists), which an agent might need.

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 100% (baseline 3), and the description goes further by warning that params vary per type and pointing to everyinfra_list_captcha_types. The IP-bound proxy caveat in the schema is reinforced, adding real meaning beyond field names.

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 ('Solve a CAPTCHA or bot challenge and get a ready-to-use solution') and enumerates the challenge families (Turnstile / reCAPTCHA / hCaptcha / Cloudflare / GeeTest). This clearly separates it from administrative siblings like everyinfra_account or everyinfra_usage.

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 an explicit trigger condition ('Use it when a target site is blocked by ...') and a prerequisite/alternative action: check per-type params with everyinfra_list_captcha_types first. Both when-to-use and the routing to a sibling are spelled out.

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