FetchPan

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

Annotations already declare readOnlyHint and openWorldHint, covering safety and scope. The description adds that it consumes no quota, which is useful but not rich behavioral context (e.g., latency, auth, or caching semantics).

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, front-loaded with the core purpose as a direct question, followed by a concise usage note. Every sentence earns its place with no waste.

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 simple check tool with an output schema and annotations, the description covers purpose and usage adequately. It leaves slight ambiguity about whether the 'working right now' check is live or cached, which could matter given openWorldHint=false.

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% for the single `url` parameter, and the description adds no new meaning beyond what the schema provides. 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 clear verb (check) and resource (link), specifying it verifies site support and current availability. Names the `download` sibling as a follow-up, though it does not explicitly differentiate from `list_supported_sites`.

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 to call it before `download` when unsure, and notes it uses no quota. No explicit when-not condition is stated, but the context is clear enough for an agent to act.

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 a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds real value beyond that: 'Nothing is charged by calling this' reassures the agent no monetary side effect occurs, which is not derivable from the hints. It omits that repeated calls create multiple distinct links (relevant given idempotentHint=false).

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 short sentences, front-loaded with the action and return value, with zero filler. Every sentence 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?

An output schema exists so return values need no explanation, and the description still notes the URL is the key output. For a one-parameter create tool the coverage is strong; missing only edge details such as link expiry or auth requirements.

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 single parameter's description ('A code from list_packages') already routes the agent to the correct source. The prose adds nothing about package_code, so 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?

Specific verb+resource: 'Create a payment page for a traffic pack and return its URL.' The outcome (a URL) is stated up front, which cleanly separates it from siblings like start_download, get_download_link, and check_link.

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?

'Give the URL to the user: only a person can pay it' tells the agent what to do with the result and that the agent itself cannot complete payment. It does not name alternatives or explicit when-not conditions, but the context is clear and actionable.

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 real context beyond annotations: it blocks up to wait_seconds, surfaces status/job_id values, and discloses an auth carve-out ('No token needed for the first free files'). Given readOnlyHint=false and idempotentHint=false, it could have gone further on cost/quota implications of tier='fast' and on repeat-call behavior, which is the remaining gap.

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 sentences, front-loaded with the outcome, then branches, then the wait/auth caveat — no wasted preamble. The parenthetical '(open folders with list_files)' is slightly intrusive but carries usable routing 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 six parameters, a full schema, and an output schema already defining return shapes, the description supplies exactly the missing piece: the state machine (pick_required → share_id/file_id, running → get_job) and the auth caveat. Nothing needed to invoke it correctly is absent.

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 earns above that by describing the pairing relationship the schema cannot express — share_id and file_id must be supplied together, drawn from a prior pick_required answer, with folders opened via list_files. The tier parameter's free/fast trade-off is still not explained anywhere.

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 ('Fetch a link and return a download URL') plus the compound-call value proposition ('in one call'). It also names the exact follow-up siblings (list_files, get_job, get_download_link) so an agent can place it in the flow rather than confusing it with a raw link checker.

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 conditional guidance for the two non-happy paths: status 'pick_required' → re-call with share_id + file_id, and status 'running' → get_job then get_download_link. It does not, however, say when to prefer this over the sibling start_download or check_link, so the entry-point choice is left 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the result is scoped to the caller's token, which is useful context, but says nothing about auth failure behavior or rate limits. It mostly restates fields the output schema already exposes.

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?

