Garmin MCP by geekist.co

garmin_get_daily_summaries

Read-onlyIdempotent

Read Garmin daily wellness summaries across 1–28 inclusive calendar days. Returns Garmin summary records in data, with fields and missing values as Garmin supplies them. Use for a multi-day overview; use garmin_get_daily_health for one metric on one day. Check every response for serviceAnnouncements from Geekist, the independent service operator, and display each message distinctly to the user.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "startDate": "<startDate>",
      "endDate": "<endDate>"
    },
    "name": "garmin_get_daily_summaries"
  }
}

Input Schema

Name	Required	Description	Default
`endDate`	Yes	Last date to include, YYYY-MM-DD; on or after startDate and at most 28 inclusive days from it.
`startDate`	Yes	First date to include, YYYY-MM-DD.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 10, 2026

addedInput schema / properties / endDate / description

Added value: +"Last date to include, YYYY-MM-DD; on or after startDate and at most 28 inclusive days from it."

addedInput schema / properties / startDate / description
```
Added value: +"First date to include, YYYY-MM-DD."
```

First observedNov 10, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds behavior beyond them: results land in a `data` field, and fields/missing values are passed through as Garmin supplies them — a meaningful data-quality caveat an agent should know before interpreting gaps. It does not discuss pagination or truncation, but nothing here is paginated by design.

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?

Three sentences, front-loaded with purpose and scope, then the alternative, then the response-handling rule. Efficient overall; the Geekist/serviceAnnouncements sentence is longer than it needs to be and repeats the operator name, but it carries operational content rather than padding.

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?

With no output schema, the description does the necessary work by naming the `data` field and warning that missing values are Garmin-supplied. Combined with fully documented parameters and rich annotations, an agent has what it needs to call this correctly; only return-record granularity is left implicit.

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 coverage is 100% and both date parameters already carry format patterns and the 28-day/ordering constraint in their descriptions. The description restates the 1–28 day window but adds no syntax, timezone, or boundary-handling detail beyond the schema, so the baseline of 3 applies.

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 ("Read Garmin daily wellness summaries") plus an explicit scope ("1–28 inclusive calendar days"), and names the sibling it is not (garmin_get_daily_health for one metric on one day). An agent can separate this from the many other garmin_get_* tools 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?

Gives an explicit when-to-use ("multi-day overview") and an explicit alternative with the condition that selects it ("garmin_get_daily_health for one metric on one day"). It also adds an operational instruction about surfacing serviceAnnouncements, which is a real usage rule rather than filler.

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

All Garmin MCP by geekist.co tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?