Server Quality Checklist

Tool Scores

• stealth_fetchB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description assumes full responsibility. It mentions evasion and return format but does not disclose potential side effects (e.g., proxy rotation, session persistence) or explicitly confirm read-only behavior. While a fetch is inherently non-destructive, the description lacks explicit details about side effects or failure modes.

  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 succinct, using only two sentences to convey the core functionality and output format. It avoids unnecessary verbosity and presents information in a clear, direct manner.

  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 description provides essential info (purpose, output) but omits details such as error handling, rate limits, or when to use the tool in conjunction with siblings. The presence of an output schema is noted, but its contents are not described. Overall, it covers the basics but misses edge-case guidance, making it adequate but not fully comprehensive.

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

  Parameters1/5

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

  The schema provides no descriptions for parameters, and the tool description merely lists them without explaining their meaning or expected values. For instance, 'bypass_challenge' is not defined, and 'session_id' is unclear. With 0% schema coverage and no explanatory text, the agent has no guidance on how to appropriately set or use these parameters.

  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 clearly states the tool's purpose: fetching any webpage with automated anti-bot evasion and returning Markdown. The verb 'Fetch' and resource 'webpage' are explicit, and the scope is well-defined without ambiguity.

  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 for pages that may require anti-bot or Cloudflare evasion, but it does not explicitly state when to prefer this tool over sibling tools like stealth_search or proxy_status. The guidance is implicit rather than explicit, leaving some room for interpretation.

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

• rotate_proxyA
  3.5/5.0
  Behavior3/5

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

  The description discloses that the tool forces an immediate lease rotation, which implies a side effect on the proxy IP. However, it does not mention potential consequences, rate limits, or whether the operation is synchronous or asynchronous, so behavioral transparency is partial.

  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 concise and well-structured, using a single clear sentence for the tool purpose and a short, focused argument description. No unnecessary words or redundant information are present.

  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 description covers the core action and parameter, but it does not mention return values, error conditions, or any output schema details. Given that an output schema exists, some additional context about expected results would improve completeness.

  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?

  The only parameter, session_id, is described as 'Session identifier to renew,' which clarifies its purpose. However, the description does not elaborate on whether it is required, how it is validated, or what happens if it is missing or invalid.

  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 clearly states the tool's action: forcing an immediate lease rotation to a new residential IP for a specified session. This is specific and unambiguous, and it distinguishes the tool from the sibling tools that fetch, search, or check proxy status.

  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 does not provide guidance on when to use this tool versus alternatives like proxy_status or stealth_fetch. It only states what the tool does, leaving the agent to infer appropriate usage context.

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

• proxy_statusA
  4/5.0
  Behavior3/5

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

  The word 'Inspect' suggests a read-only operation with no side effects, and no annotations are present to clarify behavior. The description does not explicitly state whether the tool returns data, mutates state, or has any side 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 concise, direct, and free of unnecessary detail. It lists exactly what is inspected in a compact sentence.

  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?

  For a parameterless status-check tool, the description adequately conveys the core purpose and scope. It does not describe the output format, but the presence of an output schema and the simple inspection nature make the description reasonably complete.

  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?

  The tool has no parameters, so the baseline score applies. The description is consistent with a parameterless status inspection tool and requires no additional parameter explanation.

  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 clearly states the tool inspects current residential proxy pool health, active sticky sessions, and provider status. It uses a specific verb and resource scope, and is easily distinguishable from the sibling tools fetch, search, and rotate proxy.

  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 for status inspection rather than fetching, searching, or rotating proxies, but it does not explicitly state when to prefer this tool over alternatives. No direct usage conditions or exclusions are provided.

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

• stealth_searchA
  4.5/5.0
  Behavior4/5

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

  The description explains the tool's behavior: it searches the web and returns ranked citations. It does not explicitly mention side effects like proxy rotation or network activity, but the optional session_id parameter hints at proxy usage. No annotations are present, so the description carries the full burden and covers the primary behavior adequately.

  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 concise and well-structured, with a clear opening sentence followed by a parameter list. No unnecessary information or redundancy.

  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 provides enough context for an agent to decide when to use this tool. It does not explicitly state that it is read-only or non-destructive, but the nature of a search implies that. An output schema is present, so return format is already defined. Overall, sufficient for correct usage.

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

  Parameters5/5

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

  All three parameters are described in the tool description: query (search terms), num_results (count with default and max), and session_id (optional sticky proxy session). Even though the schema has no per-parameter descriptions, the tool description fully covers them.

  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 clearly states the tool performs a web search across multiple engines (DuckDuckGo, Google) and returns ranked citations with titles, URLs, and snippets. It explicitly distinguishes it from potential alternatives by mentioning no API keys required.

  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 implies usage for general web search tasks, mentioning real-time results and multi-engine support. While it does not explicitly contrast with sibling tools (stealth_fetch, proxy_status, rotate_proxy), the purpose is distinct and the sibling names are self-explanatory.

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