Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Accessibility MCP Server audit https://example.com for WCAG 2.1 AA issues"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides conversational, actionable accessibility testing. This server exposes accessibility auditing tools that can be used by AI agents and chat interfaces.
Conversational Results: Results formatted for natural language understanding, not raw data
Session Management: Reusable authenticated sessions for testing protected pages
Tag Filtering: Filter results by specific WCAG levels (wcag2a, wcag2aa, wcag21a, etc.)
Educational Focus: Tools that explain issues in plain language with code examples
Code-Level Fixes: Actual before/after code examples, not just descriptions
Progress Updates: Streaming progress for long-running batch operations
Smart Prioritization: AI-powered issue prioritization with quick wins identification
Compliance Reports: Automated VPAT/WCAG/ADA compliance documentation
Trend Tracking: Historical data and predictions for accessibility improvements
Related MCP server: aria51 MCP Server
Node.js 18+ (for npx command)
That's it! Everything else is handled automatically.
Add this server to your MCP client configuration (e.g., Claude Desktop, Cursor):
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"accessibility-audit": {
"command": "npx",
"args": ["-y", "@ali0113/accessibility-mcp-server"]
}
}
}Add to your Cursor MCP settings (~/.cursor/mcp.json or Cursor Settings → MCP):
{
"mcpServers": {
"accessibility-audit": {
"command": "npx",
"args": ["-y", "@ali0113/accessibility-mcp-server"]
}
}
}Restart Claude Desktop or Cursor to load the new MCP server configuration.
That's it! You're ready to use all 25+ accessibility tools. The package will be automatically downloaded and cached by npx on first use.
How it works:
npx automatically downloads and runs the package if needed
The -y flag answers "yes" to prompts (non-interactive)
Playwright browsers install automatically on first run
No manual installation, building, or configuration needed!
Audit any website - Single URLs, multiple pages, or entire sites
Test protected pages - Authenticated session management for login-protected content
Batch processing - Test multiple URLs in parallel with progress tracking
WCAG compliance - Check against WCAG 2.0, 2.1 (Levels A, AA, AAA) and best practices
Identify critical blockers - Find must-fix issues that block users
Quick wins detection - Easy fixes with high impact
Intelligent prioritization - Sort by impact, WCAG level, fixability, or user impact
Focus your efforts - Know exactly what to fix first
Before/after code examples - See exactly what needs to change
Copy-paste ready solutions - Actual code, not just descriptions
Multiple formats - Markdown, HTML, or JSON output
Specific fix suggestions - Targeted solutions for each issue
Plain language explanations - Understand what each issue means
Why it matters - Learn the user impact
How to fix - Step-by-step guidance with examples
WCAG references - Direct links to accessibility standards
Common mistakes - Learn from typical errors
VPAT reports - Generate Voluntary Product Accessibility Template documentation
WCAG compliance reports - Detailed compliance breakdowns
ADA reports - Americans with Disabilities Act compliance
Section 508 reports - Federal accessibility compliance
Executive summaries - High-level reports for stakeholders
Before/after comparison - Track improvements over time
Trend analysis - Historical data and predictions
Score tracking - Monitor accessibility scores
Visual diffs - See what changed between audits
CSV export - Import into Excel for analysis
Excel export - Professional reports with charts and formatting
JSON export - For API integration and data processing
HTML reports - Standalone web reports with visualizations
Dashboard generation - Visual summaries with charts
Filter by criteria - Rule IDs, categories, impact levels, WCAG levels
Search issues - Find specific problems quickly
Include/exclude modes - Focus on what matters
Element type filtering - Find issues in specific HTML elements
Site-wide analysis - Combine multiple audit results
Detailed statistics - Breakdowns by category, impact, WCAG level
Aggregated summaries - Overall site accessibility metrics
Grouping options - Organize by URL, category, rule, or impact
Dashboards - Visual summaries with key metrics
Charts - Score trends and category breakdowns
Multiple formats - Text, Markdown, HTML, JSON
Executive reports - High-level summaries for stakeholders
Get code-level fixes for accessibility issues
Learn accessibility concepts with educational explanations
Integrate into CI/CD pipelines
Export results for team sharing
Batch test multiple pages efficiently
Track accessibility over time
Generate compliance reports
Compare before/after deployments
Executive summary reports
Compliance documentation (VPAT, ADA)
Dashboard visualizations
Track accessibility scores over time
Generate VPAT reports automatically
WCAG compliance documentation
Section 508 compliance checks
Detailed remediation plans
Once configured, you can immediately start using the accessibility tools in your AI assistant:
Example: Audit a website
"Audit https://example.com for accessibility issues"Example: Get quick fixes
"Show me quick fixes for the accessibility issues on cursor.com"Example: Generate compliance report
"Generate a VPAT report for docs.atlan.com"Example: Compare before/after
"Compare the accessibility of example.com before and after the redesign"The AI assistant will automatically use the appropriate tools to fulfill your requests!
audit_url - Single URL AuditTest a single URL for accessibility issues with conversational, actionable results.
Inputs:
url (required): Full URL or relative path
domain (optional): Base domain if URL is relative
tags (optional): Array of accessibility tags to check (e.g., ["wcag2a", "wcag2aa", "wcag21a", "best-practice"]). If not provided, all tags are checked.
waitForLoad (optional): Wait strategy - "networkidle" (default) | "load" | "domcontentloaded"
timeout (optional): Timeout in seconds (default: 30)
Example:
{
"url": "https://example.com",
"tags": ["wcag21aa"],
"timeout": 45
}Output: Structured JSON with summary, prioritized violations, WCAG compliance breakdown, quick fix suggestions, and conversational explanation.
audit_multiple_urls - Batch AuditTest multiple URLs efficiently with progress updates.
Inputs:
urls (required): Array of URLs or comma-separated string
domain (optional): Base domain
tags (optional): Array of accessibility tags
parallel (optional): Number of parallel tests (default: 1)
continueOnError (optional): Continue if one fails (default: true)
Example:
{
"urls": ["/home", "/about", "/contact"],
"domain": "https://example.com",
"tags": ["wcag2aa"],
"parallel": 2
}Output: Per-URL results, aggregated summary, and progress updates (streaming).
audit_site - Smart Site AuditIntelligent site-wide audit with prioritization.
Inputs:
domain (required): Base domain
tags (optional): Array of accessibility tags. Applied to all pages.
strategy (optional): "critical" | "comprehensive" | "custom" (default: "comprehensive")
maxPages (optional): Maximum pages to test (default: 50)
priorityPaths (optional): Array of high-priority paths to test first
Example:
{
"domain": "https://example.com",
"strategy": "critical",
"priorityPaths": ["/", "/login", "/checkout"],
"tags": ["wcag21aa"],
"maxPages": 20
}Output: Prioritized results (critical pages first), site-wide score, and trend analysis if previous audits exist.
create_session - Authenticated SessionCreate a reusable authenticated session for testing protected pages.
Inputs:
domain (required): Base domain
username (required): Login username
password (required): Login password
loginUrl (optional): Custom login URL (default: {domain}/login)
loginSelectors (optional): Custom selectors for login form:
usernameSelector (default: "input[type='email'], input[name='username'], input[id='username']")
passwordSelector (default: "input[type='password']")
submitSelector (default: "button[type='submit'], input[type='submit']")
sessionId (optional): Custom session identifier (auto-generated if not provided)
Example:
{
"domain": "https://app.example.com",
"username": "user@example.com",
"password": "password123",
"loginUrl": "https://app.example.com/auth/login"
}Output:
sessionId: Reusable session identifier
expiresAt: Session expiration time (ISO 8601)
testUrl: Test URL to verify session
Differentiator: Only MCP with reusable session management for authenticated pages.
audit_with_session - Authenticated AuditRun an audit using an existing authenticated session.
Inputs:
sessionId (required): Session from create_session
url (required): URL to test (can be relative)
domain (optional): Base domain
tags (optional): Array of accessibility tags
waitForLoad (optional): Wait strategy (default: "networkidle")
timeout (optional): Timeout in seconds (default: 30)
Example:
{
"sessionId": "session-abc123",
"url": "/dashboard",
"domain": "https://app.example.com",
"tags": ["wcag21aa"]
}Output: Same as audit_url but for authenticated pages.
get_accessibility_score - Calculate ScoreCalculate accessibility score (0-100) with detailed breakdowns.
Inputs:
results (required): Audit result object or URL string
weights (optional): Custom weights for different issue types:
errors (default: 10)
contrast (default: 8)
alerts (default: 5)
features (default: 3)
structural (default: 6)
Example:
{
"results": "https://example.com",
"weights": {
"errors": 15,
"contrast": 10
}
}Output:
Overall score (0-100)
Breakdown by category (contrast, navigation, forms, etc.)
WCAG level compliance (A, AA, AAA)
Trend if historical data available
prioritize_issues - Smart PrioritizationIntelligently prioritize issues, identifying quick wins and critical blockers.
Inputs:
results (required): Audit result object
criteria (optional): "impact" | "wcag" | "fixability" | "user-impact" (default: "impact")
limit (optional): Top N issues to return (default: 10)
Example:
{
"results": { /* audit result object */ },
"criteria": "fixability",
"limit": 5
}Output:
Prioritized list with reasoning
Quick wins (easy fixes with high impact)
Critical blockers
explain_issue - Educational ToolExplain what an accessibility issue means in plain language.
Inputs:
ruleId (required): Accessibility rule ID (e.g., "alt_missing", "contrast", "label_missing")
context (optional): Additional context about the issue (HTML element, page URL, etc.)
Example:
{
"ruleId": "alt_missing",
"context": "Image on homepage hero section"
}Output:
Plain language explanation
Why it matters (user impact)
How to fix (with code examples)
WCAG reference
Common mistakes
Differentiator: Educational focus - helps users learn accessibility.
get_quick_fixes - Actionable FixesGet specific fix suggestions with before/after code examples.
Inputs:
results (required): Audit result object or URL string
format (optional): "markdown" | "html" | "json" (default: "json")
includeCode (optional): Include code examples (default: true)
Example:
{
"results": "https://example.com",
"format": "markdown",
"includeCode": true
}Output:
List of fixes with:
Current code (if available)
Fixed code
Explanation
Impact estimate
Differentiator: Code-level fixes, not just descriptions.
generate_compliance_report - Compliance DocumentationGenerate compliance reports in various formats.
Inputs:
results (required): Audit result object
format (optional): "VPAT" | "WCAG" | "ADA" | "Section508" (default: "WCAG")
level (optional): "A" | "AA" | "AAA" (default: "AA")
includeRemediation (optional): Include fix suggestions (default: true)
Example:
{
"results": { /* audit result object */ },
"format": "VPAT",
"level": "AA",
"includeRemediation": true
}Output:
Formatted compliance report
WCAG mapping
Remediation plan
Executive summary
get_wcag_compliance - WCAG StatusCheck WCAG compliance status with per-criterion breakdown.
Inputs:
results (required): Audit result object or URL string
level (optional): "A" | "AA" | "AAA" (default: "AA")
Example:
{
"results": "https://example.com",
"level": "AA"
}Output:
Compliance status (pass/fail/partial)
Per-criterion breakdown
Missing requirements
Compliance percentage
compare_accessibility - Before/After ComparisonCompare two audits to track improvements.
Inputs:
before (required): Previous audit result or URL
after (required): Current audit result or URL
format (optional): "summary" | "detailed" | "diff" (default: "summary")
Example:
{
"before": "https://example.com/v1",
"after": "https://example.com/v2",
"format": "detailed"
}Output:
Issues fixed
Issues introduced
Score improvement
Remaining issues
Visual diff (if applicable)
track_accessibility - Historical TrackingTrack accessibility over time with trend analysis.
Inputs:
url (required): URL to track
timeframe (optional): "7d" | "30d" | "90d" | "all" (default: "30d")
metric (optional): "score" | "issues" | "wcag-compliance" (default: "score")
Example:
{
"url": "https://example.com",
"timeframe": "90d",
"metric": "score"
}Output:
Historical data
Trend visualization (text-based)
Predictions
Recommendations
export_to_csv - Export to CSVExport audit results to CSV format for spreadsheet analysis, including metadata and violation rows.
Inputs:
results (required): Audit result object or URL string
includeMetadata (optional): Include test information and environment data (default: true)
includeViolations (optional): Include detailed violation rows (default: true)
format (optional): "standard" | "detailed" | "minimal" (default: "standard")
Example:
{
"results": "https://example.com",
"format": "detailed",
"includeMetadata": true,
"includeViolations": true
}Output:
CSV content as string with metadata section and violation rows
Format type used
Total issues count
Use case: Import into Excel, share with stakeholders, data analysis
export_to_excel - Export to ExcelExport audit results to Excel/XLSX format with formatting. Requires xlsx package.
Inputs:
results (required): Audit result object or URL string
includeCharts (optional): Generate charts for score trends and category breakdown (default: false)
formatting (optional): Apply colors, headers, and styling (default: true)
Example:
{
"results": { /* audit result object */ },
"includeCharts": true,
"formatting": true
}Output:
Excel file content (base64 encoded)
Format type (xlsx)
Total issues count
Use case: Professional reports, presentations, stakeholder sharing
Note: Requires xlsx package. Install with npm install xlsx.
export_to_json - Export to JSONExport audit results as structured JSON with optional raw results.
Inputs:
results (required): Audit result object or URL string
pretty (optional): Pretty-print JSON (default: true)
includeRaw (optional): Include raw accessibility engine results (default: false)
Example:
{
"results": "https://example.com",
"pretty": true,
"includeRaw": false
}Output:
JSON string with audit results
Pretty-print status
Raw results inclusion status
Use case: API integration, data processing, backup
export_to_html_report - Generate HTML ReportGenerate standalone HTML report with styling and optional visual charts.
Inputs:
results (required): Audit result object or URL string
template (optional): "default" | "minimal" | "detailed" (default: "default")
includeCharts (optional): Include visual charts (default: true)
Example:
{
"results": "https://example.com",
"template": "detailed",
"includeCharts": true
}Output:
HTML string with embedded CSS/JS
Template used
Charts inclusion status
Use case: Web sharing, email reports, documentation
filter_issues - Filter IssuesFilter issues from audit results by various criteria (rule IDs, categories, impact levels, WCAG levels, etc.). Supports include/exclude modes.
Inputs:
results (required): Audit result object
filters (required): Object with filter criteria:
ruleIds (optional): Array of rule IDs to include/exclude
categories (optional): Array of categories (error, contrast, etc.)
impactLevels (optional): Array of impact levels ("critical", "serious", "moderate", "minor")
wcagLevels (optional): Array of WCAG levels ("A", "AA", "AAA")
minCount (optional): Minimum occurrence count
elementTypes (optional): Filter by HTML element types (e.g., ["img", "input", "button"])
mode (optional): "include" | "exclude" (default: "include")
Example:
{
"results": { /* audit result object */ },
"filters": {
"impactLevels": ["critical", "serious"],
"wcagLevels": ["A", "AA"]
},
"mode": "include"
}Output:
Filtered audit result object
Original issue count
Filtered issue count
Filters applied
Use case: Focus on specific issue types, exclude false positives
search_issues - Search IssuesSearch issues by text content, selector, XPath, or description. Supports case-sensitive and case-insensitive search.
Inputs:
results (required): Audit result object
query (required): Search query string
fields (optional): Array of fields to search ("description", "element", "xpath", "selector", "ruleId", "userImpact", "fix", "all") (default: ["all"])
caseSensitive (optional): Case-sensitive search (default: false)
Example:
{
"results": { /* audit result object */ },
"query": "missing alt",
"fields": ["description", "userImpact"],
"caseSensitive": false
}Output:
Array of matching issues
Total matches count
Fields searched
Use case: Find specific issues, locate elements
aggregate_audit_results - Aggregate ResultsCombine and aggregate multiple audit results. Groups issues by URL, category, rule, or none, and provides aggregated summary statistics.
Inputs:
results (required): Array of audit result objects
groupBy (optional): "url" | "category" | "rule" | "none" (default: "url")
includeSummary (optional): Include aggregated summary statistics (default: true)
Example:
{
"results": [
{ /* audit result 1 */ },
{ /* audit result 2 */ }
],
"groupBy": "category",
"includeSummary": true
}Output:
Aggregated audit result with combined statistics
Grouping strategy used
Total results aggregated
Grouped issues (if applicable)
Use case: Site-wide reports, batch analysis, trend identification
get_statistics - Generate StatisticsGenerate detailed statistics from audit results with breakdowns by category, impact, WCAG level, or rule ID. Supports single or multiple audit results.
Inputs:
results (required): Audit result object or array of audit results
breakdown (optional): Array of breakdown dimensions ("category", "impact", "wcag", "rule") (default: all dimensions)
Example:
{
"results": [
{ /* audit result 1 */ },
{ /* audit result 2 */ }
],
"breakdown": ["category", "impact", "wcag"]
}Output:
Total issues count
Average accessibility score
WCAG compliance breakdown
Statistics by category, impact, WCAG level, and rule ID
Counts, percentages, and distributions
Use case: Dashboard data, reporting, analysis
generate_dashboard - Generate DashboardCreate a visual dashboard summary of audit results with key metrics, charts, and summaries. Supports multiple formats and optional charts.
Inputs:
results (required): Audit result object, array of audit results, URL string, or array of URL strings
format (optional): "text" | "markdown" | "html" | "json" (default: "markdown")
includeCharts (optional): Include ASCII/text charts (default: true)
Example:
{
"results": ["https://example.com/page1", "https://example.com/page2"],
"format": "markdown",
"includeCharts": true
}Output:
Formatted dashboard with key metrics, charts, and summaries
Format used
Total results processed
Use case: Quick overview, presentations, status reports
generate_summary_report - Generate Summary ReportGenerate executive summary report with key findings and recommendations. Supports multiple formats and detail levels.
Inputs:
results (required): Audit result object, array of audit results, URL string, or array of URL strings
format (optional): "text" | "markdown" | "html" (default: "markdown")
level (optional): "executive" | "detailed" | "technical" (default: "executive")
Example:
{
"results": "https://example.com",
"format": "markdown",
"level": "executive"
}Output:
Summary report with key findings and recommendations
Format used
Detail level used
Total results processed
Use case: Stakeholder communication, documentation
Filter results by specific WCAG levels or best practices:
wcag2a - WCAG 2.0 Level A
wcag2aa - WCAG 2.0 Level AA
wcag2aaa - WCAG 2.0 Level AAA
wcag21a - WCAG 2.1 Level A
wcag21aa - WCAG 2.1 Level AA (most common requirement)
wcag21aaa - WCAG 2.1 Level AAA
best-practice - Best practice recommendations
Example Usage:
// Only check WCAG 2.1 AA compliance
{
"url": "https://example.com",
"tags": ["wcag21aa"]
}
// Check multiple WCAG levels
{
"url": "https://example.com",
"tags": ["wcag2a", "wcag2aa", "best-practice"]
}All audit tools return structured results in the following format:
{
summary: {
totalIssues: number
score: number
wcagCompliance: { A: number, AA: number, AAA: number }
byCategory: Record<string, number>
byImpact: Record<string, number>
}
prioritizedIssues: Array<{
ruleId: string
impact: 'critical' | 'serious' | 'moderate' | 'minor'
description: string
wcagLevel: string
tags: string[] // Array of tags this violation matches
element: string
xpath: string
fix: {
current: string
suggested: string
explanation: string
}
userImpact: string
priority: number
}>
conversationalSummary: string
quickWins: Array<{
ruleId: string
description: string
impact: string
fix: string
}>
criticalBlockers: Array<{
ruleId: string
description: string
impact: string
}>
appliedFilters?: {
tags?: string[]
originalIssueCount?: number
}
}{
"tool": "audit_url",
"arguments": {
"url": "https://example.com",
"tags": ["wcag21aa"]
}
}Step 1: Create Session
{
"tool": "create_session",
"arguments": {
"domain": "https://app.example.com",
"username": "user@example.com",
"password": "password123"
}
}Step 2: Audit Protected Page
{
"tool": "audit_with_session",
"arguments": {
"sessionId": "<session-id-from-step-1>",
"url": "/dashboard",
"tags": ["wcag21aa"]
}
}{
"tool": "audit_multiple_urls",
"arguments": {
"urls": ["/home", "/about", "/contact", "/products"],
"domain": "https://example.com",
"parallel": 2,
"tags": ["wcag2aa"]
}
}{
"tool": "get_quick_fixes",
"arguments": {
"results": "https://example.com",
"format": "markdown",
"includeCode": true
}
}{
"tool": "compare_accessibility",
"arguments": {
"before": "https://example.com/v1",
"after": "https://example.com/v2",
"format": "detailed"
}
}{
"tool": "generate_compliance_report",
"arguments": {
"results": { /* audit result object */ },
"format": "VPAT",
"level": "AA",
"includeRemediation": true
}
}{
"tool": "export_to_csv",
"arguments": {
"results": "https://example.com",
"format": "detailed",
"includeMetadata": true,
"includeViolations": true
}
}{
"tool": "export_to_excel",
"arguments": {
"results": { /* audit result object */ },
"includeCharts": true,
"formatting": true
}
}{
"tool": "export_to_json",
"arguments": {
"results": "https://example.com",
"pretty": true,
"includeRaw": false
}
}{
"tool": "export_to_html_report",
"arguments": {
"results": "https://example.com",
"template": "detailed",
"includeCharts": true
}
}{
"tool": "filter_issues",
"arguments": {
"results": { /* audit result object */ },
"filters": {
"impactLevels": ["critical", "serious"],
"wcagLevels": ["A", "AA"]
},
"mode": "include"
}
}{
"tool": "search_issues",
"arguments": {
"results": { /* audit result object */ },
"query": "missing alt",
"fields": ["description", "userImpact"],
"caseSensitive": false
}
}{
"tool": "aggregate_audit_results",
"arguments": {
"results": [
{ /* audit result 1 */ },
{ /* audit result 2 */ }
],
"groupBy": "category",
"includeSummary": true
}
}{
"tool": "get_statistics",
"arguments": {
"results": [
{ /* audit result 1 */ },
{ /* audit result 2 */ }
],
"breakdown": ["category", "impact", "wcag"]
}
}{
"tool": "generate_dashboard",
"arguments": {
"results": ["https://example.com/page1", "https://example.com/page2"],
"format": "markdown",
"includeCharts": true
}
}{
"tool": "generate_summary_report",
"arguments": {
"results": "https://example.com",
"format": "markdown",
"level": "executive"
}
}The server includes comprehensive error handling:
Graceful degradation: Partial results on batch failures
Clear error messages: Human-readable error descriptions
Retry logic: Automatic retries for transient failures
Validation: Input validation with helpful error messages
Common error scenarios:
Invalid URLs or unreachable pages
Session expiration (for authenticated audits)
Timeout errors (configurable)
Invalid tag combinations
accessibility-mcp-server/
├── src/
│ ├── server.ts # Main MCP server entry point
│ ├── tools/ # Tool implementations
│ │ ├── audit.ts # Core audit tools
│ │ ├── session.ts # Session management
│ │ ├── analysis.ts # Analysis & reporting
│ │ ├── comparison.ts # Comparison tools
│ │ ├── export.ts # Export tools (CSV, Excel, JSON, HTML)
│ │ ├── filter.ts # Filtering and search tools
│ │ ├── aggregate.ts # Aggregation and statistics tools
│ │ └── visualize.ts # Visualization and dashboard tools
│ ├── core/ # Core accessibility functionality
│ │ ├── accessibility-runner.ts # Accessibility execution
│ │ ├── session-manager.ts # Session handling
│ │ ├── result-processor.ts # Result formatting
│ │ ├── error-handler.ts # Error handling
│ │ └── progress-streamer.ts # Progress updates
│ └── types/ # TypeScript types
├── dist/ # Compiled JavaScript
├── wave.min.js # Accessibility engine script (required)
├── package.json
├── tsconfig.json
└── README.mdIf you want to contribute or modify the code, you can set up a local development environment:
Node.js 18+
npm or yarn
Clone the repository
git clone <repository-url>
cd accessibility-mcp-serverInstall dependencies
npm installInstall Playwright browsers
npx playwright install --with-deps chromiumBuild the project
npm run buildVerify accessibility script
Ensure wave.min.js is present in the project root
Development Mode (with watch)
npm run devProduction Mode
npm startIf you want to use the local version instead of the published package:
{
"mcpServers": {
"accessibility-audit": {
"command": "node",
"args": ["/absolute/path/to/accessibility-mcp-server/dist/server.js"]
}
}
}Note: Use absolute paths in your configuration.
Zero Setup Required - Just add config and use! No installation, building, or manual setup needed
Conversational Interface - Results formatted for natural language understanding
Session Management - Only MCP with reusable authenticated sessions for protected pages
Educational Focus - explain_issue teaches accessibility concepts, not just reports problems
Code-Level Fixes - Actual before/after code examples, not just descriptions
Progress Updates - Streaming progress for long-running batch operations
Smart Prioritization - AI-powered issue prioritization with quick wins identification
Compliance Reports - Automated VPAT/WCAG/ADA/Section 508 documentation
Tag Filtering - Filter by specific WCAG levels to reduce noise and focus on what matters
25+ Tools - Comprehensive suite covering auditing, analysis, reporting, export, and more
MIT License - feel free to use in your projects!
Contributions are welcome! Please ensure all code follows the existing style and includes appropriate tests.
For issues, questions, or contributions, please open an issue on the repository.
Happy accessibility testing! ♿✨
Combine and aggregate multiple audit results. Groups issues by URL, category, rule, or none, and provides aggregated summary statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| groupBy | No | Grouping strategy: "url" (group by URL), "category" (group by category), "rule" (group by rule ID), or "none" (no grouping). Default: "url". | url |
| results | Yes | Array of audit result objects to aggregate. | |
| includeSummary | No | Include aggregated summary statistics (default: true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions grouping and summary statistics but omits key behaviors: what happens if results array is empty, how grouping handles ambiguity, or the exact structure of the output. Insufficient for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences conveying core functionality. No redundant phrases, front-loaded with the primary action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers basic purpose and options but lacks details on return format, edge cases, or examples. Given no output schema and multiple sibling tools, more completeness is needed to ensure correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description reiterates the grouping options and summary inclusion but adds no new meaning beyond the schema's own descriptions. No extra value or clarification for parameter constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'combine and aggregate', the resource 'audit results', and specific actions: grouping by URL/category/rule/none and providing summary statistics. This effectively distinguishes it from sibling tools like 'filter_issues' or 'audit_url'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after conducting multiple audits to combine results, but it does not explicitly state when to use this tool versus alternatives (e.g., filter_issues, get_statistics). No exclusions or context about prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test multiple URLs efficiently with optional parallel processing and progress tracking.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Specific accessibility tags to check. Applied to all URLs. | |
| urls | Yes | URLs to test (array or comma-separated string). | |
| domain | No | Base domain if URLs are relative (e.g., "https://example.com"). | |
| parallel | No | Number of parallel tests to run (default: 1). | |
| continueOnError | No | Continue processing if one URL fails (default: true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral disclosure. It highlights parallel processing and progress tracking but does not state non-destructive nature, error handling beyond the 'continueOnError' parameter, or output format. The schema parameters address some gaps, but the description itself is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is extremely concise, front-loaded with the verb and resource, and includes key features efficiently. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description lacks information about return values, result format, or what 'test' means in terms of output. The tool is relatively complex, but the description does not sufficiently contextualize the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any parameter-level information beyond what the schema already provides, merely referencing parallel processing in a general sense.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool tests multiple URLs, with emphasis on efficiency via parallel processing and progress tracking. It clearly distinguishes from the sibling 'audit_url' which handles single URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'efficiently with optional parallel processing' implies this is best for batch testing, providing clear context for use. However, it does not explicitly mention when not to use this tool or direct to siblings like 'audit_with_session' for session-based workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test a single URL for accessibility issues. Returns structured, conversational results with prioritized issues and fix suggestions.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL or relative path to test. If relative, domain must be provided. | |
| tags | No | Specific accessibility tags to check. If not provided, all tags are checked. | |
| domain | No | Base domain if URL is relative (e.g., "https://example.com"). | |
| timeout | No | Timeout in seconds (default: 30). | |
| waitForLoad | No | Wait strategy for page loading. | networkidle |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It indicates the output is 'structured, conversational results with prioritized issues and fix suggestions,' which adds some behavioral context. However, it omits security, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that communicates the core function and output without any unnecessary words. It is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema, no annotations), the description covers the basic purpose and output type but lacks details on return structure or parameter interplay. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description adds no additional meaning beyond what the schema provides for each parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Test a single URL for accessibility issues,' specifying a distinct verb and resource. This distinguishes it from siblings like audit_multiple_urls and audit_with_session, which target multiple URLs or sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for single URLs but does not explicitly state when to use it versus alternatives like audit_multiple_urls. No exclusion or prerequisite guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an accessibility audit on a URL using an existing authenticated session. This allows testing protected pages without re-authenticating for each audit.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL or relative path to test. If relative, domain must be provided. | |
| tags | No | Specific accessibility tags to check. If not provided, all tags are checked. | |
| domain | No | Base domain if URL is relative. If not provided, uses session domain. | |
| sessionId | Yes | Session ID from create_session tool. |
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 mentions using an existing session but fails to disclose side effects, error conditions, or whether the session is modified. This lack of detail 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the key action, and contains no unnecessary words. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is adequate but lacks behavioral details and clarity on prerequisites like creating a session. It could be more complete for a tool with four parameters and complex dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any new information about parameters beyond what the schema already provides, but it does not detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs an accessibility audit on a URL using an existing session, with a specific verb and resource. It distinguishes itself from sibling tools like audit_url by highlighting the session requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the use case for protected pages without re-authentication, implying when to use the tool. However, it does not explicitly state alternatives or when not to use it, though the context of sibling tools provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two accessibility audits to track improvements. Identifies issues that were fixed, introduced, or remain, with score improvement and visual diff summary.
| Name | Required | Description | Default |
|---|---|---|---|
| after | Yes | Current audit results object or URL string. If URL is provided, an audit will be run first. | |
| before | Yes | Previous audit results object or URL string. If URL is provided, an audit will be run first. | |
| format | No | Output format: "summary" for concise comparison, "detailed" or "diff" for comprehensive diff visualization (default: summary). | summary |
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 mentions identifying issues and output types but fails to state whether the tool is read-only, requires authentication, or has performance impacts. This 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences with no wasted words. It front-loads the purpose and then lists what it identifies, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema. The description mentions output elements (fixed/introduced/remaining issues, score improvement, visual diff summary) but does not detail the structure or format of the output. For a comparison tool, this is minimally adequate but leaves ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes all parameters (before, after, format) adequately. The description adds no further parameter-specific details; it only restates what the output covers. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares two accessibility audits to track improvements, identifying fixed, introduced, and remaining issues. This distinguishes it from sibling tools like audit_url (which runs audits) and get_accessibility_score (which retrieves a score).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for tracking improvements, but it does not explicitly state when to use this tool versus alternatives such as audit_url or filter_issues. No when-not-to-use or prerequisite guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a reusable authenticated session by logging into a website. The session can be reused for multiple audits of protected pages.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Base domain (e.g., "https://example.com" or "example.com"). | |
| loginUrl | No | Custom login URL. If not provided, defaults to {domain}/login. | |
| password | Yes | Login password. | |
| username | Yes | Login username. | |
| sessionId | No | Custom session identifier. If not provided, one is generated. | |
| loginSelectors | No | Custom selectors for login form. If not provided, defaults are used. |
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 mentions reusability but does not disclose potential side effects (e.g., credential storage), error handling on failed login, or session expiry behavior. Adequate but lacking depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the core purpose and usage context. Every sentence is essential, with no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (3 required), nested objects, and no output schema, the description is minimal. It does not explain the return value, how the session ID is used, or behavior of default vs custom selectors. Incomplete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond the schema, simply stating the overall action. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a reusable authenticated session by logging into a website.' This includes a specific verb (create), resource (session), and context (logging in), distinguishing it from sibling tools like audit_url or audit_with_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: 'can be reused for multiple audits of protected pages.' However, it does not explicitly state when to use this tool versus alternatives (e.g., when no session exists) or when not to use it, relying on general context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain what an accessibility issue means in plain language. Provides educational information including why it matters, how to fix it, WCAG references, and code examples.
| Name | Required | Description | Default |
|---|---|---|---|
| ruleId | Yes | Accessibility rule ID (e.g., "alt_missing", "contrast", "label_missing"). | |
| context | No | Additional context about the issue (optional). Can include element information or specific circumstances. |
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 provides educational information but does not disclose any behavioral traits such as read-only nature, side effects, or authentication needs. While no negative traits are implied, the description fails to explicitly assure safe or non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the primary purpose and then enumerate the educational content. Every sentence adds value and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the absence of an output schema, the description adequately captures what the agent can expect (plain-language explanation, fix guidance, etc.). It does not specify the exact output format (e.g., text, structured data), which is a minor gap, but overall it is sufficient for an agent to understand the tool's role among complex sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add semantic detail beyond the schema: it does not mention or elaborate on the two parameters (ruleId and context). The schema itself already provides clear descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Explain' and the resource 'accessibility issue', and lists specific educational content (why it matters, how to fix, WCAG references, code examples). This distinctly sets it apart from sibling tools focused on auditing, scoring, and reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after an issue is identified (e.g., from audit tools), but it does not explicitly state when to use this versus alternatives or provide 'when not to use' guidance. It lacks explicit contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export audit results to CSV format for spreadsheet analysis. Includes metadata section and violation rows.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Export format: "standard" (default), "detailed" (includes all fields), or "minimal" (essential fields only). | standard |
| results | Yes | Audit results object or URL string. If URL is provided, an audit will be run first. | |
| includeMetadata | No | Include test information and environment data (default: true). | |
| includeViolations | No | Include detailed violation rows (default: true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose side effects, permissions, rate limits, or error handling. It only describes the output format (metadata and violation rows), missing 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Purpose is front-loaded, and every sentence earns its place by describing what the tool does and what it includes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema, the description is somewhat incomplete. It does not explain the CSV structure, how the results parameter works (object vs URL), or error scenarios. Schema covers parameters but description lacks operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters clearly. The description adds little beyond reinforcing that metadata and violation rows are included, which matches booleans. No new semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports audit results to CSV format for spreadsheet analysis, specifying it includes metadata and violation rows. This distinguishes it from siblings like export_to_excel or export_to_json.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies CSV is for spreadsheet analysis, but offers no explicit guidance on when to use this tool over alternatives like export_to_excel or export_to_json. No exclusion criteria or suggested use cases are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export audit results to Excel/XLSX format with formatting. Requires xlsx package.
| Name | Required | Description | Default |
|---|---|---|---|
| results | Yes | Audit results object or URL string. If URL is provided, an audit will be run first. | |
| formatting | No | Apply colors, headers, and styling (default: true). | |
| includeCharts | No | Generate charts for score trends and category breakdown (default: false). |
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 the package dependency but does not disclose error handling (e.g., missing package), side effects (e.g., file creation), or output behavior (e.g., where the file is saved). This leaves the agent unclear on important execution details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a brief note, making it concise and front-loaded. It conveys the core purpose and key requirement efficiently, though the note could be integrated. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description fails to specify what the tool returns (e.g., file path, download URL), how it handles the 'results' parameter when a URL is provided, or dependency behavior. This leaves the agent with significant gaps for a tool that produces output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal value beyond schema; it mentions 'formatting' which correlates with the formatting parameter, but does not elaborate on the 'results' parameter duality (object or URL). The package note is not directly about parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export', the resource 'audit results', and the specific format 'Excel/XLSX format with formatting'. It also mentions the required package 'xlsx', which distinguishes it from sibling export tools like export_to_csv and export_to_html_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for formatted Excel output ('with formatting') and notes the xlsx package requirement, but does not explicitly state when to use this tool versus alternative export formats (e.g., CSV, JSON, HTML). It lacks direct comparison or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate standalone HTML report with styling. Includes optional visual charts.
| Name | Required | Description | Default |
|---|---|---|---|
| results | Yes | Audit results object or URL string. If URL is provided, an audit will be run first. | |
| template | No | Report template: "default" (standard report), "minimal" (essential info only), or "detailed" (comprehensive report). | default |
| includeCharts | No | Include visual charts (default: true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions the output is a report with styling and optional charts, but does not state whether the tool is read-only, requires authentication, or has side effects. The behavior is partially clear but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. Every word adds value; no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple export tool, the description is minimally adequate. However, it lacks details on what 'standalone' means, how the report is returned (file path or content), and the nature of charts. No output schema or annotations compensate, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds minimal extra meaning—only hinting at the template via 'styling' and charts via 'visual charts.' Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a standalone HTML report with styling and optional visual charts. It distinguishes from sibling export tools (csv, excel, json) by specifying the output format, and the verb 'generate' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for HTML report generation but does not explicitly state when to use it vs alternatives like export_to_csv. No prerequisites or exclusions are mentioned, relying on the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export audit results as structured JSON. Supports pretty-printing and optional raw results.
| Name | Required | Description | Default |
|---|---|---|---|
| pretty | No | Pretty-print JSON (default: true). | |
| results | Yes | Audit results object or URL string. If URL is provided, an audit will be run first. | |
| includeRaw | No | Include raw accessibility engine results (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavioral traits. It only states the output format and optional features, but does not disclose side effects, limitations, or any required permissions. For a simple export, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and add details without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple export tool with well-documented parameters, the description is adequate but does not clarify the return format or the 'audit results' source. Slightly above minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters well. The description adds no extra meaning beyond what the schema provides, achieving the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports audit results as JSON, which is specific and differentiates from sibling export tools (CSV, Excel, HTML). It also mentions key features like pretty-printing and raw results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., CSV, Excel). No mention of 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.
Filter issues from audit results by various criteria (rule IDs, categories, impact levels, WCAG levels, etc.). Supports include/exclude modes.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Filter mode: "include" (only include matching issues) or "exclude" (exclude matching issues). | include |
| filters | Yes | Filter criteria object. | |
| results | Yes | Audit result object from a previous audit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only mentions include/exclude modes but fails to state whether the input is mutated, how filters combine, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, and no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with nested objects and no output schema, the description lacks detail on return value or behavior. It is too minimal given the tool's richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with detailed parameter descriptions. The description adds minimal value beyond summarizing the criteria types, which is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool filters issues from audit results using various criteria and mentions include/exclude modes. It is distinct from sibling tools like audit_url or generate_compliance_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like search_issues. The description only implies use after an audit but does not specify prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate compliance reports in VPAT, WCAG, ADA, or Section 508 format. Includes WCAG criterion mapping, compliance percentages, executive summary, and optional remediation plan.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | WCAG compliance level to assess: "A", "AA", or "AAA". Default: AA. | AA |
| format | No | Report format: "VPAT" (Voluntary Product Accessibility Template), "WCAG" (WCAG compliance report), "ADA" (Americans with Disabilities Act report), or "Section508" (Section 508 compliance report). Default: WCAG. | WCAG |
| results | Yes | Audit result object from a previous audit. | |
| includeRemediation | No | Include remediation plan with fix suggestions in the report (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the output contents (criterion mapping, percentages, executive summary, remediation plan) but does not describe side effects (e.g., data persistence, auth requirements, rate limits). It implies a pure generation operation, but details are sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficiently stating what the tool does and its key capabilities. No extraneous content, and the most important information (verb, resource) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, one nested object, and multiple format options, the description provides a good high-level overview but lacks detail on the required input ('results') and output structure. Given no output schema, more detail on return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds marginal value: it lists the formats and mentions optional remediation, which overlaps with the schema's 'format' and 'includeRemediation' descriptions. No additional explanation of the 'results' object structure beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generate', the resource 'compliance reports', and lists specific formats (VPAT, WCAG, ADA, Section508) and contents (mapping, percentages, executive summary, optional remediation). This distinguishes it from sibling tools that primarily audit or export raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, when not to use it, or prerequisites. For example, it doesn't mention that 'results' must come from a prior audit, which is critical context for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a visual dashboard summary of audit results with key metrics, charts, and summaries. Supports multiple formats (text, markdown, HTML, JSON) and optional charts.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format: "text" (plain text), "markdown" (markdown format), "html" (HTML report), or "json" (structured JSON). Default: "markdown". | markdown |
| results | Yes | Audit result object(s) or URL string(s). If URL(s) provided, audit(s) will be run first. | |
| includeCharts | No | Include ASCII/text charts in the dashboard (default: true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Does not disclose behavioral traits like side effects (e.g., whether it stores data), performance considerations, or how URLs trigger audits. Lacks transparency beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential aspects for a dashboard tool given schema richness. Could elaborate on dashboard content or include usage notes, but still sufficiently complete for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds minor context about 'key metrics, charts, and summaries' and format options but does not significantly deepen parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool creates a 'visual dashboard summary of audit results with key metrics, charts, and summaries'. Differentiates from sibling tools like export functions and generate_summary_report by emphasizing dashboard visuality and format flexibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention scenarios where other tools (e.g., generate_summary_report, export_to_html_report) might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate executive summary report with key findings and recommendations. Supports multiple formats (text, markdown, HTML) and detail levels (executive, detailed, technical).
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Detail level: "executive" (high-level summary for executives), "detailed" (comprehensive summary with breakdowns), or "technical" (technical details for developers). Default: "executive". | executive |
| format | No | Output format: "text" (plain text), "markdown" (markdown format), or "html" (HTML report). Default: "markdown". | markdown |
| results | Yes | Audit result object(s) or URL string(s). If URL(s) provided, audit(s) will be run first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It only mentions the tool generates a report and supports formats/levels, but does not explain side effects, authentication needs, rate limits, or what the output contains beyond 'key findings and recommendations'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences; the first defines the purpose, and the second lists supported options. It is front-loaded and efficient, though it could be slightly more detailed without compromising brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and generates a report, the description should explain what the report looks like (e.g., structure, sections). It only mentions 'key findings and recommendations', leaving the output format ambiguous for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds a high-level overview of supported formats and levels, which partially repeats the schema. It adds some context but does not significantly enhance understanding beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an executive summary report with key findings and recommendations, specifying supported formats and detail levels. However, it does not explicitly differentiate from sibling tools like 'generate_compliance_report', so it loses a point for lack of sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'generate_compliance_report' or export tools. The description lacks any context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate accessibility score (0-100) from audit results with detailed breakdowns by category and WCAG compliance levels. Supports custom weights for different issue types.
| Name | Required | Description | Default |
|---|---|---|---|
| results | Yes | Audit results object or URL string. If URL is provided, an audit will be run first. | |
| weights | No | Custom weights for different issue types (e.g., {"critical": 5.0, "serious": 3.0}). If not provided, default weights are used. |
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 correctly implies a read operation but fails to disclose that providing a URL triggers an audit (mentioned only in parameter schema). No mention of auth, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loads the key information (score range, breakdowns) efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the output format (e.g., what breakdowns look like). It mentions 'detailed breakdowns' without specifics. Given tool complexity (dual input, optional weights), more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds 'Supports custom weights' but this largely echoes the schema. The dual-input behavior of 'results' is described in the schema but not reinforced in the top-level description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates an accessibility score (0-100) with detailed breakdowns by category and WCAG levels. It also mentions custom weights, making the purpose specific. However, it does not differentiate from similar tools like get_wcag_compliance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus siblings (e.g., audit_url, get_wcag_compliance). It implies audit results are needed but does not instruct the agent to run an audit first or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific fix suggestions with before/after code examples from audit results. Returns actionable fixes formatted as markdown, HTML, or JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format: "markdown" for markdown-formatted fixes, "html" for HTML format, or "json" for structured data (default: json). | json |
| results | Yes | Audit results object or URL string. If URL is provided, an audit will be run first. | |
| includeCode | No | Include before/after code examples in the fixes (default: true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It fails to mention that providing a URL as the 'results' parameter triggers an audit before generating fixes, a critical behavior only noted in the parameter description. It also omits details about side effects, safety, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, efficiently front-loading the purpose and return formats. There is no fluff or irrelevant information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the dual behavior of the 'results' parameter (object vs. URL) nor describe the structure of the returned fixes, which is essential for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description repeats the 'before/after code examples' and 'formatted as markdown, HTML, or JSON' already covered by the schema, adding no new semantic value beyond what the parameter descriptions provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get specific fix suggestions with before/after code examples from audit results.' It uses a specific verb ('Get') and resource ('fix suggestions') and distinguishes from sibling tools like 'explain_issue' or 'get_accessibility_score' by focusing on actionable fixes with code examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool requires audit results but does not explicitly state when to use it versus alternatives (e.g., 'explain_issue' for explanation, 'get_accessibility_score' for scoring). It lacks guidance on prerequisites or when not to use this tool, 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.
Generate detailed statistics from audit results with breakdowns by category, impact, WCAG level, or rule ID. Supports single or multiple audit results.
| Name | Required | Description | Default |
|---|---|---|---|
| results | Yes | Audit result object or array of audit results to analyze. | |
| breakdown | No | Array of breakdown dimensions: "category", "impact", "wcag", "rule". Default: all dimensions. |
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 discloses that the tool generates statistics and supports breakdowns, which suggests a read-only analytical operation. However, it does not explicitly state that it is non-destructive or requires no modifications, nor does it mention authorization needs or side effects. The behavior is adequately described for a simple analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences with no extraneous information. It is front-loaded, efficient, and every sentence earns its place. The structure is clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that takes audit results and returns statistics, the description covers the input and the breakdown options. It does not have an output schema, so the description would ideally specify the format of the statistics (e.g., counts, percentages). However, given the simplicity and the context of sibling tools, it is reasonably complete. The missing output format details slightly reduce the score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters thoroughly. The description adds value by listing the breakdown dimensions ('category, impact, wcag, rule') which match the enum values, but does not provide additional meaning beyond what is in the schema. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generate', the resource 'statistics from audit results', and specifics about breakdowns by category, impact, WCAG level, or rule ID. It distinguishes itself from sibling tools like 'get_accessibility_score' or 'generate_summary_report' by focusing on detailed statistics with multiple breakdown dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it supports single or multiple audit results, implying usage after an audit. However, it does not explicitly state when to use this tool versus alternatives like 'aggregate_audit_results' or 'generate_dashboard', nor does it provide when-not-to-use guidance. Usage is implied but not clearly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check WCAG compliance status with detailed per-criterion breakdown. Returns compliance status (pass/fail/partial), compliance percentage, violations per criterion, and missing requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | WCAG compliance level to check: "A", "AA", or "AAA". Default: AA. | AA |
| results | Yes | Audit results object or URL string. If URL is provided, an audit will be run first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that if a URL is provided, an audit is run first, and lists return values. However, it does not mention potential side effects (e.g., the audit might be time-consuming) or whether the tool is read-only. With no annotations, the description carries the burden but lacks full 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The purpose is front-loaded, and the return values are summarized. Could be slightly more structured but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 params, one with enum and oneOf) and no output schema, the description sufficiently covers input behavior (URL triggering an audit) and output components. Slightly lacking in output structure detail but adequate for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add significant insight beyond the schema; it summarizes the tool's function but doesn't elaborate on parameters' meanings or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check WCAG compliance status with detailed per-criterion breakdown.' It lists specific outputs (compliance status, percentage, violations, missing requirements), making it distinct from sibling tools like audit_url or get_accessibility_score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., whether a prior audit is needed) or situations where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Intelligently prioritize accessibility issues based on specified criteria, identifying quick wins (easy fixes with high impact) and critical blockers (must fix before launch).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Top N issues to return. If not provided, all issues are returned. | |
| results | Yes | Audit result object from a previous audit. | |
| criteria | No | Prioritization criteria: "impact" (by impact level), "wcag" (by WCAG compliance level), "fixability" (by ease of fix), or "user-impact" (by user experience impact). | impact |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must cover behavioral traits. It fails to disclose whether the tool mutates data, performance implications, output structure, or algorithm details, only hinting at two output categories ('quick wins', 'critical blockers').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's core function and key output categories without any redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and nested 'results' object, the description is adequate but omits details on how the prioritization works, the format of the returned issues, and whether the input is consumed or just read, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions (100% coverage), so baseline is 3. The tool description adds modest value by framing the output in terms of 'quick wins' and 'critical blockers', but does not substantially enhance parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'prioritize' with a clear resource (accessibility issues) and adds concrete output categories ('quick wins', 'critical blockers'), making the tool's purpose distinct from siblings like 'filter_issues' or 'search_issues'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after an audit (taking 'results' as input) but provides no explicit guidance on when to choose this over siblings, nor any when-not-to-use or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search issues by text content, selector, XPath, or description. Supports case-sensitive and case-insensitive search.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string. | |
| fields | No | Fields to search: "description", "element", "xpath", "selector", "ruleId", "userImpact", "fix", or "all" (default: ["all"]). | |
| results | Yes | Audit result object from a previous audit. | |
| caseSensitive | No | Case-sensitive search (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It fails to mention that the tool requires a prior audit result (the 'results' parameter) and does not explain behavior for missing or invalid inputs. The case-sensitive mention is trivial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the main purpose. However, it lacks completeness (missing fields) and could be clearer without increasing length significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 params, nested required object, no output schema) and 21 sibling tools, the description is insufficient. It does not explain the dependency on a prior audit result or how search works across multiple fields, leaving critical gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal value by repeating case sensitivity and partially listing fields, but it does not clarify the required 'results' object beyond the schema. No undocumented parameters are explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search issues by text content, selector, XPath, or description', which identifies the verb and resource. However, it omits other searchable fields like 'element', 'ruleId', 'userImpact', and 'fix' that exist in the schema's fields parameter, making the description incomplete and potentially misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus sibling tools like filter_issues or other search alternatives. It only mentions case sensitivity support, which is a feature, not usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track accessibility metrics over time with trend analysis, predictions, and recommendations. Stores audit results for historical comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to track accessibility metrics for. | |
| metric | No | Metric to track: "score" (accessibility score 0-100), "issues" (total number of issues), or "wcag-compliance" (average WCAG compliance percentage). Default: score. | score |
| timeframe | No | Timeframe for historical data: "7d" (7 days), "30d" (30 days), "90d" (90 days), or "all" (all available data). Default: 30d. | 30d |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions storing audit results, implying persistence, but does not disclose side effects, prerequisites (e.g., need for prior audits), rate limits, or authorization needs. Since no annotations are provided, the description bears full responsibility for behavioral disclosure and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The two-sentence description is concise and front-loaded, with no fluff. However, it could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 3 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return format, prerequisites, or how the tool relates to sibling tools like audit_url.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions and enums, achieving 100% coverage. The description adds no extra parameter context, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tracks accessibility metrics over time with trend analysis, predictions, and recommendations. It uses a specific verb and resource, and the mention of 'over time' helps distinguish it from point-in-time tools like get_accessibility_score, but it does not explicitly differentiate from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With over 20 sibling tools, the absence of usage context leaves the agent to infer intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.7aggregate_audit_resultsaudit_multiple_urlsaudit_urlaudit_with_sessioncompare_accessibilitycreate_sessionexplain_issueexport_to_csvexport_to_excelexport_to_html_reportexport_to_jsonfilter_issuesgenerate_compliance_reportgenerate_dashboardgenerate_summary_reportget_accessibility_scoreget_quick_fixesget_statisticsget_wcag_complianceprioritize_issuessearch_issuestrack_accessibilityEach tool has a clearly distinct purpose: auditing, sessions, scoring, prioritization, explanations, comparisons, tracking, compliance, exports, filtering, aggregation, statistics, and dashboards. No overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., audit_url, get_accessibility_score, generate_compliance_report). The verbs are descriptive and the pattern is uniform across all 22 tools.
22 tools is slightly high but justified for a comprehensive accessibility auditing server covering the full workflow from auditing to reporting. Each tool serves a specific purpose without redundancy.
The tool set covers all major aspects: auditing (single/multiple), session management, scoring, prioritization, explanations, comparisons, historical tracking, compliance reports, multiple export formats, filtering/searching, aggregation, statistics, and dashboards. No obvious gaps for the intended purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI QA tester — real browsers scan sites for bugs, SEO, perf, and accessibility issues via chat.
Scan URLs for WCAG 2.1 violations, generate AI fixes, and produce VPAT 2.5 compliance reports.
Browser-based QA for AI-built software. Test pages with real browsers via agents.
Agentic testing: HyperExecute jobs, test failure triage, SmartUI visual diffs, a11y audits
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/alii13/accessibility-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
