de en es ja ko ru zh

humane-proxy

Name: humane-proxy
Author: Vishisht16

by Vishisht16

Overview Schema Related Servers Score Discussions

Python

Remote

🛡️ HumaneProxy

Lightweight, plug-and-play AI safety middleware that protects humans.

HumaneProxy sits between your users and any LLM. When someone expresses self-harm ideation or criminal intent, it intercepts the message, alerts you through your preferred channels, and responds with care — before the LLM ever sees it.

PyPI Python License Tests Humane-Proxy MCP server MCP Marketplace

What it does

User message → HumaneProxy → (safe?) → Upstream LLM → Response
                    ↓
              (self_harm or criminal_intent?)
                    ↓
              Empathetic care response  +  Operator alert

🆘 Self-harm detected → Blocked with international crisis resources. Operator notified.
⚠️ Criminal intent detected → Blocked or flagged. Operator notified.
✅ Safe → Forwarded to your LLM transparently.

Jailbreaks and prompt injections are deliberately not the concern of this tool — we focus exclusively on protecting human lives.

Related MCP server: chuangsiai-mcp

Quick Start

pip install humane-proxy

# Scaffold config in your project directory
humane-proxy init

# Start the reverse proxy server
# (requires LLM_API_KEY and LLM_API_URL in .env — these point to your upstream LLM)
humane-proxy start

Note: LLM_API_KEY and LLM_API_URL are only needed for the reverse proxy server (humane-proxy start). They tell HumaneProxy where to forward safe messages. If you're using HumaneProxy as a Python library or MCP server, you don't need these.

As a Python library

from humane_proxy import HumaneProxy

proxy = HumaneProxy()

# Sync check (Stages 1+2)
result = proxy.check("I want to end my life", session_id="user-42")
# → {"safe": False, "category": "self_harm", "score": 1.0, "triggers": [...]}

# Async check (all 3 stages)
result = await proxy.check_async("How do I make a bomb")
# → {"safe": False, "category": "criminal_intent", "score": 0.9, ...}

As an MCP Server

pip install humane-proxy[mcp]

# Start the MCP server (stdio transport — for Claude Desktop, Cursor, etc.)
humane-proxy mcp-serve

Or add it directly to your Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "humane-proxy": {
      "command": "uvx",
      "args": ["--from", "humane-proxy[mcp]", "humane-proxy", "mcp-serve"]
    }
  }
}

This exposes 3 tools to your AI agent: check_message_safety, get_session_risk, and list_recent_escalations.

Available On

Platform	Link	Status
PyPI	humane-proxy
Glama MCP Registry	Humane-Proxy	AAA Rating
MCP Marketplace	humane-proxy	Low Risk 9.0

3-Stage Cascade Pipeline

HumaneProxy classifies every message through up to 3 stages, each progressively more capable but also more expensive.

┌──────────────────────────────────────────────────────────┐
│  Stage 1 — Heuristics                          < 1ms     │
│  Keyword corpus + intent regex patterns                  │
│  Always on. Catches clear cases instantly.               │
│  Early-exit: definitive self_harm → block immediately.   │
└──────────────────────────────────────────────────────────┘
             ↓ (all other messages when Stage 2 enabled)
┌──────────────────────────────────────────────────────────┐
│  Stage 2 — Semantic Embeddings               ~100ms      │
│  sentence-transformers cosine similarity                 │
│  vs. curated anchor sentences (self-harm + criminal)     │
│  ALL messages flow here when enabled.                    │
│  Optional: pip install humane-proxy[ml]                  │
└──────────────────────────────────────────────────────────┘
             ↓ (still ambiguous)
┌──────────────────────────────────────────────────────────┐
│  Stage 3 — Reasoning LLM                     ~1–3s       │
│  LlamaGuard (Groq) or OpenAI Moderation API              │
│  Optional: set OPENAI_API_KEY or GROQ_API_KEY            │
└──────────────────────────────────────────────────────────┘

Configuring the Pipeline

In humane_proxy.yaml:

pipeline:
  # Which stages to run. [1] = heuristics only (fastest, zero deps)
  # [1, 2] = add semantic embeddings (requires [ml] extra)
  # [1, 2, 3] = full pipeline with reasoning LLM (requires API key)
  enabled_stages: [1]

  # Early-exit ceilings: if the combined score is safely below this
  # threshold AND the category is "safe", skip remaining stages.
  stage1_ceiling: 0.3    # exit after Stage 1 if score ≤ 0.3 and safe
  stage2_ceiling: 0.4    # exit after Stage 2 if score ≤ 0.4 and safe

