Server Quality Checklist

Tool Scores

• create_viewer_grantA
  4/5.0
  Behavior4/5

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

  Annotations already declare the tool is not read-only, not idempotent, and not destructive. The description adds meaningful behavioral detail beyond those flags: the grant is short-lived, single-use, owner-scoped, and tied to an authenticated browser preview. This helps the agent predict consequences without contradicting the 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 a single, focused sentence that front-loads the action and key constraints before the purpose. There is no filler or redundant restatement of the tool name.

  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 tool with one required parameter and no output schema, the description captures the essential behavior, purpose, and grant characteristics. It does not explicitly state what the returned grant looks like, but the purpose strongly implies the output is a usable browser-opening grant, making the tool adequately callable.

  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 schema describes 'label' as 'Label of the link' with 100% coverage, so the structured field already carries the parameter meaning. The tool description does not add extra context about the label's format, purpose within the grant, or available options, but the schema is sufficient on its own.

  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 names a specific verb ('Generate'), a clear resource ('short-lived single-use owner grant'), and the exact purpose ('opening an authenticated preview in browser'). This distinguishes it from sibling tools like revoke_link or protect_link without needing to inspect their definitions.

  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 when to use the tool: when a short-lived, single-use, authenticated preview grant is needed. However, it does not explicitly state when not to use it or mention alternatives among the siblings, so the agent is left to infer the selection boundary.

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

• doctorA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds value by specifying the exact checks performed (config, identity fingerprint, account API, relay, UDP 443), which informs the agent about the tool's scope and potential network activity. It does not contradict annotations; the read-only nature is consistent with running diagnostics. It could mention that results are informational, but the added specificity justifies a 4.

  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, tightly packed sentence that front-loads the action ('Run self-diagnostics') and then lists specifics in a clear sequence. Every element adds information, with no filler or repetition. It is appropriately sized for a no-parameter diagnostic tool.

  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 has no parameters and annotations cover safety, the description is largely complete for an agent to decide when to call it. It enumerates the diagnostic areas, which is the core context. However, it does not hint at the format of the result (e.g., a structured report, log lines) or how to interpret failures. With no output schema, a brief note on expected return shape would enhance completeness, but it is still functional for selection and invocation.

  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 zero parameters, so the description has no parameter details to add. Per the rubric, a tool with no parameters receives a baseline of 4. The description does not mislead about parameters and correctly implies no inputs are needed. Since schema coverage is 100% (empty properties), there is nothing missing.

  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 ('Run') and a clear resource ('self-diagnostics'), then enumerates distinct checks (config, identity fingerprint, API health, relay health, UDP 443 reachability). This differentiates it from siblings like tunnel_status and account_status, which target narrower concerns. It is not a tautology and gives the agent a concrete picture of what the tool does.

  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 states what the tool does but provides no guidance on when to use it relative to sibling tools. There is no mention of scenarios where doctor is preferred over tunnel_status or account_status, nor any exclusions or prerequisites. The agent must infer usage context from the tool name and sibling list, which is weak.

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

• update_ttlA
  4.1/5.0
  Behavior3/5

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

  Annotations indicate non-readonly and non-destructive, and the description adds the crucial detail that credentials are not rotated. However, it does not specify other side effects, idempotency, or error conditions, which are relevant given the tool modifies link state.

  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?

  A single, concise sentence that conveys the core function and a key differentiator without extraneous words. Ideal structure for quick understanding.

  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?

  For a simple update operation, the description fully explains the tool's purpose and effect. No output schema is declared, and the description does not need to mention it. Sibling context is sufficiently covered by the explicit 'without rotating credentials' phrase.

  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 covers both parameters with descriptions defining format (e.g., '48h, 7d') and meaning ('Label of the link'). The description adds no extra parameter detail beyond the schema, matching the baseline for 100% coverage.

  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 (update) and resource (expiration TTL of a protected link), and explicitly distinguishes from credential rotation, aligning well with sibling tools like renew_link or protect_link.

  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 phrase 'without rotating existing credentials' implies when to use this tool (for TTL changes only, not for credential updates), but does not explicitly list alternatives or conditions. It provides adequate context for selection among siblings.

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

