Fuses biometric signals into a stress score (0-100) for AI adaptation. MCP + A2A native.
Scored across 7 tools
Each tool has a distinct role: two are sequential auth steps, one ingests signals, three retrieve different slices of state (current, historical, cross-session triggers), and one deletes subject data. The only apparent overlap is that ingest also returns state fields, but its required signal inputs clearly separate it from get_human_state.
Almost all names follow a snake_case verb_noun or verb_noun_noun pattern (get_human_state, get_session_history, get_trigger_memory, delete_subject, request_api_key, check_api_key_status). The lone single-verb name 'ingest' is a minor deviation from that pattern but remains clear.
Seven tools is well-scoped for this domain, covering auth, signal ingestion, current state, session history, trigger memory, and subject deletion without obvious bloat. Each tool earns its place and the set stays lightweight.
The surface covers the core lifecycle: authorize, ingest signals, read current state, inspect history, review cross-session triggers, and delete a subject. Minor gaps include no session-level deletion or subject listing, but agents can likely work around these for the stated purpose.
Check a pending API key authorization using its request_id.
Use request_id exactly as returned by request_api_key, never an email.
Poll every 10 seconds. awaiting_user means the user must open the URL;
pending means email verification is still required. ready returns the
API key once only. Store it and include it in all subsequent HTTP calls.
Stop on expired; ask the user before starting another authorization.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It describes states, polling cadence, one-time key return ('returns the API key once only'), what to do with it, and stop conditions. This is rich behavioral disclosure far beyond what the minimal schema provides.
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?
Short, front-loaded with the core action and critical parameter guidance, then sequential instructions. No wasted words; every sentence conveys necessary information.
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 no output schema, no annotations, and a single parameter, the description fully covers how to poll, interpret states, handle the returned key, and stop. Nothing essential is missing for correct invocation.
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% and there is only one parameter, so description must explain request_id. It explicitly states 'Use request_id exactly as returned by request_api_key, never an email,' which is critical usage detail not in the schema (which merely says string).
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?
States a specific verb ('Check') and resource ('pending API key authorization') and clearly distinguishes from the sibling request_api_key by indicating this is for an existing request_id, not generating a new one.
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 polling interval (every 10 seconds), what to do in each state (awaiting_user, pending, ready, expired), and the stop condition with user consent needed before re-authorization. Leaves no ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete all sessions and trigger memory for a subject.
Irreversible. Only call when the user explicitly requests this deletion.
| Name | Required | Description | Default |
|---|---|---|---|
| subject_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so safety is covered structurally; the description adds value by making the destruction scope concrete (sessions AND trigger memory) and emphasizing 'Irreversible' and 'Permanently', which are stronger claims than the generic destructive hint.
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?
Two short sentences, front-loaded with the operation and its irreversibility; no filler or 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?
For a destructive one-parameter tool with annotations covering safety and no output schema, the description supplies the essential scope and irreversibility warnings. It omits edge-case behavior (e.g., deleting a nonexistent subject) and auth requirements, keeping it from a 5.
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% for the single subject_id parameter, and the description does not explain what a subject_id is, where to obtain it, or its format. The name is largely self-evident, so this is not fatal, but the description adds no semantic detail beyond the schema.
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?
States a specific verb (delete) plus the exact scope of the resource destroyed (all sessions and trigger memory for a subject), which an agent cannot confuse with the read-only siblings get_session_history or get_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?
'Only call when the user explicitly requests this deletion' gives an explicit precondition, which is the key gating rule for a destructive tool. It does not name an alternative tool or describe what to do otherwise, so it falls just short of a 5.
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, the description carries the full burden and does well: it enumerates the returned datapoint fields (stress_score, state, heart_rate), the trend values (rising|falling|stable), the lookback default/max, and a 'Not a medical device' limitation. It omits auth/privacy requirements, which is the main remaining gap for a health-data tool.
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?
Front-loaded with the purpose, then return shape, then parameter guidance, then a caveat. Every sentence carries information; the 'Not a medical device' line is a legitimate disclaimer rather than filler. Slightly more verbose than strictly needed but not padded.
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?
No output schema exists, and the description compensates by naming the returned fields and trend values, so an agent knows what to expect. Combined with parameter guidance, nothing critical is missing for correct invocation, though the sibling distinction and any auth constraints remain unstated.
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%, so the description must compensate. It adds real meaning for minutes (lookback window, default 5, max 60), but says nothing about session_id beyond the obvious. With only one of two params meaningfully enriched, this is adequate but incomplete.
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?
States a specific verb+resource (get state history for a session over time) and distinguishes itself from generic state tools by emphasizing the time-series nature. It does not explicitly differentiate from the sibling get_human_state, leaving the agent to infer the distinction from 'over time' versus a presumed point-in-time read.
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?
'Useful for detecting stress patterns during a conversation' gives implied usage context, and the minutes parameter guidance is helpful. However, it never states when to prefer this over get_human_state or get_trigger_memory, nor any when-not conditions, so routing remains inferred.
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)
Returns same fields as get_human_state plus signals_received list and topics_detected (if conversation text was included).
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?
Without annotations, the description carries the full behavioral burden. It discloses fusion behavior, partial-data tolerance, cross-session tracking via subject_id, confidence impact from source_device, and a non-medical disclaimer. It does not cover error conditions, idempotency, or rate limits, so it falls short of a 5.
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?
Front-loaded with the core action and required inputs, then uses short bullets for common signals and trigger memory. Every sentence adds value; the only minor inefficiency is the long list of signals that could be trimmed, but it remains readable.
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 37 parameters, no output schema, and no annotations, the description provides essential context: required fields, signal categories, return shape ('same fields as get_human_state plus signals_received and topics_detected'), and trigger-memory guidance. It is largely complete, though it omits behavior for unrecognized signals and does not explain most of the 35 optional parameters.
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 the description must compensate. It documents required fields (session_id, timestamp ISO 8601) and gives meaning, units, and ranges for several key signals (heart_rate 30-220 bpm, rmssd, tone enums, sentiment -1.0 to 1.0, expression enums). With 37 parameters, many others (e.g., eda, spo2, eeg powers) are left undocumented, so it does not fully close 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?
The description states a specific verb and resource: 'Send biometric signals from any sensor, get unified state back.' This clearly distinguishes it from read-only siblings like get_human_state or get_session_history. The tool's ingest-and-fuse action is unmistakable.
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 states required inputs and the 'send whatever you have' flexibility, but it does not explicitly contrast with alternatives or mention when not to use it. The absence of sibling callouts keeps it from a 5, but practical guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start free API key authorization; no existing API key needed.
Returns a verification_url. Ask the user to open that URL in their
browser, enter their own email, then open the verification email and
confirm access for their agent. This tool
does not accept email addresses and does not send email.
Do not choose, invent, or submit an email on the user's behalf.
Poll check_api_key_status with the returned request_id at the supplied
interval. Stop if the request expires. Never create new requests in a loop.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does it well: it discloses the return value (verification_url), the side effect model (it does NOT accept emails and does NOT send email), the human-in-the-loop requirement (user must open the URL and confirm), and anti-patterns the agent must avoid (no fabricated emails, no request loops). This is far more than a restatement of the name.
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?
Front-loaded with the action and the key constraint, then flows into the human-confirmation workflow and polling rules. Every sentence carries a distinct instruction or constraint; nothing is padding.
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?
No output schema and no annotations exist, yet the description supplies the return handle (verification_url, request_id), the follow-up tool, the polling interval convention, and expiry handling. Nothing essential for correct invocation is missing.
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 tool takes zero parameters and the schema is empty at 100% coverage, so the baseline is 4. The description correctly implies no input is needed and instead points at the output (request_id, verification_url) that drives subsequent calls.
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?
States a specific verb and resource (start API key authorization) and immediately scopes it ('no existing API key needed'). It also names the follow-up sibling check_api_key_status, so an agent can distinguish this initiation step from the status-checking step without inspecting either schema.
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 when-to-use and when-not-to-use guidance: use this when the user has no key, do not supply an email on the user's behalf, do not invent an email. It routes to the alternative (poll check_api_key_status), specifies the cadence ('at the supplied interval'), and states stop conditions ('stop if the request expires', 'never create new requests in a loop').
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.
check_api_key_status2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / titlePrevious value: -"check_api_key_statusArguments"New value: +"CheckKeyStatusArguments"delete_subjectget_session_history2 fields changedInput schema / properties / minutes / maximumAdded value: +60Input schema / properties / minutes / minimumAdded value: +1ingest2 fields changedInput schema / properties / ai_responseAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Ai Response"
+}Input schema / properties / user_messageAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "User Message"
+}request_api_key4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / emailRemoved value: -{
- "title": "Email",
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "email"
-]Input schema / titlePrevious value: -"request_api_keyArguments"New value: +"RequestKeyArguments"delete_subjectcheck_api_key_statusrequest_api_keyget_historyget_session_historyget_trigger_memorydelete_subjectget_historyget_human_stateingestAdaptive running coach MCP server — training data, plans, and recovery for AI assistants.
Connect your wearables, rings and training apps, then ask your AI about your own health data.
Intelligence subscription protocol for AI agents. Scored, filtered AI intelligence signals via MCP.
21-framework people intelligence and compatibility scoring for any MCP client.
Add one secure layer between your agents and this server.
