garmin-owl

Overview Schema Source Related Servers Discussions Admin

get_stress

Read-only

Fetch a single day's Garmin stress metrics—average, maximum, and seconds in rest, low, medium, and high bands—to assess daily stress exposure.

Instructions

Get one calendar day's Garmin stress: average and maximum (0-100) and seconds spent resting and at low, medium, and high stress, with optional readings.

Use for stress detail on one date; use get_daily_summary for a whole-day overview, get_recovery for recovery context, or get_recovery_trend for change over several days.

Field notes: Garmin's bands are rest 0-25, low 26-50, medium 51-75, and high 76-100. Stress is measured only while the watch is worn and the wearer is still, so the band durations need not add up to 24 hours. Today's values are partial.

Requires saved local Garmin authentication (garmin-owl-auth). Reads Garmin and may update the local cache; never changes your Garmin account. Garmin failures are not retried automatically.

Input Schema

Name	Required	Description	Default
`date`	No	Calendar date in YYYY-MM-DD format, e.g. 2026-10-09; any past date Garmin still stores. Omit or pass null for today in the server's local timezone.
`include_timeseries`	No	When true, also return timeseries: up to 48 {timestamp, value} readings sampled evenly across the day (first and last always kept), with ISO 8601 timestamps that include the UTC offset. Always reads Garmin fresh instead of the cached daily summary. Defaults to false.

Output Schema

Name	Required	Description
`date`	Yes
`max_stress`	No
`timeseries`	No
`availability`	No
`average_stress`	No	Garmin's whole-day average stress (0-100). Sleep stress is a separate metric reported by get_sleep.
`low_duration_seconds`	No
`high_duration_seconds`	No
`rest_duration_seconds`	No
`medium_duration_seconds`	No
`stress_duration_seconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.3.1Oct 24, 2026

changedInput schema / properties / date / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / date / description

Added value: +"Calendar date in YYYY-MM-DD format, e.g. 2026-10-09; any past date Garmin still stores. Omit or pass null for today in the server's local timezone."

addedInput schema / properties / include_timeseries / description

Added value: +"When true, also return timeseries: up to 48 {timestamp, value} readings sampled evenly across the day (first and last always kept), with ISO 8601 timestamps that include the UTC offset. Always reads Garmin fresh instead of the cached daily summary. Defaults to false."

addedOutput schema / $defs

Added value: +{
+  "AvailabilityNotice": {
+    "properties": {
+      "field": {
+        "title": "Field",
+        "type": "string"
+      },
+      "message": {
+        "title": "Message",
+        "type": "string"
+      },
+      "status": {
+        "title": "Status",
+        "type": "string"
+      }
+    },
+    "required": [
+      "field",
+      "status",
+      "message"
+    ],
+    "title": "AvailabilityNotice",
+    "type": "object"
+  },
+  "TimePoint": {
+    "properties": {
+      "timestamp": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "integer"
+          }
+        ],
+        "description": "Reading time: ISO 8601 with an explicit UTC offset, e.g. 2026-10-09T23:18:16+02:00. The wall time is already local; never add the offset again. The offset is the one Garmin recorded for the device at that moment, or this computer's time zone when Garmin gives only UTC. A bare date or number is a Garmin value that could not be parsed as a time.",
+        "title": "Timestamp"
+      },
+      "value": {
+        "anyOf": [
+          {
+            "type": "number"
+          },
+          {
+            "type": "integer"
+          }
+        ],
+        "title": "Value"
+      }
+    },
+    "required": [
+      "timestamp",
+      "value"
+    ],
+    "title": "TimePoint",
+    "type": "object"
+  }
+}

removedOutput schema / additionalProperties
```
Removed value: -true
```

addedOutput schema / properties

Added value: +{
+  "availability": {
+    "items": {
+      "$ref": "#/$defs/AvailabilityNotice"
+    },
+    "title": "Availability",
+    "type": "array"
+  },
+  "average_stress": {
+    "anyOf": [
+      {
+        "type": "integer"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "description": "Garmin's whole-day average stress (0-100). Sleep stress is a separate metric reported by get_sleep.",
+    "title": "Average Stress"
+  },
+  "date": {
+    "title": "Date",
+    "type": "string"
+  },
+  "high_duration_seconds": {
+    "anyOf": [
+      {
+        "type": "integer"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "title": "High Duration Seconds"
+  },
+  "low_duration_seconds": {
+    "anyOf": [
+      {
+        "type": "integer"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "title": "Low Duration Seconds"
+  },
+  "max_stress": {
+    "anyOf": [
+      {
+        "type": "integer"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "title": "Max Stress"
+  },
+  "medium_duration_seconds": {
+    "anyOf": [
+      {
+        "type": "integer"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "title": "Medium Duration Seconds"
+  },
+  "rest_duration_seconds": {
+    "anyOf": [
+      {
+        "type": "integer"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "title": "Rest Duration Seconds"
+  },
+  "stress_duration_seconds": {
+    "anyOf": [
+      {
+        "type": "integer"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "title": "Stress Duration Seconds"
+  },
+  "timeseries": {
+    "anyOf": [
+      {
+        "items": {
+          "$ref": "#/$defs/TimePoint"
+        },
+        "type": "array"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "title": "Timeseries"
+  }
+}

addedOutput schema / required
```
Added value: +[
+  "date"
+]
```

changedOutput schema / title

Previous value: -"get_stressDictOutput"New value: +"StressSummary"

First observedv0.1.0Aug 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Despite readOnlyHint/destructiveHint already covering safety, the description adds substantial context beyond annotations: Garmin auth requirement (garmin-owl-auth), that it reads Garmin and may update the local cache but never modifies the account, and that failures are not retried. It also explains measurement preconditions (watch worn, wearer still) and that today's values are partial.

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?

Front-loads purpose in the first sentence and follows with routing, field notes, and operational constraints in a logical order. Slightly long, but each block (bands, partial-today caveat, auth/cache behavior) carries distinct information an agent needs.

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?

An output schema exists so return structure needn't be re-explained, and the description covers what remains: band definitions, why durations don't sum to 24h, partial-day data, auth prerequisites, cache behavior, and failure handling. 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.

Parameters3/5

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

Schema description coverage is 100%, so date and include_timeseries are fully documented in the schema, establishing a baseline of 3. The description adds no param-specific detail beyond the schema (e.g., no extra guidance on timeseries sampling or date edge cases) — the band ranges it supplies are output semantics, not parameters.

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?

States a specific verb and resource ('Get one calendar day's Garmin stress') and enumerates what is returned (average/max 0-100, seconds in each band, optional readings). An agent can immediately distinguish it from overview or trend tools.

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?

Explicitly names when to use it ('stress detail on one date') and routes the agent to three clearly differentiated alternatives (get_daily_summary, get_recovery, get_recovery_trend) with the condition that selects each.

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