Skip to main content
Glama
Sign In
Garmin Connect MCP Server

Garmin Connect MCP Server

by sedoglia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Stress Data

get_stress_data
Read-only

Retrieve stress data for a specific date, including average, maximum, minimum, and time spent in each stress band. Optionally include timestamped samples to see stress changes throughout the day.

Instructions

Get stress for a date on the 0-100 scale (0-25 resting, 26-50 low, 51-75 medium, 76-100 high). Returns average/max/min and the seconds spent in each band; set includeValues to also get the ~460 three-minute samples. The average and maximum are the day figures Garmin itself reports, so they match the Connect app; the minimum and the band seconds are derived from the samples. Use get_all_day_stress for the same day broken down hour by hour.

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

Input Schema

NameRequiredDescriptionDefault
dateNoDate in YYYY-MM-DD format. Defaults to today if not specified.
includeValuesNoInclude the individual timestamped stress samples (default false). Only worth requesting to see when during the day stress rose or fell.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.5.7
    • addedInput schema / properties / includeValues
      Added value: +{
+  "description": "Include the individual timestamped stress samples (default false). Only worth requesting to see when during the day stress rose or fell.",
+  "type": "boolean"
+}
  2. First observedv4.3.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses return contents (average/max/min, seconds per band, ~460 samples with includeValues), data provenance (average/max match Garmin's day figures; min/band seconds are derived), and scaling semantics. This is substantial behavioral context that annotations alone cannot provide.

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?

Three sentences carry a high density of useful information: scale bands, return values, data provenance, and the sibling alternative. No filler or redundancy; the key actions and semantics are front-loaded.

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?

For a simple two-parameter tool with no output schema, the description fully covers what is returned, how to interpret the scale, when to request samples, and how this differs from the nearest sibling. Nothing an agent needs to call it correctly is missing.

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 coverage is 100% with both parameters described, setting a baseline of 3. The description adds value by quantifying the includeValues output as '~460 three-minute samples' and by explaining that min/band seconds are derived from those samples, deepening understanding 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 states a specific verb ('Get'), a resource ('stress for a date'), and the 0-100 scale with band ranges. It also distinguishes itself from get_all_day_stress by noting the hourly breakdown alternative, so an agent can tell it apart without opening the schema.

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 explicitly directs to get_all_day_stress for hour-by-hour data and clarifies when includeValues is worth requesting (to see when during the day stress rose or fell). This gives concrete selection criteria for both the tool and its parameter.

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

Deploy Server

Other Tools