mcp-garmin-connect

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Tools generally target distinct data types (recovery, sleep, stress, activities, load, fitness). However, composite tools like get_health_summary and get_full_snapshot overlap with individual metrics, and get_running_summary vs get_monthly_running_stats could be confused. Descriptions provide guidance, so most tools are distinguishable.
Naming Consistency5/5
All tools follow a consistent 'get_' prefix with clear noun suffixes (e.g., get_recovery, get_sleep, get_activity_detail). The naming pattern is uniform and predictable.
Tool Count4/5
14 tools is within the expected range for a Garmin Connect server and covers all major data domains. However, some redundancy (e.g., get_health_summary and get_full_snapshot) means a few tools could be consolidated, slightly reducing focus.
Completeness5/5
The server provides comprehensive read-only coverage of Garmin Connect: recovery, sleep, stress, activities, activity details, training load, fitness metrics, zones, records, and running-specific summaries. There are no obvious missing data types for a read-only health/fitness API.
Average 2.9/5 across 14 of 14 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 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
This repository is licensed under MIT License.
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?
With no annotations available, the description must disclose behavioral traits. It only says 'snapshot' which implies a read-only aggregate, but it does not describe what data is fetched, whether it is expensive, how the load_days and activity_days parameters affect the result, or what the response structure looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is technically concise, but it is under-specified and acts as a vague label rather than an informative summary. It uses words that sound comprehensive without actually conveying any concrete details, so the space is not well utilized.
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?
For an aggregation tool that could replace many sibling calls, the description is severely incomplete. It lacks scope details, parameter semantics, usage context, and relationship to the sibling tools. The existence of an output schema does not compensate for the missing behavioral and usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain load_days or activity_days. The parameter names hint at time ranges, but the agent cannot determine their precise meaning, acceptable units, or how they alter the snapshot without additional documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Comprehensive Garmin data snapshot for holistic analysis' conveys an all-encompassing data retrieval, but it lacks an explicit action verb and doesn't specify which data domains are included. It does not meaningfully distinguish itself from sibling tools like get_sleep or get_stress, other than by the generic 'full' label.
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 instead of or in combination with the sibling tools. The description does not mention scenarios such as 'when you need all data at once' or contrast with single-domain tools.
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 'normalized sport-aware summary fields', which gives some insight into the response structure, but does not disclose important aspects like whether this is a read-only operation, how pagination works (though limit/days params exist), or any rate limits. The absence of side-effect warnings is a gap since mutation tools would need such disclosure, but here the tool appears read-only; still, the description does not explicitly state that.
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 sentence, front-loaded with the core purpose ('Recent Garmin activities') and adds a meaningful qualifier about the output fields. It is efficient and avoids redundancy. However, it is arguably too sparse, sacrificing essential details for brevity, but the conciseness itself is well-executed.
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?
The tool has an output schema, so the description need not explain return values, but it should still provide enough context for an agent to know when to invoke it. The description lacks usage guidelines and parameter semantics, and while the output schema may cover the return shape, the description does not connect the tool's purpose to the available parameters. The low parameter coverage and missing guidance make it incomplete for a tool with only two optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'days' or 'limit' parameters at all. The description only says 'recent', which implies a time window but does not explain how the 'days' parameter controls that window or what 'limit' does. With no parameter documentation in either the schema or description, the agent has no way to know how to set these parameters correctly.
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 identifies that the tool returns recent Garmin activities, and the phrase 'normalized sport-aware summary fields' adds specificity about the output format. It distinguishes from sibling tools like get_activity_detail (which likely returns a single activity's detail) by implying a summary-level list. However, it lacks an explicit verb like 'retrieve' or 'list', and the differentiation from siblings is only implicit.
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 such as get_activity_detail or get_training_load. It does not mention any prerequisites, exclusions, or scenarios where this tool is preferred. The only hint is 'recent', which is vague. Without explicit usage context, an agent may not know if this is the right tool for a given query.
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, the description must disclose behavior but only says data is 'returned'. It does not explain whether the data is live, filtered, or what scope personal records cover, nor any side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief—a single fragment—but this brevity results in under-specification. It lacks a clear verb or complete sentence structure, making it less useful despite being short.
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 rich set of sibling tools and no annotations, the description is inadequate. It fails to clarify what 'personal records' means, when to use this tool, or what distinguishes it from similar health/fitness tools.
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?
With zero parameters, the schema fully covers the invocation contract (none required). The description adds no parameter info, but no params minimizes the need; baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that personal records are returned from Garmin Connect, giving a resource and source, but uses no imperative verb and lacks specificity about what constitutes 'personal records'. It does not distinguish from siblings like get_fitness or get_running_summary.
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 only identifies the resource, offering no context or exclusions.
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. It does not state that the tool is read-only, nor does it describe any behavioral characteristics such as data range, aggregation, or limitations. The 'days' parameter that controls the summary window is not mentioned, leaving the agent uninformed about how the operation behaves.
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, concise sentence that immediately lists the key contents of the summary. It is well-structured and front-loaded with the most important information, with no unnecessary words.
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?
While an output schema exists to cover return values, the description is incomplete given the available context. It does not explain the 'days' parameter, does not distinguish from sibling tools like get_monthly_running_stats, and lacks usage guidance. The tool is simple, but the missing parameter semantics and context leave significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'days' has zero description coverage in the tool description. The schema provides type and default but no semantic meaning. The description fails to explain what 'days' represents or how it affects the summary, offering no value beyond the schema.
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 indicates a running summary with specific metrics (sessions, distance, pace, HR, etc.). The purpose is evident but lacks an explicit verb like 'get' or 'list' in the description itself. It doesn't explicitly distinguish it from siblings like get_monthly_running_stats, but the metric list provides some differentiation.
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. There is no mention of preferred scenarios, prerequisites, or exclusions. The description is purely a noun phrase without any usage context.
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 must disclose behavioral traits itself. It mentions that stats are 'based on recent activities,' which hints at computation from activity data, but it does not explain how activities are aggregated, what 'calendar-ish' means, or whether historical data is required. No side effects or data dependencies are described, leaving significant gaps.
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 with no redundant words. It leads with the core purpose ('Monthly running stats') and conveys the essential time scope, making it well-structured and appropriately sized for the tool's simplicity.
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?
Although an output schema exists, the description lacks sufficient context for an agent to confidently use the tool. It does not clarify the semantics of 'calendar-ish' or 'recent activities,' and with no annotations, the agent cannot assess safety or prerequisites. The sparse description leaves notable gaps in usage and behavioral understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'months' parameter, so the description must compensate. It uses 'N' in the text, which likely corresponds to the months parameter, but it does not explicitly confirm this mapping or explain the default value. The agent cannot be certain how to set this parameter correctly.
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 that the tool provides monthly running statistics over a recent time range, which distinguishes it from sibling tools like get_running_summary or get_recent_activities. However, 'calendar-ish months' is vague and the specific metrics included are not mentioned, leaving some ambiguity about the exact output.
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 gives no explicit guidance on when to use this tool versus alternatives such as get_running_summary or get_recent_activities. It lacks any mention of prerequisites, exclusions, or comparative context, so the agent receives no direction 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?
No annotations are provided, so the description carries the full burden. It only says 'detailed summary' without disclosing what metrics are included, whether any side effects exist, or the response format. This is minimal behavioral disclosure for a data-retrieval tool.
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?
One concise sentence with no redundant words. It is front-loaded with 'Detailed summary' and immediately clarifies the key identifier, making it easy to scan.
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?
While an output schema exists, the description is otherwise minimal. It lacks usage guidance, behavioral detail, and sufficient parameter semantics. For a tool with one parameter and no annotations, this is adequate but leaves clear gaps in when and how to use it.
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 schema has one parameter with 0% description coverage. The description clarifies that the parameter is a Garmin activity ID, adding meaning beyond the bare schema. However, it does not provide format, range, or examples, so it only partially compensates for the coverage gap.
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 indicates the tool returns a detailed summary for one activity, and specifies the unique identifier (Garmin activity ID). It distinguishes this from sibling tools like get_recent_activities, though it lacks an explicit verb like 'retrieves' or 'gets'.
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 on when to use this tool versus alternatives, such as get_recent_activities for listing activities. The description implies you need a specific activity ID but does not state prerequisites, use cases, or exclusions.
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, the description carries the full burden of behavioral disclosure, but it provides minimal detail. It does not explain what 'compact' means, how the combination works, or what the output structure is, leaving the agent to guess about the tool's behavior.
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, concise sentence with no wasted words. It is front-loaded and easy to parse. However, it omits important contextual details, so it is efficient but not fully comprehensive.
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?
Despite having an output schema, the description is incomplete. It does not provide usage guidelines or parameter semantics, and the tool has multiple similar siblings. More context is needed for an agent to confidently select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'days' with 0% description coverage. The tool description does not mention this parameter at all, so the agent gets no additional semantic context about how 'days' affects the result. The parameter name alone is insufficient.
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?
The description clearly states that this tool provides a compact health snapshot combining recovery, sleep, and stress. It uses a specific verb ('get' implied) and resource ('health summary'), and the combined scope distinguishes it from sibling tools like get_recovery, get_sleep, and get_stress.
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 when-to-use guidance is provided. The description implies a combination use case but does not explicitly mention alternatives or when not to use this tool. Given the large sibling set, this lack of guidance could confuse an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. It discloses that the tool returns daily all-day stress levels and stress duration buckets, which is useful behavioral context. However, it does not explain what 'stress duration buckets' mean, whether there are any side effects, or any time-related nuances like timezone handling.
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 concise sentence with no filler words. 'Daily all-day' is slightly redundant, and the phrase lacks a verb, but overall it is appropriately short and front-loaded with the key term 'stress'.
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?
The tool is simple, but the description fails to provide enough context for the meaning of 'stress duration buckets' or how the 'days' parameter works. Given the presence of many sibling tools, it does not help the agent decide when to select this tool over others. While an output schema exists, the description still leaves gaps in parameter semantics and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes one optional parameter 'days' with a default of 7, and schema description coverage is 0%. The description says 'Daily' which hints that the parameter likely controls the number of days of data, but it never explicitly explains the parameter's meaning or format. Since coverage is low, the description should compensate, but it only indirectly relates to the parameter.
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 identifies the resource (stress) and the scope (daily all-day levels, duration buckets), which distinguishes it from siblings like get_recovery and get_sleep. However, it lacks an explicit verb such as 'retrieves' or 'returns', instead using a noun phrase.
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. With sibling tools for related metrics (recovery, sleep, activities), it does not mention when stress data is needed or when other tools would be more appropriate, nor does it note any exclusions.
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 should disclose behavioral traits like read-only nature, data source, or units. It merely lists output metrics without any behavioral context. There is no contradiction, but the description fails to carry the transparency burden.
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 concise phrase, listing three key metrics. It is front-loaded and contains no fluff. However, it's so brief that it verges on being a title rather than a descriptive sentence, so it doesn't earn a 5.
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?
The tool is simple (0 params, output schema present), but the description could offer more context about what these metrics represent or how they're calculated. It's enough to know the tool returns fitness data, but it lacks clarity on scope or source. An output schema may fill the gap, but the description alone is minimal.
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 zero parameters, and the input schema is empty. Per the rubric, a baseline of 4 applies for 0 params. The description doesn't need to explain parameters, and it doesn't, which is acceptable.
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 identifies the tool's purpose: it provides VO2 max, cycling FTP, and race predictions. These specific metrics distinguish it from sibling tools like get_recovery or get_sleep. Though it's a noun phrase rather than a full sentence, the meaning is unambiguous.
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?
There is no guidance on when to use this tool versus alternatives. It doesn't state 'for fitness metrics' or recommend get_recovery for recovery data. The agent must infer usage solely from the listed metrics and sibling names.
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, the description must carry the transparency burden. It only states that data is aggregated, without disclosing whether this is a safe read operation, what data sources are involved, or any potential side effects or limitations. The description is too sparse to inform the agent about behavioral traits beyond the basic aggregation.
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 concise sentence that is front-loaded with the key concept ('Training volume aggregated by sport') and avoids any wasted words. It is appropriately sized for a simple tool with one parameter.
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?
The tool is relatively simple with one parameter and an output schema present, so the description does not need to explain return values. However, it lacks context about how this relates to sibling tools (e.g., get_training_load) and what 'training volume' specifically means (units, sport types). The output schema may fill some gaps, but the description alone is minimally complete.
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 schema has one parameter 'days' with a default of 28 but no description field (0% coverage). The description's 'last N days' implies that 'days' represents the time window, adding meaning that the schema lacks. However, it does not explain the default value, allowed range, or format, leaving some ambiguity.
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 function: 'Training volume aggregated by sport over the last N days.' It specifies the resource (training volume), the aggregation dimension (by sport), and the time window (last N days). This distinguishes it from siblings like get_training_load, which likely focuses on overall load without sport breakdown.
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 explicit guidance on when to use this tool vs alternatives. It does not mention exclusions or refer to sibling tools like get_training_load or get_recent_activities. The usage context is only implied by the description, offering no help for an agent deciding between similar tools.
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 present, so the description carries full responsibility. It discloses the data content but does not indicate whether this is a read-only operation, whether it has any latency or prerequisites, or any other behavioral traits. A simple getter like this would benefit from a statement about it being a read-only snapshot.
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, front-loaded phrase that directly names the resource and its key components. Every word adds value, with no filler or unnecessary elaboration.
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?
For a tool with zero parameters and an output schema present, the description adequately identifies the resource and enumerates the main data points. It could optionally clarify that it returns only the current state, but the tool's simplicity makes the description sufficient.
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 zero parameters, and the schema coverage is 100% with empty properties. Since there are no parameters to explain, the description is not required to compensate; per the baseline for zero-parameter tools, a score of 4 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 identifies the specific resource (recovery state) and lists its components (readiness, HRV, sleep, body battery, and status), which distinguishes it from sibling tools like get_sleep and get_fitness. However, it uses a noun phrase rather than an explicit verb like 'Gets', making it slightly less direct than ideal.
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?
There is no guidance on when to use this tool versus its many siblings. The description simply states what it returns, leaving the agent to infer the appropriate context without any exclusions or alternatives.
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 only states that it returns sleep data for the last N days, but does not clarify whether it returns per-day values, aggregates, or any details about the output format or data source. This leaves significant behavioral ambiguity.
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, front-loaded sentence with no superfluous words. It efficiently conveys the core purpose within 10 words.
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?
For a simple read tool with one parameter and an output schema, the description provides the essential purpose. However, it lacks guidance on how to interpret 'sleep scores' and does not differentiate when to use this tool relative to closely related siblings, leaving some contextual gaps.
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 0%, so the description must compensate. The phrase 'last N days' directly explains the sole parameter (days), indicating its purpose. However, it does not provide details like valid range, inclusion of today, or behavior with edge cases, so it only partially compensates.
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?
The description clearly indicates the tool returns sleep duration and sleep scores for a specified period, distinguishing it from sibling tools like get_recovery and get_stress. Though lacking an explicit verb, the noun phrase accurately conveys the tool's purpose and scope.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives such as get_recovery or get_health_summary, nor does it offer any exclusions or prerequisites.
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 bears the full burden of disclosing behavioral traits. It only lists the data categories, but does not mention whether the operation is safe/read-only, whether any authentication is required, or any rate limits. It also doesn't describe the time period or units, though the output schema may cover those details. This falls short of the transparency expected for a tool with no annotation support.
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, compact phrase that lists exactly the essential data elements. Every word earns its place, with no filler or repetition. It is appropriately sized for a simple no-parameter getter and is easily scanned.
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?
Given the tool's simplicity (no parameters) and presence of an output schema, the description is nearly complete. It conveys the core purpose and the kind of data returned. It does not elaborate on edge cases or typical use contexts, but for a basic read-only getter, this is sufficient. A slightly more explicit statement about data scope would push it to 5.
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 zero parameters, and the schema coverage is 100% (vacuously). The baseline for 0 params is 4. The description adds no parameter-specific explanation, but none is needed since there are no parameters to clarify. The short description does not detract from schema adequacy.
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 identifies the resource as Garmin training load and lists specific components (status, acute/chronic load, load focus), which distinguishes it from sibling tools like get_recovery or get_sleep. However, it lacks an explicit verb (e.g., 'returns' or 'gets'), relying on the tool name to imply the action, so it falls just short of 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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, typical use cases, or cases where another sibling tool (e.g., get_recent_load) would be more appropriate. The only context is the data content, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavior. It adds the caveat 'when available,' which hints that data may be absent, but does not explain what happens in that case (e.g., empty response, error). There are no details on data freshness or other behavioral traits.
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, front-loaded sentence with no wasted words. It states the key subject and the availability caveat immediately, making it highly concise and well-structured.
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?
For a no-parameter read tool with an output schema, the description is compact but sufficient. It names the data type and source, and the 'when available' qualifier alerts the agent to potential non-availability. The output schema likely covers return structure.
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 zero parameters and complete schema coverage, so no parameter explanation is needed. The description adds value by specifying the types of zones (heart-rate, power) and their source (Garmin profile), enriching understanding beyond the empty schema.
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 identifies the resource (Garmin profile data) and content (heart-rate and power zones), distinguishing it from sibling tools focused on recovery, sleep, or stress. The verb is implied by the tool name but not explicitly stated, which is a minor gap.
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 gives no guidance on when to use this tool versus alternatives like get_recovery or get_training_load. It lacks context on typical scenarios or exclusions, leaving the agent to infer usage solely from the name.
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:

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

Score Badge

Copy to your README.md:

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

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/kavakoss/mcp-garmin-connect'

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