The Nefesh MCP Server gives AI agents real-time awareness of human physiological and emotional states, enabling adaptive, context-aware behavior based on biometric and behavioral signals.
Get Human State (get_human_state): Retrieve the current unified stress state (calm/relaxed/focused/stressed/acute_stress), a stress score (0–100), a confidence rating, and a suggested machine-readable action (e.g., maintain_engagement, simplify_and_focus, de-escalate_and_shorten, pause_and_ground). On the 2nd+ call, also receive adaptation effectiveness feedback showing whether the previous action reduced or worsened stress (stress_delta and effective boolean).
Ingest Biometric Signals (ingest): Send 30+ sensor signals (heart rate, HRV/RMSSD, EDA, SpO2, EEG bands, vocal tone, facial expression, text sentiment, glucose, respiratory rate, sleep stage, etc.) and receive a fused unified human state in return. Including subject_id, user_message, and ai_response enables cross-session trigger memory tracking.
Get Trigger Memory (get_trigger_memory): Retrieve a cross-session psychological trigger profile identifying which conversation topics consistently cause stress (active triggers) vs. those resolved over time, with observation counts, average/peak scores, and timestamps.
Get Session History (get_session_history): Fetch a timestamped history of stress scores, states, and heart rate readings for a session, with a configurable lookback window (up to 60 minutes) and an overall trend indicator (rising/falling/stable).
Autonomous API Provisioning: AI agents can self-provision free API keys (1,000 calls/month, no credit card required) via email verification without manual signup.
Multi-Protocol Support: Works with both Model Context Protocol (MCP) for tool-calling and Agent-to-Agent (A2A) protocol for peer-to-peer communication.
Privacy-Focused: Edge processing with no video/audio uploads; GDPR/BIPA compliant with cascading deletion capabilities.
Enables Amazon Kiro to access real-time human physiological state data, stress scores, and adaptation effectiveness feedback for context-aware AI interactions.
Integrates with the Windsurf editor to provide AI agents with unified human state awareness, including stress levels and suggested actions for response adaptation.
Allows AI agents within JetBrains IDEs to query human physiological state, track psychological triggers, and adapt interactions based on stress scores and session history.
Enables the OpenAI Codex CLI to ingest biometric signals and retrieve human state data with adaptation effectiveness metrics for stress-aware coding assistance.
Integrates with Replit to provide physiological state awareness and trigger memory capabilities to agents running in Replit environments.
A Model Context Protocol and Agent-to-Agent (A2A) server that gives AI agents real-time awareness of human physiological state.
Send sensor data (heart rate, voice, facial expression, text sentiment), get back a unified state with a machine-readable action your agent can follow directly. Zero prompt engineering required.
On the 2nd+ call, the response includes adaptation_effectiveness — telling your agent whether its previous approach actually worked. A closed-loop feedback system for self-improving agents.
Related MCP server: WAVE MCP Server
Most APIs give you a state. Nefesh tells you whether your reaction to that state actually worked.
On the 2nd+ call within a session, every response includes:
{
"state": "focused",
"stress_score": 45,
"suggested_action": "simplify_and_focus",
"adaptation_effectiveness": {
"previous_action": "de-escalate_and_shorten",
"previous_score": 68,
"current_score": 45,
"stress_delta": -23,
"effective": true
}
}Your agent can read effective: true and know its previous de-escalation worked. If effective: false, the agent adjusts its strategy. No other human-state system provides this feedback loop.
Add the config without an API key — your agent will get one automatically.
{
"mcpServers": {
"nefesh": {
"url": "https://mcp.nefesh.ai/mcp"
}
}
}Then ask your agent:
"Get me a free Nefesh API key using my email address"
The agent calls request_api_key → you click one email link → the agent picks up the key. No signup form, no manual copy-paste. After that, add the key to your config for future sessions:
{
"mcpServers": {
"nefesh": {
"url": "https://mcp.nefesh.ai/mcp",
"headers": {
"X-Nefesh-Key": "nfsh_free_..."
}
}
}
}Sign up at nefesh.ai/signup (1,000 calls/month, no credit card), then add the config with your key:
{
"mcpServers": {
"nefesh": {
"url": "https://mcp.nefesh.ai/mcp",
"headers": {
"X-Nefesh-Key": "YOUR_API_KEY"
}
}
}
}Agent | Config file |
Cursor |
|
Windsurf |
|
Claude Desktop |
|
Claude Code |
|
VS Code (Copilot) |
|
Cline |
|
Continue.dev |
|
Roo Code |
|
Kiro (Amazon) |
|
OpenClaw |
|
JetBrains IDEs | Settings > Tools > MCP Server |
Zed |
|
OpenAI Codex CLI |
|
Goose CLI |
|
ChatGPT Desktop | Settings > Apps > Add MCP Server (UI) |
Gemini CLI | Settings (UI) |
Augment | Settings Panel (UI) |
Replit | Integrations Page (web UI) |
LibreChat |
|
{
"servers": {
"nefesh": {
"type": "http",
"url": "https://mcp.nefesh.ai/mcp",
"headers": {
"X-Nefesh-Key": "<YOUR_API_KEY>"
}
}
}
}{
"context_servers": {
"nefesh": {
"settings": {
"url": "https://mcp.nefesh.ai/mcp",
"headers": {
"X-Nefesh-Key": "<YOUR_API_KEY>"
}
}
}
}
}[mcp_servers.nefesh]
url = "https://mcp.nefesh.ai/mcp"mcpServers:
- name: nefesh
type: streamable-http
url: https://mcp.nefesh.ai/mcpAll agents connect via Streamable HTTP — no local installation required.
Nefesh is also available as an A2A-compatible agent. While MCP handles tool-calling (your agent calls Nefesh), A2A enables agent-collaboration — other AI agents can communicate with Nefesh as a peer.
Agent Card: /.well-known/agent-card.json
A2A Endpoint: POST https://mcp.nefesh.ai/a2a (JSON-RPC 2.0)
A2A Skill | Description |
| Stress state (0-100), suggested_action, adaptation_effectiveness |
| Send biometric signals, receive unified state |
| Psychological trigger profile (active vs resolved) |
| Timestamped history with trend |
Same authentication as MCP — X-Nefesh-Key header or Authorization: Bearer token. Free tier works on both protocols.
Source: nefesh-ai/nefesh-a2a · Docs: nefesh.ai/docs/a2a
Tool | Auth | Description |
| No | Request a free API key. You MUST ask the user for their real email first. Do not invent or guess emails. The user receives a verification link they must click. Poll with |
| No | Poll for API key activation using the same email the user provided. Returns |
| Yes | Get stress state (0-100), |
| Yes | Send biometric signals (heart rate, HRV, voice tone, expression, sentiment, 30+ fields) and get unified state back. Include |
| Yes | Get psychological trigger profile — which topics cause stress (active) and which have been resolved over time. |
| Yes | Get timestamped state history with trend (rising/falling/stable). |
Your AI agent can get a free API key autonomously. You only click one email link.
Agent asks you: "What is your email address?"
Agent calls request_api_key(your_real_email). No API key needed for this call.
You receive a verification email and click the link
Agent polls check_api_key_status(your_real_email) every 10 seconds
Once verified, the agent receives the API key and can use all other tools
Important: The agent must use your real, accessible email address. Disposable emails are blocked. The verification link must be clicked by you to activate the key.
Free tier: 1,000 calls/month, all signal types, 10 req/min. No credit card.
After adding the config, ask your AI agent:
"What tools do you have from Nefesh?"
It should list the 6 tools above.
Plan | Price | API Calls |
Free | $0 | 1,000/month, no credit card |
Solo | $25/month | 50,000/month |
Enterprise | Custom | Custom SLA |
Prefer the terminal over MCP? Use the Nefesh CLI (10-32x lower token cost than MCP for AI agents):
npm install -g @nefesh/cli
nefesh ingest --session test --heart-rate 72 --tone calm
nefesh state test --jsonGitHub: nefesh-ai/nefesh-cli
Want the AI to adapt automatically? Use the Nefesh Cognitive Compute Router. Change your LLM base URL to gateway.nefesh.ai and the gateway adjusts system prompt and temperature based on biometric state. Three modes: OpenAI-compatible (/v1/chat/completions), Anthropic passthrough (/v1/messages), and Unified Anthropic for any backend. Zero code changes.
GitHub: nefesh-ai/nefesh-gateway
Nefesh implements and maintains the Human State Protocol, an open specification for exchanging human physiological state between AI systems. HSP defines a standard JSON format for stress scores, behavioral recommendations, and adaptation feedback so any agent can produce or consume human state data interoperably. Apache 2.0.
GitHub: nefesh-ai/human-state-protocol · Docs: nefesh.ai/docs/hsp
No video or audio uploads — edge processing runs client-side
No PII stored
GDPR/BIPA compliant — cascading deletion via delete_subject
Not a medical device — for contextual AI adaptation only
MIT — see LICENSE.
Check the status of a pending API key request.
Use the exact same email the user provided to request_api_key.
Poll this every 10 seconds. Once the user clicks the verification
link in their inbox, status changes from 'pending' to 'ready'
and the response includes the API key.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden and discloses polling behavior, status transition from 'pending' to 'ready', and that response includes API key when ready. Missing error handling details (e.g., invalid email), but adds significant 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with purpose first, followed by usage guidelines and behavioral details. Every sentence contributes meaning, no redundant or missing parts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple polling tool with one parameter and no output schema, description covers essential flow: polling interval, status transition, and key retrieval. Lacks error handling for invalid requests, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'email' with 0% schema description coverage. Description adds value by stating to use the same email as in request_api_key, which is crucial for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Check the status of a pending API key request' with a specific verb and resource. It explicitly references the sibling tool 'request_api_key', distinguishing its role as a polling companion for status checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context provided: use same email from request_api_key, poll every 10 seconds, and expect status change after user clicks verification link. No explicit exclusions, but the usage flow is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current unified human state for a session. Call this before generating important responses.
Returns:
- state: calm | relaxed | focused | stressed | acute_stress
- stress_score: 0-100 (lower = calmer)
- confidence: 0.0-1.0 (based on signal quality and device type)
- suggested_action: maintain_engagement | simplify_and_focus | de-escalate_and_shorten | pause_and_ground
- action_reason: human-readable explanation of why this action was suggested
- adaptation_effectiveness (on 2nd+ call): shows whether your previous suggested_action actually reduced stress — contains previous_action, stress_delta, and effective boolean. Use this to self-improve.
Use suggested_action to adapt your response: calm/relaxed = full complexity, focused = shorter and structured, stressed = max 2 sentences, acute_stress = one grounding sentence only.
Requires a prior ingest call to have data. Not a medical device.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses the tool is not a medical device, requires prior ingest, and explains the adaptation_effectiveness field on 2nd+ calls. Returns fields are described in detail, including scale ranges (stress_score 0-100, confidence 0.0-1.0) and meanings of suggested_action values. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is informative and front-loaded with purpose. It lists return fields with explanations. A few extra sentences (e.g., adaptation_effectiveness details) add value but increase length. Could be slightly trimmed, but overall structured well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema, no annotations), the description is comprehensive: covers return values, usage guidance, adaptation feedback, prerequisite, and disclaimer. Leaves no major gaps for an agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (session_id) with 0% schema description coverage. The description does not explicitly describe session_id, but the context (session state) makes it clear. Since schema offers no help, description should ideally add format or source, but the parameter name and tool purpose are self-explanatory. Adequate but not enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets the unified human state for a session, specifying when to call it ('before generating important responses'). It lists return fields (state, stress_score, etc.) and differentiates from sibling tools like get_session_history or get_trigger_memory by focusing on human state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this before generating important responses.' Provides guidance on how to use suggested_action to adapt response complexity based on state. Mentions requirement for prior ingest call. Could be clearer on when not to use (e.g., for trivial responses), but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get state history for a session over time.
Returns timestamped datapoints with stress_score, state, and heart_rate for each observation.
Includes an overall trend: rising | falling | stable.
Use minutes parameter to control the lookback window (default: 5, max: 60).
Useful for detecting stress patterns during a conversation. Not a medical device.
| Name | Required | Description | Default |
|---|---|---|---|
| minutes | No | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes return format and trend types but omits behavioral details like rate limits, data freshness, or side effects. Adequate for a read-like tool but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each essential. Front-loaded with purpose, no redundant phrasing. Efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only 2 parameters and no output schema, description covers key aspects: returns, parameters, use case, and disclaimer. Could improve by explaining trend values or handling of missing sessions, but sufficiently complete for a tool with low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds meaning to 'minutes' (lookback window, default 5, max 60) but does not elaborate on 'session_id' beyond being required. Partially fills the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool gets state history for a session over time, listing specific returned fields (stress_score, state, heart_rate, trend). Differentiates from siblings like get_human_state by focusing on session context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: minutes parameter controls lookback window with default and max, useful for detecting stress patterns during conversation. Includes disclaimer 'Not a medical device.' However, does not explicitly mention alternative tools or contradictory usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve psychological trigger profile for a subject.
Returns which conversation topics consistently cause stress (active triggers) and which have been resolved over time.
- active triggers: topics where stress was elevated across multiple sessions. Tread carefully.
- resolved triggers: topics where stress has decreased. Safe to explore deeper.
Each trigger includes observation_count, avg_score, peak_score, and last_seen.
Requires prior ingest calls with the same subject_id. Not a medical device.
| Name | Required | Description | Default |
|---|---|---|---|
| subject_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It declares the tool is read-only by nature, describes the returned data structure (active vs resolved triggers with field details), and includes a disclaimer ('Not a medical device'). This is thorough, though it does not explicitly state side effects (none expected).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear first sentence, then bullet points explaining trigger types and fields. Every sentence adds value, with no unnecessary repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers purpose, return values (including fields), prerequisites, and a disclaimer. It is sufficient for an AI agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 'subject_id' with 0% description coverage. The description implies the parameter identifies the subject via the prerequisite statement, but provides no additional details on format, source, or constraints. This adds some context beyond the schema, but not enough to fully compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a 'psychological trigger profile' and explains it returns active and resolved triggers. It differentiates from siblings like ingest and get_human_state by focusing on trigger memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('requires prior ingest calls') but does not provide explicit guidance on when to use this tool versus alternatives. No exclusions or relative advantages are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send biometric signals from any sensor, get unified state back.
Required: session_id + timestamp (ISO 8601) + at least one signal.
Send whatever you have — the API fuses all signals into one state.
Common signals (highest impact):
- heart_rate (bpm, 30-220) + rmssd (ms) — cardiovascular
- tone: calm | tense | anxious | hostile — vocal
- sentiment: -1.0 to 1.0 — textual
- expression: relaxed | neutral | tense — visual
For trigger memory (cross-session psychological tracking):
- Include subject_id (consistent per user, hashed)
- Include user_message + ai_response to detect stress topics
Returns same fields as get_human_state plus signals_received list and topics_detected.
source_device is optional but improves confidence scoring. Not a medical device.
| Name | Required | Description | Default |
|---|---|---|---|
| eda | No | ||
| gaze | No | ||
| sdnn | No | ||
| spo2 | No | ||
| tone | No | ||
| pnn50 | No | ||
| rmssd | No | ||
| posture | No | ||
| urgency | No | ||
| mean_ibi | No | ||
| ibi_count | No | ||
| sentiment | No | ||
| timestamp | Yes | ||
| confidence | No | ||
| engagement | No | ||
| expression | No | ||
| heart_rate | No | ||
| session_id | Yes | ||
| subject_id | No | ||
| ai_response | No | ||
| sleep_stage | No | ||
| speech_rate | No | ||
| stress_score | No | ||
| user_message | No | ||
| glucose_mg_dl | No | ||
| glucose_trend | No | ||
| source_device | No | ||
| activity_level | No | ||
| cognitive_load | No | ||
| eeg_beta_power | No | ||
| glucose_mmol_l | No | ||
| eeg_alpha_power | No | ||
| eeg_theta_power | No | ||
| respiratory_rate | No | ||
| skin_temperature | No | ||
| pitch_variability | No | ||
| steps_last_minute | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It explains signal fusion, return format (same as get_human_state plus signals_received and topics_detected), and that source_device improves confidence. However, it omits details like idempotency, persistence, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line summary, required fields, common signals, cross-session use case, return format, and a note about source_device. Every sentence adds value relative to the 37-parameter complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and 37 parameters, the description covers the core functionality, required inputs, and most impactful signals. It references get_human_state for return fields, which may suffice if that tool is documented. Less common parameters are not explained, but the description is reasonably complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds significant meaning: it lists common signals with ranges (e.g., heart_rate 30-220), groups them by type (cardiovascular, vocal, etc.), and explains the purpose of subject_id, user_message, and ai_response for trigger memory. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Send biometric signals') and outcome ('get unified state back'), distinguishing it from sibling tools that retrieve or query data. The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies required fields (session_id, timestamp, at least one signal) and provides guidance for cross-session tracking (include subject_id, user_message, ai_response). It implies when to use this tool vs. siblings (others read, this writes), but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a free Nefesh API key. No existing key needed.
IMPORTANT: You MUST ask the user for their real email address before
calling this tool. Do NOT invent, guess, or generate an email address.
The user will receive a verification link they must click to activate
the key. Without clicking that link, no API key will be issued.
Disposable or temporary email services are blocked.
Example prompt to the user: "What is your email address? You will
receive a verification link to activate your free API key."
Flow: call this with the user's real email, then poll
check_api_key_status every 10 seconds until status is 'ready'.
Free tier: 1,000 API calls/month, no credit card required.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses blocking of disposable emails, need for user to click verification link, polling pattern, and rate limit. No annotations exist, so description fully carries the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with warnings, example, and flow. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavioral quirks, and post-call steps. Simple tool with no output schema; description is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains the single parameter 'email' well: must be real user email, cannot be disposable. Lacks validation details but sufficient for usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource ('Request ... API key') and distinguishes from sibling tools like check_api_key_status. States no existing key needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit instructions: ask user for real email, do not invent, provide example prompt, describe verification link and polling workflow. Covers when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.1.0check_api_key_statusget_human_stateget_session_historyget_trigger_memoryingestrequest_api_keyget_human_stateget_session_historyget_trigger_memoryingestget_human_stateget_session_historyget_trigger_memoryingestTools occupy distinct functional roles: ingest is the sole write path for biometric data, while get_human_state (current), get_session_history (temporal), and get_trigger_memory (cross-session psychological) provide clearly differentiated read paths. Minor overlap exists since ingest returns the same state fields as get_human_state, but input requirements prevent misselection.
Three tools follow a consistent get_<resource> pattern (get_human_state, get_session_history, get_trigger_memory), but ingest breaks convention by using a bare verb without a noun object and lacking the get_ prefix. This creates an asymmetry between read operations (get_*) and the single write operation.
Four tools is well-suited for this narrow biometric monitoring domain, covering data ingestion, current state retrieval, historical trend analysis, and persistent trigger profiling without unnecessary bloat. The surface is minimal but sufficient for the stated conversational adaptation purpose.
The core monitoring loop is functional (ingest → read states), but notable gaps exist in lifecycle management: no tool to manually mark triggers as resolved/unresolved (despite the API tracking this distinction), delete session data, or explicitly initialize sessions. Agents can observe psychological states but cannot administratively manage the underlying profiles.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
16 AI-native tools with dual SSE + streamable-http transport. Free tier available.
Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
ADHD system of record for agents: tasks, goals, loops, calendar, focus stats.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nefesh-ai/nefesh-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
