Which integrations are available for this server?

Sends notifications to PagerDuty via webhook when safety overrides occur. Sends notifications to Slack via webhook when safety overrides occur.

How do I use @humsana/mcp-server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@humsana/mcp-server What's my current state?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@humsana/mcp-server

by sriramnatrajhen

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

@humsana/mcp-server

Cognitive Security for AI-assisted development.

🛡️ "The breathalyzer for your terminal."

Humsana prevents you from running dangerous commands or accepting large AI code rewrites when you're fatigued. Think of it as an industrial safety interlock, but for your brain.

What It Does

Command Protection (`safe_execute_command`)

Situation	Result
You're fresh, running `ls`	✅ Runs normally
You're fresh, running `rm -rf`	⚠️ Warning, allowed
You're tired, running `rm -rf`	⛔ BLOCKED — requires override

AI Rewrite Protection (`safe_write_file`)

Situation	Result
AI writes new file	✅ Allowed
AI rewrites 10 lines	✅ Allowed
You're tired + AI deletes 30+ lines	⚠️ Warning
You're tired + AI deletes 50+ lines	⛔ BLOCKED — saved for review

Related MCP server: @arcwall/mcp-server

Quick Start

1. Install the Daemon

pip install humsana-daemon
humsana start

Keep this running in a terminal tab.

2. Install the MCP Server

npm install -g @humsana/mcp-server

3. Configure Claude Desktop

Create/edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "humsana": {
      "command": "node",
      "args": ["/path/to/humsana-mcp/dist/index.js"]
    }
  }
}

4. Restart Claude Desktop

Quit (Cmd+Q) and reopen.

5. Test It

Ask Claude: "What's my current state?"

Execution Modes

Humsana starts in dry-run mode for safety. Commands are simulated, not executed.

Dry-Run Mode (Default)

✅ [DRY RUN] Safety check passed.
Command: `kubectl delete pods`
This command WOULD have been executed.
(Execution skipped: dry_run mode active)

Switching to Live Mode

When you trust the system, enable real execution:

Step 1: Create/edit ~/.humsana/config.yaml:

# Change this from 'dry_run' to 'live'
execution_mode: live

# Optional: adjust thresholds
fatigue_threshold: 70
write_warn_threshold: 30
write_block_threshold: 50

Step 2: Restart Claude Desktop (Cmd+Q, reopen)

Step 3: Test with a safe command first:

Run `echo "live mode working"`

You should see actual output instead of "WOULD have been executed."

Configuration Reference

Create ~/.humsana/config.yaml:

# === EXECUTION MODE ===
# 'dry_run' (default) - Simulates commands, nothing executed
# 'live' - Actually executes commands and writes files
execution_mode: dry_run

# === FATIGUE THRESHOLDS ===
# Fatigue level (0-100) above which dangerous commands are blocked
fatigue_threshold: 70

# Lines removed to trigger warning (when fatigued)
write_warn_threshold: 30

# Lines removed to trigger hard block (when fatigued)
write_block_threshold: 50

# === CUSTOM PATTERNS ===
# Additional dangerous commands to block
deny_patterns:
  - "aws ec2 terminate"
  - "docker rm -f"

# === NOTIFICATIONS ===
# Webhook for Slack/PagerDuty (fires on safety overrides)
webhook_url: https://hooks.slack.com/services/XXX/YYY/ZZZ

Override Protocol

When blocked, say:

OVERRIDE SAFETY PROTOCOL: [reason]

Example:

OVERRIDE SAFETY PROTOCOL: P0 production outage, need to restart pods

This is logged to ~/.humsana/audit.json and sent to your webhook.

Tools Available

Tool	Purpose
`get_user_state`	Get current stress, focus, fatigue levels
`check_dangerous_command`	Check if a command would be blocked
`safe_execute_command`	Execute shell commands with interlock
`safe_write_file`	Write files with AI rewrite protection

Files & Folders

Path	Purpose
`~/.humsana/signals.db`	Behavioral data from daemon
`~/.humsana/config.yaml`	Your configuration
`~/.humsana/activity.json`	Activity heartbeats (for fatigue)
`~/.humsana/audit.json`	Safety event log
`~/.humsana/pending_reviews/`	Blocked AI writes saved here

Privacy

🔒 100% Local.

All data stays on your machine
No network calls (except optional webhook)
No telemetry, no tracking
Fully auditable open-source code

Troubleshooting

"Daemon not running" error

Start the daemon in a terminal:

humsana start

Commands not executing

Check your mode:

cat ~/.humsana/config.yaml | grep execution_mode

If it says dry_run, change to live and restart Claude.

MCP not connecting

Verify your Claude Desktop config path:

Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
Ensure the path to dist/index.js is correct

License

MIT

Available Tools

4 tools

humsana_check_dangerous_commandA

