Skip to main content
Glama

get_daily_briefing

Consolidate sleep, HRV, Body Battery, readiness, training load, and resting heart rate into a single daily health snapshot, so you can review recovery and training metrics at a glance without multiple calls.

Instructions

One-call morning snapshot: sleep, HRV, Body Battery, readiness, load, and RHR.

Fuses the individual recovery and training-load tools into a single payload so you can reason across them in one shot instead of making six separate calls. Each section is fetched independently and concurrently; a section that fails comes back null and is named in sections_unavailable rather than failing the whole briefing. Also returns rhr_vs_baseline_bpm, the most recent resting HR relative to its trailing average.

The server returns facts only and computes no training advice — interpret the numbers yourself (e.g. weigh readiness, HRV status, and Body Battery together).

Args: date: Calendar date in YYYY-MM-DD format. Defaults to today. The sleep, Body Battery, and training-readiness sections honour this date; the HRV, training-load, and resting-HR sections always report their own most-recent trailing window. For the default (this-morning) call everything lines up; passing a past date yields a mixed snapshot.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hrvNo
dateYesCalendar date the briefing is anchored to, YYYY-MM-DD.
sleepNo
body_batteryNo
training_loadNo
resting_heart_rateNo
training_readinessNo
rhr_vs_baseline_bpmNoMost recent resting HR minus the trailing average of the prior days in the window. Positive means elevated vs baseline (often a recovery or illness signal). Null when fewer than two days of data exist.
sections_unavailableNoNames of sections that could not be fetched for this briefing.
Behavior5/5

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

No annotations are provided, so the description carries the full burden of disclosure. It fully describes the independent, concurrent fetching behavior, the fact that failed sections return null and are named in sections_unavailable rather than failing the whole call, and the mixed-date semantics. It also states that no advice is computed, setting clear expectations about the output's scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: it opens with a punchy summary, then explains the aggregation benefit, error handling, and parameter semantics. Every sentence adds essential information—there is no fluff. The length is justified by the need to explain subtle behaviors like partial failures and date handling, making it concise despite its word count.

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?

Given the tool's complexity (a composite of six data sources) and the existence of an output schema, the description provides sufficient context for an agent to understand the tool's nature, its error tolerance, and how to interpret results. It covers the main integration points and caveats without needing to enumerate return fields, which the output schema presumably handles.

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

Parameters5/5

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

The schema provides zero description coverage for the 'date' parameter. The description compensates thoroughly by specifying the format (YYYY-MM-DD), its default (today), and exactly which sections honor it versus which always report trailing windows. This gives the agent complete instructions on how to set the parameter correctly for different query intents.

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 clearly states the tool's purpose as a 'One-call morning snapshot' aggregating six specific metrics (sleep, HRV, Body Battery, readiness, load, RHR). It explicitly distinguishes itself from sibling tools by noting it fuses the individual recovery and training-load tools into a single payload, making it obvious how it differs from get_sleep, get_body_battery, etc.

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?

It provides explicit guidance on when to use this tool ('instead of making six separate calls') and explains the intended use case (reasoning across multiple metrics in one shot). It also clarifies that the server returns facts only and no training advice, which subtly tells the agent not to expect recommendations. The detailed date behavior further specifies how to use the parameter correctly across different scenarios.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Tyler-Irving/garmin-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server