project_human

Name: project_human
Author: humanity4ai

by humanity4ai

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Humanity4AI ⭐

9 humanity skills for AI agents — crisis detection, accessibility auditing, empathy, cultural sensitivity, and more. Ready-to-use via MCP, npm, or direct prompting.

npm License: MIT Release Works with CodeQL MCP Registry

Demo

Skills at a Glance

Skill	Category	What it does
🛡️ Supportive Reply	Emotional Safety	Detects crisis signals, generates supportive responses with escalation guidance
📝 Safe Content Rewriter	Emotional Safety	Audits and rewrites text to remove harmful, stigmatising, or triggering patterns
♿ Accessibility Audit	Accessibility	Scores pages against all 86 WCAG 2.2 success criteria (A/AA/AAA)
🧠 Cognitive Accessibility	Cognitive Support	Audits content for reading level, structure, and cognitive load
🌍 Cultural Context Check	Cultural Context	Flags cultural sensitivity issues for a given audience and region
🔥 De-escalation Plan	Conflict Navigation	Generates structured de-escalation plans calibrated to conflict intensity
💬 Empathetic Reframe	Communication	Reframes messages with genuine empathy, catching hollow empathy patterns
🧩 Neurodiversity Design	Neurodiversity	Audits UIs for ADHD, autism, dyslexia, and sensory sensitivity
👶 Age-Inclusive Design	Age Inclusion	Audits user flows for age barriers across children, adults, and older users

⭐ If you find this useful, a star helps others discover it

Related MCP server: mcp-llm

Quick Start

Zero setup — just a URL:

{
  "mcpServers": {
    "humanity4ai": {
      "url": "https://humanity4ai.ascent.partners/api/mcp"
    }
  }
}

Or one command with npx:

npx @humanity4ai/mcp-servers

Then configure your MCP client:

{
  "mcpServers": {
    "humanity4ai": {
      "command": "npx",
      "args": ["-y", "@humanity4ai/mcp-servers"]
    }
  }
}

Docker: docker compose up
For contributors: git clone … && pnpm install && pnpm start

All 9 skills are discoverable via tools/list and invocable via tools/call.

Prerequisites (for local only): Node.js >= 22, pnpm >= 10 | Windows, macOS, Linux, Android, iOS

Architecture

graph TD
    A[MCP Client<br/>VS Code / Cursor / Claude Code] -->|stdio| B[mcp-server.ts]
    A -->|HTTP POST| C[Vercel<br/>humanity4ai.ascent.partners]
    B --> D[server-factory.ts<br/>createServer]
    C -->|api/mcp.ts| D
    D --> E[9 Tool Registrations]
    E --> F[handlers.ts<br/>invokeAction]
    F --> G[validate.ts<br/>SCHEMA_REGISTRY]
    G --> H[schemas-data.ts<br/>18 inline schemas]
    F --> I[9 Handler Functions<br/>rule-based, zero LLM calls]
    I --> J[crisis-resources<br/>patterns<br/>i18n<br/>wcag-criteria]

Four Ways to Use

Method	Best for	How
Remote URL	Zero-setup, any MCP client	Point to `https://humanity4ai.ascent.partners/api/mcp`
MCP Server	VS Code, Cursor, Claude Code, Copilot, Manus AI, OpenCode	`npx @humanity4ai/mcp-servers` or clone & start
LLM Prompting	ChatGPT, Claude, Gemini (web chat)	Share `llms.txt` or paste `llms-full.txt` into the chat
Local Files	Offline CLI tools	Clone the repo, point your tool at the `skills/` directory

See Agent Adapter Guide for platform-specific setup instructions.

Why Humanity4AI?

AI agents are everywhere — but they're not always humane. Humanity4AI gives agents reusable, tested skills for the moments that matter:

An agent detects a user in crisis → Supportive Reply generates an appropriate response and escalates to qualified help
A UI is inaccessible to screen readers → Accessibility Audit scores it against WCAG 2.2 and provides remediation
Content uses stigmatising language → Safe Content Rewriter flags and rewrites harmful patterns
A conflict is escalating → De-escalation Plan generates structured, non-coercive guidance

Every skill includes:

Explicit safety boundaries — what the skill can and cannot do
Uncertainty disclosure — confidence level stated upfront (low/medium/high)
Evaluation gates — automated baseline checks for quality

These skills are rule-based and non-clinical — they do not provide diagnosis, treatment, or professional medical/legal advice.

Supported Platforms