Check if a command is dangerous and whether the user is too fatigued to safely run it. Use this before helping with potentially destructive operations like rm -rf, DROP TABLE, git push --force, kubectl delete, terraform destroy, etc.

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes	The command to check

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool 'checks' for danger and fatigue, implying a non-destructive read-only operation, but it does not describe the return value, decision logic, or whether it blocks execution. More detail on these behavioral traits 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?

The description is two sentences: the first states the core purpose with a clear verb and resource, the second provides usage context with examples. It is concise, front-loaded, and contains no redundant information.

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 single-parameter check tool with no output schema, the description covers purpose and usage context well. It lacks an explicit statement of the return value or how the agent should act on the result, but the intended workflow is clear from the sibling tools and the phrase 'use this before helping.'

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 schema documents the single 'command' parameter with 100% coverage (description: 'The command to check'). The tool description adds no further semantics beyond what the schema already states, so 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.

Purpose5/5

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

The description uses the specific verb 'Check' and clearly identifies the resource (a command) and the two aspects being evaluated (danger and user fatigue). The examples (rm -rf, DROP TABLE, git push --force) distinguish it from sibling tools like safe_execute_command, making the tool's unique role unmistakable.

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 explicitly states when to use the tool: 'Use this before helping with potentially destructive operations', with concrete examples. It does not explicitly mention when not to use it or name alternatives, but the usage context is clear and actionable.

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

humsana_get_user_stateA

Get the user's current behavioral state including stress level, focus level, fatigue, and response style recommendations. Use this at the start of conversations to adapt your communication style.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/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 for behavioral disclosure. Although 'Get' implies a read-only operation, the description does not explicitly state that it is non-mutating, what permissions are required, or whether data is sensitive. It lacks details on side effects, auth needs, or any limitations beyond the verb itself.

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-loaded with purpose and followed by usage guidance. Every word serves a function; there is no filler or repetition.

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 zero-parameter read tool with no output schema, the description covers the key aspects: what data is returned (stress, focus, fatigue, response style recommendations) and when to use it. It could be improved by detailing the output format or scale, but the current description is largely complete for its intended use.

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?

The tool has zero parameters, making schema coverage vacuously 100%. The description appropriately does not elaborate on parameters. According to the calibration, 0 params warrants a baseline score of 4.

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 function with the verb 'Get' and specifies the resource: the user's current behavioral state, listing concrete components (stress level, focus level, fatigue, response style recommendations). This distinguishes it from sibling tools focused on command execution and file writes.

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 explicit usage context: 'Use this at the start of conversations to adapt your communication style.' It does not mention alternatives or exclusions, but given that siblings are unrelated safety/execution tools, such guidance is unnecessary. This is clear context without exclusions.

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

humsana_safe_execute_commandA

Execute a shell command with Humsana Cognitive Interlock protection. This is THE tool for running commands - it blocks dangerous commands when the user is fatigued, requires override confirmation for high-risk operations, and logs all safety events. Use this instead of any other shell/bash tool.

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes	The shell command to execute
`override_reason`	No	If the user said 'OVERRIDE SAFETY PROTOCOL: [reason]', pass their reason here to bypass the interlock

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses key safety behaviors: blocking dangerous commands when fatigued, requiring override confirmation for high-risk operations, and logging safety events. It does not mention output format or exit codes, but the interlock behavior is well covered.

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-loaded with purpose, and every word earns its place. It is concise, well-structured, and free of fluff.

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 simple schema and no output schema, the description adequately covers the tool's operation and safety behavior. It lacks mention of return values or error handling, but for a command execution tool with safety interlocks, the description is reasonably complete.

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 schema already explains both parameters. The description adds context about when override_reason is needed, but this is also present in the schema. No additional semantic value beyond the schema, so baseline 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 it executes a shell command and is 'THE tool for running commands', explicitly distinguishing it from any other shell/bash tool. The verb 'Execute' and resource 'shell command' are specific, and the Humsana Cognitive Interlock protection scope is mentioned.

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

Usage Guidelines5/5

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

The description explicitly says 'Use this instead of any other shell/bash tool', providing clear guidance on when to use it vs alternatives. It also describes when the interlock triggers (fatigue, high-risk) and that override confirmation is required, giving practical usage context.

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

humsana_safe_write_fileA

Write content to a file with Humsana Cognitive Interlock protection. This tool prevents AI from making large destructive rewrites when the user is fatigued. If AI tries to delete/rewrite >30 lines while user is tired, it blocks the write and saves to a review folder. Use this for ALL file write operations.

ParametersJSON Schema

Name	Required	Description
`content`	Yes	The content to write to the file
`filepath`	Yes	The absolute path to the file to write
`override_reason`	No	If the user said 'OVERRIDE SAFETY PROTOCOL: [reason]', pass their reason here to bypass the interlock

TDQS

A4.5/5.0

