Retrieve detailed sleep metrics for a night—phases, respiration, heart rate, HRV, and sleep score factors—using the wake-up date; enable time series when needed.
Detaillierter Schlaf einer Nacht (Phasen, Atmung, HF, HRV, Sleep Score inkl. Faktoren).
date = Datum des Aufwachens. Zeitreihen nur mit include_timeseries=true.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| include_timeseries | No |
Changes observed during successful MCP inspections.
v0.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose a real behavioral trait the schema cannot: the time series are gated behind a flag. It says nothing about behavior when `date` is null, what happens if no sleep record exists, or whether the data is read-only/cached, so coverage is partial.
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?
Two short sentences, parenthetical payload summary and the key semantics, nothing redundant. Front-loaded with the resource before the parameter rules.
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?
With no annotations and no output schema, the description sensibly enumerates the returned content and explains both parameters, which is enough to call it correctly. The remaining gap is the meaning of an omitted `date` and the accepted date format.
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%, and the description compensates well for both parameters — notably clarifying that `date` refers to the wake-up date, a genuinely non-obvious semantic that the schema does not convey, and that include_timeseries controls time-series inclusion. It omits the date string format and the default (null) meaning, keeping it from a 5.
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?
States a specific resource and scope: detailed data for a single night's sleep, enumerating the payload (phases, respiration, HR, HRV, sleep score incl. factors). That enumeration makes it distinguishable in practice from sleep_summaries, but the description never names the sibling or contrasts the two explicitly, so it stops short of a 5.
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?
It gives two useful calling rules: `date` is the wake-up date, and time series are only returned with include_timeseries=true. However, there is no guidance on when to use this versus sleep_summaries, nor on what happens when `date` is omitted (both params are optional).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.