GarminMCP

get_coach_daily_briefing

Fetches a morning coaching briefing for a chosen date, combining readiness, sleep, HRV, heart rate, stress, and recent workouts into a recommended training intensity.

Instructions

Fetch a complete morning coaching briefing for a single date (defaults to today).

Coaching Purpose: High-level morning readiness aggregator designed to be the first tool called in a daily check-in. Synthesizes Training Readiness score & contributors, Body Battery (current, charged, drained), overnight Sleep quality & stages, Heart Rate Variability (HRV) status vs. personal baseline, Resting Heart Rate (RHR vs. 7-day baseline), daily Stress, and yesterday's completed workouts into an actionable training intensity prescription (high_intensity, moderate_steady, easy_recovery, or rest).

Args: target_date: Target ISO calendar date (YYYY-MM-DD). Defaults to today if omitted. response_format: Output representation: "markdown" for human-readable summary, "json" for compact normalized JSON, or "hybrid" (default) for Markdown + JSON.

Returns: Formatted coaching briefing containing readiness score, autonomic recovery metrics, sleep architecture, yesterday's training load, and today's recommended workout intensity.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_coach_daily_briefing"
  }
}

Input Schema

Name	Required	Description	Default
`target_date`	No
`response_format`	No		hybrid

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

TDQS

A4/5.0

Behavior3/5

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

With no annotations supplied, the description carries the full disclosure burden. It does well on output shape (readiness score, autonomic recovery, sleep architecture, training load, recommended intensity) and on the three response formats, but says nothing about data availability edge cases (no sleep recorded, no workouts yesterday), permissions, or whether the tool is strictly read-only beyond the verb "Fetch." Useful but incomplete for a zero-annotation tool.

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 core purpose is front-loaded in one sentence, then organized under Coaching Purpose / Args / Returns headings, which makes scanning easy. The Returns section largely restates the metric list already given under Coaching Purpose, so there is mild redundancy, but nothing is padded with filler.

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, so return values did not need spelling out, yet the description still frames them usefully. Parameters are fully covered. The remaining gap is behavioral edge cases (empty or partial data for a date) and explicit sibling routing, which keeps it short of a 5 for a multi-metric aggregator.

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 description coverage is 0%, so the description must supply all parameter meaning, and it does: target_date is documented with its ISO YYYY-MM-DD format and today-default, and response_format is documented with all three enum values explained plus its hybrid default. This adds real meaning the bare schema lacks.

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 opening sentence gives a specific verb and resource ("Fetch a complete morning coaching briefing for a single date"), and the Coaching Purpose section enumerates exactly which metrics are aggregated and the four possible intensity prescriptions. It positions itself as the "first tool called in a daily check-in," which implicitly distinguishes it from the metric-specific siblings, though it never names an alternative explicitly.

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?

"Designed to be the first tool called in a daily check-in" is a clear when-to-use statement, and the default-to-today behavior sets expectations for the common case. There is no when-not guidance and no named alternative for narrower queries (e.g., a sleep-only or training-load-only sibling), so an agent must infer when to skip the aggregator.

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

Deploy Server