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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds behavioral context by clarifying that owned links are unlimited by count and that the tool reports allowance usage. This helps the agent interpret results and plan around limits.

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

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

Three tight sentences with no filler. The first sentence defines the resource content, the second gives a concrete use case, and the third prevents misuse by pointing to the `links` tool. Every sentence earns its place and the key information is front-loaded.

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

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

For a zero-parameter, read-only account status tool with no output schema, the description names the relevant data categories: plan, entitlement, storage/transfer/publish allowance usage, and the 'unlimited owned links' caveat. There is no missing guidance an agent would need to select and invoke this tool correctly.

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

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

The tool has zero parameters and 100% schema coverage, so there is no parameter information the description must supply. The description's mention of plan, entitlements, and allowance usage aligns with what such a no-argument status tool would return, which is sufficient.

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

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

The description clearly identifies the tool as a read-only account-level status resource, naming specific data: plan, entitlement, and usage of storage, transfer, and publish allowances. It also explicitly contrasts itself with the `links` tool, which covers link-level details. This lets the agent distinguish it from siblings without inspecting schemas.

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

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

The description states when to use the tool: to check what the account may do or whether it is near a limit. It also explicitly says to use `links` instead for link-specific details such as labels, URLs, and protection state. This provides clear routing guidance and excludes the main alternative.

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

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

Beyond annotations, the description discloses single-use behavior, a two-minute validity window, the Pro plan requirement, and that the returned value is a bypass URL. No contradiction with readOnlyHint=false or idempotentHint=false.

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

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

Three sentences, front-loaded with the core action and result, with every sentence adding either a constraint, a use case, or validity details. No filler or repetition.

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

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

For a one-parameter, no-output-schema tool, the description covers purpose, output type, constraints, validity, and exclusions. The only minimal gap is exact response formatting, which is not necessary for correct invocation.

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

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

Schema coverage is 100% for the single label parameter, so the schema already documents the parameter. The description adds no extra parameter-level meaning beyond the link context, which fits the baseline for fully covered schemas.

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

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

Description opens with a specific verb and resource: create a single-use owner-browser bypass grant and return a bypass URL. It further differentiates the tool from a general viewer-sharing credential, so an agent can distinguish it from sibling tools 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.

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

Gives an explicit use case: open a protected link in the browser without sharing the viewer credential. It also states a clear when-not boundary: not a general viewer-sharing credential, which routes agents away from misuse even without naming a sibling.

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

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

Annotations indicate readOnly and non-destructive, and the description reinforces this by explaining probes are best-effort and require no login. Also clarifies that a UDP send with no reply is inconclusive, not proof of failure, which is valuable behavioral context.

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

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

Two concise sentences with no redundancy. Every clause adds useful information, and the key warning is front-loaded.

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

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

Fully covers purpose, when to use, alternative tools, behavioral expectations, and result interpretation. With no parameters or output schema, nothing essential is missing.

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

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

The tool has zero parameters, so the baseline of 4 applies. The description needs no parameter detail.

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

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

Clearly states it runs self-diagnostics and lists specific checks (config/identity fingerprint, account API health, relay health, UDP 443 reachability). Explicitly differentiates from sibling tools by directing plan/quota to account_status, link inventory to links, and tunnel state to tunnel_status.

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

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

Explicitly says when to use it ('when a link is unreachable or a call fails') and provides clear alternative tools for other needs, 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

The description discloses important behavioral side effects not captured by annotations, such as replacing existing credentials and invalidating previous share URLs. It also mentions the Pro plan prerequisite, providing transparency beyond the basic annotations.

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

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

The description is well-organized and concise, with each sentence contributing meaningful information about functionality, defaults, side effects, and alternatives. It avoids redundant fluff while covering all essential aspects.

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

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

Given the tool's moderate complexity (no output schema, simple parameters), the description is complete. It covers the return value (share URL with #cap= and secret code), side effects, prerequisites, defaults, and relationships to sibling tools, leaving no critical context missing.

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

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

The schema already provides descriptions for both parameters (100% coverage). The description adds value by explaining default behaviors tied to omitted parameters (e.g., first owned link used when label is omitted, 24-hour default TTL), which are not fully specified in the schema.

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

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

The description clearly states the tool's purpose: enabling capability token and readable secret protection on an owned link. It uses specific verbs and resource references, and distinguishes itself from similar tools like renew_link and update_ttl by mentioning them as alternatives.

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

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

Explicit usage guidance is provided: it notes the Pro plan requirement, explains default behavior when labels or TTLs are omitted, and explicitly states when to use this tool versus renew_link (rotate credentials) or update_ttl (change duration).

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

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.

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.

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.

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.

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.

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.

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

The description adds critical behavior beyond the annotations: fresh credentials are minted, the countdown restarts, and previous credentials stop working immediately. This helps the agent anticipate the irreversible invalidation of old credentials. 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.

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

Two sentences, no waste, and the primary action is front-loaded. The alternative tool is mentioned at the end with a clear conditional. Every sentence earns its place.

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

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

The description covers prerequisites, ttl defaults, and the consequence of rotation. With no output schema, it could also state whether the new credentials are returned in the response, but this is a minor gap for an otherwise complete description.

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

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

Schema description coverage is 100%, so parameters are already well documented. The description adds meaning around ttl (defaults to 24 hours) and differentiates ttl-only changes as a separate tool, but label is not enhanced beyond the schema.

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

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

