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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds the constraint that files must be 'beneath the configured allowed root', which is a behavioral safety detail not present in any structured field. It also reinforces the read-only nature. 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.

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

The description is extremely concise: two short sentences that front-load the core purpose ('Render a local .html or .htm file') and key constraints ('beneath the configured allowed root', 'Read-only'). No fluff or redundant detail.

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

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

Given the tool has 6 parameters (fully documented in schema), annotations, and no output schema, the description is largely complete. It covers the file type constraint, the allowed root security boundary, the read-only nature, and the expected output (accessibility findings and corrections). Missing is explanation of what 'render' entails (e.g., headless browser, JavaScript execution), but this is minor and compensated by the schema details.

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

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

Schema description coverage is 100%, so each parameter (filePath, width, height, standard, maxIssues, maxNodesPerIssue) already has a description in the schema. The tool description adds no additional information about parameters beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the verb ('Render' and 'return accessibility findings and corrections') and resource ('local .html or .htm file beneath the configured allowed root'). It distinguishes itself from sibling tools like audit_url (which works on URLs) by explicitly specifying 'local file' and the file path restriction.

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

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

The description does not provide any explicit guidance on when to use this tool versus the available siblings (audit_url, audit_html, etc.). It does not state alternatives, prerequisites (e.g., file must be accessible), or exclusion criteria (e.g., not for raw HTML strings). The purpose implicitly suggests local files, but no clear usage context is given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, read-only operation. The description adds 'isolated headless browser' and 'Read-only' which align with and reinforce the annotations. No contradictions. The description provides modest additional context beyond 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.

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

The description is two sentences with no redundant or filler content. The first sentence clearly states the action and outcome, and the second provides usage guidance and a read-only note. Every part earns its place, making it highly efficient.

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

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

For a tool with 7 parameters and no output schema, the description covers the core purpose, usage context, and safety (read-only). It mentions the output type (WCAG findings, evidence, corrections) at a high level. However, it does not explain how parameters like standard or maxIssues influence behavior, though the schema descriptions handle those details. The description is sufficiently complete for an agent to use the tool effectively.

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

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

Schema description coverage is 100%, so each parameter already has a description in the input schema. The tool description does not add specific parameter-level details, but it does describe the output (WCAG findings, evidence, corrections), which indirectly informs parameter usage. Baseline 3 is appropriate given full schema coverage.

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

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

The description uses a specific verb ('Render') and resource ('supplied HTML') with a clear outcome ('return WCAG findings plus evidence and suggested corrections'). It also distinguishes from sibling tools like audit_url and audit_file by stating 'Use for generated UI before it is hosted', making the purpose unambiguous.

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

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

The description explicitly says 'Use for generated UI before it is hosted', which provides clear context for when to use this tool. While it does not explicitly list alternatives or when not to use, the sibling tool names (audit_url, audit_file) imply the distinction, and the guidance is sufficient for an agent to select this over siblings.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint true, and destructiveHint false. The description adds context: it uses headless Chromium, is read-only (reinforcing safely), and lists concrete outputs (WCAG findings, DOM evidence, computed styles, contrast corrections). 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.

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

The description is a single sentence front-loaded with the primary action and outputs, then ends with 'Read-only.' Every part is essential and no filler. Excellent structure and brevity.

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

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

Given 6 parameters (100% schema coverage), rich annotations, and no output schema, the description provides enough context for an AI agent to select and invoke the tool correctly. It covers inputs, behavior, and safety. Slight deduction because it doesn't mention pagination or error handling for invalid URLs, but overall complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value beyond schema by summarizing the overall return structure (prioritized findings, evidence, contrast corrections), but doesn't detail individual parameter behaviors beyond what schema provides. Slight extra context earns a 4.

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

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

The description clearly states the tool loads a page, runs axe-core, and returns prioritized WCAG findings with specific outputs like DOM evidence and computed styles. It distinguishes itself from siblings like audit_html and audit_file, which operate on different input types.

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

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

The description implicitly indicates usage for accessibility auditing of rendered URLs and mentions 'Read-only.' However, it does not explicitly contrast with siblings like check_contrast or explain_issue, nor does it specify when not to use this tool (e.g., for non-public pages or HTML fragments).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as false, so the tool's safe behavior is clear. The description adds value by explaining the return includes ratio and pass/fail for given text size/weight, but does not disclose any edge cases (e.g., handling of transparent colors, out-of-gamut colors) or limits (e.g., only sRGB). A 3 is appropriate as annotations carry the safety burden.

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

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

The description is a single sentence that front-loads the main action and includes key details (ratio, pass determination, text attributes). It is concise and efficient, though it could be slightly more scannable by breaking into two sentences. No redundancy is present.

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

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

Given the tool has 5 parameters (2 required) and no output schema, the description covers the main computation (contrast ratio and pass/fail) but omits specifics about return format (e.g., numeric ratio, boolean pass, object). For a calculation tool with moderate complexity, additional context about the scope (sRGB only) or limitations (e.g., does not handle transparency) would improve completeness.

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

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

Schema description coverage is 40%, so the parameter descriptions in the schema partially explain foreground/background colors as 'CSS sRGB color'. However, the tool description clarifies that both 'fontSizePx' and 'fontWeight' are used to determine the pass level, adding meaning beyond the schema's default values and constraints. It compensates for the missing schema descriptions on those parameters, though the level parameter's enum (AA, AAA) is already clear in the schema.

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

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

