Garmin Dynamic MCP

Overview Schema Source Related Servers Discussions Admin

List Garmin endpoints

list_endpoints

Read-onlyIdempotent

Discover which Garmin Personal API endpoints the server can call and inspect their parameters, verification, and sensitivity status; optionally filter results with a case-insensitive query.

Instructions

List the Garmin Personal API endpoints this server can call, with their parameters.

query: optional case-insensitive text matched against path and summary (e.g. "sleep").

Each entry has: path, summary, params (name, location 'path' or 'query', required, type), verified (whether the endpoint was tested against a real account), disabled (sensitive endpoints are off unless GARMIN_MCP_ENABLE_SENSITIVE=1) and, when known, max_range_days (longer date ranges are split automatically). Date parameters use YYYY-MM-DD. If the answer contains update_available, tell the user once (version and how to update).

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": "list_endpoints"
  }
}

Input Schema

Name	Required	Description	Default
`query`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.2Nov 13, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's job is to add context, and it does: it discloses the per-entry fields, that sensitive endpoints are disabled unless GARMIN_MCP_ENABLE_SENSITIVE=1, that long date ranges are auto-split per max_range_days, and the YYYY-MM-DD format. The only notable gaps are whether results are paginated or how large the catalog is.

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?

It is front-loaded with the purpose, then the parameter meaning, then the return shape and operational notes. Every sentence carries information an agent needs (search semantics, safety gating, date format, auto-splitting, the update_available nudge), with no filler.

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?

It is complete enough to call without inspecting anything further: the parameter is defined, the disabled entry condition is stated, and the important agent-facing behavior (telling the user about update_available) is spelled out. Because an output schema exists, listing entry fields is somewhat redundant, though it usefully annotates the semantics of 'disabled' and 'verified'.

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 carries the full burden for the single 'query' parameter, and it does: 'optional case-insensitive text matched against path and summary (e.g. "sleep")' defines matching semantics, case behavior, and which fields are searched. A minor gap is whether partial or substring matching applies.

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 description gives a specific verb and resource: 'List the Garmin Personal API endpoints this server can call, with their parameters.' That is unambiguous about what the tool returns. It does not explicitly contrast with the sibling 'get' tool (which presumably invokes an endpoint), so the sibling differentiation is left implicit.

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?

Usage is implied rather than stated: the query example ('sleep') signals this is the discovery/search entry point for endpoints, and the field list hints at why an agent would call it. There is no explicit statement of when to use this versus the 'get' sibling, and no exclusions.

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

getA
list_endpointsA