Server Quality Checklist

Tool Scores

• get_fix_verificationB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds polling behavior and scoped reporting ('only what was detected on selected pages'), which provides useful context beyond annotations. However, it does not elaborate on return format or potential edge cases.

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

  Conciseness3/5

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

  The description is very short (two sentences), but the 'Pro+' fragment is incomplete and potentially confusing. It is efficient but lacks clarity in the second part.

  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 tool's simplicity (1 param, annotations, output schema exists), the description is adequate but not thorough. It conveys the core purpose but misses details like expected response or prerequisites (already partly in schema).

  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% and the schema's description for fixVerificationId is already clear ('The id returned by verify_fix'). The description adds no further parameter meaning, so baseline 3 is appropriate.

  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 indicates the tool polls a fix verification and reports detected issues. The verb 'polls' and resource 'fix verification' are specific. It distinguishes from sibling tools like verify_fix (which initiates verification) and get_fixes (which lists all fixes), though not explicitly.

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

  Usage Guidelines2/5

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

  The description implies usage after calling verify_fix (since it requires a fixVerificationId from that tool), but it provides no explicit guidance on when to use or when not to use, and no alternatives are mentioned.

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

• get_fixesA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds that the tool returns 'status and the scope of any automated verification proof', which is output-oriented rather than behavioral. No additional behavioral traits (e.g., rate limits, side effects) are disclosed beyond annotations.

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

  Conciseness5/5

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

  The description consists of two concise sentences. The first sentence clearly states the purpose and includes output details. The second mentions the required feature gate. No extraneous information; front-loaded with the action verb.

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

  Completeness4/5

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

  Given the tool has a single parameter, no enums, and an output schema exists, the description adequately covers the purpose and output content. It mentions the required Pro+ feature. It might miss details like pagination or ordering, but these are likely covered by the output schema. Overall, it is sufficiently complete for a list tool.

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

  Parameters4/5

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

  The schema describes the single required parameter 'siteHost' as 'The registered site's normalized host'. The description adds value by specifying 'as list_sites reports it', which clarifies the expected format and ties it to another tool's output. This reduces ambiguity beyond the schema alone.

  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 'Lists tracked remediation items for a registered site', specifying the verb (list), resource (remediation items), and scope (per site). It distinguishes itself from siblings like verify_fix by focusing on listing, not verification. The inclusion of output details (status, verification proof scope) adds clarity.

  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 usage for listing fixes but lacks explicit guidance on when to use this tool over related siblings (e.g., get_fix_verification, verify_fix). The mention of 'Pro+ (REMEDIATION_TRACKING)' hints at subscription requirements but does not provide when-not-to-use or exclusion criteria.

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

• get_trendsA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds valuable behavioral context: chronological ordering, per-run points, severity counts, marker conditions, and plan requirement. 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?

  The description is two efficient sentences, front-loading key information: chronological order, data points, constraints. Every sentence adds value with no 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?

  Given the presence of an output schema and only two parameters, the description covers core aspects: data shape, ordering, feature marker, plan requirement. Missing details like limit default or pagination are minor omissions for a tool of this 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?

  Schema coverage is 100% with descriptions for both parameters. The description does not add extra meaning to parameters beyond what the schema provides. Baseline 3 is appropriate as the schema already documents parameters adequately.

  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 returns chronological per-run point history for a registered site's completed full-site runs, with counts by severity and optional added/resolved markers. It distinguishes from 'score' and mentions the Pro+ plan requirement, making the purpose specific 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 description implies usage for historical trend data and specifies constraints (registered site, completed full-site runs, no score). However, it does not explicitly compare with siblings like get_run or get_findings, nor does it state when not to use this tool. The guidance 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.

• get_pdf_checkA
  4.1/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint and idempotentHint. The description adds value by explaining the polling behavior and the specific data returned (status, counts, failure reason), which are not captured 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?

  The description is a single sentence that efficiently conveys the tool's purpose and return data. No unnecessary words or repetition.

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

  Completeness5/5

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

  Given the existence of an output schema (not shown but indicated), the description appropriately mentions key return fields without needing to detail the schema. The single parameter is clearly documented.

  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 a clear description for checkId. The description does not add significant new meaning beyond the schema, so a baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it polls a PDF check started by check_pdf and returns status, counts, and failure reason. It distinguishes from siblings by specifying the polling nature and the type of data returned.

  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 usage after check_pdf but does not explicitly state when to use this tool versus alternatives like get_scan or get_findings. No exclusions or alternative recommendations are provided.

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