The description clearly states the verb 'Calculate' and the resource 'WCAG contrast ratio', and distinguishes the tool from siblings like 'suggest_contrast_fix' by specifying the output includes both the ratio and a pass/fail determination based on text size and weight.

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

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

The description implies usage for checking color contrast but does not explicitly state when to use this tool versus alternatives like 'suggest_contrast_fix'. It lacks guidance on prerequisites or context (e.g., checking multiple pairs vs. one). Without sibling differentiation, the agent may not know when to choose this over other audit tools.

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

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

Annotations already indicate the tool is read-only and non-destructive. The description adds that it returns 'remediation steps' and 'axe rule reference', which is useful but does not elaborate on any potential limits or side effects. Given the annotations cover the safety profile, a 3 is appropriate.

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

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

The description is one sentence that front-loads the core purpose ('return implementation-focused remediation steps') and adds the specific context about axe rule reference. No wasted words, but could be slightly more concise by removing 'the axe rule reference' redundancy.

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

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

Given that there is a single required parameter with full schema coverage and no output schema, the description sufficiently explains what the tool does and what it returns. It does not need to detail return structure since there's no output schema. The tool is straightforward and the description covers the key aspects.

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

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

The input schema already provides a detailed description for the 'ruleId' parameter (axe rule ID pattern), so schema coverage is 100%. The description does not add new parameter information beyond what the schema states, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns remediation steps and a reference for a given rule ID. It specifies the verb 'return' and the resource 'implementation-focused remediation steps and axe rule reference', and distinguishes from sibling tools like 'check_contrast' which are more specific.

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

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

The description implies the tool should be used when a rule ID from an audit is known, but does not explicitly state when NOT to use it or suggest alternatives. For example, it doesn't mention that if you need to run a new audit you should use 'audit_url' instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context about the output (references, coverage types) but does not disclose additional behavioral traits such as response size, pagination, or performance implications. Given the rich annotations, a 3 is appropriate as the description adds some value beyond the structured fields.

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

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

The description is two sentences long, each adding value. The first sentence clearly defines what the tool returns, and the second sentence provides usage guidance. There is no wasted text, and no repetition of schema information. This is a model of conciseness.

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

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

Given that the tool has three optional parameters, no output schema, and moderate complexity (WCAG profiles with multiple dimensions), the description is too minimal. It does not mention that all parameters are optional, the default value for 'standard' (wcag22aa), or what the response structure looks like (e.g., list of criteria with metadata). For a checklist tool used for planning, users need more context about how the parameters affect the results.

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

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

Schema description coverage is 0%, meaning the parameters (standard, principle, evaluation) have no descriptions in the schema. Although the parameter names and enum values are somewhat self-explanatory (e.g., 'standard' with values like 'wcag2aa'), the description does not explain how these parameters filter the checklist or fill the gap left by the schema. The description should at least describe the effect of providing these optional parameters.

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

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

The description explicitly states it returns 'every success criterion required by a WCAG 2.0, 2.1, or 2.2 A/AA/AAA profile, with W3C references, axe rule mappings, and explicit automated-partial versus manual coverage.' This clearly distinguishes the tool from sibling audit tools (audit_url, audit_html, audit_file) which perform automated checking, and from issue-specific tools (check_contrast, etc.). The verb 'return' and resource 'checklist' are precise.

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

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

The description explicitly states 'Use this to plan the checks that a browser audit cannot complete,' giving a clear use case and implying differentiation from automated audit tools. However, it does not explicitly state when not to use this tool or mention alternative tools for other scenarios, which would earn a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is safe and non-destructive. The description adds key behavioral context: it returns a 'mathematical candidate' and explicitly states it is 'not an automatic edit.' This goes beyond annotations by clarifying that the user must apply the suggestion themselves, fully disclosing the tool's scope.

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

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

The description is two sentences long, each sentence earns its place. The first sentence states the core function concisely; the second clarifies the non-destructive, advisory nature. No wasted words.

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

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

The tool has 6 parameters (2 required, 2 enums), moderate complexity. The description explains the what and the result, but lacks details like what happens when no adjustment can reach the threshold (returns null/error?). Additionally, there is no output schema, so the return format is left to experimentation. For a mathematical suggestion tool, the description is largely complete, but could mention error handling.

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

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

Schema description coverage is only 33%, meaning the schema documents only two parameters (foreground, background) with descriptions. The description adds meaning by explicitly mentioning 'black-or-white-directed' adjustments and connecting parameters to WCAG thresholds. It does not detail each parameter beyond what the schema provides, but for the low coverage, it compensates well by explaining the tool's purpose. The enum parameters (level, adjust) are left for the schema to define, which is acceptable given the tool's focused purpose.

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

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

The description uses specific verbs ('Find', 'adjustment') and resources ('foreground', 'background', 'WCAG contrast threshold'). It clearly identifies the tool's output as a mathematical candidate, distinguishing it from automatic edits and sibling tools like check_contrast or explain_issue.

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

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

The description does not explicitly state when to use this tool versus alternatives like check_contrast or get_wcag_checklist. However, the mention of 'nearest...adjustment that reaches the selected WCAG contrast threshold' implies it is used when a user needs a suggestion to fix contrast, and 'Returns a mathematical candidate, not an automatic edit' distinguishes it from an auto-fix. No explicit exclusions are given.

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