• protect_linkA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate this is a non-read-only, non-idempotent operation, but the description adds concrete behavioral detail: it returns a share URL and secret, and it replaces existing credentials if the link is already protected. This is valuable side-effect disclosure beyond what the 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.

  Conciseness5/5

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

  Two sentences with no filler. The action and return values are front-loaded, and the important caveat about replacing credentials is stated concisely at the end. Every sentence earns its place.

  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 simple tool with two optional parameters and no output schema, the description provides the essential return information and the key side-effect caveat. It does not cover error conditions or permission requirements, but the schema and annotations cover the remaining structural details adequately.

  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 input schema covers both optional parameters fully: ttl has examples and label has a default behavior. The description does not add parameter-specific semantics, but with 100% schema coverage the schema already carries the load. Baseline 3 is appropriate.

  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 action ('Enable... protection'), the target ('an owned link'), and the distinctive outputs (share URL with #cap=... and human-readable secret code). It also differentiates behavior on an already-protected link, which helps distinguish it from a simple first-time protect call.

  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 gives clear context for when it applies: enabling capability-token and readable-secret protection on an owned link. It also notes the re-protection case, which tells the agent the operation still makes sense on an already-protected link. It does not explicitly name alternatives like unprotect_link or renew_link, but the intent is clear.

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

• revoke_linkA
  4.2/5.0
  Behavior4/5

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

  The description discloses that the action revokes credentials and preserves owner access, which is key behavioral information. It does not mention reversibility or return values, but the destructive nature is reinforced by the 'destructiveHint' annotation and the term 'revoke.'

  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, concise sentence that conveys the action, the target, and a key nuance (keeping owner access). There is no superfluous detail or redundant phrasing.

  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 simple one-parameter destructive tool, the description provides enough context to understand its purpose and effect. It lacks explicit edge-case handling or return information, but that is not critical given the tool's simplicity and the presence of annotations.

  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 single parameter 'label' is adequately described in the schema, and the tool description refers to it as 'a link,' which is consistent but not additive. Since schema coverage is 100%, the description does not need to elaborate further, so a baseline score of 3 is appropriate.

  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 action (revoke) and the target (active secret and capability token for a link). It distinguishes itself from sibling tools like protect_link or release_link by specifying exactly what is being revoked.

  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 phrase 'Immediately revoke' indicates urgency and the intent to invalidate credentials, providing clear context for when to use this tool. It does not explicitly reference alternatives, but the action is specific enough that an agent can infer appropriate usage.

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

• serve_fileA
  4.3/5.0
  Behavior4/5

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

  The description adds useful behavioral context beyond the annotations: it explains the file is 'auto-hosted and tunneled,' and that remote residency publishes to serve's storage so the URL works with the machine off. This complements the idempotentHint and destructiveHint annotations without contradicting them.

  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 and front-loaded with the core purpose, then adds usage guidance and the key alternative. It is slightly redundant—'Pass the file or directory path to path to have it auto-hosted and tunneled' largely repeats the opening—but overall it is concise and scannable.

  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 tool with 6 parameters, an output schema, and several related siblings, the description covers the core use case, the key residency distinction, and the most important alternative tool. It does not enumerate every parameter or output detail, but the schema and output schema already cover those.

  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 coverage is 100%, so the baseline is 3. The description adds some high-level meaning for 'path' and 'residency' but mostly restates what the schema already says; it does not add detail for ttl, name, protect, or replace beyond their schema descriptions.

  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: 'Serve a local file or directory and get a public shareable URL.' It clearly distinguishes itself from the sibling 'serve' tool by stating that the sibling handles already-running dev servers by port.

  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 gives explicit when-to-use guidance: 'Use this when the user asks to share/serve a file, markdown document, image, or artifact.' It also provides a concrete alternative: 'To expose an already-running dev server by port instead, use the serve tool.' It even warns against starting a separate static server.

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

• tunnel_statusA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying the returned fields (public URL, uptime, state, last error), which is especially valuable given there is no output schema.

  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 sentence that front-loads the action and resource, then lists the key return fields. Every part earns its place, and there is no redundant or vague wording.

  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?

  For a simple read-only status tool, the description is complete: it identifies the tunnel, lists the returned information, and the annotations plus schema cover safety and parameters. No output schema exists, so the description's inclusion of return fields is sufficient.

  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 documents both parameters. The description adds the relationship that port and label are alternative identifiers, but this is also stated in the schema, so the description does not significantly expand parameter meaning beyond the structured data.

  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 ('Return'), a specific resource ('status of a single tunnel'), and the identifying fields (local port or link label). It also lists the returned data, clearly distinguishing it from sibling tools like list_tunnels, which would return all tunnels.

  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 makes the usage context clear: this is for inspecting a single tunnel by port or label. It does not explicitly name alternatives or exclusions, but the 'single tunnel' framing and the sibling list imply when it should be used over list_tunnels.

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

• renew_linkA
  4.4/5.0
  Behavior4/5

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

  Annotations mark readOnlyHint=false, so the mutation nature is already known. The description adds the critical side-effect that 'previous credentials stop working immediately', which is non-obvious and important for agent planning. It also notes the timer reset, providing meaningful behavioral transparency beyond 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 three concise sentences, each earning its place: the main action, the critical side-effect, and the routing to the alternative tool. No redundant or filler content.

  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 simple schema (two documented parameters, no output schema), the description adequately conveys the outcome (new credentials, reset timer, old credentials invalid) and the boundary with update_ttl. The only minor gap is not explicitly stating the response format, but it is strongly implied by the regeneration action.

  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%, with both parameters already documented. The description's alternative reference to update_ttl slightly clarifies the ttl parameter's role, but it doesn't add significant parameter-level detail beyond the schema. Baseline 3 is appropriate.

  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 ('Regenerate') and resource ('capability token and secret code for a protected link'). It also explicitly distinguishes itself from the sibling update_ttl by contrasting the use case, making the tool's purpose unambiguous among 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 gives an explicit when-not condition and alternative: 'For a duration-only change without rotating credentials, use update_ttl instead.' This clearly instructs the agent on when to choose a different tool, leaving no ambiguity about the primary use case.

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

• release_linkA
  4.5/5.0
  Behavior5/5

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

  Beyond the annotations declaring destructive behavior, the description discloses the failure mode (remote_link), a prerequisite (unpublish with stop_remote), and the expected return ('confirmation and the account's usage'). This gives the agent concrete behavioral expectations without an output schema.

  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 tightly packed sentences with no filler. The core action is front-loaded, followed by the key error condition and the return value; every sentence earns its place.

  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?

  For a single-parameter tool with no output schema, this description is complete: it specifies what to do, what can go wrong, how to recover, and what the response will contain. Nothing essential is missing for correct invocation.

  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 description coverage at 100% and only one parameter, the schema already fully documents label. The description reinforces that the operation is by label but adds no additional parameter-specific meaning, so the baseline of 3 is appropriate.

  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 uses a specific verb ('Release (free)') with a clear resource ('an owned link by label') and distinguishes this operation from related link-management siblings by explaining the owned/remote distinction and the stop_remote prerequisite. This is enough for an agent to know what operation it is invoking.

  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 gives a clear conditional workflow: if releasing fails with remote_link while a published artifact exists, use stop_remote first. This is explicit context for when this tool is appropriate, though it does not name a direct alternative for permanent revocation such as revoke_link.

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

• stop_remoteA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint and non-readOnly, and the description adds specific context about what is destroyed ('deleting its stored artifact bytes') and the effect ('returning to local residency'). This enriches understanding beyond the bare destructive flag.

  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, conveying the action, effect, and disambiguation in two sentences without unnecessary verbosity.

  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?

  The tool has no output schema, but the description covers the action, scope, and relationship to sibling tools (e.g., stop_tunnel). This is sufficient for an agent to understand when and how to use it.

  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 'label' is fully described in the schema with the same text as in the description. The description adds no additional semantic detail beyond the schema, so a baseline score of 3 is appropriate.

  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: unpublish a remote link, delete stored artifact bytes, and return to local residency. It also distinguishes from stop_tunnel, leaving no ambiguity about the tool's purpose.

  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 gives explicit when-to-use and when-not-to-use guidance: 'Use links to see published (remote) links' and 'To stop a live tunnel, use stop_tunnel instead; this tool only removes published bytes.' This enables correct tool selection.

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

• stop_tunnelA
  4.5/5.0
  Behavior4/5

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

  Annotations already flag destructive and idempotent behavior. The description adds useful context by naming the exact effect ('revoking its public URL') and reaffirming idempotency. No hidden side effects like authentication requirements are mentioned, but none are implied by the tool's simple purpose.

  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 two short sentences with no filler. Every clause serves a purpose: the action, the target specification, the effect, and idempotency.

  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?

  For a low-complexity tool with two optional parameters and no output schema, the description provides all necessary context: what is stopped, how it is identified, what the result is, and that repeated calls are safe. No additional context is required.

  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?

  Both schema parameters are described clearly ('Local port of the tunnel to stop' and 'Link label ... alternative to port'). The description also reinforces the logical OR relationship between port and label. No constraints or defaults are given, but the schema coverage is complete and the semantics are understandable.

  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?

  Clearly states the verb 'stop' and the resource 'tunnel', and specifies the scope ('for a local port or link label') and the consequence ('revoking its public URL'). This unambiguous purpose distinguishes it from related tools like stop_all_tunnels.

  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 when to use it: to stop a specific tunnel by port or label. It also notes idempotency, which guides repeated calls. It does not explicitly contrast with stop_all_tunnels or tunnel_status, but the targeted scope is clear enough.

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

• serveA
  4.6/5.0
  Behavior5/5

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

  Annotations already establish non-read-only and non-destructive behavior, but the description adds substantial behavioral context: auto-hosted serving, remote storage persistence, replace and conflict semantics, and protection token behavior. It also explains response-shape variations without contradicting the schema or 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?

  The description is information-dense but organized: purpose first, then mode selection, then safety constraints, then response behavior. A few return-field details are redundant with the output schema, but the text remains front-loaded and economical given the tool's complexity.

  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?

  For a tool with seven optional parameters, the description covers all key decision axes: path vs port, local vs remote residency, protection, replacement conflicts, and the caution against starting a separate static server. With an output schema present, nothing essential for correctly invoking the tool is missing.

  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 the baseline is 3. The description enriches the schema by explaining that path implies auto-hosting, port implies a pre-existing server, and remote residency publishes to serve's storage. It also clarifies replace's conflict behavior, which adds real meaning beyond the property names.

  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 sentence clearly states a specific verb and resource: publish a local resource to a public HTTPS URL. It further distinguishes the three target modes (file, directory, port) and the expected output, so an agent can tell this apart from sibling tunnel-management tools.

  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 gives concrete selection rules: pass path for a file/directory, port for an already-running dev server, and residency 'remote' for persistence with the machine off. It also includes a strong when-not instruction: 'Do NOT start your own static file server; pass exactly one of path or port.' It stops short of naming sibling tools as alternatives, so it misses the top bar for 5.

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

• account_statusA
  4.7/5.0
  Behavior4/5

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

  The annotations already declare readOnlyHint=true, so the description doesn't need to repeat that. It adds useful context about account limits and the note that 'Owned links are unlimited by count,' which helps the agent understand the scope of the returned state. This exceeds the baseline given the 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 concise, comprising only three sentences. It fronts the core purpose, then gives usage guidance, and ends with a sibling clarification. No unnecessary words or redundancy.

  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?

  The tool has no parameters and no output schema, so the description is complete for its low complexity. It covers what the tool does, when to use it, and how it differs from the 'links' sibling. The additional fact about owned links being unlimited is helpful context for interpreting the account state.

  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 no parameters (0 params), so the baseline is 4. The description doesn't need to explain any parameter semantics, and the schema coverage is 100% (vacuous). The description adds domain context about account limits, which is helpful but not necessary for parameter understanding.

  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: 'Account-level state: plan, entitlement, and how much of the storage, transfer and publish allowance is used.' It also distinguishes itself from sibling tool 'links' by explicitly saying 'For the links themselves — labels, URLs, protection state — use links instead.' This makes the purpose unambiguous.

  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 this tool: 'Use this to check what the account may do or whether it is near a limit.' It also names the alternative for a different use case: 'For the links themselves — labels, URLs, protection state — use links instead.' This satisfies the requirement for explicit when-to-use and when-not-to-use.

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

• linksA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with those. It adds useful behavioral context beyond the annotations: the output is one record per owned link, includes live/stale/protection/activity/quarantine fields, and carries live-tunnel capacity and usage as context. The note that owned links are unlimited by count is also helpful. It does not describe pagination or rate-limit behavior, but annotations already cover the safety profile.

  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?

  Four sentences, each earning its place: the first defines the inventory and record contents, the second gives usage intent, the third notes companion context data, and the fourth routes to a sibling and clarifies count limits. The key content is front-loaded, and there is no filler.

  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?

  For a zero-parameter, read-only list tool with an output schema present, the description is complete. It gives purpose, scope, record categories, companion usage context, an explicit alternative, and a count-limit clarification. Nothing an agent needs to select or call this tool correctly is missing.

  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 no parameters in the input schema, so the baseline is 4. The description does not need to explain parameter meaning because there is nothing to explain. It focuses instead on what the returned inventory contains, which is appropriate for a zero-parameter read-only list.

  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-resource relationship: it inventories every owned link for the account, enumerates record contents (kind, URL, live/stale markers, protection status, activity, quarantine window), and clarifies what the tool is for (seeing what is served/published or finding a label to act on). It also distinguishes itself from account_status by explicitly routing quota/plan questions elsewhere.

  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 gives explicit use cases: 'Use this to see what is currently served or published, or to find a label to act on.' It also names the alternative for plan/entitlement/quota questions: 'use account_status instead.' This provides clear when-to-use and when-not-to-use guidance.

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

• list_tunnelsA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond annotations by specifying the scope ('in this manager') and the exact fields returned, which is important since there is no output schema. It does not mention pagination or size limits, but for a simple list tool this is sufficient.

  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?

  Two sentences with zero filler. The core purpose is front-loaded in the first sentence, and the second sentence provides compact routing guidance to the sibling tool.

  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?

  For a no-parameter, no-output-schema list tool, the description covers what it lists, the fields returned, and the alternative for single-tunnel inspection. Combined with annotations that establish read-only behavior, nothing essential is missing.

  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 is empty with zero parameters, so there is no parameter ambiguity to resolve. The baseline for 0 params is 4, and the description correctly avoids inventing parameter details that don't exist.

  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 (List), a resource (all active tunnels in this manager), and enumerates the returned fields (ports, labels, public URLs, uptime, state, last error). It also differentiates from the sibling tunnel_status by naming it explicitly for single-tunnel inspection.

  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?

  It gives explicit when-to-use guidance: use list_tunnels to list all active tunnels, and use tunnel_status for a single tunnel. The alternative and condition are named directly, leaving no ambiguity about which sibling tool to choose.

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

• stop_all_tunnelsA
  4.7/5.0
  Behavior4/5

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

  The annotations already include destructiveHint=true, so the baseline bar is lower. The description adds meaningful context by specifying that the action affects every active tunnel and revokes public URLs, which goes beyond a generic destructive label.

  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 two sentences with no wasted words. The primary scoping statement comes first, followed by a useful pointer to the sibling tool.

  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 no parameters, no output schema, and a destructiveHint annotation, the description fully covers the essential context: what the tool does, its scope, and the alternative for a narrower operation. Nothing critical is missing for correct invocation.

  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?

  With zero parameters, the schema is fully covered and the description cannot add parameter-level detail. The baseline of 4 is appropriate because there is nothing missing for the agent to understand about inputs.

  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 precise verb and resource ('Stop every active tunnel') and clarifies the consequence ('revoking all public URLs'). It also distinguishes itself from the sibling tool stop_tunnel by explicitly naming the single-tunnel alternative.

  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 usage guidance by saying when to use this tool (to stop every tunnel) and when to use the alternative ('To stop a single tunnel, use stop_tunnel instead'). This leaves no ambiguity about tool selection.

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

• unprotect_linkA
  4.7/5.0
  Behavior5/5

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

  Beyond the annotations, the description adds the security-relevant consequence ('anyone with the URL can view it') and the ownership requirement. It aligns with destructiveHint=true by identifying the protection state as what is cleared, giving useful context beyond the structured 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?

  Three sentences, with the core action first, a concrete use case second, and alternative routing and prerequisites last. Every sentence earns its place and there is no padding.

  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?

  For a one-parameter mutation with annotations already marking it destructive and non-read-only, the description covers operation, use case, alternatives, and ownership requirement. No critical operational context is missing for an agent to select and invoke it correctly.

  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 schema already provides 100% coverage for the single required 'label' parameter with a clear description. The tool description adds no significant parameter semantics beyond restating that the label identifies the link, so the baseline 3 applies.

  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 object: 'Clear protection on an owned link, returning it to public access.' This fully states what the tool does and distinguishes it from the sibling revoke/release operations by naming what they do 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?

  It explicitly says when to use this tool ('Use this to open up a protected link so anyone with the URL can view it') and differentiates against revoke_link and release_link with concrete conditions. It also states the ownership prerequisite, leaving no ambiguity about selection.

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