Strong foundation with 12 well-named tools following verb_noun convention (audit_*, inspect_*, get_*, suggest_*, compare_*). All tools have descriptions (avg 95 chars, within 10-1024 baseline). Input schemas are comprehensive with enums, ranges, and defaults. However, output schemas are partially documented via Zod but not fully visible in source; error handling lacks recovery guidance; some parameter descriptions could be more prescriptive about constraints and dependencies.

• Document output schemas explicitly in tool descriptions. For audit_* tools, state: 'Returns an AuditResult object with fields: summary (violationCount, affectedNodeCount, byImpact), issues (array of violations with impact, rule ID, affected nodes), coverage (WCAG criteria coverage), and evidence (DOM selectors and computed styles).'
• Add recovery guidance to error responses. Wrap tool implementations with try-catch that returns structured errors: {error: 'Browser timeout', retryable: true, guidance: 'URL took >30s to load. Verify the site is accessible and try again.'}
• Enhance parameter descriptions with actionable constraints. E.g., 'maxIssues (1-200, default 50): Limits returned violation groups to reduce token usage. Summary totals always cover the full run, so increasing this does not affect accuracy, only verbosity.'
• For complex object parameters (baseline, current, root), provide example JSON structures in the tool description or link to a schema definition. E.g., 'baseline: AuditResult object from a previous audit_url call. Must include summary and issues fields.'
• Add a dry_run parameter to future remediation tools (e.g., apply_contrast_fix) to preview changes before committing. This prevents accidental DOM modifications and aligns with the confirmation-request pattern.

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry