Server Quality Checklist

Tool Scores

• start_tunnelA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it starts a tunnel process, returns a public URL, allows naming for management, and mentions the need to wait and check status with another tool. It covers the core operational flow but doesn't mention potential errors, timeouts, or security implications.

  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 well-structured and front-loaded with the core purpose, followed by bullet points for key behaviors and a clear follow-up instruction. Every sentence earns its place with no redundant information, making it efficient and easy to parse.

  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 tool's moderate complexity (creating a network tunnel), no annotations, and no output schema, the description does a good job covering the essential context: what it does, key behaviors, and follow-up steps. However, it doesn't describe the return value format or error conditions, leaving some gaps for a mutation tool with no structured output documentation.

  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 100%, so the schema already fully documents both parameters (name and url). The description adds marginal value by mentioning naming 'for easier management' and giving an example URL format, but doesn't provide additional semantic context beyond what the schema descriptions already state.

  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 specific action ('Creates a secure tunnel'), the resource ('from a public internet address to your local server'), and distinguishes from siblings by mentioning 'list_tunnels' for status checking. It explicitly describes what the tool does beyond just the name.

  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 clear context on when to use this tool (to expose a local server) and references 'list_tunnels' as a follow-up action. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'stop_tunnel' for tunnel management, leaving some guidance implicit rather than explicit.

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

• list_tunnelsA
  4.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it shows all tunnels in the registry, auto-detects running tunnels not in the registry, displays specific details (status, name, URLs, runtime info), and indicates local vs. remote. However, it lacks information on permissions, rate limits, or error handling, which are important for a tool with no annotations.

  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 well-structured and appropriately sized. It starts with a clear purpose statement, uses bullet points for key behaviors, and ends with usage guidance. Every sentence adds value without redundancy, making it efficient and easy to parse.

  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 tool's complexity (listing and auto-detecting tunnels), no annotations, no output schema, and 0 parameters, the description is mostly complete. It covers purpose, usage, and behavioral details but could benefit from mentioning output format or error cases. However, it provides sufficient context for basic use.

  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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's behavior and output. Baseline for 0 parameters is 4, as it avoids unnecessary parameter details.

  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 specific action ('Lists all active tunnels') and resource ('tunnels'), including their status and details. It distinguishes from siblings by focusing on listing/status checking rather than starting or stopping tunnels, which are the sibling tools.

  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 explicitly states when to use this tool: 'Use this tool to check the status of your tunnels and get their public URLs.' This provides clear context for usage versus the sibling tools (start_tunnel, stop_tunnel), which are for different operations.

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

• stop_tunnelA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden and discloses key behavioral traits: it only affects tunnels on the current machine, not others, and the outcome depends on name parameter presence. It doesn't mention error handling or permissions, but covers scope and conditional 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?

  Front-loaded with purpose, followed by bullet points for key behaviors, and ends with a usage tip. Every sentence earns its place, with no redundancy or fluff, making it efficient and well-structured.

  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 no annotations, no output schema, and a simple parameter, the description is nearly complete: it explains purpose, usage, behavioral scope, and references a sibling tool. It lacks details on errors or return values, but for a stop action with one optional parameter, this is sufficient.

  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 100%, so baseline is 3. The description adds value by explaining the semantic effect of the parameter: if provided, stops a specific tunnel; if not, stops all local tunnels. This clarifies the conditional logic beyond the schema's description.

  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 verb ('stops') and resource ('a running tunnel or all local tunnels'), distinguishing it from sibling tools list_tunnels (for listing) and start_tunnel (for starting). It specifies the scope ('local tunnels') and dual functionality (specific vs. all).

  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 guidance is provided: use with a name to stop a specific tunnel, or without to stop all local tunnels. It distinguishes when to use this tool vs. list_tunnels for confirmation, and implicitly contrasts with start_tunnel for opposite actions.

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