Un servidor de Model Context Protocol y Agent-to-Agent (A2A) que proporciona a los agentes de IA conciencia en tiempo real del estado fisiológico humano.
Envía datos de sensores (frecuencia cardíaca, voz, expresión facial, sentimiento del texto) y recibe un estado unificado con una acción legible por máquina que tu agente puede seguir directamente. No requiere ingeniería de prompts.
En la segunda llamada en adelante, la respuesta incluye adaptation_effectiveness, indicando a tu agente si su enfoque anterior realmente funcionó. Un sistema de retroalimentación de bucle cerrado para agentes que mejoran por sí mismos.
Related MCP server: WAVE MCP Server
La mayoría de las API te dan un estado. Nefesh te dice si tu reacción a ese estado realmente funcionó.
En la segunda llamada dentro de una sesión, cada respuesta incluye:
{
"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
}
}Tu agente puede leer effective: true y saber que su desescalada anterior funcionó. Si effective: false, el agente ajusta su estrategia. Ningún otro sistema de estado humano proporciona este bucle de retroalimentación.
Añade la configuración sin una clave API; tu agente obtendrá una automáticamente.
{
"mcpServers": {
"nefesh": {
"url": "https://mcp.nefesh.ai/mcp"
}
}
}Luego pregúntale a tu agente:
"Obtén una clave API de Nefesh gratuita usando mi dirección de correo electrónico"
El agente llama a request_api_key → haces clic en un enlace de correo electrónico → el agente obtiene la clave. Sin formularios de registro, sin copiar y pegar manualmente. Después de eso, añade la clave a tu configuración para futuras sesiones:
{
"mcpServers": {
"nefesh": {
"url": "https://mcp.nefesh.ai/mcp",
"headers": {
"X-Nefesh-Key": "nfsh_free_..."
}
}
}
}Regístrate en nefesh.ai/signup (1,000 llamadas/mes, sin tarjeta de crédito), luego añade la configuración con tu clave:
{
"mcpServers": {
"nefesh": {
"url": "https://mcp.nefesh.ai/mcp",
"headers": {
"X-Nefesh-Key": "YOUR_API_KEY"
}
}
}
}Agente | Archivo de configuración |
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/mcpTodos los agentes se conectan a través de Streamable HTTP — no se requiere instalación local.
Nefesh también está disponible como un agente compatible con A2A. Mientras que MCP maneja la llamada a herramientas (tu agente llama a Nefesh), A2A permite la colaboración entre agentes: otros agentes de IA pueden comunicarse con Nefesh como un par.
Tarjeta de agente: /.well-known/agent-card.json
Endpoint A2A: POST https://mcp.nefesh.ai/a2a (JSON-RPC 2.0)
Habilidad A2A | Descripción |
| Estado de estrés (0-100), suggested_action, adaptation_effectiveness |
| Enviar señales biométricas, recibir estado unificado |
| Perfil de disparadores psicológicos (activo vs resuelto) |
| Historial con marca de tiempo y tendencia |
La misma autenticación que MCP — encabezado X-Nefesh-Key o token Authorization: Bearer. El nivel gratuito funciona en ambos protocolos.
Fuente: nefesh-ai/nefesh-a2a · Docs: nefesh.ai/docs/a2a
Herramienta | Autenticación | Descripción |
| No | Solicita una clave API gratuita. DEBES pedir primero al usuario su correo electrónico real. No inventes ni adivines correos. El usuario recibe un enlace de verificación en el que debe hacer clic. Consulta con |
| No | Consulta la activación de la clave API usando el mismo correo que proporcionó el usuario. Devuelve |
| Sí | Obtén el estado de estrés (0-100), |
| Sí | Envía señales biométricas (frecuencia cardíaca, VFC, tono de voz, expresión, sentimiento, más de 30 campos) y recibe el estado unificado. Incluye |
| Sí | Obtén el perfil de disparadores psicológicos — qué temas causan estrés (activo) y cuáles se han resuelto con el tiempo. |
| Sí | Obtén el historial de estados con marca de tiempo y tendencia (subiendo/bajando/estable). |
Tu agente de IA puede obtener una clave API gratuita de forma autónoma. Solo haces clic en un enlace de correo electrónico.
El agente te pregunta: "¿Cuál es tu dirección de correo electrónico?"
El agente llama a request_api_key(tu_correo_real). No se necesita clave API para esta llamada.
Recibes un correo de verificación y haces clic en el enlace.
El agente consulta check_api_key_status(tu_correo_real) cada 10 segundos.
Una vez verificado, el agente recibe la clave API y puede usar todas las demás herramientas.
Importante: El agente debe usar tu dirección de correo electrónico real y accesible. Los correos desechables están bloqueados. El enlace de verificación debe ser clicado por ti para activar la clave.
Nivel gratuito: 1,000 llamadas/mes, todos los tipos de señales, 10 req/min. Sin tarjeta de crédito.
Después de añadir la configuración, pregúntale a tu agente de IA:
"¿Qué herramientas tienes de Nefesh?"
Debería listar las 6 herramientas anteriores.
Plan | Precio | Llamadas API |
Gratuito | $0 | 1,000/mes, sin tarjeta de crédito |
Solo | $25/mes | 50,000/mes |
Enterprise | Personalizado | SLA personalizado |
¿Prefieres la terminal sobre MCP? Usa la CLI de Nefesh (costo de tokens 10-32 veces menor que MCP para agentes de IA):
npm install -g @nefesh/cli
nefesh ingest --session test --heart-rate 72 --tone calm
nefesh state test --jsonGitHub: nefesh-ai/nefesh-cli
¿Quieres que la IA se adapte automáticamente? Usa el Nefesh Cognitive Compute Router. Cambia tu URL base de LLM a gateway.nefesh.ai y el gateway ajustará el prompt del sistema y la temperatura según el estado biométrico. Tres modos: compatible con OpenAI (/v1/chat/completions), paso a través de Anthropic (/v1/messages) y Anthropic unificado para cualquier backend. Cero cambios de código.
GitHub: nefesh-ai/nefesh-gateway
Nefesh implementa y mantiene el Human State Protocol, una especificación abierta para intercambiar el estado fisiológico humano entre sistemas de IA. HSP define un formato JSON estándar para puntuaciones de estrés, recomendaciones de comportamiento y retroalimentación de adaptación para que cualquier agente pueda producir o consumir datos de estado humano de forma interoperable. Apache 2.0.
GitHub: nefesh-ai/human-state-protocol · Docs: nefesh.ai/docs/hsp
Sin subidas de video o audio — el procesamiento de borde se ejecuta en el lado del cliente
No se almacena PII
Cumple con GDPR/BIPA — eliminación en cascada mediante delete_subject
No es un dispositivo médico — solo para adaptación contextual de IA
MIT — ver 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 provided, the description carries the full burden. It discloses return fields, the precondition of prior ingest, adaptive usage of suggested_action, that adaptation_effectiveness appears on 2nd+ call, and a 'not a medical device' disclaimer. This is comprehensive transparency.
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-sentence purpose, a clear list of return fields, adaptation guidance, and a prerequisite/disclaimer. It is information-dense without being bloated.
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 no output schema, the description fully documents the return structure and semantics, usage guidance, and prerequisites. It is remarkably 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?
The only parameter session_id is barely explained beyond the schema title. The description says 'for a session' and implies ingest must have happened, but doesn't define its format, origin, or how it relates to ingest. With schema description coverage at 0%, this is a significant 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?
The description clearly states a specific action: 'Get current unified human state for a session.' It also specifies when to use it ('Call this before generating important responses'), which distinguishes it from siblings like ingest or get_session_history.
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?
It provides explicit context: call before important responses, and requires a prior ingest call. However, it does not mention alternatives or when not to use, so it's not a full 5.
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?
With no annotations provided, the description carries the burden and does well: it discloses return fields (stress_score, state, heart_rate), the trend format (rising | falling | stable), the minutes parameter's range, and a disclaimer. It doesn't mention side effects or permissions, but as a 'get' operation this is minor. Adds value beyond the schema's scope.
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 efficiently packed: purpose, return data, trend, parameter control, use case, and disclaimer—all in a few sentences. No fluff, and key information is front-loaded.
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?
Even without annotations or an output schema, the description provides a comprehensive picture: what it does, what it returns (including field names and trend values), how to control the lookback window, and its intended use case. It's complete for a relatively simple read tool.
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 description explains the minutes parameter with its default (5) and adds a max (60) not present in the schema, which is helpful. However, session_id is only implied ('for a session') and not explicitly defined, though it's a required identifier. With 0% schema description coverage, the description partially compensates but could be more explicit.
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 a specific verb and resource: 'Get state history for a session over time.' It distinguishes from siblings like get_human_state (likely current state) and get_trigger_memory by focusing on historical timestamped data with a trend.
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?
It provides a clear use case: 'Useful for detecting stress patterns during a conversation.' It doesn't explicitly name alternatives, but the 'over time' and 'trend' language strongly implies a historical analysis tool compared to likely current-state siblings. A brief statement about when not to use it would push this to a 5.
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?
With no annotations provided, the description carries the burden. It discloses that the tool returns behavioral profiles (active vs resolved), the fields included, and the prerequisite of prior ingest calls. It also adds a safety disclaimer ('Not a medical device'). It does not mention side effects, but 'Retrieve' implies read-only.
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 moderately long but well-structured with bullet points and clear labels. It covers purpose, output details, and prerequisites without excessive verbosity. Slightly more concise could be better, but the structure aids readability.
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 one parameter and no output schema, the description compensates well by detailing what is returned (active vs resolved triggers, observation_count, avg_score, peak_score, last_seen). It also notes the ingest prerequisite. It is reasonably complete for a simple retrieval tool.
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 provides only the parameter name (subject_id) with 0% description coverage. The description adds that prior ingest calls must use the same subject_id, giving some context. However, it does not explain what the subject_id represents or where to obtain it, leaving partial ambiguity.
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 uses a specific verb ('Retrieve') and identifies the exact resource ('psychological trigger profile'). It clearly differentiates from siblings by focusing on trigger memory, not general session history or human state. The active/resolved distinction adds precision.
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 provides clear context: it requires prior ingest calls with the same subject_id, implying use after ingest. It also warns to tread carefully with active triggers. However, it does not explicitly mention alternatives or when not to use this tool.
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.
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_memoryingestScored across 6 tools
Each tool has a clear distinct role: ingest submits data, get_human_state reads current state, get_trigger_memory and get_session_history cover long-term and recent context, and the two API key tools handle onboarding. Even where get_human_state and ingest both return state-like data, their write/read purposes are explicitly separated by the descriptions.
Most tools follow a verb_noun snake_case pattern (get_human_state, get_trigger_memory, get_session_history, request_api_key, check_api_key_status). The one outlier is 'ingest', which is a bare verb rather than verb_noun, but it is still lowercase and style-consistent. This is a minor deviation rather than a mixed-convention problem.
Six tools is a well-scoped count for a specialized server. Two focus on API key access and four cover the core state/ingest/history/memory workflows, with no redundant helpers or unnecessary bulk. The count feels right for both the domain and the agents that would consume it.
The core workflow is covered: send signals, check current human state, pull session history, and retrieve trigger memory. The primary gaps are not fatal—there is no way to enumerate known sessions/subjects or revoke an API key—but those are auxiliary management features rather than dead ends in the primary state-tracking workflow.
16 AI-native tools with dual SSE + streamable-http transport. Free tier available.
ADHD system of record for agents: tasks, goals, loops, calendar, focus stats.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
