Wellness Project

log_wearable

Log daily wearable/manual health metrics (RHR, HRV, Zone Minutes / AZM, VO2max, calories eaten / dietary energy, stress, supplemental steps, and physiological vitals including SpO₂, respiratory rate, skin temperature, blood pressure, blood glucose, and core temperature).

VITALS — use the vital fields for manual/home/device readings and corrections, including a finger-stick, CGM, home glucose meter, or wearable/Apple Health/Health Connect value the user explicitly wants stored manually. A glucose value from an actual lab report or blood draw belongs in log_lab_results instead, not here.

STEPS — read before using step_count: manual step_count is ADDITIVE — it adds on top of whatever a connected wearable (Fitbit, Oura, Apple Health, Health Connect) already recorded that day; it never replaces or overrides device data. Only use it when the user explicitly says they walked steps their device did NOT capture (phone left home, battery died, device not worn). If the user says sync is wrong, steps look doubled, or they want to fix/override/replace device data: do NOT pass step_count — explain that manual steps add on top, and sync issues need investigating at the device level.

ALL OTHER FIELDS (RHR, HRV, AZM, VO2max, stress, and physiological vitals) replace the existing manual value for that day and are safe to use for corrections.

SLEEP ADDITIONS — only when the user EXPLICITLY asks to add missing sleep periods to an EXISTING record, use sleep_periods and add_to_existing_sleep_record: true. Each start/end accepts local HH:MM or ISO 8601 with offset. Only the source powering the displayed sleep total can be enriched, selected using the user's Sleep source priority. If sleep_source is specified it must match that source. Never infer consent from a complaint about sleep; do not mix additions with other metrics.

INFER — do not ask: date defaults to today unless the user says otherwise.

IDEMPOTENT: if the values you'd log already exist for that date (any source), the tool returns a no-op success — report this as "already had data", not "failed".

Input Schema

Name	Required	Description
`date`	Yes	Date for the entry. Format: YYYY-MM-DD. Default to today.
`resting_hr`	No	Legacy provider resting heart rate, BPM. Use only when the measurement type is unknown; do not infer waking or sleeping from this value.
`step_count`	No	Supplemental steps NOT captured by any connected wearable. ADDITIVE — adds to device data, never replaces it. Only use when user explicitly says their device missed these steps.
`hrv_morning`	No	Morning HRV in milliseconds (RMSSD or similar). Optional.
`skin_temp_c`	No	Skin temperature in °C. Manual/home/device reading. Optional.
`sleep_source`	No	Optional source identity. Must match the displayed sleep total source; see SLEEP ADDITIONS.
`spo2_avg_pct`	No	SpO₂ in %. Manual/home/device reading. Optional.
`stress_score`	No	Stress score (0–100 scale). Optional.
`sleep_periods`	No	Missing sleep periods to ADD. Start/end: local HH:MM or offset-aware ISO 8601. See SLEEP ADDITIONS.
`vo2max_estimate`	No	VO2max estimate (ml/kg/min). Optional.
`core_body_temp_c`	No	Core temperature in °C. Manual/home/device reading. Optional.
`dietary_calories`	No	Dietary energy / calories eaten for the day in kcal, imported from a connected health app (Apple Health / Health Connect). Optional.
`overnight_min_hr`	No	Overnight minimum HR in BPM: the actual lowest reading during the MAIN sleep period. Never log nighttime average or generic RHR here.
`systolic_bp_mm_hg`	No	Systolic blood pressure in mmHg. Provide with diastolic_bp_mm_hg. Manual/home/device reading. Optional.
`daytime_resting_hr`	No	Daytime resting HR in BPM, measured during awake rest or estimated from documented awake, stable, non-exercise samples. Only when the user identifies this type.
`diastolic_bp_mm_hg`	No	Diastolic blood pressure in mmHg. Provide with systolic_bp_mm_hg. Manual/home/device reading. Optional.
`blood_glucose_mg_dl`	No	Blood glucose in mg/dL. Manual/home/device reading. Optional.
`active_zone_min_peak`	No	Zone Minutes (also called Active Zone Minutes by Fitbit, Heart Points by Google Fit) at peak intensity. Optional.
`confirm_supplemental`	No	Set to true ONLY after the user has explicitly confirmed these steps were walked without their device and were not captured. Do not set true based on your own inference.
`respiratory_rate_bpm`	No	Breathing in br/min. Manual/home/device reading. Optional.
`active_zone_min_moderate`	No	Zone Minutes (also called Active Zone Minutes by Fitbit, Heart Points by Google Fit) at moderate intensity. Optional.
`add_to_existing_sleep_record`	No	True only on an explicit request to supplement an existing sleep record. See SLEEP ADDITIONS.

Output Schema