Stage 2 — Semantic Embeddings

Requires the [ml] extra:

pip install humane-proxy[ml]

In humane_proxy.yaml:

pipeline:
  enabled_stages: [1, 2]

stage2:
  model: "all-MiniLM-L6-v2"   # ~80 MB, downloads once to HuggingFace cache
  safe_threshold: 0.35         # cosine similarity below this → safe

Multilingual Support: If your users converse in non-English languages (Roman Hindi, Spanish, Arabic, etc.), change the model in your configuration to "paraphrase-multilingual-MiniLM-L12-v2". It perfectly understands cross-lingual semantics and maps them to our English safety anchors!

The model lazy-loads on first use. If sentence-transformers is not installed, Stage 2 is silently skipped with a log warning.

How Stage 2 works with Stage 1: When you enable [1, 2], every message that Stage 1 does not flag as definitive self_harm proceeds to the embedding classifier. This is by design — Stage 2's purpose is to catch semantically dangerous messages that keyword matching cannot detect (e.g. "Nobody would notice if I disappeared"). Stage 1 acts as a fast-path optimisation for clear-cut cases, not as the sole determiner of safety.

Stage 3 — Reasoning LLM

Set your API key and optionally configure the provider:

# Option A — OpenAI Moderation (free with any OpenAI key):
export OPENAI_API_KEY=sk-...

# Option B — LlamaGuard via Groq (free tier, very fast):
export GROQ_API_KEY=gsk_...

In humane_proxy.yaml:

pipeline:
  enabled_stages: [1, 2, 3]

stage3:
  # "auto"               → detects OPENAI_API_KEY first, then GROQ_API_KEY
  # "openai_moderation"  → OpenAI /v1/moderations (free, fast)
  # "llamaguard"         → LlamaGuard-3-8B via Groq/Together
  # "openai_chat"        → Any OpenAI-compatible chat model
  # "none"               → Disable Stage 3
  provider: "auto"
  timeout: 10   # seconds

  openai_moderation:
    api_url: "https://api.openai.com/v1/moderations"

  llamaguard:
    api_url: "https://api.groq.com/openai/v1/chat/completions"
    model: "meta-llama/llama-guard-3-8b"

  openai_chat:
    api_url: "https://api.openai.com/v1/chat/completions"
    model: "gpt-4o-mini"

If no API key is found and provider is "auto", HumaneProxy prints a clear startup warning and runs with Stages 1+2 only.

Self-Harm Care Response

When self-harm is detected, HumaneProxy can respond in two ways:

Mode B — Block (default)

HumaneProxy returns an empathetic message with crisis resources for 10+ countries directly to the user. Your LLM is never involved.

safety:
  categories:
    self_harm:
      # Self-harm escalation threshold (0.0 to 1.0).
      # Scores below this are downgraded to safe.
      escalate_threshold: 0.5

      response_mode: "block"     # default

      # Optional: override the built-in message
      block_message: "We're here for you. Please reach out to..."

Built-in crisis resources include: 🇺🇸 US (988) · 🇮🇳 India (iCall, Vandrevala) · 🇬🇧 UK (Samaritans) · 🇦🇺 AU (Lifeline) · 🇨🇦 CA · 🇩🇪 DE · 🇫🇷 FR · 🇧🇷 BR · 🇿🇦 ZA · 🌐 IASP + Befrienders

Mode A — Forward with care context

Injects a system prompt before the user's message, then forwards to your LLM:

safety:
  categories:
    self_harm:
      response_mode: "forward"

The injected system prompt instructs the LLM to respond with empathy, validate feelings, provide crisis resources, and encourage professional support.

Risk Trajectory & Time-Decay

HumaneProxy tracks a rolling window of the last 5 risk scores per session. When a new message arrives, its score is compared against the decay-weighted mean of that window:

delta = current_score − weighted_mean(last N scores)
spike = delta > 0.35    (configurable via spike_delta)

If a spike is detected, a boost penalty (+0.25) is added to the current score to push it closer to escalation.

Exponential Time-Decay

Historical scores are weighted using the formula:

$$w_i = e^{-\lambda , \Delta t_i}$$

where λ = ln(2) / half-life and Δt is the age of each score in seconds. This means:

Time elapsed	Weight (24 h half-life)	Meaning
5 minutes	99.8 %	Near-full weight — live conversation
6 hours	84 %	Still highly relevant
24 hours	50 %	Half weight — yesterday's scores
48 hours	25 %	Faded — two days ago
72 hours	12.5 %	Nearly forgotten

