Server Quality Checklist

Tool Scores

• pipeline_tracesA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, establishing it as a safe read operation potentially accessing external data. The description adds valuable behavioral context by disclosing that 'Pipelines are auto-detected from webhook payloads,' explaining the data source mechanism. However, it omits details about error handling, rate limits, or what the trace records contain.

  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 consists of two highly efficient sentences. The first front-loads the action and resource with helpful parenthetical examples; the second provides essential operational context (auto-detection). There is no redundant or filler content—every clause 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?

  Given the low complexity (2 primitive parameters, no nested objects), high schema coverage (100%), and rich annotations (readOnly, openWorld), the description is appropriately complete. It adequately explains the tool's purpose, data source (webhooks), and provider scope. While it could benefit from describing the return structure (absent output schema), this is not critical for a straightforward list operation with clear safety 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?

  With 100% schema description coverage, the baseline score is 3. The description reinforces the pipeline_id parameter by listing provider examples (Replicate, fal.ai, RunPod, OpenAI), which adds marginal context beyond the schema's examples ('replicate', 'fal-ai'), but does not significantly expand on parameter semantics or validation rules beyond what the schema already provides.

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

  Purpose4/5

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

  The description clearly defines the tool's function with a specific verb ('List') and resource ('execution traces'), and provides concrete examples of supported pipeline providers (Replicate, fal.ai, RunPod, OpenAI). However, it does not explicitly distinguish its scope from the sibling tool 'trace_timeline', which prevents a score of 5.

  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 provides implicit usage guidance through examples of pipeline identifiers (Replicate, fal.ai, etc.) and notes that pipelines are 'auto-detected from webhook payloads,' hinting at prerequisites. However, it lacks explicit guidance on when to use this versus sibling tools like 'trace_timeline' or 'list_requests', and does not state when NOT to use it.

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

• disconnectA
  3.8/5.0
  Behavior3/5

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

  Confirms the mutation aspect (aligns with readOnlyHint=false) but adds minimal behavioral detail beyond annotations. Doesn't clarify error conditions (e.g., port not found) despite idempotentHint=false, or whether stop is graceful vs immediate.

  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?

  Single efficient sentence with zero waste. Front-loaded with action verb. Every word 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?

  Adequate for a simple 1-parameter mutation tool with comprehensive annotations covering safety/idempotency. Could improve by clarifying relationship to delete_tunnel and failure modes, but sufficient for agent selection.

  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 baseline applies. Description reinforces the 'port' parameter's role by stating 'by its local port number', but doesn't add format details or constraints beyond the schema.

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

  Purpose5/5

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

  Specific verb 'Stop', clear resource 'running tunnel', and targeting mechanism 'by its local port number' distinguishes this from sibling tools like delete_tunnel (removal) or connect (establishment).

  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?

  Implies usage through 'Stop' (use on active connections vs creating/deleting), but lacks explicit when-to-use guidance or differentiation from delete_tunnel which might remove configuration vs stopping traffic.

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

• tunnel_statusA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable context about what information is returned (current online status and protocol), but does not elaborate on the real-time nature implied by 'currently' or any rate limiting concerns.

  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?

  Single sentence with no wasted words. The structure front-loads the action ('Check') and immediately qualifies the data returned (online status, protocol), making it easy to scan.

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

  Completeness4/5

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

  Given no output schema exists, the description appropriately indicates what data is retrieved (online status and protocol). For a read-only single-parameter tool, this is sufficient completeness.

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

  Parameters3/5

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

  Schema coverage is 100% with the 'subdomain' parameter fully described. The description implies a singular target ('specific tunnel') but does not add syntax details, format constraints, or examples beyond the schema definition.

  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 ('Check') and resource ('tunnel') and qualifies the scope ('specific tunnel'), clearly distinguishing it from sibling list operations like 'list_tunnels' or 'active_tunnels'.

  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 phrase 'a specific tunnel' implies usage for targeted status checks rather than bulk listing, but there is no explicit guidance on when to choose this over 'list_tunnels' or 'active_tunnels', nor are alternatives named.

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

