Server Quality Checklist

Tool Scores

• tor_check_anonymityA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows the tool is safe and idempotent. The description adds valuable behavioral context: it contacts check.torproject.org, compares Tor exit IP with direct IP, and describes error handling (e.g., Tor not running returns install instructions). This goes beyond what annotations provide.

  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?

  The description is well-structured with clear sections (purpose, args, returns, examples, error handling). It is front-loaded with the main purpose. While slightly verbose due to examples and error handling, every section is relevant and adds value.

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

  Completeness5/5

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

  Given the tool's moderate complexity (checking anonymity involves multiple steps), the description is comprehensive. It explains the process, output schema, error cases, and provides usage examples. The presence of an output schema further enriches completeness. For a tool with one parameter, this is fully adequate.

  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?

  Although schema description coverage is 0%, the description details the single parameter (params: TorStatusInput) and its subfield response_format, including the enum values ('json' or 'markdown') and default. It also explains the output schema. This adds substantial meaning beyond the input schema alone.

  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: 'Check if Tor is active and verify anonymity.' It uses specific verbs (check, verify) and a clear resource (Tor anonymity). The description also distinguishes from sibling tools by explicitly stating when not to use it, such as for fetching URLs (use tor_private_fetch) or full connection details (use tor_privacy_status).

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use the tool (e.g., 'before making sensitive requests', questions like 'Am I anonymous right now?') and when not to use it (e.g., 'Don't use when: You want to fetch a URL'). It also names alternative tools (tor_private_fetch, tor_privacy_status), making differentiation easy.

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

• tor_privacy_statusA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. Description adds value by stating 'Returns status regardless of Tor state (offline status is valid)', which is important behavioral context not in annotations.

  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?

  Description is well-structured with sections (main, args, returns, json schema, examples, error handling). However, it is somewhat lengthy and could be more concise while retaining clarity.

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

  Completeness5/5

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

  Given the presence of a detailed output schema and comprehensive annotations, the description covers all essential aspects: purpose, usage, parameters, return structure, error handling, and behavioral traits. No gaps identified.

  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 coverage is 0% but the description has an 'Args' section explaining the response_format parameter and its enum options (json/markdown). This adds meaning beyond the schema references. Could be more detailed on usage of each format.

  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?

  Description clearly states 'Show current Tor connection status and routing configuration' with specific verb and resource. Distinguished from siblings by naming tor_check_anonymity as the alternative for verifying anonymity.

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

  Usage Guidelines5/5

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

  Explicit usage examples for common queries (e.g., 'Is Tor working?', 'Show me the routing config', 'Debug why requests are failing') and a clear exclusion: 'Don't use when: You just need to verify anonymity (use tor_check_anonymity)'. Error handling note adds context.

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

• tor_new_identityA
  4.8/5.0
  Behavior5/5

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

  Discloses that it changes IP, requires Tor control port 9051, is rate-limited to once per 10 seconds, and details error handling (stem not installed, control port not enabled, rate limiting). This goes beyond the annotations (readOnlyHint=false, etc.).

  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?

  Well-structured with clear sections and front-loaded purpose. Every sentence adds value, though there is slight repetition in the examples (e.g., 'default params' repeated).

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

  Completeness5/5

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

  Covers prerequisites, rate limiting, error handling, return schema, and example usage. No gaps given the tool's complexity and the presence of an output schema.

  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 description lists the fields of the params object with defaults and meanings, but the input schema already provides descriptions for each parameter. The description adds value through usage examples and error handling context, but the parameter details are largely redundant with the schema.

  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 requests a new Tor circuit to get a different exit IP, and distinguishes it from sibling tools by explicitly noting not to use for checking IP (use tor_check_anonymity instead).

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

  Usage Guidelines5/5

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

  Provides explicit examples of when to use (e.g., 'Get a new exit IP', 'A site rate-limited me') and when not to use ('You just need to check current IP'), including a sibling tool alternative.

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

• tor_private_fetchA
  4.8/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. Description adds substantial behavioral context: automatic routing rules, error handling for various HTTP responses, and response format details. 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.

  Conciseness4/5

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

  Description is well-structured with sections (Args, Returns, Examples, Error Handling). It is front-loaded with the core purpose. While somewhat lengthy, all content is relevant and earns its place. A minor trim could be possible, but overall efficient.

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

  Completeness5/5

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

  Given the tool's complexity (automatic routing, error handling, multiple use cases), the description is remarkably complete. It covers the routing decision logic, error scenarios with suggested actions, and provides a detailed output schema. No gaps identified.

  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 descriptions already cover parameter meanings, but description adds valuable context beyond schema: explains automatic routing logic, when to use force_tor/force_direct, and error handling strategies that relate to parameters. Since schema coverage is high, baseline is 3, and description adds enough to warrant a 4.

  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?

  Description clearly states it fetches a URL with privacy-aware routing through Tor. Uses specific verb 'fetch' and resource 'URL', and distinguishes from sibling tools like tor_check_anonymity and tor_new_identity in usage guidelines.

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

  Usage Guidelines5/5

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

  Explicit 'Use when' and 'Don't use when' examples with clear alternatives, e.g., 'Don't use when: You need to verify Tor is working (use tor_check_anonymity)'. Provides excellent context for when to use this tool versus siblings.

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