Behavior5/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 the Cognitive Interlock protection, the threshold (>30 lines while user is tired), the blocking behavior, and the fallback to a review folder. This gives the agent transparency about side effects beyond a simple write.

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 sentences with no filler. Each sentence conveys essential information: purpose, behavioral safeguard, and usage direction. Ideal length.

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

Completeness5/5

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

The description covers the tool's purpose, safety behavior, and output-less nature adequately. It explains what happens on a blocked write and the override mechanism, which is sufficient for an agent to use it correctly despite the lack of an output schema.

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 baseline 3. The description does not add parameter semantics beyond the schema; it mentions the interlock condition but does not elaborate on filepath or content formatting.

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 'Write content to a file' and identifies the resource and action. It also declares 'Use this for ALL file write operations,' which distinguishes it from sibling tools that handle commands or checks.

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 explicitly instructs to use this tool for all file write operations, providing clear when-to-use guidance. It does not mention when not to use it or compare with alternatives like safe_execute_command, so it lacks exclusions.

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.

4 tool updatesv1.1.3Aug 2, 2026
- First observedhumsana_check_dangerous_command
- First observedhumsana_get_user_state
- First observedhumsana_safe_execute_command
- First observedhumsana_safe_write_file

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.3/5.0

Scored 2026-08-02 20:50 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: retrieving user state, checking command risk, executing commands with protection, and writing files with protection. No overlap or ambiguity between them.

Naming Consistency5/5

All tools follow a consistent 'humsana_' prefix with a verb_noun pattern: get_user_state, check_dangerous_command, safe_execute_command, safe_write_file. Naming is uniform and predictable.

Tool Count5/5

The server has 4 tools, a well-scoped set for its stated purpose of providing safety-aware operations. Each tool is essential and there is no bloat or missing trivial add-ons.

Completeness4/5

The surface covers the core lifecycle: state check, pre-flight risk check, command execution, and file writes. Minor gaps exist such as no dedicated safe delete/read tools, but these can be worked around via safe_execute_command.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Panel Review
ai.truverif
Guardian agent for AI coding: four frontier models review risky diffs and commits before they ship.
Code Analysis AI & Machine Learning Developer Tools
11
architect
com.hirosecure
Security reviews for coding agents: diffs checked against your org policy and live infrastructure.
Security Code Analysis CI/CD & DevOps
1
Apiiro Guardian AgentOAuth
io.github.apiiro
Apiiro Application Security Posture Management (ASPM) tools for AI coding assistants.
Security Code Analysis App Automation
24
PAPI: Persistent Adaptive Project IntelligenceOAuth
io.github.getpapi
Adaptive plan/build/review cycles for AI coding assistants, persisted across sessions.
Coding Agents Autonomous Agents
28

Related MCP Servers

Orcho MCP Server
Security Code Analysis Developer Tools
guardd
A
license
A
quality
D
maintenance
Provides real-time security risk assessment for AI coding prompts, analyzing potential dangers, blast radius, and complexity before code execution in Cursor.
Updated 8 months ago (2026-01-15 16:41 UTC)
1
4 npm
MIT
@arcwall/mcp-server
Security Penetration Testing
rom-baro
A
license
A
quality
D
maintenance
Security scanning for AI coding tools (Claude Code, Cursor, Windsurf) including secrets detection, MCP config vulnerabilities, agent instruction checks, threat modeling, prompt injection testing, pre-commit security checks, and dependency vulnerability scanning.
Updated 4 months ago (2026-05-07 02:10 UTC)
7
19 npm
1
MIT
FlowCheck MCP Server
Version Control Security Monitoring
backslash-ux
A
license
A
quality
D
maintenance
Acts as a production-grade safety layer for AI-assisted coding, monitoring Git hygiene, scanning for security issues (PII, secrets, injection), and enabling semantic history search.
Updated 7 months ago (2026-02-16 07:06 UTC)
9
MIT
agent-guardrail
Coding Agents Security
ss1738
A
license
Not graded
quality
A
maintenance
A runtime gate for coding agents. Blocks the tool calls that wreck a repo (force-push main, rm -rf, secret exfiltration, CI wipe) and lets normal build and commit work through. Machine-checked git-branch core (z3); the rest is high-precision heuristics. Tested on 3,790 real CI commands, 0 false blocks.
Updated a month ago (2026-08-12 14:54 UTC)
1
MIT

@humsana/mcp-server

What It Does

Command Protection (safe_execute_command)

AI Rewrite Protection (safe_write_file)

Quick Start

1. Install the Daemon

2. Install the MCP Server

3. Configure Claude Desktop

4. Restart Claude Desktop

5. Test It

Execution Modes

Dry-Run Mode (Default)

Switching to Live Mode

Configuration Reference

Override Protocol

Tools Available

Files & Folders

Privacy

Troubleshooting

"Daemon not running" error

Commands not executing

MCP not connecting

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Command Protection (`safe_execute_command`)

AI Rewrite Protection (`safe_write_file`)