• delete_tunnelA
  4/5.0
  Behavior4/5

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

  Annotations confirm destructiveHint=true, but the description adds critical context: specifically that 'stored requests' are destroyed alongside the tunnel, and explicitly states 'Cannot be undone' to emphasize irreversibility. No contradictions 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.

  Conciseness5/5

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

  Two sentences with zero waste. First sentence front-loads the action and scope ('Permanently delete a tunnel and all its stored requests'), second provides the irreversibility constraint. Every word 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?

  Appropriately complete for a single-parameter destructive operation. Annotations cover safety profile (destructiveHint, readOnlyHint), while description covers what gets destroyed. No output schema expected for a delete operation. Minor gap: could clarify behavior when tunnel doesn't exist (given idempotentHint=false).

  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% with 'subdomain' well-documented as 'The tunnel subdomain to delete'. Description adds no parameter syntax details, but with complete schema coverage, this is acceptable. 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 uses specific verb 'delete' with resource 'tunnel' and explicit scope 'and all its stored requests'. 'Permanently' distinguishes it from sibling 'disconnect' (temporary) and 'create_tunnel' (opposite action). Clear and unambiguous.

  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 phrase 'Cannot be undone' warns about irreversibility, implying this should be used only when permanent removal is intended. However, it lacks explicit comparison to sibling 'disconnect' for temporary severance or guidance on when deletion is preferred over deactivation.

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

• replay_requestA
  4/5.0
  Behavior4/5

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

  While annotations declare safety hints (idempotent, non-destructive), the description adds runtime constraint (tunnel must be online) and discloses return values (new response status and duration) not present in annotations.

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

  Conciseness5/5

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

  Two tightly constructed sentences with zero waste: first establishes action and target, second states prerequisites and return values. Information is front-loaded appropriately.

  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?

  Appropriately complete for a two-parameter tool; compensates for missing output schema by describing return values, though it could specify error behavior when the tunnel is offline.

  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 100% schema coverage, the schema carries the parameter documentation. The description adds context that request_id refers to a 'previously captured webhook request' but does not elaborate parameter syntax or formats beyond the schema.

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

  Purpose5/5

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

  The description uses specific verb 'Replay' with clear resource 'previously captured webhook request' and destination 'tunnel client', distinguishing it from siblings like inspect_request (viewing) and list_requests (enumerating).

  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?

  States the prerequisite that 'The tunnel must be online' but lacks explicit guidance on when to choose this over siblings like inspect_request or alternatives for testing webhooks.

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

• trace_timelineA
  4/5.0
  Behavior4/5

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

  Adds valuable behavioral context beyond annotations by specifying exact return fields (step name, status, duration, ordering) that readOnlyHint=true alone doesn't convey. Contradicts no annotations.

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

  Conciseness5/5

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

  Two tightly constructed sentences: first declares the operation, second details the output structure. Zero redundancy, every word earns its place, appropriately front-loaded.

  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 read tool with single parameter and no output schema, the description adequately compensates by describing the return structure (name, status, duration, ordering). Given annotations cover safety profile, this provides sufficient context.

  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 has 100% coverage describing 'trace_id' as 'The trace identifier'. The description mentions 'specific pipeline trace' aligning with the parameter but adds no additional syntax, format, or sourcing guidance beyond the schema baseline.

  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 specific verb 'Get' with clear resource 'execution timeline for a specific pipeline trace', distinguishing it from sibling 'pipeline_traces' (likely a list operation) by emphasizing the single-trace scope and step-by-step detail level.

  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?

  Provides implied usage context by stating 'for a specific pipeline trace', indicating a trace_id is required, but lacks explicit guidance on when to use this versus 'pipeline_traces', 'inspect_request', or 'replay_request' siblings.

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

• connectA
  4.1/5.0
  Behavior4/5

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

  Adds important auth context (active account requirement) not present in annotations. Explains the open-world behavior (public URL creation) which aligns with openWorldHint=true. Annotations already disclose non-read-only and non-idempotent traits, so description appropriately adds operational context rather than repeating safety flags.

  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 structured components: purpose declaration, auth prerequisite, and concrete example. Every clause earns its place with zero redundancy. Information density is high and front-loaded.

  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?

  With annotations covering safety/idempotency and schema covering parameters, the description successfully establishes complete operational context: tunnel creation mechanism, URL forwarding behavior, and authentication requirements. No output schema exists but the result structure is evident from the example.

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

  Parameters4/5

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

  Schema coverage is 100% so baseline is 3. The example ('connect port 3000 with subdomain my-app to get https://my-app.yourdomain.com') significantly clarifies the semantic relationship between 'subdomain' parameter and resulting URL structure, adding concrete value beyond schema definitions.

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

  Purpose4/5

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

  Clear specific description of what the tool does (starts tunnel, forwards public URL to local port). Includes concrete example showing the forwarding mechanism. Does not explicitly differentiate from sibling 'create_tunnel' though 'Start' vs 'Create' implies a distinction.

  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?

  Provides critical prerequisite ('Uses the active account from pie login') and concrete example showing parameter usage and expected URL outcome. While it lacks explicit 'when not to use' guidance, the prerequisite and example provide clear usage context.

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

