Skip to main content
Glama

get_daily_briefing

Retrieve a consolidated morning snapshot of sleep, HRV, Body Battery, training readiness, load, and resting heart rate from Garmin Connect. Each metric is fetched concurrently.

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.
Behavior4/5

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

With no annotations, the description carries full burden. It discloses concurrent fetching, null sections on failure, and that it returns facts only without training advice. This is good but could mention if data is cached or updated in real-time.

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 well-structured and front-loaded with the main purpose. It's somewhat lengthy but every sentence adds value. Minor trimming possible without losing clarity.

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 presence of an output schema, the description doesn't need to detail return values. It explains null sections and sections_unavailable, and mentions rhr_vs_baseline_bpm. This is complete for a consolidated tool.

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?

Schema coverage is 0%, so description compensates fully. It explains the date parameter's format, default, and the mixed behavior for different sections. This adds significant meaning beyond the schema.

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 it's a 'one-call morning snapshot' that consolidates sleep, HRV, Body Battery, readiness, load, and RHR. It distinguishes from sibling tools by noting it replaces six separate calls, providing a clear verb+resource+scope.

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?

It explains when to use (for a consolidated snapshot) and notes the alternative of making individual calls. It also warns about the date parameter's behavior for past dates. However, it doesn't explicitly state when not to use or direct to specific siblings for single metrics.

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