One front-loaded sentence with a compact field list and no filler. The phrasing is slightly informal ('The account behind the token') but nothing is wasted.

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 an output schema present, the description need not explain return values, and it is complete enough for a no-argument read tool. The only real gap is the absence of any usage or auth-failure context, which is minor for a token-scoped getter.

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 the baseline of 4 applies. There is nothing parameter-wise for the description to clarify, and it correctly avoids inventing inputs.

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 the resource (the account bound to the calling token) and enumerates its contents — email, traffic balance in bytes, free files per day, last downloads. The verb is implied rather than stated, but no sibling tool touches account data, so an agent can distinguish it easily.

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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives. The token-scoped nature ('behind the token') hints at the usage context, but nothing tells the agent when this call is appropriate versus other read tools like list_packages.

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 explains why readOnlyHint=false matters: a free link consumes one of the account's daily free files and a fast link draws down the account balance — a real side effect not expressed by the annotations. It also confirms repeat calls return the same link, consistent with idempotentHint=true. It omits error behavior for non-succeeded jobs and any auth/permission requirements.

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 short sentences, front-loaded with the core action and free of filler. The tier explanation partially restates the schema's own tier description, a minor redundancy, but nothing is padded.

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 two-parameter tool with an output schema, this covers the key unknowns: the succeeded-job precondition, the cost model per tier, and idempotency. Missing only failure-mode behavior (invalid or unfinished job_id) and auth requirements.

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 tier values are already documented; the baseline is 3. The description goes slightly beyond by tying tier to consumption behavior (quota vs balance) and by noting that the same job_id + tier pair yields the same link, adding per-parameter behavioral meaning.

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 ('Get the download URL') and adds a real precondition ('of a succeeded job'), which meaningfully narrows scope. It does not, however, distinguish itself from close siblings like download, check_link, or start_download, leaving the agent to infer the boundary.

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 only implied: the agent can infer this is called after a job has succeeded, and the tier sentence hints at the free-vs-paid tradeoff. There is no explicit when-to-use-vs-alternatives guidance, so the agent still cannot tell whether this replaces or precedes 'download' or 'check_link'.

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 and openWorldHint=false, so the safety profile is covered. The description adds the state model (queued/running/succeeded/failed) and the success-case semantics for 'free' and 'fast', but with an output schema present much of the field-level detail is duplicated rather than new.

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 short sentences with zero waste; the state enumeration is front-loaded so the most useful information comes first.

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 an output schema documenting the response and annotations covering read-only safety, the description only needs to frame the operation, which it does. Minor gaps remain around error/not-found behavior and polling expectations, but nothing essential for a correct call 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?

There is a single required job_id with 100% schema description coverage, so the schema already explains it ('Job id from start_download or download'). The description adds no further parameter semantics, which is the expected baseline when the schema does the work.

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 resource and action ('Status of a job') and enumerates the four possible states, so an agent immediately knows this is a read of job state. It does not explicitly differentiate itself from siblings like get_download_link or check_link, leaving some ambiguity about which retrieval tool to pick.

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 only implied: the reader infers you call this after start_download or download to poll a job, which is reinforced by the schema parameter text but never stated in the description. There is no explicit when-to-use/when-not guidance and no named alternative among the many sibling retrieval 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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds real value by confirming no download occurs and no free/quota file is consumed, plus that a multi-item share returns 'pick_required' rather than content. It doesn't mention rate limits or error behavior for bad passwords, keeping it short of a 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 core scope is front-loaded in the first sentence, and the second paragraph is a compact workflow. Some of the prose re-narrates the download tool's contract (pick_required handling) rather than this tool's own behavior, which costs a bit of focus.

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 an output schema present, the description needn't explain return values, and it correctly avoids that while covering the entry paths and the folder-navigation state machine. The only gap is that nothing is said about how `page` relates to long folders beyond the parameter's own note.

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 relational meaning the schema does not: how `share_id` + `folder_id` combine to open a subfolder, and that `url` is the alternative entry point. It does not explain `page`/`next_page` paging interaction in depth, so not a full 5.

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 ('What is inside a Quark or PikPak share: its folders and files, with sizes') and immediately scopes it against the sibling download tool ('Lists only: downloads nothing'). An agent can distinguish this from download/start_download 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 the explicit entry conditions (start with `url`, or continue with `share_id` from a pick_required response or an earlier list_files) and the follow-on action (call `download` with url + share_id + a single file_id). The when-to-use-this-vs-download branching is spelled out in both directions.

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 and openWorldHint=false, so the safety profile is covered. The description adds content context (what a pack record contains) but says nothing about pagination, ordering, auth requirements, or whether the list is exhaustive, so it adds modest value beyond the structured data.

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 tight sentence with the identifying noun front-loaded and no filler. It is appropriately sized for a zero-parameter list tool, though it is slightly under-specified rather than optimally informative.

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 parameters, an output schema that already documents the return shape, and annotations covering the read-only/open-world profile, the description is nearly complete. What is missing is only minor framing (e.g., that no filtering or pagination options exist), which the output schema largely covers.

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, which per the scoring baseline maps to a 4. The schema description coverage is 100% and the description's field list describes return payload rather than inputs, so there is no parameter ambiguity to resolve.

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 the specific resource (traffic packs that can be bought) and enumerates the returned fields (code, size, price in USDT), which is clear enough for an agent to distinguish it from download/payment/account siblings. The omission is the verb itself, which only appears in the title ('List'), so the description reads as a noun fragment rather than an action.

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?

