Skip to main content
Glama
Fino-wind

Vaultbeat MCP Server

Sleep, every night

get_sleep_nights
Read-onlyIdempotent

Read night-by-night sleep history to compare periods and spot patterns: bed/wake times, stages, awakenings, and vitals, newest first.

Instructions

Every night as one compact row — the tool for reading a sleep HISTORY.

One row per night, newest first: date, weekday, bed and wake time, time asleep, deep / REM / core / awake minutes, deep and REM share, number of awakenings, longest unbroken stretch of sleep, heart and breathing rate while asleep, and any OTHER sleep that day (naps, the second half of a broken night) — so a day's total sleep is asleep plus other. Column names come once in columns; each row is the values in that order, so a whole year is ~40k characters. Read it when the question is about a period or a pattern: weekends vs weekdays, drifting bedtimes, which nights were worst, what changed after a date.

Which sleep tool: · THIS one for any span of time. · get_metric with the sleep series (sleep_minutes, bedtime_minutes, deep_sleep_minutes, awakenings, ...) when you want the arithmetic — weekly/monthly averages computed for you, from these same rows. · get_sleep_detail for one or two nights in depth (stage bands, per-stage vitals).

limit = newest N nights (default 120; pass 400 for everything, and check coverage.more_available). since = "YYYY-MM-DD" keeps every night on or after that day — use it for "last month" rather than guessing a limit; with since, limit applies only if you pass it.

Read legend once. Five flags, comma-separated when a night has several: unworn means sleep was never measured that night (not zero sleep), motion_inferred means phone motion guessed it (leave it out of averages, as get_metric does), daytime means the day's only sleep was a daytime nap (real, but not a night — out of get_metric's nightly series, still a row here), short means a main sleep under 3 h with no stages — a nap or a partly recorded night, left out of get_metric's sleep-duration and clock series — and no_stages means the total is known but the stage columns are null. A null anywhere is "not measured", never zero. Reads YOUR nights; partner=true reads your partner's shared sleep.

Carries a coverage block: quote coverage.days_covered beside any average, and read coverage.more_available before saying how far back the history goes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
freshNo
limitNo
sinceNo
partnerNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description goes well beyond: it discloses approximate output size (~40k chars/year), that column names come once in `columns`, the `legend` flag semantics (`unworn` means never measured, not zero; `motion_inferred` should be excluded from averages), that null means 'not measured, never zero', and that `partner=true` reads a partner's shared data. This is exactly the operational 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?

It is a long description, but the load-bearing facts are front-loaded (one row per night, newest first, column layout) and the tool-selection routing and legend semantics are each stated once. The length is justified by the tool's complexity, though the schema/legend material is dense enough that it could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still usefully explains the row/column shape and the `coverage` block (`days_covered` to quote beside averages, `more_available` before claiming history depth), which is high-value context for correct answer framing. Combined with the flag semantics and null rules, coverage is strong; the sole miss is the unexplained `fresh` parameter.

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 description coverage is 0%, so the description must carry the entire burden. It explains `limit` (newest N nights, default 120, 400 for everything), `since` (YYYY-MM-DD, inclusive, overrides guessing a limit), and `partner` (reads partner's shared sleep). However `fresh` is never mentioned anywhere in the description or schema, leaving one of four parameters completely undocumented.

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?

States the resource ('one compact row per night'), the ordering ('newest first'), and the enumeration of every returned column, giving an agent a complete picture of what the tool produces. The explicit 'Which sleep tool' section names the two sibling alternatives (get_metric, get_sleep_detail) and the condition that selects each, so the tool is separable from its siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('any span of time', 'period or a pattern: weekends vs weekdays, drifting bedtimes'), when-to-use-elsewhere (get_metric for precomputed arithmetic, get_sleep_detail for one or two nights), and parameter-level guidance for choosing between `since` and `limit`. Nothing about tool selection is left to inference.

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