• get_journey_runA
  4.2/5.0
  Behavior4/5

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

  Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds that the tool polls, provides per-step checkpoints, and gives failure reason on terminal state. No contradictions.

  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 key information, no redundancy. Every sentence adds value.

  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 full schema coverage and output schema implied, the description sufficiently covers polling behavior and terminal state. Minor gap: no mention of error handling or rate limits, but acceptable for a simple read-only 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 coverage is 100% for the single parameter runId, described as 'The id returned by run_journey.' The description does not add new meaning beyond the schema, so baseline score of 3.

  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 polls a journey run started by run_journey, with per-step checkpoints and failure reason. It differentiates from siblings like get_run by specifying 'journey run' and referencing run_journey.

  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 indicates usage after run_journey and mentions 'Pro+' tier. It does not explicitly state when not to use or list alternatives, but the sibling list provides context.

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

• verify_fixA
  4.2/5.0
  Behavior4/5

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

  Annotations provide minimal information (no read-only, destructive, or idempotent hints). The description adds value by explaining the tool queues a check, is targeted, and not a guarantee. It could mention response time or queuing behavior but is adequate.

  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 wasted words. Purpose is front-loaded, and the second sentence clarifies limitations. Ideal length for a simple tool.

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

  Completeness4/5

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

  With one parameter and an output schema (not shown), the high-level behavior is covered. The description lacks details like confirmation of queuing or polling instructions, but the tool's simplicity makes it mostly complete.

  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 a clear description for remediationItemId ('A fix id returned by get_fixes'). The description adds no further semantic details about how the ID is used, so 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 tool queues an automated re-check of representative pages for one tracked fix, distinguishing it from full-scans (scan_url) and listing tools (get_fixes). The verb 'verifies' is implied by the name and description.

  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 explicitly notes this is 'not a full-site re-scan or a compliance guarantee', but stops short of naming alternatives or stating when to use this over sibling tools like get_fix_verification. The mention of 'Pro+' hints at subscription requirements.

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

• check_pdfA
  4.3/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds behavioral details: it downloads the PDF, queues a check, counts against daily quota, and returns immediately. This goes beyond annotations by explaining the async workflow and quota impact.

  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 concise sentences front-load the core purpose and constraints, then add essential workflow info. No redundant phrases; every sentence contributes.

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

  Completeness5/5

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

  For a simple tool with one parameter, the description covers purpose, workflow, quota, and follow-up action (poll with get_pdf_check). The presence of an output schema is acknowledged, and the description complements it well.

  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 a clear description for the url parameter. The description reiterates 'public PDF URL' but adds no new semantics beyond the schema; the main value is in behavioral context, not parameter-specific details.

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

  Purpose5/5

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

  The description clearly states the tool downloads a public PDF and runs a PDF/UA-1 conformance check, specifying exact checks (structure, tags, reading order) and explicitly distinguishing it from a full WCAG audit, which differentiates it from siblings like scan_url.

  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 explains the free tier quota and the asynchronous nature (returns id, poll with get_pdf_check). It implicitly advises against use for full WCAG audits, providing some when-not guidance, though explicit alternatives are not named.

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

• get_root_causesA
  4.4/5.0
  Behavior5/5

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

  The description adds value beyond annotations by mentioning deterministic behavior and the limitation regarding automated-test coverage and component boundaries. It also notes the Pro+ tier, which is not 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?

  The description is three sentences with no wasted words. The first sentence states purpose, the second adds a behavioral caveat, and the third notes the tier. Each sentence serves a clear function.

  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?

  The tool has one required parameter, an output schema (not shown but present), and clear annotations. The description explains what is returned and gives a key limitation. For a simple read-only tool, this is nearly complete; a missing element would be describing the output structure, but the output schema likely covers that.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the parameter 'runId' is already documented as 'The id returned by scan_site.' The description adds no further semantic detail about the parameter beyond what the schema provides, earning a baseline of 3.

  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 returns 'deterministic repeated DOM patterns and factual blast-radius counts' for a 'full-site run', distinguishing it from sibling tools like get_findings or get_run_findings. It also specifies the Pro+ tier, which sets context.

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

  Usage Guidelines4/5

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

  The description provides implicit guidance by noting the tool is for full-site runs and warns that grouping 'does not expand automated-test coverage and may not match the site's real component boundaries'. However, it does not explicitly list alternatives or 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.

