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

No annotations are provided, so the description carries the transparency burden. It discloses the grouping strategies (url, category, rule, none) and that aggregated summary statistics are produced, but it does not explain the output format or whether the input results are modified. This is moderate behavioral disclosure but leaves important details unspecified.

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 leads with the main action, then lists grouping options and the summary output. Every phrase adds value; no redundancy or unnecessary 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?

The schema clarifies parameters, but there is no output schema, so the description should describe return values. It mentions 'aggregated summary statistics' only vaguely and does not specify the shape of the returned object, which is a meaningful gap for a tool that aggregates heterogeneous audit 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?

The schema describes all three parameters with 100% coverage, so the description does not need to repeat them. The description's mention of grouping and summary statistics mirrors the schema's enum and includeSummary field without adding deeper semantics or usage nuance, meeting the baseline.

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-resource pair: 'Combine and aggregate multiple audit results.' It also names the grouping options, which clarifies its role. However, it does not explicitly differentiate itself from siblings like get_statistics or generate_summary_report, so it is clear but not fully distinctive.

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 phrase 'multiple audit results' indicates the intended context: use when you have several audit result objects to aggregate. It does not provide explicit exclusions or name alternative tools for different scenarios, but the condition is clear enough for selection.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions optional parallel processing and progress tracking, which are useful behavioral traits, but it does not disclose error handling, side effects, or any requirements. This is adequate but not rich.

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?

A single, front-loaded sentence that states the core purpose and key features without filler. Every word contributes value, 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.

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

For a tool with six parameters and no output schema, the description gives the high-level purpose but omits details about return values, error handling, or input formats. The rich schema and sibling context compensate, but the description alone leaves some gaps for a complete understanding.

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

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

The schema covers 100% of parameters, so the baseline is 3. The description adds the concept of progress tracking, which is not a parameter, and aligns with the 'parallel' parameter, but it does not add significant meaning beyond the schema's existing parameter descriptions.

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

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

The description clearly states the tool tests multiple URLs, distinguishing it from sibling tools like audit_url which handle individual URLs. It also adds specific behavioral features (parallel processing, progress tracking) that make 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 phrase 'multiple URLs' implies use when multiple URLs need testing, and the context of sibling tools (audit_url for single URLs) reinforces this. However, it does not explicitly state when to choose this over alternatives or provide exclusion criteria, leaving the guidance somewhat implied rather than explicit.

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?

With no annotations provided, the description carries full behavioral disclosure. It states it returns structured, conversational results with prioritized issues and fix suggestions, which is informative. However, it does not explicitly state that the operation is read-only or describe any limitations (e.g., handling of invalid URLs, network dependency), though these are not contradictory.

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, front-loads the action, and provides useful output details without filler. It earns a top score for efficiency.

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 six parameters and no output schema or annotations, the description is slightly thin but adequate. It explains the purpose and output format, but could mention additional behaviors like handling relative paths or engine selection, though the schema covers these. A score of 3 reflects a minimally complete description.

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

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

All six parameters have schema descriptions (100% coverage), so the schema carries the parameter details. The description does not add further parameter semantics, but its mention of 'conversational results' hints at the output rather than the input, 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 uses a specific verb ('Test'), clarifies the resource ('a single URL'), and the intent ('accessibility issues'). It also differentiates from siblings like audit_multiple_urls by explicitly stating 'single URL'.

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 provides clear context: it's for testing a single URL, which implies use cases. However, it does not explicitly reference alternatives such as audit_multiple_urls for batch auditing or audit_with_session for session-based testing, so it misses an opportunity to draw contrasts.

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?

