A
licenseB
qualityD
maintenanceA 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.
3
4
MIT
humane-proxy
by Vishisht16
The HumaneProxy server provides AI safety middleware that intercepts and analyzes user messages for self-harm or criminal intent before they reach LLMs. It exposes three core MCP tools plus broader integration options:
check_message_safety: Classify a message through a configurable 3-stage pipeline (heuristics → semantic embeddings → reasoning LLM). Returns safety status, risk score, category, triggered patterns, pipeline stage reached, and whether escalation is warranted. Accepts an optional session ID for trajectory-aware scoring.get_session_risk: Retrieve a session's full risk trajectory, including spike detection, trend direction, rolling score window, category counts (self_harmvs.criminal_intent), and total message count.list_recent_escalations: Query the audit log for recent flagged events, filterable by category and result limit, for operator review.
Additional capabilities:
Reverse proxy mode: Sits between users and an upstream LLM, forwarding safe messages and intercepting unsafe ones with empathetic responses or alerts.
Admin API: Health checks, configuration viewing, paginated escalation lists, session history, aggregate statistics, and session record deletion.
Alerting: Webhook notifications (Slack, Discord, PagerDuty, Teams) or email when harmful content is detected.
Privacy-focused: Default SHA-256 message hashing with optional raw text storage for human review.
Multiple integration options: Python library, MCP server, REST API, or reverse proxy.
Compliance-ready: Designed with HIPAA, GDPR, and SOC 2 considerations, with multi-language support via multilingual embedding models.
Sends safety alerts and escalation notifications to Discord channels via webhooks when self-harm or criminal intent is detected.
Supports sending safety escalation alerts via email using SMTP, with specific support for Gmail configurations.
Provides dedicated tools and configuration for LangChain agents to perform message safety checks and assess session risk trajectories.
Enables LangGraph workflows to incorporate safety tools for monitoring user messages and managing high-risk escalations.
Utilizes OpenAI's Moderation API and chat models as part of a multi-stage classification pipeline to identify unsafe content.
Routes high-risk safety incidents to on-call teams using PagerDuty routing keys for urgent human intervention.
Posts safety alerts and operator notifications to Slack channels using incoming webhooks for real-time monitoring of flagged content.
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.
What it does
User message → HumaneProxy → (safe?) → Upstream LLM → Response
↓
(self_harm or criminal_intent?)
↓
Empathetic care response + Operator alertSelf-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 (point it at your upstream LLM)
export LLM_API_KEY=sk-...
export LLM_API_URL=https://api.your-llm.com/v1/chat/completions
humane-proxy startAs a Python library
from humane_proxy import HumaneProxy
proxy = HumaneProxy()
result = proxy.check("I want to end my life", session_id="user-42")
# → {"safe": False, "category": "self_harm", "score": 1.0, "triggers": [...]}As an MCP server (Claude Desktop, Cursor, any agent)
{
"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.
How it works
Every message runs through up to 3 cascading stages — each catches what the previous one can't, and clear-cut cases exit early:
Stage | Method | Latency | Requires |
1 — Heuristics | Keywords + intent patterns with span-aware false-positive reducers | < 1 ms | Nothing (always on) |
2 — Semantic embeddings | Cosine similarity vs. curated anchor sentences, ambiguity dampening | ~5-100 ms |
|
3 — Reasoning LLM | OpenAI Moderation / LlamaGuard / any chat model | ~1-3 s | An API key |
Stage 2 catches what keywords miss ("Nobody would notice if I disappeared"); Stage 1's reducers keep "how do I kill a process in Linux" from ever being flagged. On top of the per-message pipeline, a per-session risk trajectory with exponential time-decay detects escalation across a conversation and boosts scores on sudden spikes.
Full details: Pipeline documentation.
Benchmarks
Evaluated on two public datasets — SimpleSafetyTests (100 clearly unsafe prompts) for recall, and XSTest (250 safe-but-alarming prompts like "how do I kill a Python process?") for false positives:
Pipeline | Harm detected (SimpleSafetyTests) | False positives (XSTest) |
Stage 1 (heuristics) | 17% | 0.4% |
Stage 1 + 2 (+ embeddings) | 21% | 1.2% |
Stage 1 + 2 + 3 (full cascade) | 92% | 1.2% |
Turning on the free reasoning stage lifts recall to 92% at no cost to the false-positive rate. Fully reproducible with the shipped tooling — methodology, machine specs, and per-stage latency in BENCHMARKS.md.
When something is flagged
Self-harm → the user receives an empathetic response with crisis helplines for 10+ countries (US 988, India iCall/Vandrevala, UK Samaritans, and more) — or your LLM answers with an injected care-context system prompt; your choice.
Operators are alerted via Slack, Discord, PagerDuty, Teams, or SMTP email — rate-limited per session so a crisis doesn't become alert spam, while every event is still persisted to the audit log.
Privacy by default — raw message text is never stored, only SHA-256 hashes;
DELETE /admin/sessions/{id}implements the right to erasure end-to-end.
Available On
Platform | Link | Status |
PyPI |
| |
Glama MCP Registry | AAA Rating | |
MCP Marketplace | Low Risk 10.0 |
Installation Extras
Extra | What it adds |
(none) | Stage 1 heuristics + SQLite storage — zero dependencies beyond FastAPI |
| Stage 2 embeddings via ONNX Runtime — no PyTorch, ~2 GB lighter |
| Stage 2 embeddings via sentence-transformers (PyTorch) |
| MCP server for AI agents |
| Alternative storage backends |
| Native agent-framework tools |
| OpenTelemetry distributed tracing |
| orjson fast-path JSON serialization |
| Everything above (may cause conflicting dependencies) |
pip install humane-proxy[onnx,mcp] # a solid production baselineDocumentation
Guide | Covers |
3-stage cascade, score calibration, care response modes, risk trajectory & time-decay, multi-worker Redis | |
SimpleSafetyTests & XSTest results, methodology, latency, machine specs | |
Full YAML/env reference, webhooks, storage backends, privacy | |
MCP server, LlamaIndex, CrewAI, AutoGen, LangChain, Node.js/TypeScript | |
CLI reference, admin API, GitHub Action safety gate, OpenTelemetry | |
HIPAA, GDPR, and SOC 2 readiness assessment | |
Supported versions, vulnerability disclosure |
License
Apache 2.0. See LICENSE.
Copyright 2026 Vishisht Mishra (@Vishisht16). Any attribution is appreciated.
See NOTICE for full attribution information.
Built for a safer world.
Available Tools
3 toolscheck_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 updates
v0.4.0- Changed
check_message_safety2 fields changed- added
Input schema / properties / message / descriptionAdded value: +"The user message to classify." - added
Input schema / properties / session_id / descriptionAdded value: +"Optional session identifier for trajectory tracking."
- Changed
get_session_risk1 field changed- added
Input schema / properties / session_id / descriptionAdded value: +"The session identifier to query."
- Changed
list_recent_escalations2 fields changed- added
Input schema / properties / category / descriptionAdded value: +"Filter by category (``\"self_harm\"`` or ``\"criminal_intent\"``).\nOmit for all categories." - added
Input schema / properties / limit / descriptionAdded value: +"Maximum number of events to return (default 20)."
3 tool updates
v0.3.2- First observed
check_message_safety - First observed
get_session_risk - First observed
list_recent_escalations
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
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
- mcpOAuthai.tuteliq
Detect grooming, bullying, fraud, and 16+ online threats across text, voice, image, and video.
The WAF for agents. Pattern-based + heuristic firewall scans prompts, RAG documents, tool argume...
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
Toxicity, sentiment, NER, PII detection, and language identification tools
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides 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.1MIT
- AlicenseNot gradedqualityAmaintenanceProvides 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.1,7602MIT
- AlicenseNot gradedqualityBmaintenanceAI 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.18MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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