• active_tunnelsA
  4.2/5.0
  Behavior4/5

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

  Complements annotations well: 'currently connected' explains why idempotentHint=false (active set changes over time) and 'through this MCP session' clarifies the context scope. The description also compensates for missing output schema by disclosing return fields (port, subdomain, forward address). Does not mention rate limits or auth, though openWorldHint=true is present.

  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?

  Single, efficiently structured sentence. Front-loaded with the action verb 'List,' immediately followed by scope and output fields. Zero redundancy or filler. Every clause earns its place by conveying distinct information.

  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?

  Adequate for a zero-parameter read operation. Annotations cover safety profile (readOnlyHint, destructiveHint). Description compensates for missing output schema by listing return fields. Could marginally improve by noting return format (array vs object) or pagination, but sufficient given tool simplicity.

  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?

  Input schema has zero parameters. Per rubric baseline for 0 params is 4. Description appropriately does not invent parameters, maintaining alignment with the empty schema.

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

  Purpose5/5

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

  Excellent specificity: 'List' (verb) + 'tunnels' (resource) + 'currently connected through this MCP session' (scope). The phrase 'currently connected' effectively distinguishes this from sibling 'list_tunnels' (likely all tunnels) and 'tunnel_status' (likely individual status). Output fields (port, subdomain, forward address) are also previewed.

  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?

  Provides implicit usage guidance through the scope qualifier 'currently connected,' suggesting use when monitoring active connections rather than historical/configured tunnels. However, lacks explicit comparison to siblings (e.g., 'Use this instead of list_tunnels when you only need active connections...') or when-not guidance.

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

• create_tunnelA
  4.2/5.0
  Behavior4/5

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

  Annotations indicate write operation (readOnlyHint=false) and external effects (openWorldHint=true). Description crucially adds return value specification ('Returns the tunnel ID and public URL') which is essential given no output schema exists. Also adds validation constraints (1-63 chars) that affect behavior.

  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 efficient sentences totaling ~20 words. First establishes action/resource, second covers validation and return value. Zero redundancy, perfectly front-loaded.

  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 creation tool with external side effects (openWorldHint=true) and no output schema, the description adequately covers return values and input validation. Could briefly mention persistence or cleanup requirements (linking to 'delete_tunnel'), but covers core needs.

  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?

  Despite 100% schema coverage (baseline 3), description adds the length constraint '1-63 characters' which is absent from the schema's parameter description, providing necessary validation detail for the 'subdomain' parameter.

  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?

  Clear specific verb ('Register') plus resource ('tunnel subdomain'). Distinguishes from siblings like 'connect', 'list_tunnels', and 'delete_tunnel' by specifying this creates a new registration rather than managing existing connections or enumerating.

  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?

  Provides implied usage through the verb 'Register' (suggests initial creation vs connection), but lacks explicit when-to-use guidance or prerequisites (e.g., when to use this vs 'connect', or whether a tunnel must be created before connecting).

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

• list_requestsA
  4.2/5.0
  Behavior4/5

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

  Adds valuable behavioral details beyond annotations: specifies ordering (newest first), enumerates returned fields (method, path, status code, duration, pipeline metadata), and confirms pagination support. Does not contradict readOnlyHint=true or destructiveHint=false.

  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 constructed sentences with zero waste. Front-loaded with core action and ordering, followed by data payload description, and ending with capability note. 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?

  Compensates well for missing output schema by enumerating the specific fields returned (method, path, status code, duration, metadata). Would be perfect if it clarified the time window for 'recent' or mentioned total count availability.

  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 100% schema coverage, baseline is 3. Description adds context by mentioning 'Supports pagination', which explains the relationship between limit and offset parameters without repeating their individual schemas.

  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?

  Excellent clarity with specific verb 'List', resource 'webhook requests', scope 'received by a tunnel', and ordering 'newest first'. Distinguishes from sibling 'inspect_request' (single detail) by emphasizing 'recent' and listing summary fields.

  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?

  Implies usage context by stating 'recent' and describing pagination, suggesting it's for browsing history rather than deep inspection. However, lacks explicit guidance on when to prefer 'inspect_request' for detailed single-request analysis or limitations on historical data retention.

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

