WCAG MCP Server

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation4/5
Most tools have distinct purposes targeting different WCAG entities (criteria, techniques, glossary terms, guidelines), but some overlap exists: get-criteria-by-level and list-success-criteria both retrieve criteria with filtering, and get-criterion/get-success-criteria-detail/get-full-criterion-context all provide criterion details with varying depth. Descriptions help differentiate these, but an agent might initially confuse them.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, using kebab-case uniformly. Verbs like get, list, search, and count are applied predictably to nouns like criteria, techniques, glossary-terms, and guidelines, making the set easy to navigate and understand.
Tool Count4/5
With 20 tools, the count is slightly high but reasonable for the comprehensive WCAG domain, covering principles, guidelines, criteria, techniques, and glossary terms. It feels thorough rather than bloated, though some consolidation (e.g., merging criterion detail tools) could streamline it without losing functionality.
Completeness5/5
The toolset provides complete coverage for exploring WCAG 2.2, including listing, retrieving details, and searching across all key components (principles, guidelines, success criteria, techniques, glossary). It supports filtering, contextual information, and even highlights updates in WCAG 2.2, leaving no obvious gaps for an agent working in this domain.
Average 3.3/5 across 20 of 20 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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 passing
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

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 states the tool 'gets' data, implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns paginated results, or what the output format looks like. This leaves significant gaps for a tool that likely queries a database or API.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It is appropriately sized for a simple lookup tool and front-loads the key information without unnecessary elaboration.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of failure descriptions, error codes, or structured data), how failures are defined, or any behavioral traits like error handling. For a tool with one parameter but no structured output documentation, more context is needed.
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 100% description coverage, clearly documenting the single required parameter 'ref_id'. The description adds no additional parameter semantics beyond what the schema provides, such as examples of valid reference numbers beyond '1.1.1' and '2.4.7', or how failures are structured. This meets the baseline for high schema coverage.
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 'gets' and the resource 'failure techniques (common mistakes)' for a specific success criterion. It distinguishes the tool's focus on failures from other tools that might retrieve criteria or techniques more broadly, though it doesn't explicitly differentiate from siblings like 'get-techniques-for-criterion' which might return all techniques rather than just failures.
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. It doesn't mention when-not scenarios, prerequisites, or compare it to sibling tools like 'get-techniques-for-criterion' or 'get-criterion', leaving the agent to infer usage from the name and description alone.
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 states it 'Gets' data (implying a read-only operation) but doesn't cover critical aspects like whether it requires authentication, rate limits, error handling, or the format/structure of the returned context. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Gets comprehensive context for a success criterion') and specifies included content. There is no wasted verbiage, repetition, or unnecessary detail, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (retrieving multiple data types), lack of annotations, and absence of an output schema, the description is incomplete. It doesn't explain what 'comprehensive context' entails structurally, how techniques/rules/terms are returned, or any behavioral constraints. For a context-rich tool with no structured support, more detail is needed to be fully helpful.
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 100% description coverage, fully documenting the single parameter 'ref_id'. The description adds no additional parameter semantics beyond what the schema provides (e.g., it doesn't clarify format examples beyond 'e.g., "1.1.1"' or explain how 'comprehensive context' relates to the input). Baseline 3 is appropriate since the schema does the heavy lifting.
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 tool's purpose with a specific verb ('Gets') and resource ('comprehensive context for a success criterion'), including what content it retrieves (techniques, test rules, glossary terms). It distinguishes from simpler sibling tools like 'get-criterion' by emphasizing comprehensiveness, though it doesn't explicitly contrast with all similar siblings like 'get-success-criteria-detail'.
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. It doesn't mention prerequisites, when it's preferred over simpler tools like 'get-criterion' or more specialized ones like 'get-techniques-for-criterion', or any exclusions. Usage is implied by the name and purpose but not explicitly stated.
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 responsibility for behavioral disclosure. It only states the basic function without mentioning whether this is a read-only operation, what format results return, if there are rate limits, or how search matching works. For a search tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core function without any wasted words. It's appropriately sized for a simple search tool and gets straight to the point.
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?
For a search tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the search returns (terms, definitions, partial matches), how results are formatted, or any behavioral characteristics. The agent needs more information to use this tool effectively.
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 schema has 100% description coverage, with the single parameter 'query' documented as 'Search query'. The description adds no additional parameter information beyond what the schema already provides, so it meets the baseline for high schema coverage without adding 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 the action ('Searches') and resource ('WCAG glossary'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'search-techniques' or 'search-wcag' that also perform search operations, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-glossary-term' or 'list-glossary-terms'. There's no mention of prerequisites, limitations, or comparative advantages, leaving the agent with insufficient context for optimal tool selection.
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 burden. It states the search scope ('by keyword in titles') but doesn't disclose behavioral traits like case sensitivity, partial/full matching, pagination, sorting, error handling, or what happens with no results. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple search tool and front-loads the core purpose without unnecessary elaboration.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain return values (e.g., list of technique objects with fields), behavioral details, or usage context relative to siblings. For a search tool in a server with many related tools, more guidance is needed to ensure correct agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'query' documented as 'Search query'. The description adds that it searches 'by keyword in titles', which clarifies the target field but doesn't provide additional syntax, format, or constraint details beyond what the schema implies. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('searches') and resource ('techniques'), specifying the search scope ('by keyword in titles'). It distinguishes from some siblings like 'get-technique' (single retrieval) and 'list-techniques' (unfiltered listing), but doesn't explicitly differentiate from 'search-glossary' or 'search-wcag' which have similar search patterns for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It doesn't mention when to prefer this over 'list-techniques' (for unfiltered listing) or 'get-techniques-for-criterion' (for criterion-specific techniques), nor does it specify any prerequisites or exclusions for usage.
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 burden. It states the tool returns counts but doesn't disclose behavioral traits like whether it's read-only (implied by 'returns'), performance characteristics, error handling, or output format. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality ('returns counts of success criteria') and specifies the grouping method. Every word earns its place with no redundancy or unnecessary detail, making it easy to scan and understand quickly.
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 low complexity (1 parameter, 100% schema coverage) and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on output format, error cases, or usage context. Without annotations, it should do more to compensate, but the simplicity of the tool keeps it from being severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'group_by' fully documented in the schema (including enum values). The description adds minimal value beyond the schema by mentioning the grouping options, but doesn't provide additional context like default behavior or examples. Baseline 3 is appropriate as the schema does the heavy lifting.
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 tool's purpose with a specific verb ('returns') and resource ('counts of success criteria'), and specifies the grouping dimension ('by level, principle, or guideline'). However, it doesn't explicitly differentiate from sibling tools like 'list-success-criteria' or 'get-success-criteria-detail', which might provide similar data in different formats.
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. It doesn't mention prerequisites, context, or compare it to sibling tools like 'list-success-criteria' (which might list rather than count) or 'get-success-criteria-detail' (which might provide detailed info). Without this, users must infer usage from the name and description alone.
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 only states the basic function without mentioning error handling (e.g., what happens if term doesn't exist), response format, or any constraints like rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple lookup tool and gets straight to the point.
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 read operation with one well-documented parameter and no output schema, the description is minimally adequate. However, it lacks information about return values or error conditions that would be helpful given the absence of output schema and 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 schema description coverage is 100%, so the parameter 'term' is already well-documented in the schema. The description doesn't add any additional semantic information beyond what's in the schema, meeting the baseline expectation for high schema coverage.
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 action ('Gets') and resource ('definition of a WCAG glossary term'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list-glossary-terms' or 'search-glossary', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list-glossary-terms' or 'search-glossary'. It simply states what the tool does without any context about appropriate use cases 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 full burden but only states it returns information without detailing behavioral traits. It doesn't specify if this is a read-only operation, potential rate limits, authentication needs, or what type of information is included (e.g., version, capabilities, status), leaving 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It could be slightly more front-loaded with key details like 'metadata' or 'configuration', but it's appropriately sized and clear.
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 has 0 parameters, no annotations, and no output schema, the description is minimally adequate but incomplete. It doesn't explain what information is returned (e.g., server version, data source details) or potential use cases, which would help the agent understand the output despite the lack of structured fields.
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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no parameters are required, earning a high baseline score for this context.
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 ('Returns') and resource ('information about this WCAG MCP server and data source'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'whats-new-in-wcag22' which might also return server-related information, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention use cases like server configuration checks, data source metadata retrieval, or comparisons to other tools, leaving the agent without contextual direction.
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 burden. It states it 'Gets details' which implies a read-only operation, but doesn't disclose behavioral traits like error handling (e.g., what happens if ID is invalid), response format, or any rate limits. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the core purpose and includes helpful examples. Every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameter usage, but lacks details on output (what 'details' include) and behavioral context. For a simple lookup tool, it's passable but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'id' fully documented in the schema. The description adds examples ('H37', 'ARIA1', etc.) which provide context, but doesn't add meaning beyond what the schema already states. Baseline is 3 since the schema does the heavy lifting.
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 action ('Gets details') and resource ('specific technique by ID'), with examples provided. It distinguishes from siblings like 'list-techniques' (which lists all) and 'search-techniques' (which searches), but doesn't explicitly contrast them. The purpose is 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 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 'list-techniques' or 'search-techniques' is provided. The description implies usage when you have a specific technique ID, but doesn't state this explicitly or mention prerequisites. It lacks context about 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' data, implying a read-only operation, but doesn't describe the return format (e.g., structure, pagination), error handling, or any constraints like rate limits or authentication needs. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every part contributing essential information about what the tool does.
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 moderate complexity (single parameter, read operation) and no output schema, the description is minimally adequate but incomplete. It specifies what the tool retrieves but lacks details on return values, error cases, or behavioral traits, which are important for a tool with no annotations. The high schema coverage helps, but more context is needed 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 schema description coverage is 100%, with the single parameter 'ref_id' fully documented in the schema as a success criterion reference number with examples. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
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 tool's purpose with a specific verb ('gets') and resource ('all techniques for a specific success criterion'), including the types of techniques (sufficient, advisory, and failures). It distinguishes from some siblings like 'get-technique' (singular) and 'list-techniques' (general list), but doesn't explicitly differentiate from 'get-failures-for-criterion' which focuses only on failures.
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. It doesn't mention when to choose this over 'get-failures-for-criterion' (which gets only failures) or 'get-success-criteria-detail' (which might include techniques), nor does it specify prerequisites or context for use.
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 behavioral disclosure. It states the action ('Lists') but doesn't describe any behavioral traits, such as whether it returns all terms at once, supports pagination, or has rate limits. This leaves gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate as a basic listing tool. However, it lacks context about output format (e.g., structure of returned terms) and doesn't leverage the absence of annotations to clarify behavioral aspects, leaving room for improvement in completeness.
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 0 parameters, and the schema description coverage is 100% (though empty). The description doesn't need to add parameter details, but it could mention if there are implicit filters or options (e.g., sorting). Since no parameters exist, a baseline of 4 is appropriate, as there's nothing to compensate for.
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 ('Lists') and resource ('all WCAG glossary terms'), making the purpose unambiguous. However, it doesn't differentiate from its sibling 'search-glossary' or 'get-glossary-term', which could help the agent choose between listing all terms versus searching or fetching a specific term.
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 'search-glossary' or 'get-glossary-term'. It lacks context about use cases, such as when a full list is needed versus filtered results, leaving the agent to infer usage from tool names alone.
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. It states the tool lists success criteria, implying a read-only operation, but doesn't disclose behavioral traits like pagination, rate limits, response format, or whether it returns a subset or full details. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavior, output, or usage context. For a read-only list tool, this is acceptable but leaves gaps in understanding how to interpret results.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it could have mentioned if any implicit parameters (like filters) are applied. Baseline is 4 for zero parameters.
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 tool's purpose with a specific verb ('Lists') and resource ('success criteria that were added in WCAG 2.2'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list-success-criteria' or 'get-success-criteria-detail', which reduces clarity about its unique role.
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. It doesn't mention prerequisites, exclusions, or compare it to similar sibling tools (e.g., 'list-success-criteria'), leaving the agent without context for selection.
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 but lacks behavioral details. It doesn't disclose whether this is a read-only operation, if it requires authentication, rate limits, error handling, or response format. The description only covers the scope of returned data, missing critical operational context for a tool with unknown safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and clearly specifies inclusions and exclusions. Every word earns its place with zero redundancy or unnecessary elaboration.
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 single-parameter read tool with no output schema, the description adequately covers what data is returned but lacks completeness regarding behavioral aspects. Without annotations or output schema, it should ideally mention response structure or operational constraints, but the core purpose is clear enough for basic use.
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 no parameter information beyond what's in the schema, which has 100% coverage for the single parameter 'ref_id'. The schema already fully describes the parameter as a success criterion reference number with examples. Baseline score of 3 is appropriate since the schema does all the work.
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 action ('Gets') and resource ('normative success criterion requirements'), specifying what information is included ('title and exception details') and excluded ('without Understanding documentation'). It distinguishes from siblings like 'get-full-criterion-context' by focusing on core requirements only, though it doesn't explicitly name alternatives.
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 when only basic success criterion details are needed, excluding Understanding documentation. However, it doesn't explicitly state when to use this tool versus alternatives like 'get-criterion' or 'get-full-criterion-context', nor does it mention prerequisites or exclusions beyond the implied 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 carries full burden. It mentions filtering behavior but doesn't disclose pagination, rate limits, authentication needs, or what the output looks like (e.g., list format, fields). For a list tool with no annotations, this leaves significant behavioral 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?
Single sentence efficiently conveys purpose and both filtering options with clear examples. No wasted words, front-loaded with the main action.
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 list tool with good schema coverage but no annotations or output schema, the description is adequate but incomplete. It covers what the tool does but lacks behavioral context like output format or operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear enum values, so the schema documents parameters well. The description adds minimal value by listing example technologies and types, but doesn't explain semantics beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 'Lists' and resource 'WCAG techniques' with specific filtering capabilities. It distinguishes from siblings like 'get-technique' (singular) and 'search-techniques' (keyword search) by focusing on listing with optional filters, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing techniques with optional filters, but doesn't explicitly state when to use this vs. alternatives like 'search-techniques' or 'get-techniques-for-criterion'. No exclusions or prerequisites 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 provided, so the description carries full burden. It states the search behavior but lacks details on permissions, rate limits, result format, pagination, or error handling. For a search tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads key information (action, resource, scope) with zero wasted words. It is appropriately sized for a simple search tool.
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 moderate complexity (search with filtering), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but omits details on behavioral traits, result structure, and usage context, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('query' and 'level') with descriptions and enum values. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high coverage.
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 action ('Searches') and resource ('WCAG 2.2 success criteria'), specifying the scope ('by keyword in titles and descriptions'). It distinguishes from siblings like 'list-success-criteria' or 'get-criterion' by emphasizing search functionality, though it doesn't explicitly name alternatives.
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 keyword-based searches, but provides no explicit guidance on when to use this tool versus alternatives like 'search-glossary' or 'search-techniques'. It mentions the search scope but lacks context on exclusions 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?
No annotations are provided, so the description carries the full burden. It describes the filtering behavior but does not disclose other traits such as pagination, rate limits, authentication needs, or what the output format looks like (e.g., list structure, fields included). For a tool with no annotations, this leaves significant gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and succinctly lists the optional filters. There is no wasted verbiage, and every part of the sentence contributes directly to understanding the tool's functionality.
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 lack of annotations and output schema, the description is incomplete for a tool that likely returns a list of success criteria. It covers the input parameters well but does not address output behavior, such as what data is returned or how results are structured. This is adequate for a read-only list tool but leaves room for improvement in contextual 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning the same filters (level, guideline, principle) without providing additional semantics beyond what the schema specifies. This meets the baseline for high schema 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 verb ('Lists') and resource ('WCAG 2.2 success criteria'), and specifies the optional filtering capabilities by level, guideline, or principle. This distinguishes it from siblings like 'get-success-criteria-detail' (which likely retrieves detailed info for a specific criterion) or 'list-principles' (which lists principles rather than success criteria).
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 by mentioning optional filters, but does not explicitly state when to use this tool versus alternatives like 'search-wcag' or 'get-success-criteria-detail'. It provides context for filtering but lacks guidance on exclusions or specific scenarios where this tool is preferred over others.
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 burden. It states it 'Gets full details' but doesn't disclose behavioral traits like whether it's a read-only operation, what format the details are returned in, error handling for invalid ref_ids, or if there are rate limits. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Gets full details for a specific WCAG guideline') and adds essential context ('including all its success criteria'). There is zero waste, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It clearly states the purpose but lacks behavioral context (e.g., return format, error handling). Without annotations or output schema, more detail would improve completeness for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'ref_id' clearly documented as 'Guideline reference number (e.g., "1.1", "2.4", "4.1")'. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Gets full details') and resource ('for a specific WCAG guideline including all its success criteria'). It distinguishes from siblings like 'list-guidelines' (which lists multiple) and 'get-criterion' (which focuses on individual success criteria rather than entire guidelines).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'for a specific WCAG guideline,' suggesting it should be used when detailed information about a particular guideline is needed. However, it doesn't explicitly state when NOT to use it or name alternatives like 'list-guidelines' for overviews or 'get-criterion' for individual criteria details.
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. It states what the tool does but lacks behavioral details such as whether it returns all guidelines at once or uses pagination, what the output format is, or any rate limits. The description is minimal and doesn't compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes the optional filtering detail. There is no wasted text, and it effectively communicates the essential information in minimal words.
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 low complexity (one optional parameter, no output schema, no annotations), the description is adequate but has gaps. It covers the purpose and parameter use, but lacks details on output behavior (e.g., format, pagination) which would be helpful for an agent. It's minimally viable but not fully 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 description coverage is 100%, with the parameter 'principle' fully documented in the schema (including enum values and descriptions). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 for high schema 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 specific verb ('Lists') and resource ('WCAG 2.2 guidelines'), and distinguishes from siblings by specifying the optional filter by principle number. It differentiates from tools like 'get-guideline' (singular) and 'list-principles' (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to list guidelines with optional principle filtering), but does not explicitly state when not to use it or name alternatives. For example, it doesn't contrast with 'list-success-criteria' or 'get-guideline' for different needs.
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 burden. While it states what content is returned, it doesn't disclose behavioral traits like whether this is a static list or dynamic query, response format, error conditions, or performance characteristics. The description provides basic output content but lacks operational 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 a single, efficient sentence that immediately conveys the tool's purpose without any redundant information. It's appropriately sized for a simple tool and front-loads the essential information about what the tool returns.
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 zero-parameter tool with no output schema, the description provides the essential information about what content is returned. However, it lacks details about the return format (e.g., structured data vs plain text), ordering, or any metadata that might accompany the principles list. The description is minimally adequate but could provide more context about the response structure.
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 with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema fully documents the empty input structure.
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 specific action ('Lists') and the exact resource ('all four WCAG 2.2 principles') with explicit enumeration of the items returned. It distinguishes this tool from siblings like list-guidelines or list-success-criteria by focusing specifically on principles rather than other WCAG components.
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 context by specifying what content is returned (WCAG 2.2 principles), but doesn't explicitly state when to use this tool versus alternatives like get-criterion or list-guidelines. No guidance is provided about prerequisites, timing, or exclusion 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?
With no annotations provided, the description carries the full burden. It discloses the tool's read-only nature implicitly through 'Gets' and explains the inclusive/exclusive level behavior, but doesn't mention potential limitations like pagination, rate limits, authentication needs, or error conditions. The behavioral context is adequate but minimal.
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 with zero waste: the first states the core purpose, and the second explains the optional parameter's effect. It's front-loaded and efficiently structured, with every word contributing to understanding.
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 moderate complexity (filtered retrieval), 100% schema coverage, and no output schema, the description is reasonably complete. It covers the purpose and key parameter behavior, but lacks details on return format (e.g., structure of criteria objects) or error handling, which would be helpful for a tool with no 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 description coverage is 100%, so the schema already fully documents both parameters. The description adds marginal value by clarifying the 'include_lower' parameter's effect with an example ('e.g., AA includes A'), but doesn't provide additional semantics beyond what the schema specifies. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Gets') and resource ('all success criteria for a specific conformance level'), specifying the exact scope of retrieval. It distinguishes from siblings like 'get-criterion' (single criterion) and 'list-success-criteria' (unfiltered list) by focusing on level-based filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by explaining the optional 'include_lower' parameter behavior, which helps determine when to use this tool for inclusive vs. exclusive level queries. However, it doesn't explicitly state when to choose this over alternatives like 'list-success-criteria' or 'get-success-criteria-detail'.
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 full burden of behavioral disclosure. It describes the tool's function (retrieving details) and output scope ('complete Understanding documentation'), but lacks information on error handling (e.g., what happens with invalid ref_id), performance characteristics, or authentication needs. This is adequate for a read-only tool but leaves gaps in behavioral understanding.
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, well-structured sentence that front-loads the core purpose and efficiently includes key details (reference number examples and output scope). There is no redundant or unnecessary information, making it highly concise and effective for its purpose.
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 low complexity (one required parameter, no output schema, no annotations), the description is largely complete. It covers the purpose, parameter context, and output scope. However, it could improve by addressing potential errors or clarifying the relationship with similar sibling tools like get-success-criteria-detail, which might overlap in functionality.
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 100% description coverage, clearly documenting the ref_id parameter. The description adds minimal value beyond the schema by reinforcing the parameter's purpose ('by its reference number') and providing examples ('e.g., "1.1.1", "2.4.7"'), but does not explain semantic nuances like format constraints or validation rules. This meets the baseline for high schema 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 specific action ('Gets full details'), target resource ('WCAG success criterion'), and scope ('by its reference number'), distinguishing it from siblings like list-success-criteria (listing) or get-criteria-by-level (filtering by level). It explicitly mentions what details are included ('complete Understanding documentation'), which further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to retrieve detailed information for a specific WCAG success criterion identified by its reference number. However, it does not explicitly state when not to use it or name alternatives (e.g., list-success-criteria for a broad overview or get-success-criteria-detail which might be a similar sibling tool), which prevents a score of 5.
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

Copy to your README.md:

[![wcag-mcp MCP server](https://glama.ai/mcp/servers/joe-watkins/wcag-mcp/badges/card.svg)](https://glama.ai/mcp/servers/joe-watkins/wcag-mcp)

Score Badge

Copy to your README.md:

[![wcag-mcp MCP server](https://glama.ai/mcp/servers/joe-watkins/wcag-mcp/badges/score.svg)](https://glama.ai/mcp/servers/joe-watkins/wcag-mcp)

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/joe-watkins/wcag-mcp'

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