GarminMCP

get_body_composition_and_biometrics

Fetch weight, body fat, muscle mass, hydration, and physiological thresholds (LTHR, Max HR, FTP) over a date range to track body composition changes and calibrate training zones.

Instructions

Fetch weight trends, body fat %, muscle mass, hydration, and physiological thresholds (LTHR, Max HR, FTP).

Coaching Purpose: Tracks body composition shifts (weight, body fat percentage, skeletal muscle mass, body water, BMI), daily hydration intake, and physiological threshold anchors (Lactate Threshold Heart Rate & Pace, Max HR, Resting HR, Cycling FTP, VO2 Max) used to calibrate training zones and race power/pacing targets.

Args: start_date: Start ISO date (YYYY-MM-DD). Defaults to a 30-day window ending on end_date. end_date: End ISO date (YYYY-MM-DD). Defaults to today. response_format: Output representation: "markdown", "json", or "hybrid" (default).

Returns: Formatted body composition and biometrics report with weight delta, weigh-in history, hydration averages, and Lactate Threshold / Max HR / FTP configurations.

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_body_composition_and_biometrics"
  }
}

Input Schema

Name	Required	Default
`end_date`	No
`start_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

A3.9/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full burden, and it does reasonably well: 'Fetch' signals a read-only operation, defaults for both date bounds are spelled out (30-day window ending on end_date, end_date defaults to today), and the Returns section scopes the payload. It stops short of stating data ownership, empty-result handling, or units, which keeps it out of the top band.

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 purpose statement is front-loaded in the first sentence, then cleanly partitioned into Purpose, Args, and Returns blocks. Every line carries information an agent needs; the Returns section is mildly duplicative given the output schema but still aids routing decisions.

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?

For a 3-parameter read tool with no annotations and an existing output schema, the definition covers what is needed: scope, parameter formats and defaults, and a summary of returned content. The only meaningful omission is how this tool relates to the nearby health-trends sibling.

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 compensate, and it does: it supplies the ISO YYYY-MM-DD format for both date parameters, documents the 30-day default window and today-default, and names the three response_format enum values with 'hybrid' as default. Minor gap: no guidance on maximum range or behavior when start_date exceeds end_date.

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 names a specific verb (Fetch) and enumerates exactly the resources covered: weight trends, body fat %, muscle mass, hydration, and thresholds (LTHR, Max HR, FTP), reinforced by the Coaching Purpose paragraph. It does not, however, differentiate itself from plausibly adjacent siblings such as get_health_trends, leaving an agent to guess at boundaries.

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?

The Coaching Purpose section implies usage context (calibrating training zones, tracking body composition shifts), which is useful but indirect. There is no explicit statement of when to prefer this tool over get_health_trends or get_sleep_and_recovery, and no exclusions or prerequisites are given.

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

Deploy Server