Skip to main content
Glama

HRV summaries

get_hrv_summaries
Read-onlyIdempotent

Retrieve daily heart rate variability summaries for a date range to compare overnight average, 5-minute high, 7-day average, baseline band, and status.

Instructions

Daily heart rate variability over a range: overnight average, 5-minute high, 7-day average, baseline band, status.

Input Schema

NameRequiredDescriptionDefault
periodNoNamed period resolved in the user's time zone (weeks start Monday). Use instead of start_date/end_date.
end_dateNoLast day, YYYY-MM-DD, inclusive. Defaults to start_date. Max span 92 days.
start_dateNoFirst day, YYYY-MM-DD, inclusive. Required unless period is given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that values are daily and that a baseline band and status classification come back, but says nothing about timezone resolution, gaps in data, or the 92-day span limit the schema mentions.

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?

One compact sentence that front-loads the resource and granularity before enumerating returned metrics. The colon-list style is dense and readable, though the fragment form leaves the action verb implicit.

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?

With no output schema, the description usefully enumerates the returned metrics (overnight average, 5-minute high, 7-day average, baseline band, status), which is the main thing an agent needs. It stops short of noting result ordering or handling of missing days, but for a simple three-parameter read tool this is close to sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including the enum meanings, timezone resolution, Monday week start, inclusive dates and 92-day max span. The description adds no parameter detail beyond 'over a range', so it neither compensates nor needs to; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (heart rate variability) and scope (daily values over a range), plus the exact metrics returned: overnight average, 5-minute high, 7-day average, baseline band, status. It does not explain how this differs from the sibling get_hrv, so an agent must infer that this is the aggregated daily view.

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

Usage Guidelines3/5

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

Usage is only implied: 'over a range' signals this tool is for multi-day queries, but there is no explicit when-to-use guidance, no distinction from get_hrv or get_daily_summaries, and no mention of the period-vs-start_date/end_date choice, which the schema alone carries.

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