EveryInfra

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

Annotations already provide readOnlyHint=false and destructiveHint=true, and the description does not contradict them. It adds useful context about billing, failure/empty result not charging, reservation auto-restore, and async job creation with polling, but it does not explicitly explain the destructive side effect implied by destructiveHint, relying on the annotation.

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?

Each sentence carries operational value: what it does, pricing, failure safeguard, prerequisite, and async behavior. The core purpose is front-loaded, and there is no redundant 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 generic tool with a nested params object, high schema coverage, and no output schema, the description explains the return contract (structured JSON or job_id) and directs the agent to list_capabilities for capability-specific details. It is adequate for correct invocation, though it does not enumerate possible error 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?

Schema coverage is 100% and already documents all parameters, so baseline is 3. The description adds extra semantics: set limit to maximum in one call, use mode=async for slow/large tasks, and verify params via list_capabilities, which clarifies parameter usage 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 clearly states the tool calls any EveryInfra data-fetching capability and returns structured JSON, with examples of actions such as search/profile/user_posts. It does not explicitly contrast itself with siblings like everyinfra_search, so agents must infer its generic role rather than being told directly.

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 instructs to first use everyinfra_list_capabilities to confirm platform/action, required parameters, and max_limit, and recommends mode=async for slow or large-limit tasks. This gives a clear precondition and selects the right mode, but it does not state when to prefer this tool over specific 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?

Annotations already declare destructive/idempotent/openWorld, but the description adds substantial context beyond them: account-level 5 RPM, concurrency 5, daily 1,000 and first-period 30,000 unit caps; cleanup does not deduct wallet funds; the task is executed asynchronously by the server; and delete_result makes the body immediately unreadable. The idempotency retry prohibition and the explicit permission requirement for the activate key are also operational details the annotations cannot convey.

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?

Content is dense with substance and nothing is obviously filler, but it is delivered as a single undifferentiated paragraph mixing Chinese and English, so the four distinct action branches are not structurally separated. For a four-action tool this hurts scanability, even if the length itself is defensible.

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 complex oneOf-discriminated multi-action tool with rich annotations and no output schema, the description covers the activation gate, submit input restrictions, retry/idempotency rules, rate limits, billing non-impact, and the destructive effect of delete_result. It is largely complete; minor gaps remain around what cancel does and what the successful submit/activate responses contain.

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, but the description adds real constraint meaning: submit accepts only recipe/source/version/selected_fields/options plus a stable idempotency_key and rejects arbitrary prompt, model, tools, or URL. It also ties policy_version and confirm_activation semantics to activate, going beyond the raw schema types.

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 enumerates the four concrete operations (activate, submit a fixed-recipe cleanup, cancel a job, delete a result) with a specific verb+resource for each, so an agent can tell what the tool does. It does not name the sibling `everyinfra_data_cleanup_read` directly, though '查询不自动激活' and '先读原任务' gesture at it, so sibling differentiation is only implicit.

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 real when-to-use conditions: activate requires explicit user confirmation plus the current policy_version, submit is scoped to the caller's own EveryData collection results, and queries never auto-activate. It also prescribes retry behavior ('超时或 unknown 不得换幂等键重发；先读原任务'), which is genuine usage guidance, though it never names the read sibling explicitly as the alternative.

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/idempotent annotations, it states that this will not re-collect data, call models, charge the customer wallet, or consume cleanup-success quota, and that preview does not create tasks. It also flags that source body content is untrusted and that instructions inside it must not be taken as authorization, plus the 404-does-not-prove-never-submitted subtlety for find_job. That is genuinely useful context layered on top of the annotations.

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?

It is a dense, multi-clause sentence, but the workflow steps are front-loaded and each clause carries distinct information (ordering, safety guarantees, injection warning). Only the sheer density and single-sentence packaging keep it from a 5.

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 complex 11-variant read tool with no output schema, the description supplies workflow ordering, safety semantics, and a security caveat, and the annotations cover the read-only profile. An agent has enough to call it correctly, though parameter-level detail for some variants (pagination limits, cursor behavior) is left implicit.

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% and the discriminator enum already documents every action, so the schema does the heavy lifting (baseline 3). The description adds value by explaining the intent and ordering of each action variant (e.g., find_job using the original idempotency key, preview against still-valid collection results), which goes beyond the raw field definitions.

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 names concrete sub-actions (get_entitlement, get_source, get_source_fields, list_jobs, find_job, list_recipes, preview, and reading jobs/units/results/exports) and frames the whole tool as a read/inspection surface, which lets an agent separate it from the write sibling everyinfra_data_cleanup_action. It is a bundle of read operations rather than one crisp verb+resource, so it stops short of a 5, but the intent 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?

Usage is spelled out as an ordered workflow: first query entitlement, then source/version/fields, then list/find jobs, then list recipes, then preview or read existing artifacts. The exclusion of re-collection and task creation clarifies when this is the right (read) choice. It never names the write sibling explicitly, so it lacks the full when-not/alternative routing 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?

Annotations already establish read-only and non-destructive behavior. The description adds useful behavioral context: it is a pre-call discovery/capability listing, not the actual data fetch, and it excludes cleaning workflows. There is no contradiction with annotations.

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?