• overviewA
  4.4/5.0
  Behavior4/5

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

  While annotations confirm readOnlyHint=true, the description adds valuable behavioral context by detailing what specific data aggregates are computed (request counts, uptime, etc.). It also clarifies scope ('all tunnels') which explains why no input parameters are needed for filtering, complementing the safety annotations with content expectations.

  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 redundancy. First sentence front-loads the action and comprehensive data details (seven specific metrics listed). Second sentence provides concise usage guidance. Every word earns its place; no tautology or schema repetition.

  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?

  No output schema exists, but the description compensates well by enumerating the specific statistical fields included in the dashboard. Given the read-only aggregate nature and good annotation coverage, this is sufficient, though explicit mention of return structure format (object vs array) would achieve a 5.

  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?

  Zero parameters present, establishing baseline 4. The description reinforces this by stating it retrieves data for 'all tunnels', confirming no filtering or selection parameters exist and explaining why the empty schema is correct for this use case.

  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?

  Specific verb 'Get' with clear resource 'dashboard overview of all tunnels'. Enumerates exact aggregate statistics returned (total requests, success/error counts, success rates, online status, uptime, last request time), distinguishing it from sibling inspection tools like 'inspect_request' or 'tunnel_status' that likely handle individual items.

  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?

  Explicitly identifies when to use: 'Best starting point for understanding the current state'. This provides clear contextual guidance for beginning a session, though it does not explicitly name specific alternative tools for deeper dives (e.g., 'use list_tunnels for unaggregated data').

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

• list_tunnelsA
  4.6/5.0
  Behavior4/5

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

  Annotations cover safety profile (readOnly/destructive), but description adds valuable return value context: it specifies exactly what data fields are returned (status, protocol, creation time) despite lacking an output schema. Could clarify implications of openWorldHint/external 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?

  Two perfectly weighted sentences: first defines the operation and return payload, second provides usage context. Front-loaded with the action verb, zero redundancy or waste.

  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 zero-parameter list tool with good annotations, description adequately compensates for missing output schema by documenting returned fields. Minor gap: doesn't mention pagination behavior or caching implications of openWorldHint.

  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?

  Zero parameters present, triggering baseline score of 4 per evaluation rules. Schema coverage is 100% (empty object), requiring no compensation from description.

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

  Purpose5/5

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

  Clear specific verb 'List' with resource 'registered webhook tunnels' and attributes 'online/offline status, protocol, and creation time'. The word 'all' distinguishes it from sibling 'active_tunnels' (likely filtered), and 'registered' distinguishes from creation/connect 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?

  Explicitly states when to use: 'discover available subdomains before inspecting requests'. This directly references sibling tool 'inspect_request' as the logical next step, establishing clear workflow precedence.

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

• inspect_requestA
  4.7/5.0
  Behavior4/5

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

  Annotations cover read-only safety and idempotency. Description adds valuable content transparency by listing the specific data fields returned (headers, response body, metadata), compensating for the missing output schema. It doesn't mention side effects or rate limits, but annotations sufficiently 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?

  Two sentences, zero waste. First sentence front-loads the action and specific return fields; second sentence provides prerequisite. Every word 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 lookup tool, it compensates perfectly for the missing output schema by detailing what 'full details' includes. Combined with annotations and the explicit reference to list_requests, this is complete.

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

  Parameters4/5

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

  Schema has 100% coverage with 'The request UUID.' Description adds semantic value by specifying these IDs come from list_requests, establishing the tool relationship. Baseline 3 elevated by workflow context.

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

  Purpose5/5

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

  Description uses specific verb 'Get' and enumerates exactly what is retrieved (headers, body, status, duration, IP, metadata). It clearly targets a single webhook request, distinguishing it from list_requests (which lists many) and replay_request (which executes).

  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?

  Explicitly states prerequisite: 'Use request IDs from list_requests.' This tells the agent exactly when to use this tool (when you have a specific ID and need full details) and where those IDs originate.

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