EveryInfra

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

The description frames the operation as pure data fetching that returns JSON ('数据抓取能力...返回结构化 JSON'), implying a read operation, while annotations declare destructiveHint: true. No destructive or write-side effect is disclosed, even though the example action 'post' could imply one, so an agent receives contradictory signals about the tool's safety. Pricing and no-charge-on-failure details are additive, but the contradiction with the destructive annotation dominates.

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?

Four dense sentences, each carrying distinct information: purpose, cost, limit strategy, and prerequisite lookup. The purpose is front-loaded and no sentence is wasted, though the pricing figures add moderate reading load for an agent scanning quickly.

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 description smartly routes the agent to everyinfra_list_capabilities to resolve dynamic platform/action values and max_limit, covering the biggest knowledge gap for a generic dispatcher. However, with no output schema it leaves the JSON return envelope unspecified, and the destructiveHint flag is never reconciled. For a generic tool with dynamic parameters this is adequate but not 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% with example values for all three parameters, giving a baseline of 3. The description adds meaning beyond the schema by stating that valid platform/action values are dynamic and must be confirmed via everyinfra_list_capabilities, and by instructing the agent to set limit to max — guidance that compensates for the absence of enums and static value lists.

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: it calls any one of EveryInfra's data-scraping capabilities ('调用 EveryInfra 任意一项数据抓取能力') and returns structured JSON. This clearly positions it as a generic capability dispatcher, but it never explicitly contrasts itself with sibling everyinfra_search, so differentiation is implied rather than stated.

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 precondition — '先用 everyinfra_list_capabilities 确认 platform/action、必填参数和该能力的 max_limit' — and a concrete execution strategy: max out limit in one call since billing is not per-page. It does not state when to prefer a sibling tool like everyinfra_search over this generic caller, so exclusions are absent.

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 annotations (readOnlyHint=false, destructiveHint=true), the description adds meaningful behavioral context: per-call pricing (¥0.0125/次), billing behavior (空响应不计费 - empty responses not billed), and a ~20k token reliability ceiling. The cost disclosure usefully contextualizes the destructiveHint=true (financial consumption). 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?

A single dense paragraph with no filler: each sentence earns its place (function → cost → use cases → input limits). The core purpose is front-loaded before the cost and usage detail. Slightly packed, but nothing is redundant with the schema.

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 simple 2-parameter tool with no output schema, the description covers the essentials: function, cost model, use cases, and input constraints. The 'OpenAI 兼容' framing implicitly conveys the standard chat-completion response shape. Minor gaps: it doesn't explicitly describe the return format or explain why destructiveHint=true, but these are partially mitigated by the OpenAI-compatibility convention and cost disclosure.

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 both 'model' and 'messages' are already documented in the schema. The description confirms the default model (matching the schema) and reinforces the OpenAI-format/multi-turn semantics of 'messages'. It adds token-limit guidance for content sizing, which is genuinely useful, but the schema carries the heavy lifting — 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?

The description states a specific verb ('调用' - invoke/call) and resource ('EveryInfra 的 AI 文本补全' - AI text completion), with the OpenAI-compatible framing and default model clearly identified. It lists concrete use cases (摘要、翻译、情绪打标、主题分类、结构化抽取) that distinguish it from siblings like everyinfra_search and everyinfra_solve_captcha without needing to inspect their schemas.

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 clear usage context: '适合...批量任务' (suitable for batch tasks) with specific task types, plus an input-sizing guideline ('更长文档请先切块' - chunk longer documents). It doesn't explicitly name alternatives to exclude, but the sibling tools are functionally distinct enough that the implied usage is unambiguous.

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?

The annotations already flag mutation/destruction/idempotency, and the description goes beyond them: explicit user confirmation for activate, account-level rate limits, asynchronous execution, durable idempotency-key rules on timeout/unknown, and immediate unreadability after delete_result. No contradiction with the annotations 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?

