This server has critically weak definition quality. Only 2 tools are registered, both with minimal descriptions and severely incomplete input schemas. The 'a11y.evidence' tool has a generic description ('Evidence capture') without context for when/why to use it. Its input schema defines 'bundle_id' (string) and 'input' (object) but the 'input' parameter has no property definitions, it is just a bare object type with no fields described, making it impossible for an LLM to know what data structure to pass. The 'a11y.diagnose' tool similarly has a terse description ('Accessibility diagnosis') and accepts either 'bundle_id' or 'bundle' as alternatives, but again no details on the 'bundle' object structure. Neither tool has documented output schemas. Parameter descriptions are minimal (e.g., 'Bundle identifier' for bundle_id is 10 chars, below the 20-char floor for meaningful guidance). No error handling, recovery guidance, or actionable error messages are evident. The tool names use dot notation (a11y.evidence, a11y.diagnose) rather than verb_noun patterns, which is non-standard and less intuitive for LLM tool selection. No pagination, validation rules, or composition chain support is visible. The source code references (src/a11y-mcp-tools/src/tools/evidence.js, diagnose.js) are mentioned but the actual implementation files are not provided in the source excerpt, so schemas and output types cannot be verified, they are only inferred from the summary provided.

• Rename tools to verb_noun pattern: 'capture_a11y_evidence', 'diagnose_a11y_issues', or 'run_accessibility_scan'. This makes intent obvious to LLMs without reading descriptions.
• Expand tool descriptions to 50-200 characters. Example for evidence tool: 'Capture accessibility evidence from a web application or component. Returns a bundle ID for use with diagnosis. Call this first to collect WCAG violations, ARIA issues, and color contrast failures.' Example for diagnose: 'Analyze a previously captured evidence bundle to generate a detailed accessibility report with remediation guidance. Requires a bundle_id from prior capture_a11y_evidence call.'
• Define the 'input' parameter schema explicitly. Replace {'type':'object','description':'Evidence input data'} with {'type':'object','properties':{'url':{'type':'string','description':'...'},'scope':{'type':'string','enum':['page','component','app'],'description':'...'},...},'required':['url']}.
• Document output schemas for both tools. Example: 'a11y.evidence returns {bundle_id (string, UUID), timestamp (ISO 8601), violation_count (integer), scanned_elements (integer)}. a11y.diagnose returns {bundle_id, issues (array of {type, wcag_level, element, suggestion}), summary (string), pass_rate (number 0-100)}'.
• Add parameter validation descriptions: 'bundle_id must be a valid UUID returned by a prior evidence capture call. If invalid, call list_recent_bundles() to find available IDs.'
• Implement error responses with recovery guidance: 'Invalid bundle_id: xyz. Recent bundles: abc (2024-01-15), def (2024-01-14). Try one of these or call capture_a11y_evidence() to create a new bundle.'