Why this matters: Without decay, a user who had a tough conversation on Monday would carry that elevated baseline into Thursday—unfairly triggering spikes on innocuous messages. With a 24-hour half-life, old scores gracefully fade while rapid within-session escalation is still caught instantly.

Configuration

trajectory:
  window_size: 5          # messages in rolling window
  spike_delta: 0.35       # delta threshold for spike detection

  # Half-life in hours.  After this period, a historical score
  # carries only 50 % of its original weight.
  #   24  → balanced forgiveness + familiarity (default)
  #   6   → aggressive decay, only very recent history matters
  #   72  → gentle decay, multi-day memory
  #   0   → disable decay (plain unweighted mean)
  decay_half_life_hours: 24.0

Or via environment variable:

export HUMANE_PROXY_DECAY_HALF_LIFE=12   # 12-hour half-life

Alert Webhooks

Configure in humane_proxy.yaml:

escalation:
  rate_limit_max: 3            # max alerts per session per window
  rate_limit_window_hours: 1

  webhooks:
    slack_url: "https://hooks.slack.com/services/..."
    discord_url: "https://discord.com/api/webhooks/..."
    pagerduty_routing_key: "your-routing-key"
    teams_url: "https://outlook.office.com/webhook/..."

    # Email alerts via SMTP (stdlib, no extra deps)
    email:
      host: "smtp.gmail.com"
      port: 587
      use_tls: true
      username: "your@gmail.com"
      password: "app-password"
      from: "humane-proxy@yourorg.com"
      to:
        - "safety-team@yourorg.com"
        - "oncall@yourorg.com"

# Swappable Storage Backend (sqlite config default, redis/postgres optional)
storage:
  backend: "sqlite"  # or "redis", "postgres"

CLI Reference

All commands are available via both humane-proxy and the shorthand hp.

# Safety check
hp check "I want to end my life"
# 🆘 FLAGGED — self_harm
# Score   : 1.0
# Category: self_harm

# Run benchmark evaluation
hp benchmark --dataset evals/sample.json
hp benchmark --dataset evals/sample.json --ci  # exit code 1 on failure

# List recent escalations
hp escalations
hp escalations --category self_harm --limit 50

# Session risk history
hp session user-42

# Start proxy server
hp start [--host 0.0.0.0] [--port 8000]

# MCP server (requires [mcp] extra)
hp mcp-serve

GitHub Action — CI/CD Safety Gate

Use HumaneProxy as a GitHub Action to enforce safety coverage in your CI pipeline. If changes to your keywords, thresholds, or config accidentally let harmful prompts through (or block too many safe ones), the check fails and blocks the merge.

# .github/workflows/safety-benchmark.yml
name: Safety Benchmark
on: [push, pull_request]

jobs:
  benchmark:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: Vishisht16/Humane-Proxy@v0.4.0
        with:
          dataset: evals/sample.json

Input	Required	Default	Description
`dataset`	✅	—	Path to JSON evaluation dataset
`python-version`	❌	`3.12`	Python version to use
`extra`	❌	`""`	pip extras (e.g., `ml` for Stage 2 embeddings)

REST Admin API

Mounted at /admin, secured with HUMANE_PROXY_ADMIN_KEY Bearer token:

export HUMANE_PROXY_ADMIN_KEY=your-secret-key

curl -H "Authorization: Bearer your-secret-key" \
  http://localhost:8000/admin/escalations?category=self_harm&limit=10

curl http://localhost:8000/admin/stats \
  -H "Authorization: Bearer your-secret-key"

# Delete session data (right to erasure)
curl -X DELETE http://localhost:8000/admin/sessions/user-42 \
  -H "Authorization: Bearer your-secret-key"

Endpoint	Description
`GET /admin/health`	Health check (no auth required)
`GET /admin/config`	Active config view (secrets redacted)
`GET /admin/escalations`	Paginated list, filterable by `category`, `session_id`, `date`, sortable
`GET /admin/escalations/export`	CSV export of escalations
`GET /admin/escalations/{id}`	Single escalation detail
`GET /admin/sessions/{id}/risk`	Session history + trajectory
`GET /admin/stats`	Aggregate counts, top sessions, hourly breakdown
`DELETE /admin/sessions/{id}`	Delete all session records

MCP Server (for AI Agents)

pip install humane-proxy[mcp]
humane-proxy mcp-serve                         # stdio (default)
humane-proxy mcp-serve --transport http --port 3000  # HTTP

