Skip to main content
Glama
Sign In
garminconnect-js

garminconnect-js

by DynamicsNinja
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_daily_stats

Read-only

Fetch daily calorie or step totals from Garmin Connect for a date range; ranges over 28 days are split into 28-day windows.

Instructions

Per-day calorie or step totals; ranges over 28 days are chunked. GETs /usersummary-service/stats/daily/{start}/{end}?statsType=CALORIES|STEPS; statsType is exactly "CALORIES" or "STEPS" (any other value, lower-case included, is a Garmin 404). Garmin 400s when end - start > 27, so longer ranges are fetched in 28-day windows and the rows concatenated; Garmin's per-request aggregations (averages) are DROPPED rather than returned wrong for a chunked range. A range with no data returns [] (Garmin answers null). Overlaps getDailySteps/getCaloriesDaily; this one returns total/act…

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": {
      "start": "<start>",
      "end": "<end>",
      "statsType": "<statsType>"
    },
    "name": "get_daily_stats"
  }
}

Input Schema

NameRequiredDescriptionDefault
endYesCalendar date, YYYY-MM-DD (UTC)
startYesCalendar date, YYYY-MM-DD (UTC)
statsTypeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the rest and does so richly: case-sensitive statsType causing a 404, Garmin 400s when end-start>27, automatic 28-day chunking with concatenated rows, dropped aggregations for chunked ranges, and [] for empty ranges. This is far beyond what annotations provide.

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 the purpose then packs dense, high-value API quirks (chunking, error codes, empty-range behavior) into tight sentences. Slightly dense, but nearly every clause earns its place given the tool's non-obvious behavior.

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?

No output schema exists, and the description covers return values ([] for no data vs Garmin's null) and the dropped aggregations, plus error behavior. For a quirky, open-world read tool this is complete enough for correct invocation.

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 documents start/end but leaves statsType with only an enum and no description. The description compensates by specifying statsType is exactly "CALORIES" or "STEPS" and that lowercase or other values yield a 404, adding real meaning beyond the enum.

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?

States a specific verb+resource: per-day calorie or step totals, with the statsType distinction. It also names the overlapping siblings (getDailySteps/getCaloriesDaily), but the differentiating clause is truncated ("this one returns total/act…"), so the split from siblings is incomplete.

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?

Provides clear context: ranges over 28 days are auto-chunked and it names the alternatives it overlaps with. However the stated distinction from getDailySteps/getCaloriesDaily is cut off, so the agent can't fully resolve when to pick this one over them.

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