The description is dense and packed with high-value caveats, with no filler. It could be more scannable if split into per-action bullets, but each clause earns its place and the most safety-critical activation warning 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 polymorphic action tool with no output schema, the description covers the main behavioral risks, async submission, rate limits, idempotency recovery, and destructive side effects. It leaves some details to the schema and sibling read tool (e.g., exact field formats, how to query status), but the essential invocation decisions are supported.

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 provides constraints like idempotency_key pattern and recipe enum, and the description adds semantic meaning: idempotency keys must be stable and not swapped after timeout/unknown, submit only accepts recipe/source/version/selected_fields/options, and activate requires confirm_activation/policy_version. This is meaningful value beyond the schema, though not every field is individually described.

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 actions (activate, submit fixed-recipe cleanup, cancel, delete_result) and the target resource (the user's own EveryData collection results), so an agent can tell this is the mutation counterpart to everyinfra_data_cleanup_read. It is much more specific than the tool name and clearly distinguishes the tool's scope.

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 explicit when-not guidance ('查询不自动激活', 'submit 只接受...', '不接受任意 prompt/model/tools/URL') and tells the agent to read the original task before retrying. It does not name sibling tools directly, but the exclusions are strong enough to route an agent away from chat/free-form call 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?

Annotations already establish read-only, idempotent, and non-destructive behavior, and the description adds substantial value beyond them: no re-collection, no model calls, no wallet charges, no consumption of cleaning quota, preview creates no task, and source body content is untrusted and cannot authorize actions. These are meaningful behavioral constraints not inferable from the schema or 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?

The description is dense and somewhat long, but the semicolon-separated workflow keeps it structured, and every clause contributes either operational sequencing, side-effect guarantees, or security guidance. Given the tool aggregates 11 sub-actions, the length is justified and 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?

The tool is complex—an 11-action discriminated union with no output schema—but the description covers all actions either by name or by category, adds error semantics for find_job/404, clarifies preview behavior, and warns about untrusted source data. This is sufficient for an agent to select and invoke the correct sub-action 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?

The top-level schema has zero direct parameters and schema coverage is 100%, so the baseline is 4. The description adds useful semantic context, such as get_source_fields returning inferred fields without sample values, find_job using the original idempotency key, and list_recipes discovering fixed recipes, without needing to repeat schema property constraints.

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 specific read operations—get_entitlement, get_source, get_source_fields, list_jobs, find_job, list_recipes, preview, and reading existing tasks, units, results, and exports—making the verb+resource mapping explicit. It also distinguishes itself from the sibling action tool by stating what it will not do: re-collect, call models, charge wallets, consume quota, or create tasks.

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 a concrete workflow order ('先用...再...') and action-specific guidance, such as using find_job with the original idempotency key and interpreting 404 as not-proven rather than never-submitted. It clearly implies the read-only use case, but it does not explicitly name the action sibling as the alternative for write/mutation operations.

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 mark this as readOnly and non-destructive. The description adds useful behavioral context: it is a capability catalog containing required/optional parameters, per-request limits, and unit price, and it does not execute scraping. It does not mention pagination or output structure, but that is a minor gap for a simple discovery tool.

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?

Two sentences deliver dense, relevant information: the first states the resource and its contents; the second states when to use it, what it reveals, and which sibling to use for chat. No filler or 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 tool with no required parameters, no output schema, and simple read-only annotations, the description supplies enough context for an agent to call it correctly: the purpose, the optional filter, the data it exposes, and the intended sequencing before everyinfra_call_api.

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 single optional platform parameter is already documented with examples. The description relates platform to the broader workflow (check platform/action before calling the API) but does not add extra meaning about the parameter itself, such as what happens when it is omitted.

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 action ('列出...平台与数据抓取能力') and resource, with concrete scope (87 平台 / 387 项) and categories (搜索/详情/评论/主页等). It also clearly separates this tool from everyinfra_call_api and 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?

The description explicitly says to use this before calling everyinfra_call_api to inspect platform/action, parameters, max_limit, and pricing. It also provides an exclusion: AI conversations should use everyinfra_chat instead, and it notes this only covers data scraping.

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 carry readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond that: the tool is free and not billed, and the output contains type names, parameters, and solution shapes. It does not describe exact response formatting, but for a read-only listing tool this is sufficient extra transparency.

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 most important fact (list of 53 types), then immediately gives the critical usage context and the actionable output expectations. Every sentence earns its place without fluff or repetition, and the bold callout makes the prerequisite relationship salient.

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 read-only listing tool with a single optional parameter, the description is complete: it tells the agent what the tool returns, why that matters for the downstream solve_captcha call, and that there is no cost. The schema covers the filter parameter, so nothing needed 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 for the single optional 'type' parameter is 100%, so the schema already fully documents the parameter. The description mentions type names as part of the output but does not explicitly explain the filtering behavior of the 'type' parameter; it adds no meaning beyond the schema, so the baseline 3 applies.

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 a precise resource (the 53 CAPTCHA/human challenge types). It also immediately frames the tool as a prerequisite for everyinfra_solve_captcha, which clearly distinguishes it from the sibling tools and from 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?

The description explicitly says to use this before calling everyinfra_solve_captcha and explains why, naming the exact sibling workflow. It does not state explicit when-not-to-use conditions or list alternative tools, but the intended usage context is clear enough.

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?

The description adds behavioral context beyond annotations: harvest is a long task taking seconds to minutes, semantic mode=deep is '更慢也更贵', and failure/empty results are not billed. Annotations declare destructiveHint=true, and while the description does not explain destructive behavior, it also does not contradict it; the provided latency and cost details justify the score.

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 list format is organized and each sub-tool line is dense with information, but the description is quite long and contains a truncated sentence ('它回答的不是「搜到了什么」，而') that breaks the structure and indicates an editorial flaw. It is not as concise as it could be, and the incomplete sentence hurts overall quality.

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 description covers all 17 sub-tools with enough context to invoke them, and it provides cost/delay warnings. However, the crosscheck description is incomplete, so its core value is partially unclear. Additionally, there is no explanation of return values or output structure, and the 'params' object format is only loosely illustrated, leaving some ambiguity for an agent.

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 covers both parameters, with 'tool' as an enum and 'params' as a generic object. The description substantially enriches parameter meaning by specifying expected inputs per sub-tool: URL inputs for lens/similar/read, natural-language queries for crawl/semantic, kind=patents for scholar, and full=true for deep. This goes well beyond the schema's single generic example.

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 identifies the tool as a search dispatcher and distinguishes 17 sub-tools with specific verbs and objects (e.g., 'crawl: 爬一个站点的多个页面并取回正文', 'lens: 反向图搜'). It differentiates internal modes well, but the crosscheck entry contains a truncated sentence ('它回答的不是「搜到了什么」，而') that leaves its distinguishing purpose incomplete, preventing a perfect score.

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?

Explicit usage guidance is provided for several sub-tools: harvest '只在 crawl 也拿不到时用', crosscheck is recommended for asserting concrete facts, semantic is suggested when keyword search fails, and forum is described as an independent evidence source from official docs. This clearly helps an agent select the right sub-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 indicate a non-read, potentially destructive/side-effect operation. The description adds meaningful behavioral context beyond that: it is paid per success, refunds on failure, and warns that some captcha types require the user to supply a proxy because the returned cookies bind to the solving IP. This is exactly the kind of practical behavioral disclosure 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?

The description is three sentences, front-loaded with the core purpose and pricing, then gives usage context and a pointer to the sibling tool. Every sentence earns its place with 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?

Given the large enum of captcha types, no output schema, and nested params, the description covers the key operational facts: what it returns, cost model, when to use it, and how to discover type-specific parameters. It could mention the return format or latency in more detail, but the pointer to list_captcha_types reasonably fills the main 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 100%, so the baseline is 3. The description adds value by clarifying that parameters vary by type and advising the agent to check everyinfra_list_captcha_types before selecting parameters. This helps an agent understand that the generic 'params' object is intentionally type-specific.

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 action (solve a captcha or human challenge) and the resource (captcha/challenge), and explains it returns a directly usable solution. It differentiates itself from sibling tools like everyinfra_list_captcha_types by being the actual solving tool.

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 explicitly says when to use it: when a target site is blocked by Turnstile, reCAPTCHA, hCaptcha, Cloudflare, GeeTest, etc. It also instructs to first use everyinfra_list_captcha_types to confirm parameters. It does not spell out negative cases or alternatives, but the use context is clear.

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