There is no explicit when-to-use or when-not-to-use guidance, and none of the siblings (create_payment_link, list_supported_sites, etc.) are referenced as alternatives even though the purchasable nature of the packs implies a buying workflow. The only usage hint is implicit in the phrase 'that can be bought'.

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 and openWorldHint=false, so the safety profile is covered. The description adds real value by defining the status vocabulary (working, slow, down) and noting it is 'live', implying freshness, but says nothing about caching, refresh frequency, or auth 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?

Three tight sentences, front-loaded with the core purpose and followed by the field glossary. Slight redundancy: the return-value taxonomy (main_sites, file_hosts, free) is partly restated by an existing output schema, though it aids interpretation.

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, read-only listing with an output schema and safety annotations, the description covers purpose and key field semantics, which is enough to invoke it correctly. Only the when-to-use framing is missing, a minor gap at this complexity.

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 the baseline of 4 applies. The description introduces no parameter concepts to misunderstand, and the schema correctly 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?

Specific verb ('List') plus resource ('the sites FetchPan can download from') with an explicit scope qualifier: live status. The catalog-listing intent is unmistakable against action siblings like download, check_link, and get_download_link.

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 implied rather than stated: an agent infers this is the discovery tool to consult before calling download or check_link, but the description never says when to call it or what to do with the result. No exclusions or alternatives are named.

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 establish this is a non-read-only, open-world, non-idempotent but non-destructive operation. The description adds useful behavior beyond that: it consumes no free file quota yet, returns a job id rather than the content, and can return a `pick_required` status with file listings for multi-file shares. That's meaningful outcome disclosure for a write-like async job starter.

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 and followed immediately by the return/poll semantics and the pick_required caveat. Three tight sentences with no filler, though the phrasing is slightly dense and could read more cleanly.

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?

An output schema exists, so return values need not be restated. The description still covers the key non-obvious outcome (job id to poll, pick_required branch) and quota implications, making it complete enough for an agent to call and follow up correctly; only minor details like authentication or failure modes are absent.

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 baseline is 3, but the description adds real meaning above the schema by explaining that `share_id` and `file_id` come from a `pick_required` answer and that they identify one file within a share. This clarifies the coupling between the optional parameters better than the per-field schema text alone.

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 (start fetching a link or a single file of a share) and immediately clarifies the scope difference from a full share download. The mention of the `get_job` follow-up and the `pick_required` outcome makes the tool's identity unambiguous against siblings like `download` and `get_job`.

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 to poll the returned job id with `get_job`, and explains the important exception: Quark/PikPak shares with folders or multiple files start no job and instead return status `pick_required` with file listings, mirroring `download`. It does not state clear when-not conditions for the other sibling tools (e.g. check_link, get_download_link), but the primary routing context is given.

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