Loading ToolBench
Screen-reader navigation cost analyzer. Measures how hard it is for AT users to discover, reach, and operate web content.
Tactual is an accessibility analysis MCP server with 9 tools focused on screen-reader navigation assessment. Strengths: all tools have descriptions (100-400 chars); most parameters are documented; input schemas are visible and typed. Weaknesses: parameter descriptions are often minimal; several tools lack actionable error guidance; no evidence of output schema documentation; tool names are verb-prefixed but somewhat domain-specific ('analyze-url', 'validate-url') which is acceptable but could be more discoverable; some parameters like 'profile', 'device', 'format' lack enum constraints or full specification. The server implements real domain logic (accessibility simulation) but the interface design doesn't fully follow agent-friendly composition patterns, e.g., analyze-url has 40+ parameters creating cognitive load and ambiguous dependencies (explore* params are conditional on explore flag, not documented). Error handling is minimal; no evidence of recovery guidance or per-item failure reporting for batch operations.
Analyze multiple pages for accessibility issues
Analyze a URL for screen-reader navigation accessibility issues
Generate calibration report comparing simulator predictions to ground-truth AT recordings
Diff two analysis results to show changes in accessibility findings
List available AT profiles
Save authentication credentials for analysis
Suggest accessibility remediations for findings
Trace the navigation path to reach a specific target on a page
save-auth tool passes credentials as a parameter, violates secret-injection pattern. Credentials must never appear in tool parameters; they enter agent logs and LLM context.
analyze-url has 40+ parameters with no documented dependencies or conditional logic. Many parameters (explore*, probe*) are conditional on parent flags but not documented. This violates the single-responsibility principle and creates ambiguity for LLM invocation.
No output schemas documented for any tool. LLMs cannot plan downstream invocations or extract required fields without knowing response structure. analyze-url is especially problematic, likely returns complex nested results but format is undocumented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Validate accessibility predictions against virtual screen-reader observations
Parameter descriptions for complex inputs ('finding', 'target', 'credentials') use generic type 'object' with no field specification. LLMs cannot determine required/optional fields or nested structure.
No error recovery guidance. Tools return errors but do not indicate whether failures are retryable, whether a different tool should be called first, or what user action is needed. Violates recovery-guide pattern.
analyze-pages batch operation lacks per-item error handling documentation. If 5 of 10 URLs fail, does the tool return partial results, fail entirely, or return per-item status?
Parameter 'profile' is used across multiple tools but no enum constraint is visible. LLMs must call list-profiles first to discover valid values, forces unnecessary lookup calls. Either provide enum inline or document the required discovery pattern.