Server Quality Checklist

Tool Scores

• download_urlC
  2.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full responsibility for behavioral disclosure. It tells the caller that timeout is total seconds and that direct links are rejected, but it does not disclose whether the download creates files, requires authentication, has rate limits, or what side effects occur. This is a significant gap for a download tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the main purpose. However, it omits essential parameter semantics and behavioral details, making it under-specified rather than efficiently complete. It earns a 4 for brevity and structure, not for completeness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has an output schema (per context signals), which may compensate for return-value details. But given the tool's complexity (3 params, 0% schema coverage, no annotations), the description is inadequate. It lacks guidance on when to use it, what the four sites are, and how subdir behaves. Completeness is partial at best.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must explain parameter meanings. It only clarifies 'timeout' (total seconds). The 'url' parameter's expected format is vaguely implied by 'work page URLs from four sites,' but 'subdir' is completely unexplained. Without schema descriptions, this leaves the agent guessing on two of three parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: identifying and downloading work-page URLs from four specific sites. It distinguishes from generic download tools by specifying the accepted URL type, but it does not name the four sites or explicitly contrast with sibling tools like download_post or download_search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a constraint (does not accept arbitrary direct file links) but offers no guidance on when to use this tool versus alternatives like search, get_post, or download_search. It doesn't state prerequisites or exclusions beyond the direct-link restriction.

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

• get_postC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full behavioral disclosure burden. It only mentions the outcome (complete metadata) and a post_id format note, with no statement on read-only behavior, side effects, permissions, rate limits, or error conditions. This is insufficient for an agent to safely predict the tool's effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very compact: two sentences. The first sentence delivers the core purpose, the second adds essential post_id semantics. There is no filler, and the structure is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the output schema exists and the parameter count is low, the description leaves critical context unanswered: possible 'site' values, how site and post_id interact, and when to use this tool over the siblings. An agent cannot fully infer the correct invocation just from this description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With schema coverage at 0%, the description partially compensates by clarifying that post_id should be numeric and that for ehentai it should be a gid/token pair. This adds real meaning to one parameter, but the 'site' parameter is left completely unexplained (allowed values, enums, or relationship to ehentai are not addressed).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states that the tool retrieves complete metadata (完整元数据) for a work, giving a clear verb-resource pairing. It implies a 'get' operation with metadata as the deliverable, but it does not explicitly name how it differs from siblings like download_post or search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no guidance on when to use this tool versus existing alternatives such as search, download_post, or download_url. It lacks explicit conditions, contextual scenarios, or exclusion criteria that would help an agent choose this tool correctly.

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

• download_postA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden and does substantive work: it defines timeout as covering multiple phases, clarifies subdir semantics, and states that failed files will not become final files. It does not mention auth, overwrite behavior, or partial-file cleanup, but it gives meaningful operational detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three compact sentences, front-loaded with the core action and returning value, followed by terse clarifications of the non-obvious parameters. Every sentence earns its place and there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is largely complete for a download tool: it covers return contents, parameter semantics for the unusual fields, timeout scope, and failure behavior. The main gaps are undocumented site values and no explicit routing to sibling tools, but an output schema exists and the core call contract is clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds real meaning for subdir and timeout, and post_id is implied by 'by ID', but the required site parameter is left entirely unexplained, leaving an agent to guess at valid values or the role of site in the request.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'download entire work by ID' and names the return value (file list and sidecar). This distinguishes it from siblings like download_url (by URL) and download_search (by search) without requiring the agent to open schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you have a post ID and want a full download, but it never explicitly says when to prefer this over download_url or download_search, nor gives exclusions. Guidance is implicit rather than stated.

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

• download_searchA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden and covers the key runtime facts: the 50-file attempt cap, whole-gallery skip, timeout scope, return fields, and success=false on partial completion while retaining successful files. It does not mention file-location/overwrite behavior or authentication side effects, so it is not 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short sentences front-load the operation and cap, then give the alternative, return shape, and failure semantics. Every sentence carries unique information and there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The high-level behavior and edge cases are well covered, and an output schema exists so return values need not be restated. However, with 7 parameters and zero schema descriptions, the lack of guidance on query/site formatting, limit semantics, subdir, rating, and min_score leaves meaningful gaps for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only adds meaning for timeout (covering search and download) and loosely implies a 50-file ceiling. Required site/query plus rating, subdir, limit, and min_score are left unexplained, so the agent must guess their formats or allowed values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening phrase '搜索并批量下载' names a specific action and resource, and the 50-file cap gives clear scope. It explicitly contrasts with 'download_post' for over-limit galleries, so an agent can distinguish it from its siblings without opening schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states that over-limit galleries are skipped and should be downloaded individually via download_post, which is an explicit alternative for a concrete condition. It does not discuss when to prefer plain search or download_url, but the batch-search-and-download intent is clear enough.

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

• self_checkA
  4.2/5.0
  Behavior4/5

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

  With no annotations present, the description takes on the transparency burden and does a strong job: it states the parallel behavior, per-call timeout, and explicitly rules out downloading media and returning credentials. It does not mention whether the check has side effects, such as logging or rate-limit consumption, but the read-only intent is reasonably clear.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, compact sentence that front-loads the main action, then appends two useful exclusions and a timeout constraint. It is efficient and adds no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that the tool takes no parameters and an output schema exists, the description covers the key operational context: it is parallel, bounded by a 45-second timeout, and intentionally avoids downloading or returning credentials. It does not explain what the four stations are or how results are reported, but these are likely covered by the output schema and domain conventions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so the schema already fully covers the input side. The description adds no parameter detail, but none is needed; the baseline of 4 reflects that 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('并行检查' / check in parallel) and a concrete resource ('四站凭证及 API 连通性'), and further clarifies what the tool does not do ('不下载媒体、不返回凭证'). This distinguishes it from retrieval/download-oriented siblings like search, get_post, and download_url.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The purpose implies this is a preflight/diagnostic tool for checking credentials and connectivity before other operations, but it does not explicitly say when to use it instead of siblings or exclude alternative workflows. The 'does not download media' hint helps somewhat, but there is no direct usage guidance.

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

• searchA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral burden. It discloses page semantics, per-site limits, rating value mappings, min_score meaning, and that filtering can return fewer results than limit. It does not mention auth, rate limits, or read-only status, but it is still more transparent than most.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, scannable, and every clause adds a distinct parameter or per-site fact. It front-loads the action and then efficiently enumerates constraints.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the multi-site complexity and absence of annotations, the description covers the main invocation requirements: per-site ratings, limits, page semantics, and min_score. An output schema exists so return values do not need explanation; the remaining gaps are explicit site parameter values and a concrete query example.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description is the only source of parameter meaning. It explains query, page, limit caps, rating values per site, and min_score. However, accepted site values are only implied by the list 'e621/rule34/ehentai/pixiv' rather than explicitly tied to the site parameter, and no query example is given.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: searching e621/rule34/ehentai/pixiv. It clearly frames this as a multi-site search tool and distinguishes it from siblings like get_post and download_post by focusing on query, rating, and limit behavior.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides concrete guidance on how to construct searches: native tags or keywords, 1-based page numbering, per-site limit caps, and per-site rating vocabulary. It does not explicitly name alternatives or state when not to use it, but the usage context is unambiguous.

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