Loading ToolBench
MCP contracts and runtime server for Humanity4AI skills — providing 9 tools for humane AI behavior across accessibility, mental health support, cultural sensitivity, and inclusive design.
The Humanity4AI MCP server provides 9 well-intentioned tools focused on accessibility, mental health support, and inclusive design. All tools have descriptions and structured input schemas with enums and optional parameters. However, there are significant gaps in output schema documentation, error handling guidance, and parameter descriptions that prevent this from reaching production-grade quality. Most tools lack explicit error recovery paths, and output structures are not formally documented. The schema definitions are present and mostly complete, but descriptions vary widely in quality, some are thorough (e.g., accessibility_audit at ~200 chars) while others are brief (e.g., cognitive_accessibility_audit at ~80 chars). Parameters are well-constrained with enums where appropriate, but several lack detailed format/range guidance. The tool set is well-composed (no overlapping concerns, clear specialization) but lacks pagination/batching patterns for tools that could return lists.
Audit web pages for WCAG 2.2 compliance or set session WCAG level. Crawl mode: provide pages with URL+HTML for per-page scoring and ranking across all 86 success criteria. Session mode: returns the complete WCAG checklist for the requested level that the agent must enforce.
Audit a user flow or interface for age-inclusive design — covering children, adults, and older users. Returns recommendations to remove age-related barriers. Safety boundary: inclusive design guidance only.
Audit content for cognitive accessibility — plain language, reading level, structure, and clarity. Returns actionable recommendations to reduce cognitive load. Safety boundary: design guidance only.
Check a message for cultural sensitivity issues for a given audience or region. Returns flags, concerns, and suggested alternatives with uncertainty disclosure. Safety boundary: context-sensitive recommendations with uncertainty disclosure.
Generate a structured de-escalation plan for a conflict or tense situation. Returns step-by-step guidance calibrated to the intensity of the conflict. Safety boundary: no coercive tactics.
Output schemas are not formally documented in the tool definitions. The source code shows input schemas clearly (via Zod schemas in server-factory.ts), but no explicit documentation of what each tool returns. LLMs cannot plan downstream tool calls or extract fields without knowing the output structure.
No error handling documentation visible. The input schemas are present, but there are no documented error codes, error recovery paths, or actionable error messages. For tools handling sensitive content (depression, mental health, de-escalation), missing error guidance is a significant gap. An LLM cannot know whether to retry, escalate, or ask the user when a tool fails.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Reframe a message with genuine empathy — acknowledging emotions, validating experience, and offering presence. Detects and replaces hollow empathy phrases with authentic alternatives. Safety boundary: no manipulation or deceptive empathy.
Audit a UI description for neurodiversity-aware design — covering ADHD, autism, dyslexia, and sensory sensitivities. Returns targeted recommendations for inclusive design. Safety boundary: inclusive design guidance only.
Audit or rewrite text to be sensitive to depression and mental health. Removes harmful language patterns and replaces them with supportive, non-stigmatising alternatives. Safety boundary: non-clinical UX/content guidance only.
Generate a supportive, non-clinical reply to a message from someone in distress. Supports general emotional support and grief-specific modes (presence, practical, reflection). Includes escalation guidance calibrated to the assessed risk level. Safety boundary: non-clinical support only; must escalate when risk is elevated.
accessibility_audit accepts multiple input patterns (url, urls, pages with pre-fetched HTML) but lacks explicit documentation on which are mutually exclusive or preferred. Parameter relationships are not stated. When a tool has optional parameters that interact (url vs urls vs pages), the description must clarify the selection logic.
cognitive_accessibility_audit has a brief description (80 chars) that lacks guidance on when to use it vs other audit tools. The description should clarify the distinction from accessibility_audit (WCAG compliance vs cognitive load/reading level). Param 'target_context' is optional but lacks format guidance, what context information should be provided?
neurodiversity_design_check and age_inclusive_design_check accept optional 'focus' and 'age_groups' array parameters, but the descriptions do not specify valid values, examples, or constraints. An LLM cannot know whether to pass 'ADHD, autism' or 'adhd, autism' or full condition names. Enums or example lists are needed.
No pagination, batching, or result-limiting patterns are documented for tools that might return large outputs (e.g., accessibility_audit returning scores across 86 WCAG criteria or cultural_context_check returning a detailed report). The tool descriptions state what they return in crawl/session modes, but do not specify result size limits or whether results could exhaust context windows.