nefesh-mcp-server

Tool Scores

• get_session_historyA
  3.9/5.0
  Behavior4/5

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

  Strong disclosure given zero annotations: describes exact return structure (timestamped datapoints with stress_score/state/heart_rate), trend values (rising/falling/stable), constraints (default: 5, max: 60), and critical disclaimer ('Not a medical device'). Carries full burden effectively.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Excellent structure: purpose → return values → parameter usage → use case → disclaimer. Every sentence delivers distinct information without redundancy. Appropriate length for the tool's complexity.

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

  Completeness4/5

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

  Given no output schema and no annotations, the description adequately compensates by detailing return structure, data fields, and behavioral constraints. Missing only minor details like rate limits or pagination, which are optional for this complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description compensates well by explaining 'minutes' semantics (lookback window, default 5, max 60). 'session_id' is not explicitly described but is intuitively linked to 'session' in the first sentence and is self-documenting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

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

  Clear verb-resource combination ('Get state history') with temporal scope ('over time'). However, it doesn't explicitly differentiate from sibling 'get_human_state' (likely current state vs. historical), which could cause agent confusion when selecting between them.

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

  Usage Guidelines3/5

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

  Provides clear use case ('detecting stress patterns during a conversation') and parameter guidance for the lookback window. Lacks explicit when-not-to-use guidance or comparison to siblings like 'get_human_state' or 'get_trigger_memory'.

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

• get_trigger_memoryA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden and excels: it explains the psychological model (active vs. resolved triggers), discloses the data structure returned (observation_count, avg_score, peak_score, last_seen), notes the dependency chain, and includes a medical disclaimer ('Not a medical device').

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Excellent structure: opening purpose statement, bulleted definitions of key concepts, data field enumeration, prerequisites, and disclaimer. Every sentence provides unique value. No redundancy or fluff.

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

  Completeness5/5

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

  Comprehensive despite no output schema and no annotations. Explains the return structure in detail (trigger types and their metrics), covers domain-specific safety considerations, and documents operational dependencies. Complete for this complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% (subject_id lacks description), so the description must compensate. It mentions subject_id in the prerequisite context ('Requires prior ingest calls with the same subject_id'), implying it must match previous calls, but does not explicitly define what subject_id represents or its format. Adequate but minimal compensation for the schema gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

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

  The description uses specific verbs ('Retrieve', 'Returns') and clearly identifies the resource as a 'psychological trigger profile'. It distinguishes from sibling 'ingest' by being retrieval-focused rather than input-focused, and differentiates from 'get_human_state' by focusing on historical trigger patterns rather than current state.

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

  Usage Guidelines4/5

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

  Explicitly states the prerequisite 'Requires prior ingest calls with the same subject_id', establishing when the tool is usable. Provides guidance on interpreting results ('Tread carefully' vs 'Safe to explore deeper'). Could be improved by explicitly contrasting with 'get_session_history' for when to use each.

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

• ingestA
  4.5/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. Discloses fusion behavior ('API fuses all signals into one state'), return value composition (mirrors get_human_state plus extras), confidence scoring dependency on source_device, and critical safety disclaimer ('Not a medical device'). Minor gap on rate limits or error handling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Excellently structured with clear hierarchy: core purpose → requirements → signal taxonomy (bullet points with units/enums) → trigger memory context → return values → safety note. No wasted sentences; front-loaded with essential action statement.

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

  Completeness4/5

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

  For a complex 37-parameter biometric tool with no output schema, description adequately explains return structure by referencing sibling tool fields plus additions. Covers required vs optional fields, units, enums, and safety scope. Would need error handling or rate limit notes for a 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 0% description coverage (titles only). Description richly compensates by documenting: timestamp format (ISO 8601), heart_rate units/range (bpm, 30-220), tone enum values (calm|tense|anxious|hostile), sentiment range (-1.0 to 1.0), subject_id hashing requirement, and source_device impact on confidence scoring.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

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

  Opens with specific verb-resource pair ('Send biometric signals... get unified state'). Distinguishes from sibling get_human_state by noting it 'Returns same fields as get_human_state plus signals_received list and topics_detected', clarifying this is the write/ingest path versus the read path.

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

  Usage Guidelines4/5

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

  Provides clear contextual guidance on when to include optional parameters ('For trigger memory... Include subject_id... user_message + ai_response'). Implicitly contrasts with get_human_state via return value description, though lacks explicit 'when not to use' exclusions.

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

• get_human_stateA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full behavioral disclosure burden. It explains state meanings, confidence calculation methodology ('based on signal quality and device type'), conditional return fields ('on 2nd+ call'), and self-improvement loops ('Use this to self-improve'). No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Perfectly structured with front-loaded purpose, followed by Returns bullet points, usage adaptation rules, and prerequisites. Every sentence provides unique value—no repetition of schema structure or tautology. Dense but scannable.

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

  Completeness5/5

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

  No output schema exists, so the description comprehensively documents all return fields (state, stress_score, confidence, suggested_action, adaptation_effectiveness) including their formats and semantic meanings. Covers behavioral adaptation, medical disclaimers, and data prerequisites—fully complete for this complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 0% description coverage for the single 'session_id' parameter. While the description mentions 'for a session' and implies the parameter through context, it does not explicitly document what the session_id represents or where to obtain it (beyond the ingest prerequisite). Partial compensation for the schema gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

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

  The description opens with a specific verb ('Get') and resource ('unified human state') scoped to 'a session'. It clearly differentiates from sibling tool 'ingest' by stating it 'Requires a prior ingest call to have data', establishing the dependency chain.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use ('Call this before generating important responses'), prerequisites ('Requires a prior ingest call'), and detailed response adaptation rules ('calm/relaxed = full complexity...acute_stress = one grounding sentence only'). Also includes necessary disclaimers ('Not a medical device').

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