With no annotations provided, the description carries the full burden. It discloses the core behavior (using an existing session, avoiding re-authentication) but does not mention side effects (e.g., whether it consumes the session, if it's read-only, or if it creates any records). The 'protected pages' context adds value but lacks details on what the audit does beyond that.

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

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

Two sentences, front-loaded with the action, and zero filler. The first sentence states the operation, the second explains the benefit, which is concise and 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?

The description is complete for the basic use case (authenticated audits), but lacks context about how to obtain a session (sibling create_session), potential alternatives (audit_url), and return value expectations since no output schema exists. It covers the core purpose but leaves some gaps given the absence of annotations/output schema.

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

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

Schema description coverage is 100%, so parameters are well-documented. The tool description itself adds little beyond the schema, though it does imply that sessionId is used to maintain authentication. Baseline 3 is appropriate as the description does not further explain parameter usage or relationships.

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

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

The description clearly states the tool's action: 'Run an accessibility audit on a URL using an existing authenticated session.' It uses a specific verb ('run') and resource ('accessibility audit'), and differentiates from siblings by explicitly mentioning the existing session and protected pages, which separates it from plain audit_url.

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 provides clear context for when to use this tool: 'This allows testing protected pages without re-authenticating for each audit.' It implies it's intended for authenticated/protected content, but does not explicitly mention alternatives or exclusions (e.g., when to 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?

With no annotations, the description carries the full burden. It discloses the output content (fixed/introduced/remaining issues, score change, visual diff). It does not mention side effects like auto-running audits on URL input, but that is already captured in the schema.

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

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

Two sentences, front-loaded with the primary purpose and key output categories. No redundant information or filler.

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

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

The tool is simple, the schema is rich, and the description covers the essential behavioral outcome. It lacks mention of prerequisites or error conditions, but for a comparison tool this is adequate without being exhaustive.

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 the schema already explains before/after/format in detail. The description adds no new parameter-level meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description uses a specific verb+resource ('Compare two accessibility audits') and clearly differentiates from siblings like get_accessibility_score or track_accessibility by stating it identifies fixed, introduced, and remaining issues plus score improvement and visual diff summary.

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 makes the use case clear: tracking improvements between two audits. It does not explicitly name alternatives or exclusions, but the sibling tools for single audits or scores make the comparison purpose distinct.

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?

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states that the tool logs into a website and creates a reusable session, but does not mention credentials handling, session persistence, security implications, or potential side effects (e.g., server-side session creation). This is a significant gap for a tool that handles authentication.

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

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

The description is concise (two sentences), front-loads the core action, and contains no redundant information. Every word serves a purpose, 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.

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

The tool has a nested object (loginSelectors) and no output schema, yet the description does not mention what the tool returns (e.g., sessionId) or how the session is used with sibling audit tools. While the schema documents parameters, the description lacks high-level context about the workflow (e.g., the need to pass the session to audit_with_session). This is a moderate gap for a tool that serves as a prerequisite to other audit tools.

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 the baseline is 3. The description does not add any parameter-specific semantics beyond what the schema already provides; it does not explain how parameters like domain, username, or loginSelectors interact. The schema handles parameter documentation adequately, so no additional credit is warranted.

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

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

The description clearly states the tool's function with a specific verb ('create') and resource ('reusable authenticated session'), and distinguishes it from sibling tools like audit_with_session by focusing on session creation rather than usage. It also mentions the purpose for audits of protected pages, which provides useful context.

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 context by noting the session is 'reused for multiple audits of protected pages,' which signals when to use this tool. However, it does not explicitly mention alternatives or exclusions (e.g., when to use audit_with_session directly with existing credentials), losing a point for not naming any sibling tool or alternative.

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

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

No annotations are provided, so the description carries the burden. It discloses the tool's educational nature and what it provides (WCAG references, code examples), but does not specify the output format or any behavioral edge cases. For a read-only explanatory tool, this is adequate but not rich.

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 packs the core purpose and deliverable list efficiently without filler. It is concise and front-loaded, though it could be slightly more structured with explicit segments.

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 is simple (2 parameters, no output schema) and the description covers its educational scope well. The missing return format is minor for an explain tool, and the schema handles parameter documentation. Overall, the description is sufficient.

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

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

Schema description coverage is 100%, with both ruleId and context well described. The tool description does not add any parameter-specific meaning beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the tool's purpose: 'Explain what an accessibility issue means in plain language' with a specific scope (why it matters, how to fix it, WCAG references, code examples). It distinguishes from sibling audit/fix tools by emphasizing educational content, though it does not explicitly name an alternative.

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

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

The description implies usage when a user needs to understand an accessibility issue, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like get_quick_fixes or filter_issues. Context is present but exclusions are absent.

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?

No annotations are provided, so the description carries the burden. It adds value by mentioning the CSV includes metadata and violation rows, but it does not disclose whether the tool triggers an audit when given a URL, or any side effects. This is minimal but not misleading.

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

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

Two concise sentences communicate the purpose and key output features with zero wasted words. Information is front-loaded.

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

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

The description is short but sufficient for a simple export tool given the rich schema. It covers the output structure but omits the URL-triggers-audit behavior, which is documented in the schema. Overall complete enough.

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

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

Schema coverage is 100%, so parameters are fully documented there. The description adds no additional param-level meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool exports audit results to CSV, which is a specific verb+resource. It distinguishes itself from sibling export tools by naming the format and use case (spreadsheet analysis).

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 phrase 'for spreadsheet analysis' gives clear context for when to use this tool, and the siblings listing shows alternative formats, but no explicit exclusions or when-not-to-use guidance is provided.

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?

No annotations are provided, so the description must convey behavioral traits. It mentions the xlsx package requirement, which is a useful dependency note. However, it does not disclose important behaviors such as how the output is delivered (e.g., file path, download), whether it triggers an audit when a URL is passed (the schema covers this, but the description doesn't add context), or any side effects. The description is too sparse to give the agent a clear picture of the tool's runtime behavior.

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, consisting of two short sentences that immediately state the core function and a prerequisite. Every word earns its place, and there is no redundant or inflated language. It is well-structured and front-loaded, making it easy to scan.

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 no output schema and no annotations, the description leaves significant gaps: it does not explain how the exported file is returned or saved, does not mention that the 'results' parameter can be a URL to trigger a new audit (though the schema does), and offers no guidance on choosing this tool over sibling export tools. For a tool with multiple parameters and related siblings, the description is under-specified.

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 provides complete descriptions for all three parameters (results, formatting, includeCharts), so the baseline is 3. The description does not add any parameter-specific information beyond the schema; it merely echoes the formatting concept without elaborating on the parameters themselves. No value is added over 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 identifies the action (export), the resource (audit results), and the destination format (Excel/XLSX). It distinguishes itself from sibling export tools by naming the specific format. The mention of formatting adds useful context without ambiguity.

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 by specifying the output format (Excel/XLSX), suggesting it is appropriate when an Excel file is desired. However, it does not explicitly contrast with sibling tools like export_to_csv or export_to_json, nor does it state conditions for when to prefer this tool over alternatives. 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.

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

With no annotations provided, the description must disclose behavioral traits, but it only mentions 'standalone' and 'optional visual charts' — features rather than behaviors. It does not describe return format, side effects, prerequisites, or limitations, which 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.

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

The description is two short, front-loaded sentences with no fluff. Every word contributes to the core message, making it very concise and scannable.

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

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

The tool has a dual-mode results parameter and no output schema, yet the description does not explain what the tool returns (HTML string, file path, etc.) or mention the dual-mode behavior. The schema covers parameters, but the description omits essential context for confident use, making it incomplete.

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 covers all three parameters with descriptions, including the dual nature of the results parameter (object or URL). The description adds no extra semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the primary action: generating a standalone HTML report with styling. This distinguishes it from CSV/Excel/JSON export tools, but it does not explicitly differentiate from other report-generating siblings like generate_summary_report or generate_dashboard.

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?

There is no guidance on when to use this tool versus other export/reporting tools. The description does not mention alternatives, exclusions, or typical use cases, leaving the agent without decision-support.

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?

With no annotations provided, the description must fully disclose behavioral traits. It fails to mention that providing a URL string will run an audit first, which is a significant side-effect. The description only covers output formatting options (pretty, raw) and does not disclose any potential side effects or state changes. This is a notable transparency gap.

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 highly concise, consisting of two short sentences that get straight to the point. It front-loads the core function and mentions the key options without wasting words. Every sentence contributes meaningful information, making it appropriately sized for the tool's simplicity.

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?

Despite the schema detailing parameters, the description omits the crucial context that the 'results' parameter can be a URL which triggers an audit. This dual-mode behavior is not reflected in the description, leaving the tool's full capability ambiguous. With no output schema and no annotations, the description does not sufficiently situate the tool among its siblings or clarify when to use it.

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

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

The schema description coverage is 100%, with each parameter already having clear descriptions. The tool description adds minimal semantic value beyond the schema, only loosely referencing 'pretty-printing' and 'optional raw results,' which map to the schema's existing parameter descriptions. Since the schema already explains the parameters well, the description's contribution is marginal.

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

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

The description clearly states the tool's function: 'Export audit results as structured JSON.' This is a specific verb+resource that distinguishes it from sibling export tools like export_to_csv and export_to_html_report. It also mentions the supported features (pretty-printing and optional raw results), further clarifying its purpose.

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

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

The description implies usage when JSON output of audit results is needed, but provides no explicit guidance on when to choose this tool over alternatives. There is no mention of the fact that passing a URL triggers an audit, which is a critical usage nuance. The context of being a JSON export tool gives some implied direction, but no explicit when/when-not/alternatives are stated.

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?

No annotations are provided, so the description must fully disclose behavior. It mentions include/exclude modes but fails to reveal whether the input results are mutated, how multiple filter criteria are combined (AND/OR), or what the return value looks like. The lack of such essential behavioral details leaves the agent uncertain about side effects and results.

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, front-loaded with the core action, and contains no redundant information. Every word contributes to understanding the tool's purpose and key modes.

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 is moderately complex due to a nested filters object and an enumeration-driven mode, but the description does not address important contextual aspects like output format, behavior with no matching filters, or interaction between filters. Without an output schema, the description should clarify what the tool returns, which it omits.

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

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

The schema provides 100% coverage of parameter descriptions, so a baseline of 3 is appropriate. The description adds minimal value beyond the schema—it lists criteria that are already in the schema's property descriptions. It does not clarify the 'results' parameter further than the schema already does.

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

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

The description clearly states the tool's function: 'Filter issues from audit results by various criteria' with specific mention of criteria types (rule IDs, categories, impact levels, WCAG levels). It also distinguishes itself by mentioning 'includes/exclude modes', a feature not implied by sibling names like 'search_issues' or 'prioritize_issues'.

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?

There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., having an audit result before filtering), nor does it specify contexts where include or exclude modes would be preferred. The description simply states what it does without situational advice.

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?

With no annotations, the description must carry the full burden of behavioral disclosure. It describes report contents but does not clarify side effects, return format, whether it persists data, or prerequisites (like results from a prior audit). This leaves the agent uncertain about the tool's operational impact.

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 is front-loaded with the main verb and object, and it contains no filler. It efficiently lists formats and key contents, though it could be structured into two sentences for even better readability.

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

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

Given the tool's complexity (4 parameters, nested results object, no output schema), the description provides a reasonable summary but misses key contextual details: it does not mention the required 'results' parameter, describe the return value shape, or explain how it differs from other reporting tools. This is adequate but not 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 the baseline is 3. The description adds limited semantic value, only mentioning the 'optional remediation plan' which maps to includeRemediation. It does not elaborate on level or format relationships beyond what the schema already provides.

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

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

The description clearly states the tool's purpose with a specific verb ('Generate'), the resource ('compliance reports'), and enumerates supported formats (VPAT, WCAG, ADA, Section 508). It also lists key report contents, distinguishing it from sibling tools like generate_summary_report or export_to_html_report.

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 generating compliance reports in specific formats, but it does not provide explicit exclusions or comparisons with alternative tools. Since siblings like generate_summary_report and export_to_html_report overlap, more guidance on when to prefer this tool would be useful.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention that the 'results' parameter can accept URLs and trigger audits, a significant side effect evident in the schema. It also does not describe the output format or whether the operation is read-only or creates persistent artifacts, so transparency is limited.

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, consisting of two sentences that front-load the primary purpose and then list supported formats. Every word adds information, with no redundant details.

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 moderate complexity (accepting objects, arrays, or URLs) and no output schema, the description is somewhat lacking. It explains the output concept ('visual dashboard summary') but does not specify what the returned dashboard looks like, nor does it mention the audit-before-dashboard behavior for URL inputs, which is covered only in the parameter schema.

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

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

The schema already provides detailed descriptions for all three parameters, including enums and defaults. The description adds no new information about parameter values beyond restating that formats include text, markdown, HTML, and JSON and that charts are optional, so it does not exceed the baseline provided by 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 identifies the tool's function with a specific verb ('Create') and resource ('visual dashboard summary of audit results'). It mentions key elements (metrics, charts, summaries) that differentiate it from sibling report tools like generate_summary_report or export_to_html_report.

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 explicit guidance on when to use this tool versus alternatives such as generate_summary_report or generate_compliance_report. It only implies that it is suitable when a dashboard with visual charts is desired, leaving the agent to infer the appropriate context.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention that providing URLs as input will trigger an audit first, nor does it clarify whether the operation is read-only or has side effects. The description only lists capabilities, not behaviors.

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 and front-loaded with the main purpose. Every sentence is informative and there is no redundant filler.

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

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

The tool has three parameters, no output schema, and no annotations. The description omits the important behavior that URL inputs trigger an audit, which could lead an agent to misuse the tool. The report content and return format are only vaguely implied, leaving gaps for correct invocation.

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

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

Schema description coverage is 100%, with detailed descriptions for each parameter including enums and defaults. The description mentions 'multiple formats (text, markdown, HTML)' and 'detail levels (executive, detailed, technical)', which reinforces the schema but adds minimal new meaning beyond it.

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

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

The description clearly states the tool's function: 'Generate executive summary report with key findings and recommendations.' It uses a specific verb ('Generate') and resource ('executive summary report'), and the mention of formats and detail levels distinguishes it from sibling tools like generate_compliance_report or export_to_html_report.

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 is used for creating executive summaries but does not explicitly state when to use it over alternatives such as generate_compliance_report or prioritize_issues. No exclusions or alternative tool references are provided.

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?

No annotations are present, so the description carries the burden. It does not disclose that providing a URL triggers an audit first, which is a significant side effect. However, the schema covers this, and the 'get' prefix suggests read-only behavior, so the description is not misleading but lacks depth.

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, front-loaded with the primary purpose, and contains no unnecessary words. Every clause adds useful information about breakdowns and weights.

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?

With only 2 parameters, a complete schema, and no output schema, the description adequately covers the score range and breakdown nature. It could mention the URL-triggered audit behavior and return format details, but the tool is simple enough that the description is mostly sufficient.

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

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

Schema coverage is 100% for both parameters (results and weights), so the schema already provides clear semantics. The description adds only the mention of custom weights, which slightly reinforces but does not substantially extend the parameter meaning.

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 'accessibility score (0-100)', with specifics about breakdowns by category and WCAG compliance levels. It also mentions custom weights, distinguishing it from sibling tools like audit_url or prioritize_issues.

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 when you have audit results and want a score, but it does not explicitly state when to use this tool versus alternatives like get_wcag_compliance or audit_url. No exclusions or alternative guidance is provided.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does state that fixes are returned in different formats, but it fails to mention a key behavioral trait: if a URL is provided in the 'results' parameter, an audit will be run first. It also does not disclose that the 'includeCode' parameter can omit code examples. This is a significant gap for a tool with no annotations.

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

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

The description is two sentences, front-loaded with the verb and resource, and every phrase earns its place. No wasted words or redundant details.

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 is relatively simple with a well-documented schema, but the description omits important behavioral context (the URL-triggered audit and the includeCode toggle). While the schema covers these, the description alone is insufficient for an agent to fully anticipate side effects. Given the low complexity, a 3 is reasonable.

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 has 100% coverage for all three parameters with detailed descriptions, so the baseline is 3. The description adds minimal value beyond the schema, only mentioning output formats that correspond to the 'format' parameter. It does not add further meaning to 'results' or 'includeCode'.

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

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

The description clearly states the tool's purpose with a specific verb ('Get'), a specific resource ('fix suggestions'), and a source ('from audit results'). It also mentions the output formats, distinguishing it from sibling tools like explain_issue or audit_url.

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 clearly implies usage context: use this tool when you have audit results and need actionable fixes. It does not explicitly name alternative tools or exclusion criteria, but the context is clear enough. No explicit exclusions are given, so a 4 is appropriate.

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?

No annotations are provided, so the description carries the full burden. 'Generate detailed statistics' implies a non-mutating analysis operation, but the description does not explicitly state side effects, return format, or any permissions required. It provides minimal but sufficient transparency for a likely read-only tool.

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 concise sentences, front-loaded with the main purpose and followed by relevant detail. No redundant or extraneous information, making it efficient and easy to parse.

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 no output schema, the description does not explain what the returned statistics look like (e.g., counts, percentages, structure). It also omits edge cases like empty results or how breakdowns are presented. While adequate for a simple statistics tool, the lack of output details leaves some uncertainty.

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

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

Schema description coverage is 100%, with both parameters described in the schema. The description adds little beyond the schema, only restating the breakdown dimensions and supporting single/multiple results, which are already covered by the schema's oneOf definition. The baseline of 3 is appropriate when schema handles the semantic heavy lifting.

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 generates detailed statistics from audit results and lists specific breakdown dimensions (category, impact, WCAG level, rule ID). It also notes support for single or multiple audit results. While it doesn't explicitly distinguish itself from siblings like aggregate_audit_results or generate_summary_report, the focus on statistical breakdowns makes the purpose clear.

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 generating statistics from audit results, and the phrase 'Supports single or multiple audit results' gives context on input flexibility. However, there is no explicit guidance on when to prefer this tool over alternatives, nor any mention of 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.

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

No annotations exist, so the description must disclose behavioral traits. It mentions the return values (pass/fail/partial, percentage, violations, missing requirements) but omits key behaviors like that a URL input triggers a fresh audit, or any side effects, permissions, or rate-limit concerns. For a read-only tool this is acceptable, but the missing audit-trigger behavior is a notable gap.

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, each earning its place: the first states the primary action, the second lists the returned information. There is no redundancy or filler.

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

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

The description covers the return content in reasonable detail, which is important given no output schema. However, it does not mention that the tool can accept a URL to audit first, nor does it provide usage context relative to related tools. This leaves some gaps for a relatively simple tool.

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 has 100% coverage, including descriptions for both 'results' and 'level'. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Check' and resource 'WCAG compliance status', and specifies the detailed per-criterion breakdown, which differentiates it from the sibling get_accessibility_score. However, it does not explicitly distinguish itself from other compliance-related tools like generate_compliance_report, so it stops short of a 5.

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?

No guidance is provided about when to use this tool versus alternatives such as get_accessibility_score or audit_url. The description only states what the tool does, without mentioning prerequisites, context, or exclusion conditions.

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?

With no annotations provided, the description carries the full burden of disclosing behavior. It mentions the outcome of identifying quick wins and critical blockers, but does not state whether the tool is read-only, returns a new list, or modifies the input. It also omits return format and any side effects, which 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.

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

The description is a single concise sentence that front-loads the core action. It includes useful, specific details (quick wins, critical blockers) without redundancy, and does not repeat schema information. The only minor padding is 'Intelligently', but it does not detract from overall efficiency.

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

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

The description gives a high-level overview of the tool's function and outputs categories, but with no output schema it fails to fully describe the return structure. It also does not explain how prioritization criteria affect the output or how the 'results' object is processed, leaving gaps for the agent.

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 the baseline is 3. The description adds little beyond the schema, only referencing 'specified criteria' which is already detailed in the criteria enum. It does not elaborate on the 'results' or 'limit' parameters, which are well-covered by the schema.

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

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

The description clearly states the tool's purpose: to prioritize accessibility issues based on specified criteria. It adds specificity by identifying 'quick wins' and 'critical blockers', which distinguishes it from sibling tools like filter_issues or search_issues. The verb 'prioritize' and resource 'accessibility issues' are explicit.

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 prioritization tasks via 'based on specified criteria' and 'identifying quick wins and critical blockers', but it does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or comparisons to sibling tools, leaving the agent to infer applicability.

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?

With no annotations, the description carries the full burden of behavioral disclosure, but only mentions case sensitivity support. It does not clarify that the tool searches within an existing audit results object, nor does it describe the return behavior or any side effects.

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 concise sentences, front-loaded with the action 'Search issues', and contains no filler or redundant information.

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 4 parameters, a nested result object, and no output schema, the description is too sparse to fully guide an agent. It omits the requirement for a previous audit result, the return format, and how results are limited, leaving important operational context missing.

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

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

The schema provides full descriptions for all parameters (100% coverage), so the baseline is 3. The description adds only a loose mapping to fields ('text content, selector, XPath, or description') but does not meaningfully enhance parameter understanding beyond the schema.

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

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

The description clearly states a search action on issues and lists some searchable fields (text content, selector, XPath, description). However, it does not differentiate from the sibling tool filter_issues, and 'text content' is somewhat ambiguous, so it is not a perfect 5.

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?

No guidance is provided on when to use this tool versus filter_issues or other sibling tools. It also fails to mention that the 'results' parameter must be an existing audit result, which is a key prerequisite.

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?

With no annotations, the description must carry the transparency burden. It discloses a side effect: 'Stores audit results for historical comparison', indicating a write/persistence behavior. However, it does not clarify whether the tool triggers new audits or only reads existing data, nor does it mention authentication, rate limits, or data retention. This is partial disclosure but leaves key behavioral questions unanswered.

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 concise sentences that front-load the primary action ('Track accessibility metrics over time') and add value with supporting details ('trend analysis, predictions, recommendations; stores audit results'). 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.

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

The tool has 3 parameters, no output schema, and no annotations. The description explains the core purpose and mentions outputs like 'trend analysis, predictions, and recommendations', but it does not describe the return format, how trends are presented, or what 'recommendations' entail. This leaves some gaps for an agent that needs to invoke the tool and interpret results, but it is adequate for understanding the basic operation.

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 the baseline is 3. The description adds no parameter-specific context beyond what the schema already provides; it does not mention url, metric, or timeframe. Thus it meets the baseline but does not enhance understanding of parameter semantics.

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

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

The description clearly states the tool's function: 'Track accessibility metrics over time' with trend analysis, predictions, and recommendations. This distinguishes it from sibling tools like get_accessibility_score (single snapshot) and audit_url (one-time audit), establishing a unique value proposition.

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 tracking metrics over time ('Track accessibility metrics over time') but does not explicitly state when to use this over alternatives or mention exclusions. While the phrase 'with trend analysis, predictions, and recommendations' suggests a historical/comparative use case, it lacks direct guidance on when not to use it compared to siblings like compare_accessibility or generate_summary_report.

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