OpenCode · Claude Code · Microsoft Copilot · Manus AI · OpenClaw · ChatGPT · Claude · Gemini

Contribute

git clone https://github.com/<your-username>/project_human.git
cd project_human
git checkout -b my-contribution
# Copy the skill template if adding a new skill:
cp -r templates/skill skills/my-skill-name
pnpm check && pnpm evals && pnpm test  # Run all checks before PR

Open a PR targeting main. Browse good first issues or read the Contributing Guide.

Error	Fix
`ERR_PNPM_OUTDATED_LOCKFILE`	Run `pnpm install`, then commit `pnpm-lock.yaml`
`pnpm: command not found`	`npm install -g pnpm`
`pnpm evals` fails	`EVAL_REPORT=1 pnpm evals` — see `evals/reports/latest.md`

Resources

Available Tools

9 tools

accessibility_auditA

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.

ParametersJSON Schema

Name	Required	Description	Default
`url`	No	URL to audit (auto-fetched — no need to provide HTML)
`mode`	No	crawl: score pages against all 86 WCAG 2.2 criteria. session: return WCAG checklist for this session.	crawl
`urls`	No	Multiple URLs to audit (all auto-fetched)
`level`	No	WCAG conformance level	AA
`pages`	No	Array of crawled pages with pre-fetched HTML (optional if url/urls provided)
`locale`	No	BCP 47 locale code	en

TDQS

A3.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses auto-fetching of URLs and the two modes, but it does not mention whether the tool is read-only, rate limits, error behavior, or any destructive actions. Key behavioral traits are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the main purpose. Every word earns its place, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 6 parameters, two modes, and no output schema or annotations, the description provides essential mode distinctions but omits details on return format, scoring interpretation, error handling, or locale usage. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters with descriptions. The description adds value by explaining the two modes (crawl vs. session) and the role of pages parameter as optional alternative to url/urls, which the schema alone does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states tool audits web pages for WCAG 2.2 compliance and distinguishes two modes (crawl and session), specifying 86 success criteria. It effectively communicates the primary resource and action, differentiating from siblings like cognitive_accessibility_audit by focusing on general WCAG compliance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description explains when to use each mode: crawl for per-page scoring with URL/HTML, session for obtaining a WCAG checklist. It provides clear context but does not explicitly exclude alternatives or mention when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

age_inclusive_design_checkA

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.

ParametersJSON Schema

Name	Required	Description	Default
`age_groups`	No	Optional list of age groups to focus on (e.g. ['children', 'elderly', 'teenagers'])
`flow_description`	Yes	Description of the user flow, interface, or product experience to audit

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses the tool returns recommendations and sets a safety boundary ('inclusive design guidance only'), indicating it is non-destructive and advisory. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with action and purpose, no wasted words. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an audit tool with no output schema, the description outlines input and purpose well. Lacks detail on output format (e.g., list of recommendations), but is mostly adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so baseline is 3. The description adds that age groups include children, adults, older users, but the schema already describes the age_groups parameter. No significant added value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool audits a user flow or interface for age-inclusive design, covering children, adults, and older users, and returns recommendations. This differentiates it from siblings like accessibility_audit (broader) and neurodiversity_design_check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for age-inclusive audits but does not explicitly guide when to choose this over siblings like accessibility_audit or cultural_context_check. The safety boundary is noted but no alternative tools are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cognitive_accessibility_auditA

Audit content for cognitive accessibility — plain language, reading level, structure, and clarity. Returns actionable recommendations to reduce cognitive load. Safety boundary: design guidance only.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	The text or UI content to audit
`target_context`	No	Optional context about the target audience or use case

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses safety boundary ('design guidance only') indicating it does not modify content. States it returns actionable recommendations, clarifying behavioral scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus a safety boundary line. Every sentence adds value. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with no output schema, the description covers purpose, output, and safety boundary. Adequate but could mention that output is structured or provide example.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% parameters with descriptions. The description adds context about cognitive accessibility dimensions but does not enhance parameter understanding beyond schema. Baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Describes a specific audit for cognitive accessibility, listing aspects (plain language, reading level, structure, clarity) and outputs actionable recommendations. Distinct from sibling 'accessibility_audit' which is likely broader.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for cognitive accessibility assessments via the description, but does not explicitly state when to choose this over siblings like 'accessibility_audit' or 'neurodiversity_design_check'. No when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cultural_context_checkA

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.

ParametersJSON Schema

