Server Quality Checklist

Tool Scores

• webcheck_securityC
  2.9/5.0
  Behavior2/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. However, the description adds no behavioral details such as how the bundle aggregates results, execution order, concurrency, or error handling. For a multi-check tool, this is a significant gap.

  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 a single sentence that efficiently lists the bundled security checks. It is front-loaded with 'Security bundle' and avoids unnecessary words. While minimal, it serves its purpose without waste.

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

  Completeness2/5

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

  Given the tool's complexity (multiple checks) and lack of an output schema, the description is under-specified. It does not explain how results are structured, whether responses aggregate all checks or are separate, or how to interpret failures. More context is needed for an agent to confidently rely on this tool.

  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 80%, with url, timeout, base_url, and max_chars documented. The tool description does not add parameter meaning beyond the schema. The undocumented max_workers parameter remains unexplained in both the schema and description, keeping the score at baseline.

  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 identifies the tool as a 'Security bundle' listing specific checks (ssl, tls, hsts, etc.), which distinguishes it from individual sibling tools like webcheck_ssl and webcheck_dns. It lacks an explicit verb like 'runs' or 'checks', but the intent is clear.

  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?

  No usage guidance is provided. The description does not indicate when to prefer this bundle over individual security tools, nor does it mention any trade-offs or prerequisites. This is a missed opportunity given the sibling tools.

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

• webcheck_whoisB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and destructiveHint false, covering the safety profile. The description adds the endpoint path ('/whois') and the data type, but does not disclose additional behavioral traits such as rate limits or error behavior. This is consistent with annotations, with minimal added context.

  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 a single concise phrase that front-loads the key information. It is efficient, but slightly terse; a full sentence with a verb would improve clarity without sacrificing brevity.

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

  Completeness3/5

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

  Given the simple nature of the tool, the schema covers parameters and annotations cover safety, but the description omits any mention of the return format or behavior of the truncation parameter. It is minimally complete but could provide more 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 coverage is 100% with descriptions for url, timeout, base_url, and max_chars, so the schema fully documents parameters. The description does not add additional parameter semantics beyond the schema.

  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 identifies the tool as providing WHOIS/domain registration data via the Web Check /whois endpoint, distinguishing it from sibling tools like webcheck_dns or webcheck_ssl. However, it lacks an explicit verb (e.g., 'retrieves'), which prevents a top score.

  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?

  No guidance is provided on when to use this tool versus alternatives in the sibling set. The description simply states what it does, leaving the agent to infer usage context.

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

• webcheck_dnsA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds only the endpoint path (/dns) but no additional behavioral context such as rate limits or response structure. No contradiction exists.

  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, direct sentence that front-loads the action and target. It contains no redundant information and wastes no words, making it easy for an agent to parse quickly.

  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 straightforward read-only DNS fetch, the description with a fully covered schema and strong annotations is sufficient. The only minor gap is that it does not hint at the type of DNS records returned (e.g., A, MX, TXT), but the tool name and purpose make this inferable.

  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 all four parameters (url, timeout, base_url, max_chars) are fully documented in the schema. The description does not need to repeat parameter details; it remains consistent with 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 clearly states the action (fetch), the resource (DNS records for a domain), and the specific endpoint (/dns). It distinguishes itself from sibling tools like webcheck_ssl or webcheck_whois by naming the exact data type.

  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?

  Usage context is implied: this tool is for fetching DNS records. However, it does not explicitly mention alternatives or when not to use it, leaving the agent to infer based on sibling names. It lacks explicit 'use this for DNS, use webcheck_ssl for certificates' guidance.

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

• webcheck_headersA
  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 destructiveHint=false, so the safety profile is covered. The description adds the API endpoint context but no further behavioral details such as rate limits, redirect handling, or response format. It does not contradict 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, efficient sentence that front-loads the verb and resource. Every word earns its place, with no redundancy or filler.

  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-only tool with fully documented parameters and clear safety annotations, the description is sufficient. It could mention return format or potential errors, but the tool name and schema provide most necessary context, making it complete enough for this scenario.

  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?

  All four parameters are fully described in the input schema (100% coverage), so the description does not need to add parameter details. It adds no additional meaning beyond what the schema provides, but that is acceptable given the schema's thoroughness.

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

  Purpose5/5

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

  The description clearly states the verb ('Fetch') and the specific resource ('HTTP response headers'), plus the exact API endpoint ('/headers'). This distinguishes it from sibling webcheck tools like webcheck_ssl or webcheck_dns, which target different resources.

  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 no explicit when-to-use or when-not-to-use guidance, nor any comparison to alternatives. The intended usage is implied by the tool name and resource, but the lack of explicit exclusions or references to sibling tools leaves it to the agent to infer.

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