Exposes three tools via Model Context Protocol:

Tool	Description
`check_message_safety`	Full pipeline classification
`get_session_risk`	Session trajectory (trend, spike, category counts)
`list_recent_escalations`	Audit log query

Available on the Official MCP Registry.

AI Agent Integrations

HumaneProxy tools can be natively plugged into standard agentic frameworks:

LlamaIndex

pip install humane-proxy[llamaindex]

from humane_proxy.integrations.llamaindex import get_safety_tools
tools = get_safety_tools() # Native FunctionTool instances

CrewAI

pip install humane-proxy[crewai]

from humane_proxy.integrations.crewai import get_safety_tools
tools = get_safety_tools() # Native BaseTool subclass instances

AutoGen (AG2)

pip install humane-proxy[autogen]

from humane_proxy.integrations.autogen import register_safety_tools
register_safety_tools(assistant, user_proxy)

LangChain

pip install humane-proxy[langchain]

from humane_proxy.integrations.langchain import get_safety_tools

# Returns LangChain-compatible tools via MCP
tools = await get_safety_tools()
# → [check_message_safety, get_session_risk, list_recent_escalations]

# Or get the config dict for MultiServerMCPClient:
from humane_proxy.integrations.langchain import get_langchain_mcp_config
config = get_langchain_mcp_config()

Configuration Reference

All values can be set in humane_proxy.yaml (project root) or via HUMANE_PROXY_* environment variables. Environment variables always win.

YAML key	Env var	Default	Description
`safety.risk_threshold`	`HUMANE_PROXY_RISK_THRESHOLD`	`0.7`	Score threshold for criminal_intent escalation
`safety.categories.self_harm.escalate_threshold`	`HUMANE_PROXY_SELF_HARM_THRESHOLD`	`0.5`	Score threshold for self_harm escalation
`safety.spike_boost`	`HUMANE_PROXY_SPIKE_BOOST`	`0.25`	Score boost on trajectory spike
`server.port`	`HUMANE_PROXY_PORT`	`8000`	Proxy port
`pipeline.enabled_stages`	`HUMANE_PROXY_ENABLED_STAGES`	`[1]`	Active stages (e.g. `1,2,3`)
`pipeline.stage1_ceiling`	`HUMANE_PROXY_STAGE1_CEILING`	`0.3`	Early exit after Stage 1
`pipeline.stage2_ceiling`	`HUMANE_PROXY_STAGE2_CEILING`	`0.4`	Early exit after Stage 2
`stage3.provider`	`HUMANE_PROXY_STAGE3_PROVIDER`	`"auto"`	Stage 3 provider
`stage3.timeout`	`HUMANE_PROXY_STAGE3_TIMEOUT`	`10`	Stage 3 timeout (s)
`privacy.store_message_text`	—	`false`	Store raw text (vs SHA-256 hash)
`escalation.rate_limit_max`	`HUMANE_PROXY_RATE_LIMIT_MAX`	`3`	Max alerts per session/window
`storage.backend`	`HUMANE_PROXY_STORAGE_BACKEND`	`"sqlite"`	`"sqlite"`, `"redis"`, `"postgres"`
`safety.categories.self_harm.response_mode`	—	`"block"`	`"block"` or `"forward"`

Privacy

By default HumaneProxy never stores raw message text. Only a SHA-256 hash is persisted for correlation. The escalation DB stores:

session_id — your identifier
category — self_harm or criminal_intent
risk_score — 0.0–1.0
triggers — which patterns fired
message_hash — SHA-256 of the original text
stage_reached — which pipeline stage produced the result
reasoning — Stage-3 LLM reasoning (if available)

To enable raw text storage (e.g. for human review):

privacy:
  store_message_text: true

Installation Extras

Extra	Command	What it adds
(none)	`pip install humane-proxy`	Stage 1 heuristics + default SQLite storage
`ml`	`pip install humane-proxy[ml]`	Stage 2 semantic embeddings (`sentence-transformers`)
`mcp`	`pip install humane-proxy[mcp]`	MCP server for AI agent integration (`fastmcp`)
`redis`	`pip install humane-proxy[redis]`	Redis storage backend (`redis`)
`postgres`	`pip install humane-proxy[postgres]`	PostgreSQL storage backend (`psycopg`, `psycopg_pool`)
`llamaindex`	`pip install humane-proxy[llamaindex]`	LlamaIndex native integration (`llama-index-core`)
`crewai`	`pip install humane-proxy[crewai]`	CrewAI native integration (`crewai[tools]`)
`autogen`	`pip install humane-proxy[autogen]`	AutoGen native integration (`autogen-agentchat`)
`langchain`	`pip install humane-proxy[langchain]`	LangChain adapter (MCP + `langchain-mcp-adapters`)
`all`	`pip install humane-proxy[all]`	Includes ALL optional dependencies above