Name	Required	Description
`region`	No	Optional geographic region for more specific context
`message`	Yes	The message or content to check
`audience`	Yes	Target audience description

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the transparency burden. It mentions 'uncertainty disclosure' and a 'safety boundary', indicating cautious behavior, but does not elaborate on limitations, side effects, or what constitutes a 'safety boundary'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the purpose and return values. Every sentence adds value—no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description outlines returns (flags, concerns, suggested alternatives) but lacks details on output structure or example usage. It is adequate but could be more complete for a moderation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the baseline is 3. The tool description does not add additional parameter semantics beyond what the schema already provides (e.g., it does not explain how region or audience affect the check).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to check a message for cultural sensitivity issues for a given audience or region. It distinguishes itself from sibling tools like rewrite_depression_sensitive_content by focusing specifically on cultural sensitivity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., accessibility_audit, empathetic_reframe). It lacks explicit when-to-use or when-not-to-use instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

deescalation_planA

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.

ParametersJSON Schema

Name	Required	Description	Default
`intensity`	No	Intensity of the conflict	medium
`situation`	Yes	Description of the conflict or tense situation

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states the output is step-by-step guidance calibrated to intensity and includes a safety boundary ('no coercive tactics'). However, it does not disclose return format, effects of intensity levels, or any limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences with no wasted words. The first states the main function, the second describes the output and safety boundary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter tool with no output schema, the description adequately covers the basic purpose but lacks detail on output format (e.g., list, paragraphs) and does not explain how intensity calibrates the plan.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (both parameters have descriptions). The description adds context that the output is calibrated to the intensity parameter, but this is a minor enhancement beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'generate' and the resource 'structured de-escalation plan', and specifies the output is step-by-step guidance calibrated to conflict intensity. It distinguishes itself from sibling tools, which are unrelated (e.g., accessibility audits, empathetic reframes), though it lacks explicit differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for conflict or tense situations ('Generate a structured de-escalation plan for a conflict or tense situation') but provides no explicit guidance on when not to use, prerequisites, or alternatives among the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

empathetic_reframeA

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.

ParametersJSON Schema

Name	Required	Description	Default
`tone`	No	Desired tone of the empathetic reframe	warm
`message`	Yes	The message to reframe with empathy

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses key behaviors: acknowledging emotions, detecting/replacing hollow phrases, and safety constraints. Missing details on return format or processing limits, but overall transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three focused sentences with no redundancy. Front-loaded with the main action and safety boundary, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers purpose, behavior, and safety adequately. Could be improved by mentioning return type (e.g., reframed message), but still sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with clear parameter descriptions. The tool description does not add extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reframes messages with genuine empathy, detects hollow phrases, and sets a safety boundary. It distinguishes from siblings like 'supportive_reply' by focusing on replacing inauthentic empathy.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for empathetic reframing and warns against manipulation, but does not explicitly state when not to use or compare to alternatives like 'supportive_reply' or 'deescalation_plan'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

neurodiversity_design_checkA

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.

ParametersJSON Schema

Name	Required	Description	Default
`focus`	No	Optional list of specific neurodiversity conditions to focus on
`ui_description`	Yes	Description of the UI, interface, or interaction flow to audit

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description bears full burden. Explicitly states 'Safety boundary: inclusive design guidance only,' clarifying what it won't do. Does not detail return format or side effects, which would improve transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with purpose, covering scope and boundary. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple audit tool with no output schema. Mentions conditions and safety boundary. Missing return format details, but context signals show no output schema, so description suffices.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters. The tool description adds context about conditions but does not significantly augment schema understanding. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action (audit), the resource (UI description), and the specific scope (neurodiversity-aware design covering ADHD, autism, dyslexia, sensory sensitivities). Distinguishes from siblings like accessibility_audit by focusing on neurodiversity conditions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage (when auditing for neurodiversity) but lacks explicit when-not-to-use or alternative tools. Mentions a safety boundary but no specific context for choosing this over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rewrite_depression_sensitive_contentA

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.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	'audit' returns issues found; 'rewrite' returns improved text	rewrite
`text`	Yes	The text content to audit or rewrite
`domain`	No	Optional domain context (e.g. 'healthcare', 'social media')

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose all behavioral traits. It explains that the tool removes and replaces language patterns, but does not elaborate on side effects, irreversibility, or specific changes made.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the purpose and immediately follow with key details, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a simple tool, but missing output format details (e.g., no description of return for 'audit' vs 'rewrite'). Relies on schema for mode distinction.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and descriptions are clear. The tool description adds context about purpose but no additional parameter-level details beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the tool's action ('Audit or rewrite text') and domain ('sensitive to depression and mental health'), distinguishing it from siblings like 'accessibility_audit' or 'cultural_context_check'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a safety boundary ('non-clinical UX/content guidance only'), implying appropriate contexts, but does not explicitly say when not to use it or mention alternative sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