• run_journeyA
  4.4/5.0
  Behavior4/5

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

  Annotations include destructiveHint=true and openWorldHint=true. The description reinforces this by warning that saved steps can submit forms or trigger actions, and explains the async nature (queues and returns immediately). 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?

  The description is four sentences, front-loaded with the main purpose. Every sentence provides essential information: purpose, licensing, risk warning, and async polling. No filler or redundancy.

  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?

  The description covers purpose, side effects, async behavior, and polling. With an output schema presumed to describe the return format, it adequately informs the agent. Lacks details on error scenarios but remains largely 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 coverage is 100% with clear descriptions of siteHost and journeyName. The description adds value by clarifying that steps and credentials come from saved config and are not accepted as parameters, enhancing understanding beyond 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 clearly states the tool replays a saved multi-step journey and checks accessibility at each step. It distinguishes from siblings like scan_url and get_journey_run by emphasizing saved journeys and polling mechanism.

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

  Usage Guidelines4/5

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

  The description provides clear context: it warns about destructive side effects from saved steps, mentions license requirements (Pro+), and directs to poll get_journey_run. It implicitly contrasts with scanning tools but does not explicitly list alternatives.

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

• get_findingsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false. The description adds valuable behavioral context: the differential output based on scan type and the fields included. 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?

  Three sentences, each adding essential information without redundancy. Front-loaded with key information about the resource and output.

  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?

  With one parameter, output schema present, and annotations covering safety, the description is complete. It explains both usage scenarios and directs to alternative tool for different inputs.

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

  Parameters3/5

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

  The only parameter 'scanId' is fully described in the schema (100% coverage). The description mentions 'The id returned by scan_url' which matches the schema description, so no additional value beyond 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 clearly states the verb-resource (get findings) and specifies the outputs: rule id, severity, help URL, and element selector. It distinguishes from sibling tool 'get_run_findings' by noting the input type (scan_url vs scan_site).

  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 indicates when to use (both kinds of scan_url scans) and when not to (for full-site runs, use get_run_findings instead). Also explains the difference in output size (top-5 sample vs full findings) based on scan type.

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

• get_run_findingsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, ensuring safe read behavior. Description adds that results are deduplicated per rule and include WCAG mappings, but doesn't contradict 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: first delivers core purpose and details, second provides alternative usage. No unnecessary words, well-structured.

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

  Completeness5/5

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

  Given the presence of an output schema, description need not detail return format. It specifies scope (full-site scan), deduplication, and WCAG mapping, which is sufficient for the tool's 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% for the single parameter runId, with clear description in schema. Tool description does not add additional parameter semantics beyond what schema provides.

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

  Purpose5/5

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

  Clearly states it retrieves run-level, rule-deduplicated findings for a scan_site run, including WCAG success criteria mapping. Explicitly distinguishes from sibling 'get_findings' for single-page scans.

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

  Usage Guidelines5/5

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

  Provides explicit alternative usage: 'For a single-page scan from scan_url, use get_findings instead.' Also notes 'Pro+' restriction, setting clear context.

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

• list_sitesA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare non-destructive, read-only, idempotent nature. Description adds permission requirements (sites:read + API_ACCESS), which is useful behavioral context beyond annotations. No contradictions.

  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 concise sentences with front-loaded action. Every word adds value, no redundancy.

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

  Completeness5/5

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

  For a zero-parameter tool with annotations and output schema, description covers permission needs and output purpose. Complete and self-sufficient.

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

  Parameters4/5

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

  No parameters exist, so description does not need to add parameter meaning. Baseline 4 applies as no parameter information is missing.

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

  Purpose5/5

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

  Clearly states it lists registered sites and explains the significance of normalized hosts. Distinguishes from sibling tools like scan_url or get_scan which focus on scanning rather than listing.

  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?

  Implies usage to obtain site hosts for other Pro+ tools, but does not explicitly provide when-not-to-use or alternative options. Still clear enough given no competing list tools among siblings.

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

