Garmin Health MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific health and fitness data domains, such as activities, health summary, heart rate zones, race predictions, sleep, training load, and VO2 max. There is no overlap in functionality, and an agent can easily differentiate between them based on their descriptive names and scopes.
Naming Consistency5/5
All tool names follow a consistent 'get_' prefix pattern with descriptive nouns, such as get_activities, get_health_summary, and get_heart_rate_zones. This uniformity makes the tool set predictable and easy to navigate, adhering to a clear verb_noun convention throughout.
Tool Count5/5
With 7 tools, the server is well-scoped for a health and fitness data domain, covering key aspects like activities, sleep, training metrics, and predictions. Each tool serves a distinct purpose without redundancy, making the count appropriate and manageable for the server's intended use.
Completeness4/5
The tool set provides comprehensive read-only coverage for retrieving health and fitness data, including summaries, detailed metrics, and predictions. A minor gap exists in the lack of write or update operations, but for a data retrieval-focused server, this is reasonable and agents can work effectively with the available tools.
Average 3.1/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data but doesn't mention whether it's read-only, has rate limits, requires authentication, or how it handles errors. For a data retrieval tool with zero annotation coverage, this is a significant gap in behavioral context.
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?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words and gets straight to the point, though it could be slightly more structured by explicitly separating scope from data details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain the return format, error handling, or behavioral traits, which are crucial for a tool with three parameters. For a data retrieval tool in a health/fitness context, more detail on data scope and limitations would improve completeness.
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?
The input schema has 100% description coverage, clearly documenting all three parameters. The description adds minimal value beyond the schema by implying filtering by activity type and date range, but doesn't provide additional context like default behaviors or parameter interactions. Baseline 3 is appropriate when the schema does the heavy lifting.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('activity breakdown'), specifying what data is retrieved (counts, distances, durations). However, it doesn't explicitly differentiate from sibling tools like 'get_health_summary' or 'get_training_load', which might also provide activity-related data, leaving some ambiguity about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, prerequisites, or specific contexts for usage, leaving the agent to infer based on tool names alone. This lack of explicit when/when-not instructions reduces its utility for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Get sleep statistics' which implies a read-only operation, but doesn't address permissions, rate limits, error conditions, or response format. For a tool with zero annotation coverage, this is a significant gap in transparency.
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?
The description is concise and front-loaded, stating the core purpose in the first clause. The second sentence adds optional filtering information. Both sentences earn their place, though it could be slightly more structured (e.g., by explicitly noting parameters are optional).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'sleep statistics' includes beyond 'average duration and total nights tracked,' nor does it cover behavioral aspects like permissions or error handling. For a tool with no structured metadata, this leaves significant gaps for an agent.
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?
The description adds minimal value beyond the input schema, which has 100% coverage. It mentions 'Optionally filter by date range,' aligning with the two parameters (start_date, end_date) but doesn't provide additional context like default behavior or date format details. With high schema coverage, the baseline score of 3 is appropriate.
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 clearly states the tool's purpose: 'Get sleep statistics including average duration and total nights tracked.' It specifies the verb ('Get') and resource ('sleep statistics') with concrete metrics. However, it doesn't explicitly differentiate from sibling tools like 'get_health_summary' which might also include sleep data, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: 'Optionally filter by date range.' It doesn't specify when to use this tool versus alternatives like 'get_health_summary' or other sibling tools, nor does it mention prerequisites or exclusions. This leaves the agent with little context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'get' operation, implying read-only behavior, but doesn't address critical aspects like authentication needs, rate limits, data freshness, or error conditions. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves in practice.
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?
The description is appropriately sized with two sentences that efficiently convey the tool's purpose and define VO2 max. It's front-loaded with the core functionality, though the second sentence could be integrated more seamlessly. There's minimal waste, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It explains what VO2 max is but doesn't cover return values, error handling, or data format. Without annotations or output schema, more context on behavioral traits would improve completeness, but it meets basic requirements for a read operation.
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?
The description adds no parameter-specific information beyond what's already in the input schema, which has 100% coverage with clear descriptions for start_date, end_date, and sport. Since schema_description_coverage is high (>80%), the baseline score is 3, as the description doesn't compensate with additional semantic context like date range defaults or sport filtering nuances.
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 clearly states the tool's purpose: 'Get VO2 max history and trends' with the specific resource (VO2 max) and verb (get). It distinguishes VO2 max as a measure of cardiovascular fitness in ml/kg/min, which helps differentiate it from siblings like get_heart_rate_zones or get_health_summary. However, it doesn't explicitly contrast with siblings beyond defining VO2 max.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_health_summary or get_activities, which might also contain fitness data. It lacks context about prerequisites, such as whether VO2 max data is available only for certain users or time periods, and offers no explicit when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data (implying read-only behavior) but doesn't mention any behavioral traits such as authentication requirements, rate limits, data freshness, or error conditions. For a tool with no annotations, this leaves significant gaps in understanding how it operates.
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?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key data included. It's front-loaded with the main action ('Get training load data') and adds necessary detail without redundancy. Every word earns its place, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving calculated metrics), no annotations, no output schema, and 1 parameter with full schema coverage, the description is minimally adequate. It explains what data is fetched and its purpose, but lacks details on output format, behavioral constraints, or integration with sibling tools. This leaves room for improvement in completeness.
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?
The input schema has 100% description coverage, with the 'days' parameter documented as 'Number of days (default: 30)'. The description doesn't add any meaning beyond this, as it doesn't explain how the 'days' parameter affects the training load calculation or the acute/chronic ratio. With high schema coverage, the baseline score of 3 is appropriate.
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 clearly states the tool's purpose: 'Get training load data' specifies the verb and resource, and 'including acute/chronic workload ratio to assess overtraining risk' adds valuable context about what specific data is retrieved and its purpose. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_activities' or 'get_health_summary', which might also provide related fitness data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions assessing overtraining risk, which implies a use case, but doesn't specify prerequisites, compare it to sibling tools, or indicate when not to use it. For example, it doesn't clarify if this should be used instead of 'get_activities' for workload analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks details on traits like whether it's read-only (implied by 'Get'), requires authentication, has rate limits, or returns data in a specific format. This is a significant gap for a tool with no structured safety hints.
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?
The description is a single, efficient sentence that front-loads the core action ('Get personalized heart rate training zones') and adds necessary detail ('based on max HR and lactate threshold'). There is zero waste, making it appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally complete. It states the purpose clearly but lacks behavioral context and usage guidelines. For a fitness data tool, more details on output format or integration with siblings would enhance completeness, but it's adequate for basic understanding.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by specifying the basis for calculations ('max HR and lactate threshold'), which clarifies the tool's logic beyond the empty schema. This compensates well for the lack of parameters.
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 clearly states the tool's purpose: 'Get personalized heart rate training zones' with specific criteria ('based on max HR and lactate threshold'). It distinguishes from siblings like get_activities or get_sleep by focusing on heart rate zones, but doesn't explicitly differentiate from similar tools like get_health_summary or get_training_load, which might overlap in fitness data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies usage for heart rate zone calculation but doesn't specify contexts (e.g., training planning vs. health monitoring) or exclusions (e.g., if other tools like get_training_load might be better for broader metrics). This leaves the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] predicted race times,' implying a read-only operation, but doesn't clarify if it requires specific permissions, how predictions are generated (e.g., algorithm details), latency, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
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?
The description is a single, efficient sentence that front-loads the core action ('Get predicted race times') and includes essential details (distances and fitness basis) without waste. Every word contributes to understanding the tool's purpose, making it appropriately sized and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (predictive analysis based on fitness) and lack of annotations and output schema, the description is minimally adequate. It covers the purpose and output types (race times for specific distances) but doesn't explain how predictions are derived, what data sources are used, or the format of results. For a predictive tool with no structured output, more detail would improve completeness, but it meets the baseline for a simple read operation.
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?
The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description adds value by specifying the types of race distances predicted (5K, 10K, etc.) and the basis ('current fitness'), which provides context beyond the empty schema. This compensates adequately for the lack of parameters, earning a high score as it clarifies what the tool does without redundant parameter info.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('predicted race times'), specifying the distances (5K, 10K, half marathon, marathon) and the basis ('based on current fitness'). It distinguishes from siblings like get_activities or get_health_summary by focusing on race predictions rather than raw data or summaries. However, it doesn't explicitly differentiate from all siblings (e.g., get_training_load might overlap in fitness assessment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing fitness data from other tools), exclusions, or comparisons to siblings like get_vo2max (which might relate to fitness metrics). Usage is implied by the phrase 'based on current fitness,' but this is vague and lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what data is included but lacks behavioral details such as data freshness, rate limits, authentication requirements, or error handling. For a read operation with zero annotation coverage, this is a significant gap in transparency.
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?
The description is a single, efficient sentence that front-loads the core purpose ('Get an overview of all health data') and lists specific data types without waste. Every word contributes to understanding the tool's scope, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (aggregating multiple data types) and lack of annotations/output schema, the description is minimally adequate. It covers what data is included but misses details like response format, data granularity, or how it differs from combining sibling tools. For a read-only tool with no structured metadata, it should provide more context.
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?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, focusing on the tool's purpose instead. Baseline is 4 for zero parameters, as it avoids unnecessary repetition.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('overview of all health data'), listing key data types (VO2 max, activities, sleep, race predictions). It distinguishes from siblings by aggregating multiple data types, unlike single-focus tools like get_vo2max or get_sleep, though it doesn't explicitly contrast them.
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?
The description implies usage for a comprehensive health summary, suggesting it's an alternative to calling multiple sibling tools individually. However, it lacks explicit guidance on when to use this vs. specific tools (e.g., if only sleep data is needed) or any prerequisites/exclusions, leaving usage context somewhat inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![garmin-mcp-server MCP server](https://glama.ai/mcp/servers/willc121/garmin-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/willc121/garmin-mcp-server)

Score Badge

Copy to your README.md:

[![garmin-mcp-server MCP server](https://glama.ai/mcp/servers/willc121/garmin-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/willc121/garmin-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/willc121/garmin-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server