Three dense sentences each earn their place: the first defines the resource, the second gives explicit usage guidance, and the third sets boundaries. Front-loaded and 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?

Even without an output schema, the description enumerates the key output fields (platform/action, parameters, max_limit, price) and specifies when to use it. For a read-only metadata listing tool with a single optional parameter, nothing essential 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 optional platform parameter is already described with examples in the schema. The description does not add much about the input parameter itself, but it does explain what information will be available in the output, which is sufficient given the schema's coverage.

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 uses a specific verb and resource: it lists EveryInfra's supported platforms and data-scraping capabilities, including scale (89 platforms/405 items) and capability types. It clearly differentiates this from sibling tools by stating it only covers data scraping and pointing to separate cleaning 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?

Explicitly tells the agent to use this before calling everyinfra_call_api, and specifies what to look for: platform/action, required/optional parameters, max_limit, and unit price. It also states what it does not cover—EveryData cleaning—and routes that to the appropriate 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 already declare readOnlyHint=true, so the safety profile is covered; the description contributes non-redundant context by disclosing that the call is free/not billed and that returned solution shapes vary (token/cookie/text/number/fields/points/boxes/tokens), implying how downstream usage differs. It stops short of describing pagination or output structure in detail.

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 noun phrase and the count, then the actionable 'call this first' guidance, then the payoff. The parenthetical about solution shapes is dense but earns its place; the bolding adds scannability without much bloat.

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 carries the return-value burden and does so: it states the volume (53 types) and the three categories of information returned, including the varied solution shapes. That is enough for an agent to know what it will get and how to use it.

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% and there is a single optional 'type' filter already documented in the schema. The description's mention of 'type 名' refers to what the tool reports rather than adding input syntax or constraints, so this sits at the baseline.

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?

Specific verb (列出/List) plus resource (CAPTCHA types) and even the exact count (53 种验证码与人机挑战类型). It explicitly positions itself against the sibling everyinfra_solve_captcha, so an agent can distinguish it without opening either 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?

It gives an explicit ordering rule: call this before everyinfra_solve_captcha. It even enumerates what to look for (type name, required/optional params, and the solution shape), which converts 'when to use' into concrete preparatory guidance.

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 openWorldHint=false, but the description routes to web search, news, crawl, forum, and scholar, all of which retrieve from external internet sources. That directly contradicts the closed-world annotation. The description does add useful billing/fallback context, but the contradiction forces a 1 under the rubric.

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 the dispatch rule and uses a compact list for the 17 sub-tools. The description is long, but the length is largely justified by the number of routing options; a few explanations are more verbose than necessary but still help selection.

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 17-way dispatcher with no output schema, the description supplies behavioral and output hints: map returns URLs only, crosscheck returns layered sources, read has fallback, harvest is long-running, and failed/empty results have billing recovery. It omits auth/rate-limit details and full return semantics for every sub-tool, but is largely complete.

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% for the top-level `tool` enum and `params` object, but nested per-tool parameters are not documented in the schema. The description compensates by adding meaning for several sub-tools: deep `full=true`, scholar `kind=patents`, semantic `mode=deep`, and web support for site/region/time/pagination.

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 '检索' and that 17 sub-tools are selected via the `tool` parameter, then enumerates each sub-tool. The dispatch purpose is clear, though it does not explicitly distinguish the parent everyinfra_search from sibling tools such as everyinfra_call_api.

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 routing rules: use crosscheck when asserting specific facts, use harvest only when crawl cannot get content, use lens for reverse image search versus media, and treat forum as an independent evidence source. It provides when-to-use and when-not-to-use guidance among the 17 sub-tools.

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 annotations with genuinely load-bearing behavior: success-based billing (USD 0.000139–0.004583/call) where failures or empty results never become a final charge and reservations are auto-restored, plus the critical proxy/IP-binding caveat for types that return a Cookie. That proxy warning is exactly the kind of trap an agent would otherwise fall into.

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 purpose, then cost, then trigger condition, then the parameter caveat — a sensible ordering with little padding. It is dense (heavy bolding and a sizeable price range) but every clause carries operational 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?

With no output schema, the description does state what comes back ('a directly usable solution') and covers cost, trigger, and the proxy binding caveat. It could say more about the returned shape or lifetime of solutions per type, but for a 2-parameter tool with a 100%-documented schema this is close to sufficient.

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 adds real value by explaining that the params object is type-dependent and that the correct keys must be discovered via everyinfra_list_captcha_types rather than guessed. The proxy warning is also echoed in the schema, so it is not purely additive.

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?

Specific verb+resource ('solve a CAPTCHA or human challenge') plus the return value ('returns a directly usable solution'). It also separates itself from the sibling catalog tool by pointing at everyinfra_list_captcha_types as the type-lookup step, so an agent knows which of the two to call and when.

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?

States the trigger condition explicitly ('when the target site is blocked by Turnstile / reCAPTCHA / hCaptcha / Cloudflare challenge page / GeeTest etc.') and gives the prerequisite alternative/first step ('parameters differ per type, first confirm with everyinfra_list_captcha_types'). Routing is unambiguous.

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