Skip to main content
Glama

Slim Chance: what the watch says beside the scale

body_signals
Read-onlyIdempotent

Use when someone with a watch or fitness tracker asks what their resting heart rate, steps, sleep or HRV say, or why the scale stalled while they trained. Gives each daily signal its own honest trend over the last 5 weeks (rising, falling, steady, or too noisy to call), with a plain meaning: resting heart rate (falling usually means fitness improving), daily steps (falling is a common hidden reason weight loss slows), sleep hours and HRV. With morning weights too, it also gives the weight trend and says when the watch explains the scale. Separate signals, not a health score; not medical advice. Needs 7 days of a signal for its trend. Only send what the person shared and asked about. Nothing you send is stored.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "body_signals"
  }
}

Input Schema

NameRequiredDescriptionDefault
hrvNoHeart rate variability per day, milliseconds (as the watch reports it).
unitNoUnit of the weights, and of the answer. Default kg.
stepsNoSteps per day.
weigh_insNoMorning scale readings, any order, one per day (a later reading for the same date replaces an earlier one).
resting_hrNoResting heart rate per day, beats per minute.
sleep_hoursNoHours slept per night, dated by the morning.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds genuinely new behavioral facts: a 5-week analysis window, a 7-day minimum before any trend is asserted, a four-way classification including 'too noisy to call', and the privacy guarantee 'Nothing you send is stored'. It also constrains input handling ('Only send what the person shared and asked about'), which is exactly the kind of context annotations cannot carry.

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

Conciseness4/5

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

The trigger condition is front-loaded, then outputs, then constraints, with no filler sentences. It is dense and slightly long — the parenthetical interpretations of resting heart rate and steps could be trimmed — but every clause carries usable information.

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?

With no output schema, the description carries the return-value burden and does so: it states the trend vocabulary, the per-signal structure, the additional weight trend, and the conditional 'says when the watch explains the scale'. For a six-optional-parameter read-only analysis tool, an agent has everything needed to decide when to call it and how to interpret what comes back.

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?

Schema coverage is 100%, so the baseline is 3, and the description earns above that by explaining what each signal means in the answer — resting heart rate falling usually means fitness improving, steps falling is a common hidden cause of stalled weight loss, and weights are specifically morning readings feeding a weight trend. It does not add detail on the unit parameter's effect or date/ordering handling, which remain schema-only.

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 names a concrete verb and resource: it produces per-signal trends (resting heart rate, steps, sleep, HRV) over the last 5 weeks, and additionally the weight trend when morning weights are supplied. The opening trigger ('someone with a watch or fitness tracker') plus the explicit field list makes it distinguishable from the weight-focused sibling slim_chance without opening either schema.

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?

It gives a clear when-to-use trigger, including the specific question type 'why the scale stalled while they trained', and states a hard prerequisite ('Needs 7 days of a signal for its trend') plus a scope boundary ('not a health score; not medical advice'). What it lacks is an explicit routing statement naming the alternative (e.g. slim_chance) for weight-only questions, so the agent must infer the boundary.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.