Loading ToolBench
A Model Context Protocol (MCP) server for performing automated accessibility scans of web pages using Playwright and Axe-core
This server has significant gaps in definition quality. While tool names are reasonably clear (navigate, screenshot, audit-site), most tools lack visible input schemas and parameter descriptions. The code shows tool definitions exist in separate .js files (e.g., src/tools/auditSite.js) but the actual schema definitions are not provided in the source excerpt. Tool descriptions are present but minimal (10-50 chars), falling well below the 194-char baseline. The server uses Zod for validation internally and defines a ToolSchema type with inputSchema fields, but actual parameter documentation and constraints are not visible in the provided source. Tools like 'audit-site', 'scan-page-matrix', and 'audit-keyboard' lack descriptions explaining WHEN to use them vs similar tools. No output schemas are documented. Error handling patterns are not visible in the provided code.
Audit keyboard navigation, focus visibility and skip links
Check accessible name quality and reading order
Crawl and scan multiple pages of a site for accessibility
Click an element on the page
Read console logs from the page
Execute JavaScript in the page context
Fill form fields
Find elements matching criteria on the page
Handle browser dialogs
No visible input schemas in provided source code. Tools reference Zod validation internally but actual schema definitions (parameter types, constraints, enums) are not shown. Per hard scoring rules, if schemas are not visible, schema score must be 0.
Descriptions are too short (10-50 chars) and lack guidance on WHEN to use each tool. Missing distinction between similar tools (e.g., audit-site vs audit-keyboard vs scan-page-matrix).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Hover over an element
Install browser dependencies
Navigate to a URL
Monitor and manage network activity
Generate a PDF of the current page
Press a keyboard key
Record browser interactions
Take a screenshot of the current page
Close a browser session
Open a new browser session
Get a snapshot of the current page
Close a browser tab
List all open browser tabs
Open a new browser tab
Type text into a field
Upload a file
Wait for page conditions
Run Axe accessibility scan on the current page
Scan the current page across multiple viewports and WCAG tag sets
No parameter descriptions visible. Tools like 'navigate' and 'fill' likely accept parameters but parameter names, types, and constraints are not documented. LLMs cannot infer parameter meaning from names alone.
No output schemas documented. Tools like 'audit-site' and 'scan-page-matrix' return complex accessibility audit results but the response structure is not described. LLMs cannot plan downstream steps without knowing what fields are available.
Tools 'navigate', 'click', 'fill', 'press' are WRITE operations that may have irreversible side effects. Descriptions do not state this clearly, and no dry-run or confirmation pattern is visible. Agents may not understand the destructive nature of these tools.
Naming: 'scan-page-matrix' is unclear on what 'matrix' means. This name does not follow verb_noun convention clearly. Consider 'scan_pages_cross_orientation' or 'audit_page_variants' for clarity.
Error handling patterns not visible in provided source.