• scan_siteA
  4.5/5.0
  Behavior4/5

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

  Annotations are minimal, but the description adds key behavioral details: it queues asynchronously (returns immediately), requires a Pro+ plan (SCAN_FULL_SITE), and scans all reachable pages. No contradiction with annotations. Could mention rate limits or retries, but sufficient.

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

  Conciseness5/5

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

  Two efficient sentences: first states purpose, second adds usage pattern and prerequisite. Zero wasted words and critical details are front-loaded.

  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?

  With one parameter, high schema coverage, and an output schema, the description covers purpose, async behavior, plan requirement, and prerequisite. No gaps left unexplained.

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

  Parameters3/5

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

  Schema description coverage is 100%, with a detailed description of siteHost. The tool description adds context (Pro+ requirement, full-site crawl) but does not significantly enhance parameter understanding beyond the schema. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool crawls and scans every reachable page of a registered site. It distinguishes itself from sibling tools like scan_url (single URL) and get_scan (polling results) by specifying the full-site scope and immediate return with a runId.

  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 advises to call list_sites first if the host is unknown, and to use get_run to poll results. This provides clear when-to-use and alternatives, meeting the highest standard for usage guidance.

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

• scan_urlA
  4.5/5.0
  Behavior5/5

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

  The description goes beyond annotations, detailing that the tool returns an id immediately, never a compliance score, and explains the recording behavior. 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.

  Conciseness5/5

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

  The description is concise with three sentences, each adding value: purpose, behavior, and important limitation. No fluff.

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

  Completeness5/5

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

  Given the simplicity (1 param, output schema exists), the description fully covers what the tool does, how results are obtained, and the caveat about compliance scores. No gaps.

  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 3. The description adds 'Pass the URL and nothing else,' which slightly reinforces the single parameter but does not add significant new semantic information 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 clearly identifies the tool as scanning a single http(s) URL for accessibility problems using axe-core, distinguishing it from sibling tools like get_scan (polling) and check_pdf (PDF scanning).

  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 explains when to use (scan a URL), how results are obtained (poll with get_scan), and notes the recording behavior for registered sites. It does not explicitly mention when not to use but provides sufficient context.

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

• get_scanA
  4.6/5.0
  Behavior4/5

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

  Description adds beyond annotations by detailing return values (severity counts, finding sample, coverage disclaimer, failure reason) and clarifying it is a polling operation. 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.

  Conciseness5/5

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

  Two sentences, no wasted words. Purpose and key details are front-loaded. Every sentence adds value.

  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 output schema exists, description sufficiently summarizes return values and covers both scan types. A bit more detail on polling behavior could be added, but it's adequate.

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

  Parameters4/5

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

  The single parameter scanId is well-described in both schema and description; description adds context that it is the id from scan_url. Schema coverage is 100%, so minor extra value justifies above 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 clearly states the tool polls a scan started by scan_url, works for registered or one-off scans, and distinguishes from sibling get_run for full-site runs.

  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 says when to use (after scan_url) and when not (instead use get_run for full-site runs). Also mentions it works for either kind of scan.

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

• get_runA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context beyond annotations: it is a polling operation (implies repeated calls), provides progress, severity counts, and failure reason. The 'Pro+' hint about access control is additional.

  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, no wasted words. First sentence defines the tool's core function, second provides a clear alternative. Information is front-loaded.

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

  Completeness5/5

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

  The description is complete for a simple read-only poll tool with one parameter and an output schema. It explains what the tool does, what it returns, prerequisites (run started by scan_site), and distinguishes from sibling. No gaps.

  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 100% and already states 'The id returned by scan_site.' The tool description reinforces this by mentioning the parameter in context ('Polls a full-site run started by scan_site — ...'). This adds value by linking the parameter to the tool's workflow.

  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 'polls', the resource 'full-site run started by scan_site', and what it returns (page progress, severity counts, failure reason). It also distinguishes from the sibling tool 'get_scan' by specifying the scope (full-site vs single-page).

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

  Usage Guidelines5/5

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

  The description explicitly says when to use ('after scan_site') and provides an alternative ('For a single-page scan from scan_url, use get_scan instead'). Also mentions 'Pro+' which indicates access tier requirements.

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