supportive_replyA

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.

ParametersJSON Schema

Name	Required	Description	Default
`locale`	No	BCP 47 locale code for the response language	en
`message`	Yes	The message from the person in distress
`risk_level`	Yes	Assessed risk level: 'low' for general distress, 'medium' for concerning signals, 'high' for crisis
`support_mode`	No	Support mode: 'general' for default emotional support	general

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It transparently states the tool generates a reply, includes escalation guidance, and is non-clinical. It does not disclose side effects or internal behavior, but for a text generation tool, this is adequate and does not contradict any annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the core purpose and following with specific details about modes and boundaries. Every sentence adds essential information without redundancy or unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters (all documented in schema) and no output schema or annotations, the description covers the tool's purpose, modes, risk calibration, and safety boundary. It could benefit from stating the output format, but overall it is sufficient for an agent to understand usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying the context of support modes (general, presence, practical, reflection) and how risk_level influences escalation guidance, going beyond the schema's descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Generate' and the resource 'a supportive, non-clinical reply'. It mentions specific support modes (general emotional support, grief-specific: presence, practical, reflection) and distinguishes from clinical support via a safety boundary, making it distinct from sibling tools like deescalation_plan or empathetic_reframe.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: use for non-clinical support in distress, with escalation guidance calibrated to risk level. The safety boundary explicitly excludes clinical use and mandates escalation for elevated risk. However, it does not explicitly name alternative sibling tools for high-risk or clinical scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

9 tool updatesv0.1.0Jul 29, 2026
- First observedaccessibility_audit
- First observedage_inclusive_design_check
- First observedcognitive_accessibility_audit
- First observedcultural_context_check
- First observeddeescalation_plan
- First observedempathetic_reframe
- First observedneurodiversity_design_check
- First observedrewrite_depression_sensitive_content
- First observedsupportive_reply

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a distinct purpose: WCAG accessibility audits, depression-sensitive rewriting, supportive replies, cognitive accessibility, cultural context checks, de-escalation plans, empathetic reframing, neurodiversity design, and age-inclusive design. No overlap; agents can easily differentiate.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., accessibility_audit, rewrite_depression_sensitive_content, cultural_context_check). Predictable and uniform.

Tool Count5/5

With 9 tools, the set is well-scoped for the domain of human-centered design and sensitive communication. Each tool earns its place without being too few or too many.

Completeness5/5

The tools comprehensively cover accessibility (WCAG, cognitive, neurodiversity, age), mental health sensitivity, cultural sensitivity, and communication guidance. There are no obvious gaps for the stated purpose of inclusive and sensitive interaction.

Maintenance

ActivityMaintained

ResponsivenessWithin a week

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
mcp-wanOAuth
io.github.AceDataCloud
MCP server for Wan AI video generation
AI & Machine Learning Image & Video Processing
21
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2

Related MCP Servers

mcp-dice
Command Line
yamaton
A
license
A
quality
D
maintenance
A MCP server enabling LLMs to roll dice
Updated 2 years ago (2025-01-01 23:16 UTC)
1
4
MIT
mcp-llm
Code Execution Autonomous Agents
sammcj
A
license
B
quality
C
maintenance
An MCP server that provides LLMs access to other LLMs
Updated a year ago (2025-03-15 05:37 UTC)
4
48
78
MIT
human-mcp
RAG Systems Autonomous Agents
upamune
A
license
B
quality
D
maintenance
An MCP server that allows AI assistants to utilize human capabilities by sending requests to humans and receiving their responses through a Streamlit UI.
Updated a year ago (2025-04-05 15:46 UTC)
7
49
MIT
Interactive Feedback MCP
Developer Tools Autonomous Agents
ISimon3
F
license
B
quality
D
maintenance
MCP server that enables human-in-the-loop workflow in AI-assisted development tools by allowing users to provide direct feedback to AI agents without consuming additional premium requests.
Updated a year ago (2025-06-16 02:44 UTC)
1
1
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/humanity4ai/project_human'

If you have feedback or need assistance with the MCP directory API, please join our Discord server