Fuses biometric signals into a stress score (0-100) for AI adaptation. MCP + A2A native.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: API key request/status, data ingestion, current state retrieval, session history, and trigger memory. No two tools overlap in functionality or could be confused.
All tool names follow a consistent snake_case verb_noun pattern (e.g., request_api_key, get_human_state, get_session_history). This creates a predictable and intuitive naming convention across the entire set.
Six tools is well-scoped for a real-time human state awareness API, covering the essential lifecycle (key management, data intake, state access, history, and psychological insights) without redundancy or bloat.
The tool surface fully covers the core domain: authentication (request and check key), data ingestion, current state, historical trends, and cross-session trigger profiles. There are no obvious missing operations for the stated purpose.
check_api_key_statusAInspectCheck 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. Store it immediately —
returned once only. Expires after 15 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, so the description must be self-sufficient. It discloses that the key is returned only once, expires after 15 minutes, and how the status changes from pending to ready. This is highly transparent.
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 compact and front-loaded with the purpose. However, the email reference is irrelevant to the request_id parameter and adds confusion, detracting slightly from the overall clarity and conciseness.
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?
The polling workflow, state transitions, and expiry are well covered. But the critical gap of not explaining the required request_id parameter leaves the description incomplete for successful tool 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?
The schema has a single required parameter request_id with no description. The description confusingly references using the user's email instead of explaining request_id, providing misleading guidance and failing to clarify what value should be passed.
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 it checks the status of a pending API key request. This is a specific verb+resource combination that distinguishes it from sibling request_api_key.
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 instructions: use the same email as request_api_key, poll every 10 seconds, and store the key immediately when status changes to ready. It also describes the transition condition, offering strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_human_stateAInspectGet 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_session_historyAInspectGet 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.
get_trigger_memoryAInspectRetrieve 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.
ingestAInspectSend 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 | ||
| sleep_stage | No | ||
| speech_rate | No | ||
| stress_score | 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 carries the full burden. It discloses that it fuses signals ('the API fuses all signals into one state'), returns certain fields, and that trigger memory is activated via subject_id. It also adds a disclaimer 'Not a medical device' and notes that source_device improves confidence scoring. This goes beyond basic functionality, though it does not cover every side effect or permission requirement.
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 front-loaded with the main purpose and structured with line breaks for lists. It includes required fields, common signals, a special use case, and return information in a compact format. Some redundancy exists ('Send whatever you have' and 'fuses all signals'), but each section serves a purpose, keeping it efficient for the 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?
For a tool with 35 parameters and no output schema, the description covers essential context: required parameters, a curated list of common signals with ranges, the return value ('same fields as get_human_state plus signals_received list and topics_detected'), and a note on source_device. It does not detail every optional parameter or error handling, but it provides enough for an agent to select and invoke the tool correctly in most cases.
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 does so by explaining key parameters: heart_rate (bpm, 30-220), rmssd (ms), sentiment (-1.0 to 1.0), tone (calm/tense/anxious/hostile), and expression (relaxed/neutral/tense). It also clarifies the role of subject_id and source_device. Not all 35 parameters are covered, but the most impactful ones are highlighted, providing significant meaning 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?
The description opens with 'Send biometric signals from any sensor, get unified state back,' which clearly states a specific verb (send), resource (biometric signals), and expected outcome (unified state). It also mentions 'Returns same fields as get_human_state plus...' showing it is distinct from the get_human_state sibling.
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 usage context: 'Required: session_id + timestamp (ISO 8601) + at least one signal' and 'Send whatever you have.' It also gives a special use case for trigger memory with subject_id. However, it does not explicitly state when not to use this tool or name alternative tools, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_api_keyAInspectRequest a free Nefesh API key. No existing API key needed for this call.
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 calls/month, all signal types, 10 req/min. No credit card.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully discloses critical behaviors: the verification link must be clicked, disposable email services are blocked, the polling flow, and free tier limits. This exceeds what annotations would typically provide, giving the agent complete awareness of side effects and prerequisites.
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 appropriately structured: a clear opening statement, an IMPORTANT note with a user prompt example, a flow instruction, and free tier details. Every sentence adds value, and the text is front-loaded with purpose. Despite its length, there is no redundant or filler content.
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?
The description covers the overall flow, prerequisites, and behavioral constraints well. However, it does not explicitly state what request_api_key returns (e.g., a request ID or confirmation), which would be needed to fully understand the polling step. Minor gap, but the flow is otherwise 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 schema only defines 'email' as a string with zero description coverage. The description compensates by explaining that the email must be the user's real email, cannot be invented or disposable, and is used for the verification link. This adds essential meaning 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?
The description opens with a specific verb+resource: 'Request a free Nefesh API key.' It clearly distinguishes this tool from its siblings, especially check_api_key_status, by describing the polling flow that follows. 'No existing API key needed for this call' further clarifies the tool's role.
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 explicit when and how to use the tool: ask the user for their real email first, do not invent one, and then poll check_api_key_status. It also gives an alternative for checking status, along with rate limits and free tier constraints, making usage guidance thorough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.