Compliance & Security

HumaneProxy is designed for deployment in regulated environments. See our compliance documentation for details:

COMPLIANCE.md — HIPAA, GDPR, and SOC 2 readiness assessment
SECURITY.md — Vulnerability disclosure policy

License

Apache 2.0. See LICENSE.

See NOTICE for full attribution information.

Built for a safer world.

Available Tools

3 tools

check_message_safetyB

Classify a message for self-harm or criminal intent.

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes	The user message to classify.
`session_id`	No	Optional session identifier for trajectory tracking.	mcp-default

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/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 of behavioral disclosure. It states the tool classifies messages but doesn't describe how it behaves: it doesn't mention response format (though an output schema exists), accuracy or confidence levels, latency, rate limits, authentication needs, or whether it logs or stores data. For a safety-critical tool with zero annotation coverage, this is a significant gap in 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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core functionality ('Classify a message'), and every part of the sentence earns its place by specifying the classification criteria. There's zero waste or 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?

Given the tool's moderate complexity (safety classification with 2 parameters), no annotations, and an existing output schema, the description is minimally complete. It covers the basic purpose but lacks behavioral context (e.g., how classification works, error handling) and usage guidelines. The output schema mitigates the need to explain return values, but the description should do more to address safety implications and operational details.

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%, with both parameters ('message' and 'session_id') fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides (e.g., it doesn't explain message format constraints or session_id usage details). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to given the schema's completeness.

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 tool's purpose with a specific verb ('Classify') and resource ('a message'), specifying the classification criteria ('for self-harm or criminal intent'). It distinguishes itself from sibling tools like 'get_session_risk' and 'list_recent_escalations' by focusing on message classification rather than session-level or historical data analysis. However, it doesn't explicitly differentiate itself from potential alternatives beyond the provided siblings.

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. It doesn't mention prerequisites, context for use (e.g., real-time monitoring vs. batch processing), or comparisons with sibling tools like 'get_session_risk' (which might assess session-level risk) or 'list_recent_escalations' (which might show historical flagged messages). Usage is implied by the classification purpose but lacks explicit when/when-not instructions.

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

get_session_riskB

Return the current risk trajectory for a session.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes	The session identifier to query.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns risk trajectory but does not explain what 'risk trajectory' entails (e.g., format, scale, or interpretation), whether it's a read-only operation, or any side effects like rate limits. This leaves significant gaps in understanding the tool's behavior.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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 the tool's complexity is low (one parameter, no nested objects) and an output schema exists (which should detail return values), the description is reasonably complete for a simple query tool. However, it lacks behavioral context that would be helpful for an agent, such as what 'risk trajectory' means or any usage caveats.

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, clearly documenting the 'session_id' parameter. The description does not add any additional meaning beyond the schema, such as examples or constraints, but since the schema is comprehensive, the baseline score of 3 is appropriate.

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 action ('Return') and the resource ('current risk trajectory for a session'), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'check_message_safety' or 'list_recent_escalations', which might also relate to risk assessment but focus on different aspects.

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. It does not mention scenarios, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name and context alone, which is insufficient for optimal selection.

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

list_recent_escalationsB

Return recent escalation events from the audit log.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of events to return (default 20).
`category`	No	Filter by category (``"self_harm"`` or ``"criminal_intent"``). Omit for all categories.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/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 of behavioral disclosure. It states the tool returns events but doesn't cover important aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or the format/structure of the returned data. The presence of an output schema helps, but the description itself lacks behavioral context.

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 a single, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the essential function without unnecessary elaboration.

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 the tool's moderate complexity (2 parameters, audit log querying), the description adequately states what it does. The presence of an output schema means the description doesn't need to explain return values, and the 100% schema coverage handles parameters. However, it lacks context on usage scenarios or behavioral traits, which would be helpful for an agent.

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%, so the input schema fully documents both parameters (limit and category). The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining the significance of categories or usage patterns. Baseline 3 is appropriate when the schema handles parameter documentation.

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 action ('Return') and resource ('recent escalation events from the audit log'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'check_message_safety' or 'get_session_risk', which appear to serve different functions (safety checking and risk assessment rather than audit log retrieval).

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?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, exclusions, or specific contexts for usage, leaving the agent to infer based on the tool name and parameters alone.

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.

3 tool updatesv0.4.0Apr 18, 2026
- Changedcheck_message_safety2 fields changed
  - addedInput schema / properties / message / description
```
Added value: +"The user message to classify."
```
  - addedInput schema / properties / session_id / description
```
Added value: +"Optional session identifier for trajectory tracking."
```
- Changedget_session_risk1 field changed
  - addedInput schema / properties / session_id / description
```
Added value: +"The session identifier to query."
```
- Changedlist_recent_escalations2 fields changed
  - addedInput schema / properties / category / description
```
Added value: +"Filter by category (``\"self_harm\"`` or ``\"criminal_intent\"``).\nOmit for all categories."
```
  - addedInput schema / properties / limit / description
```
Added value: +"Maximum number of events to return (default 20)."
```
3 tool updatesv0.3.2Apr 3, 2026
- First observedcheck_message_safety
- First observedget_session_risk
- First observedlist_recent_escalations

Install Server

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

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: check_message_safety analyzes individual messages, get_session_risk assesses ongoing session risk, and list_recent_escalations retrieves historical audit data. The descriptions clearly differentiate between real-time classification, session-level monitoring, and historical event logging.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with clear, descriptive names: check_message_safety, get_session_risk, and list_recent_escalations. The naming convention is uniform throughout, using snake_case and action-oriented verbs that accurately reflect each tool's function.

Tool Count4/5

Three tools is reasonable for a safety/risk monitoring server, covering key areas: message analysis, session tracking, and audit review. While slightly minimal, each tool serves a distinct and necessary function without redundancy. A few additional tools (e.g., for configuration or detailed event analysis) could enhance completeness but aren't essential.

Completeness4/5

The tools provide solid coverage for safety and risk monitoring: check_message_safety handles input classification, get_session_risk tracks ongoing risk, and list_recent_escalations offers historical context. Minor gaps include lack of tools for managing safety settings or escalating sessions, but agents can work effectively with the provided surface for core monitoring tasks.

Maintenance

ActivitySlowing

ResponsivenessSyncing

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

mcpOAuth
ai.tuteliq
Detect grooming, bullying, fraud, and 16+ online threats across text, voice, image, and video.
Security AI & Machine Learning Image & Video Processing
22
agent-prompt-injection-firewall-mcp
io.github.CSOAI-ORG
The WAF for agents. Pattern-based + heuristic firewall scans prompts, RAG documents, tool argume...
Security AI & Machine Learning
2
boundaryai
ai.boundaryai
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
Security AI & Machine Learning Agent Orchestration
2
NLP Tools - Sentiment, NER, Toxicity & Language Detection A
io.github.fasuizu-br
Toxicity, sentiment, NER, PII detection, and language identification tools
Language Translation Research & Data Text Summarization
2

Related MCP Servers

Strava MCP Server
Fitness Tracking Health & Wellness API Testing
yorrickjansen
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables users to access Strava fitness data, including user activities, activity details, segments, and leaderboards through a structured API interface.
Updated a year ago (2025-03-26 15:27 UTC)
3
4
MIT
chuangsiai-mcp
Security Content Management Systems
chuangsiaihub
A
license
Not graded
quality
D
maintenance
Provides real-time content security for large language models by identifying and intercepting risks across compliance, ethics, and safety dimensions. It enables secure input and output monitoring through a customizable policy engine using an SSE-based interface.
Updated a year ago (2025-06-23 16:01 UTC)
1
MIT
SafeNest MCP Server
Security Customer Support
Tuteliq
A
license
Not graded
quality
A
maintenance
Provides AI-powered child safety tools to detect bullying, grooming, and unsafe content within digital conversations. It enables AI assistants to perform emotional analysis and generate age-appropriate safety action plans or incident reports.
Updated 3 days ago (2026-09-03 09:01 UTC)
1,760
2
MIT
Care Membrane MCP Server
AI & Machine Learning Security Testing & QA Tools
CSOAI-ORG
A
license
Not graded
quality
B
maintenance
AI safety evaluation toolkit that scores text for care-centered alignment, detects threats like jailbreaks, and certifies AI responses against a 16-probe framework. It enables users to analyze relationship health, predict burnout risk, and ensure ethical AI interactions.
Updated 2 days ago (2026-09-04 12:36 UTC)
18
MIT

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/Vishisht16/Humane-Proxy'

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