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.