Wellness Project

log_sleep

Log a sleep entry. use: logging request or concrete sleep event to record, from a tracker or recall. Question/habit/hypothetical alone: no write.

PROACTIVE DATA COLLECTION: If the user says they want to log sleep but hasn't shared numbers, ask: "How many hours did you sleep, and do you have a sleep score or stage breakdown from your tracker?" They can paste or describe the summary screen.

INFER — do not ask:

date: date the primary sleep session ended / wake date (night ending on this date); default to today

You may log any subset of fields. One row per day. Calling this tool twice on the same date updates the existing entry (upsert). Entries made through this tool are always tagged as manual — the wearable-provider sources (Fitbit/Oura/Apple Health) are reserved for the actual auto-sync pipelines.

Input Schema

TableJSON Schema

Name	Required	Description
`date`	Yes	Date of the sleep entry (night ending on this date). Format: YYYY-MM-DD. Default to today.
`bedtime`	No	Bedtime / primary sleep session start time. Format: ISO 8601 timestamp (e.g. 2026-08-16T22:47:00-04:00) or HH:MM wall-clock time. Optional.
`wake_time`	No	Wake time / primary sleep session end time. Format: ISO 8601 timestamp (e.g. 2026-08-17T06:21:00-04:00) or HH:MM wall-clock time. Optional.
`awakenings`	No	Number of times woken during the night. Optional.
`sleep_score`	No	Sleep quality score on a 0-100 scale (matches wearable scoring). For a 1-10 self-rating, multiply by 10 first. Optional.
`total_hours`	No	Total sleep duration in hours (e.g. 7.5). Optional.
`rem_sleep_hours`	No	REM sleep in hours. Optional — include if the tracker reports it.
`deep_sleep_hours`	No	Deep/slow-wave sleep in hours. Optional — include if the tracker reports it.
`light_sleep_hours`	No	Light sleep in hours. Optional — include if the tracker reports it.

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 7, 2026

addedInput schema / properties / bedtime

Added value: +{
+  "description": "Bedtime / primary sleep session start time. Format: ISO 8601 timestamp (e.g. 2026-08-16T22:47:00-04:00) or HH:MM wall-clock time. Optional.",
+  "type": "string"
+}

addedInput schema / properties / wake_time

Added value: +{
+  "description": "Wake time / primary sleep session end time. Format: ISO 8601 timestamp (e.g. 2026-08-17T06:21:00-04:00) or HH:MM wall-clock time. Optional.",
+  "type": "string"
+}

First observedAug 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description discloses critical behavioral traits beyond the annotations: one row per day, calling twice on the same date is an upsert/update, manual tagging, and the exclusion of wearable-provider sources. These details are not present in the input schema or annotations and materially affect how an agent uses the tool.

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 description is longer than average but well-structured with clear sections and front-loaded purpose. Every section adds necessary operational detail—proactive data collection, inference rules, upsert behavior, and manual tagging—so the length is justified.

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?

The description is complete for a 9-parameter, mutation-prone tool with an output schema. It covers when to call, what to ask, how to infer the required date, update semantics, and provenance constraints. With the output schema present and annotations provided, nothing essential is 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 the schema already documents each parameter. The description adds useful semantic guidance not in the schema, such as inferring the date from the wake date rather than asking, defaulting to today, and allowing any subset of fields to be logged.

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 begins with a specific verb and resource, 'Log a sleep entry', and immediately clarifies what qualifies as a loggable event ('logging request or concrete sleep event') and what does not ('Question/habit/hypothetical alone: no write'). It also distinguishes itself from wearable-provider auto-sync sources by noting entries are always tagged as manual.

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?

The description gives clear guidance on when to use the tool: when a user requests logging or provides a concrete sleep event, including proactive follow-up when numbers are missing. It provides negative guidance for hypotheticals alone and implies that wearable auto-sync pipelines should not use this tool, though it does not name a specific sibling alternative such as log_wearable.

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.