The description uses a specific verb ('Rotate') and resource ('capability token and secret code') and clearly distinguishes this from the sibling update_ttl for duration-only changes. The Pro plan requirement further clarifies scope.

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

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

It explicitly tells the agent when not to use this tool ('For a duration-only change without rotating credentials, use update_ttl instead') and states the Pro plan prerequisite. The behavior is described in a way that makes the use case self-evident.

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

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

Annotations only carry destructiveHint=true, but the description enriches the behavioral picture: 'keeping owner access intact', 'link stays protected', 'old share URL and secret stop working', and 'no new credentials are minted.' This clarifies the exact scope and permanent effect of the mutation.

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

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

Three sentences with no filler: the first states the immediate action and its limits, the second states the outcome, and the third lists alternatives. The most important information is front-loaded.

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

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

For a single-parameter mutation tool with no output schema, the description fully covers behavior, consequences, exclusions, and sibling alternatives. Nothing an agent needs to correctly select and invoke this tool is missing.

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

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

The single label parameter is already fully documented in the input schema with 100% coverage. The description adds no new parameter-specific syntax, but none is needed; schema coverage carries the load, so baseline 3 is appropriate.

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

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

States a specific action: 'Immediately revoke the active secret code and capability token for a link' — identifying the verb, object, and effect. It also distinguishes itself from siblings by naming unprotect_link and renew_link as alternatives for different outcomes.

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

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

Explicitly tells the agent when to use alternatives: 'To open the link to everyone instead, use unprotect_link; to mint fresh credentials, use renew_link.' This directly maps conditions to the correct sibling tool, leaving no ambiguity.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already include idempotentHint and destructiveHint, so the bar for additional disclosure is lower. The description adds useful behavioral context by explaining the public URL is revoked and that there is no in-place reconfiguration, which is valuable beyond what annotations express. 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.

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

The description is two sentences with no fluff: it front-loads the action, consequence, and idempotency, then adds a single practical usage note about reconfiguration. Every sentence earns its place.

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

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

For a simple two-parameter, no-output-schema tool with strong annotations, the description covers the action, idempotency, effect on the URL, and reconfiguration workflow. The only minor gap is that both parameters are optional in the schema, while the description implies at least one must be provided; a short note on what happens if neither is given would make it fully complete.

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

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

The input schema already provides full descriptions for both parameters (port and label) at 100% coverage. The description only restates the schema's 'alternative to port' concept through 'for a local port or link label', which adds little beyond the schema. Baseline 3 is appropriate since the schema carries the parameter documentation.

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

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

The description states a specific verb ('Stop (tear down)') and resource ('the tunnel for a local port or link label'), along with the key consequence of revoking its public URL. It clearly distinguishes this from sibling tools like stop_all_tunnels or stop_remote by scoping to a single tunnel. The idempotent note adds further precision.

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

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

The description gives explicit context for when to use this tool: to reconfigure a live tunnel, stop it here and then call serve with new settings. It positions this tool as the stopping step and names serve as the follow-up alternative. It does not explicitly mention when to prefer stop_all_tunnels over this tool, but the usage instruction is clear enough.

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

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 naming the output details (public URL, uptime, state, last error) and clarifying this tool only inspects a single tunnel, not the entire set.

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

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

Two sentences with no filler. The primary function and output are front-loaded in the first sentence, and the sibling guidance is compactly placed in the second. Every word contributes value.

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

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

For a simple read-only tool with complete schema coverage and annotations, the description covers the core operation, output fields, and sibling differentiation. However, it does not explicitly state that port or label must be provided, and the schema lists no required parameters, leaving a small ambiguity for an agent calling with no arguments.

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

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

Schema description coverage is 100%, with clear definitions for port and label, so the baseline is 3. The description adds the relationship that these are alternative identifiers ('local port or its link label'), but it does not provide material meaning beyond the schema.

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

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

The description uses a specific verb ('Return'), names the resource ('a single tunnel'), and specifies its identifier ('local port or its link label'). It also lists the returned data fields, making the tool's function unambiguous and distinct from list_tunnels.

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

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

The second sentence explicitly tells the agent when to prefer a sibling tool: 'To see every active tunnel at once, use list_tunnels instead.' This directly states the condition for using the alternative, which is exactly the kind of guidance needed for correct tool selection.

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

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.

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.

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.

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.

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.

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.

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

The description goes beyond the basic annotations by explaining the precondition, the non-rotation of credentials, and the exact recalculation semantics (new duration, not extended from previous expiry).

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

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

The description is concise and front-loaded, conveying the core action first and then adding necessary constraints and preconditions in only three sentences.

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

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

Given the simple two-parameter input and no output schema, the description fully covers the necessary context: prerequisites, behavior, and an explicit alternative for expired protection.

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

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

Schema description coverage is 100% for both required parameters, and the parameter descriptions are clear. The main description adds context for TTL behavior but does not significantly expand on the parameter-level semantics.

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

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

The description clearly states a specific action: changing the TTL of an already-protected link, and distinguishes it from related operations by noting it does not rotate credentials and that expired protection must be renewed first.

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

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

It explicitly states when to use this tool (for protected links with unexpired credentials) and when not to (expired protection should use renew_link). It also mentions the Pro plan requirement.

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