Name	Required	Description	Default
`result`	Yes	Human-readable result text returned by the tool.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 13, 2026

addedInput schema / properties / daytime_resting_hr

Added value: +{
+  "description": "Daytime resting HR in BPM, measured during awake rest or estimated from documented awake, stable, non-exercise samples. Only when the user identifies this type.",
+  "type": "integer"
+}

addedInput schema / properties / overnight_min_hr

Added value: +{
+  "description": "Overnight minimum HR in BPM: the actual lowest reading during the MAIN sleep period. Never log nighttime average or generic RHR here.",
+  "type": "integer"
+}

changedInput schema / properties / resting_hr / description

Previous value: -"Resting heart rate in BPM. Optional."New value: +"Legacy provider resting heart rate, BPM. Use only when the measurement type is unknown; do not infer waking or sleeping from this value."

Changed3 schema fields changedOct 12, 2026

addedInput schema / properties / add_to_existing_sleep_record

Added value: +{
+  "description": "True only on an explicit request to supplement an existing sleep record. See SLEEP ADDITIONS.",
+  "type": "boolean"
+}

addedInput schema / properties / sleep_periods

Added value: +{
+  "description": "Missing sleep periods to ADD. Start/end: local HH:MM or offset-aware ISO 8601. See SLEEP ADDITIONS.",
+  "items": {
+    "properties": {
+      "end": {
+        "type": "string"
+      },
+      "start": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "start",
+      "end"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedInput schema / properties / sleep_source

Added value: +{
+  "description": "Optional source identity. Must match the displayed sleep total source; see SLEEP ADDITIONS.",
+  "type": "string"
+}

Changed7 schema fields changedSep 7, 2026

addedInput schema / properties / blood_glucose_mg_dl

Added value: +{
+  "description": "Blood glucose in mg/dL. Manual/home/device reading. Optional.",
+  "type": "number"
+}

addedInput schema / properties / core_body_temp_c

Added value: +{
+  "description": "Core temperature in °C. Manual/home/device reading. Optional.",
+  "type": "number"
+}

addedInput schema / properties / diastolic_bp_mm_hg

Added value: +{
+  "description": "Diastolic blood pressure in mmHg. Provide with systolic_bp_mm_hg. Manual/home/device reading. Optional.",
+  "type": "number"
+}

addedInput schema / properties / respiratory_rate_bpm

Added value: +{
+  "description": "Breathing in br/min. Manual/home/device reading. Optional.",
+  "type": "number"
+}

addedInput schema / properties / skin_temp_c

Added value: +{
+  "description": "Skin temperature in °C. Manual/home/device reading. Optional.",
+  "type": "number"
+}

addedInput schema / properties / spo2_avg_pct

Added value: +{
+  "description": "SpO₂ in %. Manual/home/device reading. Optional.",
+  "type": "number"
+}

addedInput schema / properties / systolic_bp_mm_hg

Added value: +{
+  "description": "Systolic blood pressure in mmHg. Provide with diastolic_bp_mm_hg. Manual/home/device reading. Optional.",
+  "type": "number"
+}

First observedAug 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Adds a great deal beyond the annotations: additive-vs-replace semantics for step_count, the no-op 'already had data' behavior, sleep-source matching constraints, and the rule that the user can never be inferred to consent. There is mild tension between the description's 'IDEMPOTENT' framing and the idempotentHint=false annotation, though the additive step behavior makes strict non-idempotency defensible.

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?

Front-loaded with purpose, then cleanly sectioned under VITALS, STEPS, ALL OTHER FIELDS, SLEEP ADDITIONS, INFER, and IDEMPOTENT headers. It is long, and the STEPS section is repetitive, but given 22 parameters with asymmetric merge semantics the length is largely earned.

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?

An output schema exists so return values need not be explained, and the description still covers routing, merge semantics, consent constraints, and defaulting rules for an unusually complex tool. Nothing an agent needs to invoke it correctly appears to be missing.

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 baseline is 3, but the description adds cross-field meaning beyond the schema: step_count is additive and never replaces device data, vitals are for manual readings while lab draws are excluded, and sleep_periods/sleep_source must match the displayed sleep source. Undocumented-in-description fields like hrv_morning and stress_score rely on the schema alone.

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 specific verb (log) and resource (daily wearable/manual health metrics) and enumerates the metric families it covers. It explicitly distinguishes itself from a sibling by routing lab-draw glucose to log_lab_results, so an agent can tell these apart 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?

Strong when/when-not guidance: vital fields for manual/home/device readings, lab values to log_lab_results, step_count only when the device missed steps, and sleep_periods only on explicit request. It does not address overlap with other logging siblings (e.g. log_sleep, log_body_metrics, log_wellbeing), so routing is not fully closed.

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

All Wellness Project tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.