Accessibility MCP

by ksmuvva

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Tools are largely distinct with clear descriptions, but some overlap exists (e.g., audit_automated_checks vs audit_axe, or audit_url vs audit_current_page). The group and principle audits are well separated.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with underscores (audit_*, browser_*, list_*, etc.). No mix of styles, highly predictable.
Tool Count3/5
41 tools is on the high side but justified by the breadth of accessibility auditing (multiple engines, groups, principles, site crawl, browser session). Could be streamlined but not excessive.
Completeness5/5
The tool surface covers automated checks, manual checks, multiple engines, site crawling, browser interactions, rule listing, and statement generation. No obvious gaps for the intended domain.
Average 3.6/5 across 41 of 41 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral traits. It fails to disclose side effects (e.g., whether the field is cleared before filling, whether events are triggered), error handling (e.g., what happens if the field doesn't exist), or any constraints on the value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but it omits essential details. It is neither front-loaded nor structured; it simply states the bare action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters, no schema descriptions, no annotations, and an output schema that is not described, the description is severely incomplete. It does not explain how to get session_id, what the output means, or how to handle errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning to the parameters. It mentions 'CSS selector' but does not explain session_id role or value format. The schema itself has no descriptions, so the agent gets no parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (fill), the target (form field), and the method (CSS selector). It is easily distinguished from sibling tools like browser_click or browser_navigate. However, it does not specify what types of values are supported (e.g., text, numbers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when to use browser_click for interactive elements. No prerequisites or error conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and only a minimal description, the tool fails to disclose behavioral traits such as side effects (e.g., page navigation, popups), error handling, or requirements for element visibility. The description 'Click an element' assumes the agent understands implications, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous words. While it could benefit from slight elaboration, it efficiently conveys the core action. However, it may be too terse for a tool with no other documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 required parameters, no annotations, and an output schema not referenced in the description, the description omits essential context. It does not explain what the output contains, error conditions, or any prerequisites (e.g., page must be loaded). The description is incomplete for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameters 'session_id' and 'selector' have 0% schema description coverage. The description only clarifies that 'selector' is a CSS selector, but does not specify format, allowed values, or how session_id is used. It adds minimal value over the parameter names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'click' and identifies the resource as 'an element (CSS selector) in a session's page'. This distinguishes it from sibling tools like browser_fill (fills form fields) and browser_navigate. However, it lacks specification of what the click triggers (e.g., navigation, event) and could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that browser_click is for clicking interactive elements while browser_fill is for form fields, or that browser_wait might be needed before clicking. The description offers no context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits but only states the action. It does not mention whether navigation waits for page load, handles errors, or returns anything. Critical details for safe invocation are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks necessary detail. While not verbose, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and available output schema, the description should at least mention that navigation modifies the session's current page and perhaps that the output contains the new page state. It does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no details about parameters. It does not explain what session_id refers to (e.g., from a previous browser_open) or the expected URL format. This leaves the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Navigate' and the resource 'a session's page to a URL', making the tool's purpose unambiguous. It distinguishes from sibling tools like browser_open (which may start a new session) and browser_click (which interacts with page elements).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., browser_open for new sessions or browser_click for links). There is no mention of prerequisites like having an active session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the input requirement and the number of rules (14), but does not disclose whether the operation is read-only, what the output contains (though an output schema exists), or any side effects. The description lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is brief. It front-loads the verb 'Audit'. While concise, it omits necessary details such as the purpose of each parameter and the nature of the output. The conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no schema descriptions, no annotations, an output schema exists), the description is incomplete. It fails to explain the 'level' parameter, how to choose parameter options, or what the audit results look like. The output schema may fill some gaps, but the description should provide enough context for an agent to decide to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning for all parameters. It clarifies that 'url', 'html', and 'session_id' are mutually exclusive alternatives. However, it ignores the fourth parameter 'level' (with default 'AA'), and provides no format or validation details for any parameter. This leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool audits the 'semantics' rule group, which includes 14 axe rules. It indicates the verb 'Audit' and the resource 'semantics rule group'. However, it does not differentiate this from sibling audit_group_* tools, which perform similar audits for other rule groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage requirement: 'Provide one of: url, html, or session_id.' This implies that exactly one of these inputs should be supplied. However, it does not specify when to use this tool over other audit groups or any conditions for exclusion. The guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only states the basic wait action without mentioning what happens when both selector and ms are provided, maximum timeout, error conditions, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely conveys the core purpose. No redundant information, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex input schema with 3 parameters and an output schema, yet the description only covers the basic idea. Missing details on return values, edge cases, and interaction between parameters leave the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should add meaning. It mentions selector and milliseconds but does not explain defaults, mutual exclusivity, or the required session_id parameter. The schema provides defaults but description adds little beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it waits for a selector to appear or for a number of milliseconds, which is a specific verb and resource. It distinguishes from sibling tools like browser_click or audit tools that perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like timeout parameters in browser_navigate or other waiting mechanisms. The description only implies usage without exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It mentions the number of rules (3) but fails to disclose any behavioral traits such as side effects, rate limits, or what happens if no parameter is provided. There is no contradiction with annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it omits critical information about the 'level' parameter. It earns its place but is not as efficient as it could be because it fails to cover all schema parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no annotations, the description should compensate. It lacks details about the output (though an output schema exists), the exact rules audited, and any restrictions. For a tool with 4 parameters and no behavioral hints, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters (url, html, level, session_id) with 0% description coverage. The description only explains url, html, and session_id as alternatives, completely ignoring the 'level' parameter (default AA). This omission leaves its purpose and default behavior unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Audit'), the exact rule group ('sensory-and-visual-cues'), and the number of rules (3 axe rules). It distinguishes this tool from sibling tools like 'audit_group_aria' by naming the specific group, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Provide one of: url, html, or session_id,' which instructs the agent on required input. However, it does not explain when to use this specific group over others, nor does it mention prerequisites or contexts where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'audit' without indicating side effects, permissions, or return behavior. The output schema exists but is not referenced in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and input requirements. It is efficient but could include key behavioral details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description still lacks coverage of parameter semantics (e.g., level) and behavioral context. It is too minimal for a tool with four parameters and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It clarifies 'Provide one of: url, html, or session_id,' implying mutual exclusivity, but the 'level' parameter is unexplained. This partially compensates for missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it audits the 'text-alternatives' rule group (12 axe rules) and specifies input options (url, html, or session_id). This is a specific verb and resource, distinguishing it from sibling tools like audit_group_aria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It mentions the rule group but lacks context on usage scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions that the tool runs 14 axe rules, but does not state whether it is read-only, requires authentication, or has side effects. Minimal additional context is provided beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with no redundant information. Key information about purpose and input requirements is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high number of sibling audit tools, the description should offer more context about what the 'Operable' principle covers (e.g., keyboard, navigable, enough time) and any prerequisites. While an output schema exists, the description lacks completeness for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It partially explains that url, html, and session_id are alternatives, but it does not describe the 'level' parameter or any constraints. Three out of four parameters are lightly covered, but the schema provides no descriptive help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool audits the WCAG 'Operable' principle and runs specifically 14 axe rules mapped to that principle. This verb+resource combination is specific and distinguishes it from sibling tools like 'audit_perceivable' or 'audit_understandable'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only provides input guidance ('Provide one of: url, html, or session_id') but gives no context on when to use this tool over alternatives like 'audit_perceivable' or 'audit_axe'. No explicit when-not or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It fails to disclose what 'audit' entails (e.g., side effects, permissions, output nature). The output schema exists but is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, immediately states purpose and input constraints. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and numerous sibling tools, the description lacks information about return values, prerequisites, or when to use specific input parameters. Incomplete for a tool with 4 parameters and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by indicating that url, html, and session_id are alternative inputs, but it ignores the level parameter entirely. With 0% schema coverage, the description partially compensates but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits the 'aria' rule group and specifies it contains 25 axe rules. This is a specific verb-resource combination that distinguishes it from sibling audit_group_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like audit_group_color or audit_axe. The description only instructs to provide one of url, html, or session_id, but does not explain the context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions 'in-process engine' and 'WCAG 2.2 rule tags', and specifies mutual exclusivity of three parameters. With no annotations, additional details like non-destructive nature, error handling, or speed are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose and constraints. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core purpose and main constraint, but leaves gaps on two parameters and the nature of 'GOV.UK checks'. Output schema exists, so return values are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning for url, html, session_id (mutually exclusive), but level and include_best_practice are unexplained. Schema coverage is 0%, so description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it audits with axe-core engine plus GOV.UK checks, distinguishing it from sibling tools like audit_ibm and audit_lighthouse. However, it does not explicitly say 'use this for axe-based audits'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. 'Audit with the axe-core engine only' implies a specific engine, but no contrast with other audit tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It fails to state that the tool is read-only, does not modify data, or describe any side effects. The term 'audit' is vague without further explanation of the action or outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence with parenthetical detail. It front-loads the action and avoids unnecessary words, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description does not need to explain return values. However, it lacks details about parameter relationships (e.g., mutual exclusivity is implied but not enforced) and does not address the 'level' parameter. Completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by indicating that url, html, and session_id are mutually exclusive inputs. However, it completely ignores the 'level' parameter (default 'AA'), and since schema description coverage is 0%, more explanation was needed for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it audits the 'language' rule group, specifying it includes 4 axe rules. It also explicitly states the required input format (one of url, html, or session_id), which distinguishes it from sibling audit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool vs alternatives. It only states the input requirement but lacks context about use cases or when not to use it, which is important given the many sibling audit group tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions the tool audits 4 axe rules and requires one input, but it does not disclose what the audit entails (e.g., whether it mutates anything, requires authentication, or has rate limits). The output schema exists but is not described, leaving uncertainty about results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff. It front-loads the purpose and follows with input requirements. It could be slightly more structured (e.g., bullet points for inputs) but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 0% schema coverage, and no annotations, the description is insufficiently complete. It mentions only 3 of 4 parameters and does not explain the output or process of the audit. The presence of an output schema helps but is not referenced. The tool has many siblings, yet no differentiation criteria are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by stating that one of 'url', 'html', or 'session_id' should be provided, implying mutual exclusivity. However, it omits the 'level' parameter entirely, which has a default of 'AA' but is not explained. With 0% schema coverage, the description partially compensates but leaves a gap for 'level'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits the 'parsing' rule group with 4 axe rules. It distinguishes from sibling tools like audit_group_aria by specifying the group name. The verb 'Audit' and resource 'parsing rule group' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells users to 'Provide one of: url, html, or session_id,' which gives input guidance. However, it does not explain when to use this tool versus other audit_group_* tools (e.g., if you need color or keyboard audits). Usage is implied but not explicit about exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that the tool 'audits' the rule group, but does not mention if it is read-only, what side effects occur, or how results are reported. The description lacks transparency about error handling, concurrency, or resource usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences covering purpose and input requirements. No superfluous text, and the information is front-loaded. However, it could be slightly restructured to list parameters more explicitly. Overall, it is efficient but minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no required, with output schema) and the presence of many sibling tools, the description is too sparse. It fails to explain what the audit produces, how to interpret results, or what happens if multiple inputs are provided. While the output schema exists, the description should still contextualize the tool's purpose within the broader suite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters (url, html, level, session_id) with no descriptions (0% coverage). The description adds context that these are exclusive options ('Provide one of: url, html, or session_id'), but does not explain the 'level' parameter (default 'AA') or clarify the format of 'html' content. The added value is moderate, partially compensating for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits the 'time-and-media' rule group, specifically noting it covers 5 axe rules and requires one of three inputs (url, html, session_id). This clearly distinguishes it from sibling tools that focus on other rule groups (e.g., audit_group_aria, audit_group_forms).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the user must provide one of url, html, or session_id, which gives some usage guidance. However, it does not explain when to use this tool versus other group-specific tools, nor does it mention any prerequisites or exclusions. The sibling list shows many overlapping audit tools, so explicit guidance would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It does not specify precedence among url/html/session_id, error handling for invalid rule_id, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and includes parameter explanations without unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description lacks detail on return values and fails to resolve the parameter requirement contradiction, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contradicts the schema: it states 'one of url, html, or session_id required' but schema only marks rule_id as required. This misleads the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check a specific axe-core rule by ID' and explains it replaces many individual tools, distinguishing it from sibling audit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use this tool (for a specific rule) and suggests calling list_axe_rules to see available IDs, but does not explicitly exclude using it for full audits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the tool audits a rule group but does not mention side effects, authentication needs, rate limits, or whether it is read-only. The lack of such information reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose and immediately follows with the key input requirements. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 parameters and an output schema, the description omits details about the level parameter, expected return values, and any prerequisites. For a tool with many siblings and no annotations, this brevity leaves the agent underinformed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the url, html, and session_id parameters by indicating they are mutually exclusive input sources. However, it does not explain the 'level' parameter (which has a default of AA) or provide constraints like format or length. With 0% schema coverage, more detail was needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits the 'keyboard' rule group and specifies it covers 9 axe rules. It also lists the required input parameters (url, html, or session_id), 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says to provide one of url, html, or session_id, which gives basic usage guidance. However, it does not explain when to use this tool versus other sibling audit group tools (e.g., audit_group_aria, audit_group_color), nor does it mention any scenarios where this tool is preferred or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'audit,' implying a read operation but not explicitly stating safety, side effects, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the key action and group name, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are not needed. However, the description omits the 'level' parameter and provides no detail on the 'structure' rule group, leaving gaps for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that three parameters (url, html, session_id) are mutually exclusive, adding meaning beyond the schema. However, the 'level' parameter is ignored, and schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it audits the 'structure' rule group, a specific set of 8 axe rules. This distinguishes it from similarly named sibling tools (e.g., audit_group_aria) by naming the group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs to provide one of url, html, or session_id, but does not compare to sibling tools or indicate when to use this versus other audit groups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes return data but does not disclose read-only nature, authentication, rate limits, or side effects. Only mentions informational nature of version parameter. Lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two concise paragraphs: first explains purpose and return fields, second lists arguments. Every sentence adds value. No redundant or vague language. Efficiently front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity, optional parameters, and presence of output schema, description covers essential aspects. It mentions defaults and informational parameter. Could explicitly state that both parameters are optional, but schema already indicates no required params. Overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It explains version is informational and level is highest conformance to include, with defaults. This adds value over the schema's titles and defaults, but does not elaborate on allowed values or constraints beyond what is implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists WCAG success criteria with automation coverage, and specifies return fields. It distinguishes from sibling tools that list other types of checks (e.g., list_automated_checks, list_axe_rules) by focusing on WCAG criteria. Could be more explicit about when to use this vs other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: to see WCAG rules with coverage. Provides filtering by version and level but does not explain when to use this tool instead of siblings like list_manual_checks or list_automated_checks. No guidance on context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions it uses axe rules and the number of rules, but does not disclose side effects (e.g., read-only), permissions needed, rate limits, or response format beyond what the output schema may cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that directly state purpose and input requirements. No redundant information. Every word contributes, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and many siblings, the description covers the essential purpose and input strategy but misses guidance on the 'level' parameter and does not help distinguish this group from other audit_group_* tools. Output schema existence reduces burden for return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It states 'Provide one of: url, html, or session_id', which adds the important constraint that exactly one of these three should be provided. However, it does not explain the 'level' parameter or provide details on parameter formats, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Audit the 'color' rule group (3 axe rules)' which specifies the exact verb (audit), resource (color rule group), and scope (3 axe rules). It differentiates from sibling audit_group_* tools by naming the specific group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for color-related accessibility audits but does not explicitly state when to use this tool versus other audit_group_* tools or when not to use it. The instruction 'Provide one of: url, html, or session_id' gives invocation guidance but lacks comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 disclosing behavioral traits. It does not mention whether the tool is read-only, destructive, or any side effects, rate limits, or error conditions. The description only states the basic action without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no redundant words, and the key information is front-loaded. Every sentence adds value without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the many sibling audit_group tools, the description could be more complete by explaining when to audit the 'forms' group versus others, or by listing the specific rules. It mentions '5 axe rules' which is helpful, but overall lacks comparative context. The presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning for 3 of 4 parameters by stating they are alternative inputs ('Provide one of: url, html, or session_id'). However, it does not describe the 'level' parameter or the semantics of each individual parameter (e.g., what 'html' expects). The description partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (audit), the resource ('forms' rule group), and the scope (5 axe rules). It distinguishes from sibling tools by specifying the group name, making it easy for the agent to select when dealing with form-related accessibility rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the inputs needed ('Provide one of: url, html, or session_id'), giving clear usage guidance. However, it lacks explicit when-to-use or when-not-to-use context compared to sibling audit_group tools, and does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states a read-like action but does not mention side effects, access requirements, or output format. The minimal description leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every word serves the purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and an output schema, the description is minimal but adequate. It covers the core functionality, but could benefit from mentioning the output structure or use case to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since there are zero parameters and 100% schema coverage, the baseline is 4. The description adds meaning by specifying that it lists 'available audit engines and whether the Node engines are installed', which is informative beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'available audit engines', and uniquely distinguishes from sibling tools like 'list_automated_checks' and 'list_axe_rules' by specifying engines rather than checks or rules. The additional detail about Node engine installation status adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool compared to siblings such as 'list_automated_checks' or 'list_axe_rules'. The agent must infer its purpose from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the tool audits 7 axe rules and requires one of three inputs, but does not disclose whether the tool is read-only, requires specific permissions, or has any side effects. This is adequate but not thorough for a black-box tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with two sentences that front-load the action and then specify input requirements. No wasted words, though a slight expansion on the level parameter would not harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 params, many siblings, output schema exists), the description provides the core purpose and input constraint. It lacks mention of the output format (though output schema is present) and does not differentiate from siblings enough. Adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that url, html, and session_id are mutually exclusive options, adding value. However, it omits the 'level' parameter, leaving its purpose undocumented. Partial compensation for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it audits the 'name-role-value' rule group, which is a specific set of 7 axe rules. This verb+resource combination distinguishes it from sibling tools like audit_group_aria or audit_group_color.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that one of url, html, or session_id must be provided, giving a clear usage condition. However, it does not guide when to use this tool instead of other audit_group_* siblings, which would be helpful given the large number of similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it audits axe rules for tables and requires one of three inputs. No annotations are present, so the description bears the full burden, but it lacks details on behavior (e.g., output shape, side effects, error conditions). The presence of an output schema mitigates this slightly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose and input requirements with no wasted words. It could be structured slightly better but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters, a large sibling set, and an output schema, the description is incomplete. It does not explain the 'level' parameter, how to choose among url/html/session_id, or how this tool differs from other group audits beyond the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning the schema itself provides no semantic context. The description only mentions three of four parameters (url, html, session_id) and does not explain the 'level' parameter. This is insufficient for a tool with 4 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it audits the 'tables' rule group, which distinguishes it from sibling audit tools for other groups. The verb 'Audit' and resource 'tables rule group (6 axe rules)' is specific and informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Provide one of: url, html, or session_id', which gives clear context on input requirements. However, it does not explicitly state when to use this tool versus other group audits, though the group name implies the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It states the engine and input options but does not describe what happens during the audit (e.g., whether it is read-only, if it modifies state, or what the triggering behavior is). The return format is covered by the output schema, but internal behavior is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and includes key constraints. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema coverage and no annotations, the description covers the input requirements and a prerequisite. It misses explaining the 'level' parameter and does not provide usage examples, but the output schema is present, reducing the need for return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds that url, html, and session_id are mutually exclusive and one is required, which is not apparent from the schema (all optional). However, it does not explain the 'level' parameter or defaults. This adds meaningful context but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits with the pa11y engine, specifying it uses HTML_CodeSniffer and axe runners. This distinguishes it from sibling tools like audit_axe (which likely uses axe only) and audit_lighthouse (Lighthouse engine).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the user that one of url, html, or session_id must be provided, but does not explicitly compare with similar audit tools (e.g., audit_axe, audit_ibm) to guide selection between engines. Usage context is 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as read-only nature, authentication requirements, or output format. It only mentions the number of rules run.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no repetition or extraneous information. It front-loads purpose and provides input guidance efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, an output schema, and no annotations, the description is incomplete. It omits the 'level' parameter and does not reference the output schema, but covers core purpose and input sources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions three of four parameters (url, html, session_id) but omits 'level', and does not explain parameter semantics like mutual exclusivity or valid values. Schema coverage is 0%, so description must compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it audits the WCAG 'Robust' principle using 31 axe rules, distinguishing it from sibling tools for other principles like 'audit_operable' and 'audit_perceivable'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies input options (url, html, session_id) but does not explicitly state when to use this tool versus alternatives, nor 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.
Behavior3/5
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 that interaction state is preserved and different engines use different DOM states. However, it does not mention rate limits, auth needs, or output behavior beyond the implied audit results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with an overview followed by parameter details. No unnecessary words, though a slight reduction in technical detail could improve brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, output schema exists), the description covers the input behavior adequately but omits information about output format, error handling, or limitations. The output schema likely fills some gaps, but the description could still mention typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter's meaning, defaults, and acceptable values (e.g., WCAG levels, engines list, include_best_practice). It clarifies session_id origin, which adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it audits the current page state, specifying multiple engines and interaction preservation. However, it does not explicitly differentiate from sibling tools like audit_axe or audit_automated_checks, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (post-interaction) and explains how different engines work (live vs snapshot). It does not explicitly state when not to use or suggest alternatives, but the guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals that Lighthouse audits by URL and reloads the page, and that it requires the Node engine runner. This is valuable behavioral context beyond simple CRUD.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the purpose and key usage details. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of auditing tools and the presence of an output schema, the description is adequate but not thorough. It fails to explain the return format or how the 'level' parameter affects results, assuming the agent will rely on the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that url, html, and session_id are mutually exclusive inputs, but does not mention the 'level' parameter or its default 'AA'. This adds partial value beyond the schema's basic type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it audits with Google Lighthouse for accessibility. It specifies the engine and mentions input options (url, html, session_id), distinguishing it from siblings like audit_axe or audit_pa11y by specifying 'Lighthouse engine only'. However, it doesn't elaborate on what Lighthouse checks beyond accessibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance: 'Provide one of: url, html, or session_id' and 'Requires the Node engine runner.' But it does not explicitly state when to use this tool over alternative audit tools (e.g., when to choose Lighthouse over axe or pa11y), leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It notes that the tool runs 6 axe rules and requires one input source. However, it does not mention whether the tool is read-only, authentication needs, error handling, or any side effects. The output schema exists but is not referenced. The description provides basic behavior but lacks thoroughness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first explains the tool's purpose, and the second gives input instructions. Each sentence adds value without redundancy. This is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values need not be detailed. However, the description omits the 'level' parameter, which is important for WCAG conformance levels. It also doesn't list the specific WCAG criteria covered. For a tool with 4 parameters and 0% schema coverage, the description should be more complete to avoid confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It correctly indicates that url, html, and session_id are mutually exclusive inputs. However, it does not explain the 'level' parameter (default AA) or its possible values (A, AA, AAA). Thus, it adds partial meaning but misses an important parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool audits the WCAG 'Understandable' principle by running 6 specific axe rules. This distinguishes it from sibling tools like audit_perceivable and audit_operable, which cover other principles. The verb 'audit' combined with the specific principle and rule count conveys purpose precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs the user to provide one of url, html, or session_id, which gives parameter usage guidance. However, it does not explicitly state when to choose this tool over alternatives like audit_perceivable or audit_operable. The context is implied by the tool name, but no when-not 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions closing and freeing resources, which implies destructiveness, but omits details like whether the session ID must be valid, what happens to associated data, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 8-word sentence, front-loaded with the verb 'Close'. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown) and one required parameter, so the description is minimally sufficient. However, for a stateful session close operation, it would benefit from mentioning invalid sessions or resource release guarantees.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool description adds no meaning to the session_id parameter beyond its name. The parameter's purpose is obvious, but the description could clarify its format or origin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Close a stateful browser session and free its resources'), using a specific verb and resource. It distinguishes from sibling tools like browser_open and browser_navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used after finishing with a browser session, but it provides no explicit guidance on when to use it versus alternatives, nor any prerequisites or post-conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it runs 29 axe rules, which gives some insight into behavior, but it does not disclose whether the tool is read-only, requires authentication, or has side effects. Since no annotations are provided, the description carries the full burden but falls short of comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the core purpose and then specify input requirements. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description adequately covers purpose and input. However, it omits details about the 'level' parameter and how session_id differs from url/html (e.g., using an existing session). Still, it is largely complete for a straightforward audit tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by stating that only one of url, html, or session_id should be provided, which is not indicated in the schema. However, it does not mention the 'level' parameter, and schema coverage is 0%, so the description only partially compensates for missing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits the WCAG 'Perceivable' principle by running 29 specific axe rules, which differentiates it from sibling tools like audit_operable. It also specifies the required input format (url, html, or session_id), 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for auditing the 'Perceivable' principle and requires one of three inputs, but it does not explicitly state when to use it versus alternatives or when not to use it. The sibling tool names provide some contextual clues, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It explicitly states the tool returns three pieces of information (url, title, visible text) and implies a read-only operation. It does not mention side effects or permissions, which is acceptable for a simple snapshot tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the essential information (return url, title, visible text). Every word adds value, and there is no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (explaining return values) and the tool's functionality is straightforward, the description adequately covers what the tool does. It is complete for a simple data retrieval operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not elaborate on the 'session_id' parameter. It does not explain how to obtain a session ID or what a session represents, leaving the parameter's meaning completely reliant on the schema's minimal label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the current URL, title, and visible text of a session's page. It specifies the exact resources (url, title, visible text) and the action (return), distinguishing it from sibling tools like browser_click or audit tools that perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like browser_navigate or audit tools. It does not mention prerequisites, context, or situations where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It explains the rendering process (headless Chromium, no network fetch) and the auditing by chosen engines. However, it does not explicitly state that the tool is read-only/non-destructive, nor does it mention failure modes or limitations for invalid HTML.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary, a brief technical explanation, and a bulleted Args list. Every sentence adds value with no redundancy, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no annotations, present output schema), the description covers the core functionality, parameter details, and common use case (CI). It omits the output format, but the output schema likely covers that. Overall sufficient for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by listing all parameters with types, defaults, and allowed values. It adds context for 'steps' by referencing audit_url, and clarifies engine defaults and subset. This adds meaning beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb ('Audit') and resource ('raw HTML string or component snippet'), immediately distinguishing it from sibling tools like audit_url or audit_current_page. It further clarifies the scope by mentioning WCAG 2.2 and headless Chromium rendering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is 'Useful for testing templates/components in CI', giving a usage context, but does not explicitly compare to alternative tools or specify when not to use it. Lacks exclusion criteria or guidance on choosing between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes that each rule is exposed as its own tool, hinting at the return content, but does not explicitly state that this is a read-only operation or describe side effects. No annotations are provided to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states purpose, second explains the parameter. No redundancy, and it is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and parameter, and since an output schema exists, the lack of return value details is acceptable. It could mention that this is a list operation, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the wcag_only parameter beyond the schema by explaining it filters rules tagged with WCAG conformance levels. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists axe-core rules and distinguishes itself from siblings like list_wcag_rules by specifying 'axe-core rules'. The verb 'List' and resource are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool can be used to discover available rules before invoking individual rule tools, but it does not explicitly state when to use this tool vs alternatives like list_wcag_rules or list_automated_checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the output (list of criteria with axe rules) and mentions a per-criterion tool. It does not discuss side effects, auth, or pagination, but for a read-only listing, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and quickly gets to the args. Two paragraphs, no wasted words. Could be slightly more structured, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter with default and an existing output schema, the description is complete enough. It explains what the tool returns and how it relates to sibling tools, without needing to detail output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the level parameter: 'Highest conformance level to include: "A" or "AA" (default).' This adds meaning beyond the schema, which only defines type string and default. Schema coverage is 0%, but the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the WCAG criteria that CAN be automated, with the axe rules behind each,' specifying the verb (list), resource (WCAG criteria), and scope (automated). It implicitly distinguishes from siblings like list_manual_checks and list_wcag_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's purpose and links it to automated-check tools (check_wcag_<n>, audit_automated_checks), telling when to use it. It does not explicitly state when not to use it or provide direct alternatives, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses requirement for Node engine runner and network egress, and that failure returns a structured engine-error. No annotations exist, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a note, no filler. Purpose is front-loaded, each sentence adds distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and an output schema, the description covers mutual exclusivity, prerequisites, and error conditions. The output schema handles return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies that url, html, and session_id are mutually exclusive options, adding meaning beyond the schema. However, the 'level' parameter is not explained, and schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Audit with the IBM Equal Access engine only' – a specific verb and resource that distinguishes it from sibling tools like audit_axe or audit_lighthouse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Provide one of: url, html, or session_id' and mentions requirements and error behavior. Could be improved by explicitly stating when not to use this tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool lists grouped tools and associated axe rules, and mentions the two grouping schemes. This is sufficient for a read-only listing tool; no side effects or preconditions need elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and followed by necessary detail on grouping schemes. No redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple list with an output schema, the description adequately explains what is returned and the grouping structure. It could be slightly more explicit about the output format, but it's complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100%. Per guidelines, baseline is 4 when no parameters exist; the description adds no additional param info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists grouped audit tools and which axe rules each runs, specifying two grouping schemes (WCAG principle and axe category). This distinguishes it from sibling tools like list_axe_rules (which lists all rules) and audit_group_* (which run audits for specific groups).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it over alternatives or provide exclusions. The grouping schemes implicitly suggest use for overview, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It mentions high-confidence pass/fail but does not disclose whether the operation is read-only, required permissions, or rate limits. The absence of such details leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus an explicit instruction. It front-loads the main purpose and every sentence adds unique value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool has a simple interface (4 parameters), the description adequately covers the tool's function and usage. It also directs to list_manual_checks for non-automated criteria, making the context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description compensates by explaining that url, html, and session_id are mutually exclusive inputs and that level controls the WCAG conformance level. This adds meaning beyond the basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it runs ALL automated WCAG checks at once, using axe rules for every WCAG 2.2 criterion up to a specified level. It distinguishes itself from siblings by covering the entire machine-testable surface and refers to list_manual_checks for non-automatable criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly instructs the agent to provide one of url, html, or session_id. It also indicates when to use list_manual_checks for non-automated criteria. However, it does not explicitly mention when not to use this tool (e.g., for specific criteria).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions that the session is 'stateful' and returns a session_id, but does not disclose details like whether it launches a real or headless browser, session limits, or resource implications. Additional behavioral context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences. The first sentence states the primary purpose. The second sentence provides usage patterns and context. There is no extraneous information, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (as indicated by context signals), the description adequately covers the tool's purpose, return value (session_id), and usage context. It is complete for an init tool that requires no additional configuration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% by default. The description does not need to add parameter semantics, as there are none. Baseline for no parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a new stateful browser session and returns a session_id. It distinguishes itself from sibling tools like browser_navigate and browser_click, which require an existing session. The verb 'Open' and resource 'browser session' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: before using browser_navigate, browser_click, etc., and for auditing pages behind logins or multi-step journeys. It lists the sequence of tools that follow. However, it does not explicitly state when not to use it or what to do if a session already exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the tool generates a statement using an existing audit or by performing a new audit. It lacks details on side effects or permissions, but the core behavior is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a brief purpose statement, a usage hint, and a parameter list. It is concise but could be marginally tighter. The front-loaded purpose is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the description's coverage of inputs and behavior, it is largely complete. It lacks details on error handling or edge cases, but these are acceptable gaps for a straightforward generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by listing all 7 parameters with clear, concise explanations in the Args section, adding meaning beyond the bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Draft a GOV.UK-format accessibility statement from an audit.' It specifies the action (draft), the resource (accessibility statement), and the format (GOV.UK-format), distinguishing it from audit-focused siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on usage: 'Provide either audit_id (from a previous audit tool call) or url (to audit now).' This explains the two modes of operation but does not explicitly compare to alternatives or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 that the tool loads the URL in headless Chromium, runs engines and GOV.UK-specific checks, and returns structured JSON, Markdown report, and compliance summary. It does not mention rate limits or auth needs but is sufficiently transparent for the intended use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence followed by an Args section. It is slightly verbose but remains focused and informative. The inclusion of parameter details is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 1 required, with optional steps and engines) and the existence of an output schema, the description thoroughly explains the tool's functionality, inputs, outputs, and behavior, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the tool description's Args section adds detailed meaning for each parameter, including defaults, allowable values (e.g., WCAG levels), and the structure for 'steps'. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool audits a single live web page for WCAG 2.2 accessibility with GOV.UK standard, clearly differentiating it from sibling tools like 'audit_site' (which likely audits multiple pages) and other specific audit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool loads the URL, optionally performs interaction steps, runs chosen engines, and returns structured output. While it gives clear context, it does not explicitly state when not to use this tool or mention alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes that the tool lists criteria that have no axe-core coverage, requiring manual assessment. It also includes examples. It does not mention side effects or permissions, but for a read-only listing tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: clear main sentence, followed by rationale in a brief paragraph, then an Args section. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema, the description explains its purpose and parameter sufficiently. It provides examples of criteria and the context of compliance scoping. The presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides type and default for 'level'. The description adds meaning by explaining it's the highest conformance level to include and specifies possible values ('A' or 'AA'). This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists WCAG criteria that cannot be automated, needing human review. It uses specific verbs and resource (list + manual checks) and distinguishes from sibling list_automated_checks and other audit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool: for criteria without automated coverage, contrasting with automated tools. It implies usage context but does not explicitly state when not to use it. However, the context is clear from the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description details crawl algorithm, output, and parameter limits. Could note time/resource usage but still strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient: one sentence for purpose, one for method/output, then bullet-free Args list. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, algorithm, output summary, all parameters. Output schema exists so return details are sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description fully explains all 6 parameters, including defaults, constraints, and valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it crawls and audits a site for WCAG 2.2, distinguishing it from single-page or specific-engine tools like audit_url or audit_axe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly implies use for site-wide audits, with constraints like same-origin and server caps, but does not explicitly exclude single-page tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Accessibility MCP MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![Accessibility MCP MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/ksmuvva/MCp-accessibility-Muvva/badges/card.svg)](https://glama.ai/mcp/servers/ksmuvva/MCp-accessibility-Muvva)

Score Badge

Copy to your README.md:

[![Accessibility MCP MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/ksmuvva/MCp-accessibility-Muvva/badges/score.svg)](https://glama.ai/mcp/servers/ksmuvva/MCp-accessibility-Muvva)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![Accessibility MCP MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fksmuvva%2FMCp-accessibility-Muvva%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/ksmuvva/MCp-accessibility-Muvva)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ksmuvva/MCp-accessibility-Muvva'

If you have feedback or need assistance with the MCP directory API, please join our Discord server