• webcheck_healthA
  3.8/5.0
  Behavior3/5

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

  The description adds behavioral context by indicating a network 'probe' for reachability, which complements the readOnlyHint=true and destructiveHint=false annotations. However, it does not disclose what happens on failure (e.g., error response, status codes) or any side effects. Since annotations already cover safety, the description adds moderate value but lacks deeper behavioral details.

  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, clear sentence that front-loads the action ('Probe') and resource. There is no redundant or filler content, making it highly concise and well-structured.

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

  Completeness4/5

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

  For a simple health-check tool with full schema coverage and annotations indicating a safe, read-only operation, the description is sufficient to convey the core action and expected outcome. While there is no output schema to clarify the return format, the nature of a reachability probe implies a boolean or status result. A small gap exists in not describing error behavior or return details, but overall it is complete for the tool's simplicity.

  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 provides full descriptions of both parameters (timeout and base_url), including defaults and environment variable fallback. The tool description itself adds no additional meaning to the parameters, so with 100% schema coverage, the baseline score of 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 clearly states the tool's purpose with a specific verb ('Probe') and resource ('the configured Web Check API base URL'), and it explicitly focuses on reachability. This distinguishes it from sibling tools like webcheck_run or webcheck_ssl, which perform specific checks rather than a general health probe.

  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 this is a preliminary connectivity check for the API base URL, especially given sibling tools like webcheck_list_checks and webcheck_run. However, it does not explicitly state when to use this tool instead of others, nor does it mention any exclusions or alternative tools. The usage context is implied but not explicit.

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

• webcheck_list_checksA
  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 destructiveHint=false, so the safety profile is clear. The description adds minimal behavioral context beyond the resource being listed, but for a simple listing tool, no additional side-effect disclosure is necessary. It is consistent with 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?

  A single, front-loaded sentence that succinctly conveys the tool's purpose. Every word earns its place, with no filler or redundant 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?

  For a simple listing tool with good annotations and one well-documented parameter, the description sufficiently conveys its function and output type (a list of endpoints/groups). A slightly richer note about the output format or intended use would push it to 5, but it is complete for the tool's complexity.

  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 already provides complete documentation for the single optional parameter 'group' (with a description of valid presets). The description adds no further parameter semantics, so the baseline of 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 the specific verb 'List' and clearly identifies the resource as 'available Web Check endpoints/groups', with examples (ssl, dns, headers, ports). This clearly differentiates it from the sibling tools that actually perform checks rather than listing them.

  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 that this tool is for discovering available endpoints/groups, but it does not explicitly state when to use it relative to alternatives (e.g., before running a specific check) or when not to use it. Usage context is inferred rather than stated.

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

• webcheck_sslA
  4/5.0
  Behavior3/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 known. The description adds minimal behavioral context beyond the endpoint name; it doesn't mention response format, truncation, or potential errors. With annotations covering safety, the additional value is modest.

  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, direct sentence that immediately states the tool's purpose. No unnecessary words or 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?

  For a read-only fetch tool with complete schema coverage and annotations declaring safety, the description sufficiently covers the tool's purpose. It doesn't detail output structure, but the return value ('SSL certificate chain') is implied, and the schema handles parameter details.

  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 all four parameters described in the schema. The description does not add parameter-specific semantics beyond what the schema already provides, so a 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 clearly states the action ('Fetch'), the resource ('SSL certificate chain'), and the target ('for a URL'). It also specifies the mechanism ('via Web Check /ssl'), which distinguishes it from sibling tools like webcheck_dns or webcheck_headers.

  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 the use case—checking SSL certificate information for a URL—and is clearly distinct from siblings. However, it does not explicitly state when to use it over alternatives or mention any exclusions, so it falls short of a 5.

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

• webcheck_runA
  4.3/5.0
  Behavior4/5

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

  Annotations already mark it as read-only and non-destructive, and the description adds behavioral context about parallel fan-out and heavy-check avoidance. There is no contradiction with 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?

  Two sentences, front-loaded with the core action, and every clause adds practical value. No filler or repetition of schema/annotations.

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

  Completeness3/5

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

  For a seven-parameter tool with no output schema, the description omits what the return payload looks like or how errors/timeouts are handled. It covers purpose and usage well but leaves result behavior implied.

  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 description coverage is 86%, so the baseline is 3. The description adds value by connecting group=quick to reconnaissance and naming example heavy checks (screenshot/ports/traceroute), going beyond what the schema alone states.

  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 a specific verb and resource ('Run ... Web Check jobs against a URL') and highlights 'parallel fan-out', clearly distinguishing it from sibling single-check tools. The action and target are unambiguous.

  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 explicit guidance to prefer group=quick for recon and avoid heavy checks unless needed. While it does not name sibling tools as direct alternatives, it gives clear when-to-use and when-to-avoid direction.

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