Garmin Connect 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 targets a distinct function: activities (query, details, compare, similar, period analysis, social, training effect), health data (weight, sleep, HR, activity metrics, summary, womens health, performance), and management (workouts, gear, devices, challenges, goals). No two tools have overlapping purposes, reducing ambiguity.
Naming Consistency4/5
Tools follow a verb_noun pattern, but the verbs vary (get, query, manage, log, analyze, compare, find). While each verb is appropriate for its operation, the mix of 'get_' and 'query_' for similar retrieval actions introduces minor inconsistency. Overall pattern is clear but not perfectly uniform.
Tool Count4/5
With 22 tools, the set is slightly above the typical well-scoped range (3-15) but appropriate for the breadth of Garmin Connect's capabilities. Each tool covers a distinct area without unnecessary duplication, and the number reflects the domain complexity.
Completeness5/5
The tool set covers all major Garmin Connect features: activity tracking (query, details, compare, similar, period analysis, social, training effect), health metrics (weight, sleep, HR, activity metrics, health summary, performance, womens health), and management (workouts, gear, devices, challenges, goals). No obvious gaps for core functionality.
Average 3.9/5 across 22 of 22 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 19, 2026
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only and not destructive, which is consistent with the mixed read/write actions listed. However, the description does not disclose additional behavioral traits like file format restrictions, upload size limits, or whether updates are allowed. Given annotations already cover the basic safety profile, a score of 3 is appropriate.
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 with a clear header and bulleted list. Every sentence provides value. Minor improvement could be grouping actions by type, but overall it is efficient.
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 action-specific details on return values (e.g., what list returns, download response format, upload confirmation). No error handling or prerequisites are mentioned. For a multi-action tool, this is insufficient for an agent to understand expected outcomes.
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?
Input schema has 100% coverage describing each parameter. The description lists actions and implicitly links parameters but adds no extra semantics beyond what the schema already provides. Baseline score of 3 is correct.
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 manages structured workouts and enumerates four specific actions (list, get, download, upload). However, it does not differentiate from sibling tools like query_activities or get_activity_details, which may overlap in functionality.
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 guidelines are provided. The description does not indicate when to use this tool over similar siblings, nor does it mention prerequisites or conditions for each action (e.g., need workout_id for get/download).
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?
The description adds no behavioral context beyond the annotations. Annotations indicate it is a write operation (not read-only) and not destructive, but the description does not disclose potential side effects (e.g., overwriting existing entries), required authentication, or rate limits. The requirement that data be a JSON string is noted but is more about parameter format.
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 short and front-loaded with a clear purpose. It uses bullet points to list data types efficiently. However, the final sentence 'All data should be provided as a JSON string' is slightly redundant given the schema's format description.
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 low complexity and the presence of an output schema, the description sufficiently covers the core functionality. It does not mention what happens on success (e.g., confirmation or ID), but the output schema likely handles that. It is adequate for a straightforward logging tool.
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%, so the description carries a lower burden. It marginally adds meaning by grouping required data fields per type, but the schema already provides detailed examples for each type. The description does not clarify optional fields or validation rules beyond the schema.
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 'Log health data entries' and enumerates specific data types (body_composition, blood_pressure, hydration) with required fields, making the tool's verb and resource unambiguous. It distinguishes itself from sibling query/analysis tools as a write operation.
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 like query_health_summary. There is no mention of prerequisites, limitations, or when not to use it, leaving the agent without decision support.
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?
While annotations already declare readOnlyHint=true, the description does not add further behavioral context such as possible empty results, error conditions, or rate limits. The description merely states the function without elaborating on behavior beyond what annotations offer.
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 efficiently communicates the tool's purpose.
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 simple tool with one parameter and an output schema, the description sufficiently covers the purpose and return types (likes, comments, kudos). It lacks guidance on edge cases, but the output schema likely handles return value documentation.
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 100% with the schema already documenting the activity_id parameter. The description does not add additional meaning, format details, or examples, so a baseline score of 3 is appropriate.
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 the verb 'Get', the resource 'social details for an activity', and lists specific examples (likes, comments, kudos), making the purpose distinct from sibling tools like get_activity_details.
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_details or compare_activities. There is no mention of prerequisites, exclusions, or typical scenarios.
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?
Annotations already declare readOnlyHint=true, so the description's mention of retrieving device info adds modest context (e.g., settings, solar data) beyond the safety profile. However, it does not disclose potential limitations (e.g., pagination, data freshness) or any side effects, which would elevate 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 at two sentences, with the main purpose front-loaded. It effectively summarizes the tool's capability without unnecessary words. However, it could be slightly more structured, e.g., bullet points for the included info types.
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 has 6 boolean parameters, an output schema, and annotations for read-only behavior, the description covers the high-level purpose. It does not explain how device_id=null vs specific id affects results, or the relationship between include_* parameters. More context about default behavior 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?
All 6 parameters have descriptions in the input schema, achieving 100% schema description coverage. The tool description lists the general categories of information, but does not add deeper semantic meaning or usage guidance beyond what the parameter descriptions already provide. Baseline 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 verb 'Query' and the resource 'Garmin devices', and lists specific types of information obtainable (last used device, primary training device, settings, solar data, alarms). While it distinguishes from sibling tools like query_activities or query_gear by focusing on devices, it does not explicitly differentiate why an agent would choose this over other query tools.
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 when device information is needed, but provides no explicit guidance on when to use this tool versus its siblings, nor mentions any prerequisites or context for invocation. The lack of when-not-to-use examples or alternative tool references makes it merely adequate.
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?
Annotations already declare readOnlyHint=true, so the tool is clearly safe. The description adds that the profile can include stats, PRs, and devices, but does not discuss any side effects, rate limits, or return structure. With annotations covering safety, the description provides adequate but not rich 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 11 words with no redundancy. Every word adds value.
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 simple boolean parameters and an output schema, the description is sufficient. It explains the tool's purpose and optional components. A slightly more detailed note on defaults or typical use would push it to 5.
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 each parameter has a clear description. The description briefly maps to the parameters ('optional stats, personal records, devices') but does not add new meaning beyond the schema. Baseline 3 is appropriate.
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 the tool retrieves a comprehensive user profile with optional data (stats, personal records, devices). It uses a specific verb ('Get') and resource ('user profile'), and distinguishes from sibling tools like query_devices or query_health_summary by focusing on the core profile.
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 does not provide guidance on when to use this tool versus alternatives like query_devices or query_goals_and_records. No exclusions or context for selection are given, limiting agent decision-making.
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?
Annotations already declare readOnlyHint=true. Description adds that results include defaults and usage stats, which is useful but not extensive. No contradictions.
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?
Two concise sentences, first stating the tool's action, second providing scope. No unnecessary words.
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 output schema present and only two optional boolean parameters, the description is sufficient to understand the tool's purpose and return scope.
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 describes both parameters with 100% coverage. Description mentions 'defaults and usage stats' matching the schema, but doesn't add new details beyond schema.
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?
Clearly states verb 'query' and resource 'gear and equipment', and specifies it includes defaults and usage stats. Differentiates from sibling query tools targeting other domains.
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 explicit guidance on when to use this tool versus alternatives. While sibling tools cover different data domains, the description does not explain the selection criteria.
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?
Annotations already declare readOnlyHint=true, so the description's alignment with read-only behavior is expected. The description adds the date-range context but does not disclose additional behavioral traits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action. Every word adds value. No redundancy.
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 simplicity of the tool (3 optional params, read-only, output schema present), the description adequately explains what the tool does. Minor lack of detail about return format is mitigated by the output schema.
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 100%, so the baseline is 3. The description mentions 'specific date or date range' which correlates with the three parameters but adds no new meaning beyond the schema.
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 the verb 'Query' and the resource 'weight data', and specifies the scope: 'for a specific date or date range'. It distinguishes from sibling tools like 'manage_weight_data' by focusing on retrieval.
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 'manage_weight_data' for writing or other query tools. The description does not provide usage context or exclusions.
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?
Annotations readOnlyHint=true already indicate no destructive effects. The description adds detail on the specific sleep metrics retrieved but does not disclose any additional behavioral traits such as data freshness, rate limits, or authentication requirements. The description is consistent with annotations but adds only content detail.
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, with two short paragraphs. It front-loads the main action and then lists retrieved data. Every sentence adds value, but the first line could be considered a title; overall it is 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?
Given the presence of an output schema, the description adequately explains the tool's purpose and the data it retrieves. Parameters are fully described in schema. It does not cover error conditions or prerequisites, but for a simple read-only tool, it is sufficient.
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 covers 100% of parameters with descriptions, so baseline is 3. The description confirms support for single date or date ranges, aligning with the schema, but adds no new meaning. The parameter descriptions in the schema are already clear.
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 uses the verb 'Get' with the resource 'sleep data and analysis'. It lists specific metrics, distinguishing it from sibling tools like query_health_summary which is broader. The purpose 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions support for single date or date range queries, providing basic usage context. However, it does not explicitly state when to use this tool versus alternatives like query_health_summary, nor does it provide exclusion criteria. Usage guidance is implied but not explicit.
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?
Annotations already declare readOnlyHint=true, and the description adds that it returns a pregnancy tracking summary or menstrual cycle data. However, it does not disclose other behavioral traits such as data freshness, user-specific scoping, or error handling. The added value is moderate.
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?
Three sentences with a clear front-loaded purpose and a bullet-style list. Every sentence adds value without redundancy or fluff.
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?
With an output schema present (context signal), the description does not need to detail return values. However, it creates ambiguity by implying pregnancy does not use date parameters while the schema allows them for all data types. This partial incompleteness reduces agent confidence.
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 coverage is 100%, but the description adds semantic grouping: it associates date/range with menstrual data and implies pregnancy uses a summary (though schema still allows date params for pregnancy). This context helps the agent understand parameter usage beyond raw schema definitions.
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 the tool queries women's health data and explicitly lists two data types (pregnancy and menstrual) with brief explanations. This distinguishes it from sibling tools like query_health_summary or log_health_data by focusing on specialized reproductive health metrics.
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 explicit guidance on when to use this tool versus alternatives. For example, it does not mention that query_health_summary may be more appropriate for general health queries. The description provides context but lacks exclusions or comparative guidance.
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?
Annotations declare readOnlyHint=true, which aligns with 'Get activity metrics'. The description adds context about available metrics but does not disclose other behavioral traits like data availability, pagination, or error handling. With annotations present, this is acceptable but not exceptional.
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 concise and front-loaded: three sentences covering purpose, included metrics, and usage of the metrics parameter. No unnecessary words or repetition.
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 an output schema exists (context signal), the description covers the tool's purpose, available metrics, and parameter usage. It does not mention data granularity or time zones, but these are less critical for a query tool with a well-defined schema. Overall, it is sufficiently 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?
Schema coverage is 100%, so all parameters have descriptions. The description adds marginal value by reinforcing the default metrics and their selection, but does not provide new semantic meaning beyond what the schema already offers.
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 the tool retrieves activity metrics and lists specific metrics (steps, stress, respiration, etc.). It distinguishes from sibling tools like 'get_activity_details' or 'query_heart_rate_data' by focusing on a broad set of activity metrics.
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 implicitly indicates usage by saying 'Select specific metrics to retrieve using the metrics parameter' and shows default metrics. However, it lacks explicit guidance on when to use this tool versus alternatives like 'query_health_summary' or 'get_activity_details'.
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?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the description's additional context ('based on recent training') adds mild value but does not significantly deepen behavioral understanding. No contradictions.
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?
Two crisp sentences with no wasted words. The verb is front-loaded, and the second sentence elaborates efficiently. Every word earns its place.
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 an existing output schema and simple boolean parameters, the description sufficiently covers the tool's purpose. It could mention that data is user-specific, but overall completeness is high given the supporting structured fields.
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?
All three boolean parameters are fully described in the input schema (100% coverage), achieving the baseline. The tool description adds no extra parameter semantics beyond listing the return categories, which is already implied by the parameter names.
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 the tool returns 'goals, personal records, and race predictions', using a specific verb ('Get') and identifying distinct resources. This effectively distinguishes it from sibling tools that focus on other data types like activities or metrics.
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 context (when you need goals/records/predictions) but provides no explicit comparison to alternatives or when-not-to-use guidance. It's adequate but lacks the proactive differentiation that would elevate it.
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?
Annotations already declare readOnlyHint=true, so the description does not need to reiterate safety. It adds value by describing the analytical outputs (metrics comparison, best/worst, insights) but does not disclose any additional behavioral traits like data limits or performance considerations.
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 concise (4 lines plus example) and front-loaded with the purpose. Every sentence earns its place, with no redundancy or filler.
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?
The tool has an output schema (context signal indicates true), so return values are covered there. The description adequately covers input (activity_ids, unit) and output intent (metrics, best/worst, insights). For a comparison tool, this is 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?
Schema coverage is 100%, so the schema already documents both parameters. The description adds an example for activity_ids but does not elaborate on unit or any additional constraints beyond the schema. Baseline 3 is appropriate as the description adds marginal value.
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 the tool compares multiple activities side-by-side, specifies the range (2-5 activities), and lists outputs like metrics comparison and best/worst identification. It distinguishes from siblings like get_activity_details (single activity) or find_similar_activities (similarity, not side-by-side comparison).
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 explains what the tool does but does not explicitly state when to use it versus alternatives. Among siblings, find_similar_activities is a potential alternative for similarity, but no exclusion or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=true, and the description aligns with a read operation. It adds details on the metrics included, providing useful context beyond annotations.
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?
Three concise sentences with front-loaded purpose. No redundant information; every sentence adds value.
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?
For a read-only tool with 8 optional parameters and an output schema, the description adequately covers the tool's capabilities and usage patterns.
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 100%, so the description adds minimal value. It groups parameters into date range and metric toggles, which is helpful but not essential.
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 'Get comprehensive performance metrics' and lists specific metrics (VO2 max, hill score, etc.), distinguishing it from sibling tools like get_activity_details or query_health_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 explicit guidance on when to use this tool versus siblings like query_activity_metrics or get_training_effect. The description implies usage for single-date or date-range queries but lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds transparent details: default inclusions, split computation logic for single-lap activities, and that exercise sets are excluded by default. No contradictions with annotations.
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 clear and front-loaded with the main purpose. It uses natural language with reasonable brevity, though it could be more structured (e.g., bullet points). No redundant information.
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?
Given the output schema exists, the description adequately explains tool behavior (default inclusions, special cases) and is complete for a fetch tool with this complexity. No missing critical information.
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% so baseline is 3. The description adds minor context (e.g., why include_exercise_sets defaults false, split computation nuance) but does not significantly enhance understanding beyond schema descriptions.
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 the tool gets comprehensive details for a specific activity, differentiating it from sibling tools like query_activities which likely return summaries. It specifies what is included by default and what requires explicit request.
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 explains parameter behaviors (e.g., exercise sets only when requested, splits computed for single lap) but does not explicitly state when to use this tool versus alternatives like get_training_effect or compare_activities. Usage context is implied but not contrasted.
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?
The description 'Query' aligns with the readOnlyHint=true annotation, indicating no mutation. No additional behavioral context (e.g., pagination, data freshness) is provided beyond annotations, so this dimension is adequate but not enhanced.
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 extremely concise (two sentences) and front-loaded with the core purpose. Every sentence is necessary and efficient, with no superfluous text.
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 (2 optional parameters, 100% schema coverage, output schema exists), the description provides sufficient context for an agent to understand what the tool does and how to use it, though it could mention that results are read-only.
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 description coverage is 100%, so the baseline is 3. The description merely restates the parameter options ('status (active/available/earned) and type (badge/adhoc/virtual)') without adding new meaning or usage nuances beyond the schema.
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 'Query challenges and badges' and specifies the filter parameters (status and type). This directly distinguishes it from sibling tools like query_activities or get_activity_details, which handle different data.
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?
The description explicitly mentions filtering by status and type, giving clear context for use. However, it does not provide explicit when-not-to-use or alternative tool names, though sibling differentiation is inherent due to unique subject matter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by specifying the data fields returned (resting HR, average HR, min/max) and query flexibility (single date or range). It is consistent with readOnlyHint and does not contradict annotations, though it could mention pagination or data availability.
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 extremely concise: two short sentences that front-load the core purpose ('Get heart rate data') and immediately provide necessary details. Every word earns its place with no redundancy or 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?
Given the tool's relatively simple nature (4 optional parameters, read-only, existing output schema), the description adequately covers the essential context: what data is retrieved and query modes. It is complete enough for an agent to select and invoke correctly, though it could mention supported date formats or error cases.
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?
With 100% schema description coverage, the baseline is 3. The description does not add new meaning beyond the schema's parameter descriptions; it merely restates the date range support. No additional value is provided for parameters like 'include_resting'.
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 the tool's purpose with a specific verb ('Get'), resource ('heart rate data'), and elaborates on what is included (resting HR, average HR, min/max values). It distinguishes from sibling tools (e.g., query_sleep_data) by focusing on heart rate, making selection unambiguous.
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 retrieving heart rate data for single dates or ranges, but provides no explicit guidance on when to use alternatives or when not to use this tool. The context is clear enough, but lacks comparative guidance to avoid misuse.
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?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that it returns training effect and progress summary but does not disclose additional behavioral traits (e.g., no side effects, data freshness). No contradiction with annotations.
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?
Extremely concise: one sentence for purpose, two bullet points for modes. Every word earns its place. Front-loaded with the main action.
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 has 0 required parameters and an output schema, the description covers the two modes adequately. However, it does not specify default behavior if no parameters are provided, or whether the modes are exclusive. Still, it is complete enough for effective use.
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 100%, but the description adds meaningful context by grouping parameters into two modes, helping the agent understand which parameters to use together. This adds value beyond raw schema.
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?
Description clearly states the tool gets 'training effect and progress summary' and identifies two distinct use cases with parameters. It differentiates from siblings like analyze_training_period and compare_activities.
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?
Explicitly explains when to use each mode: provide activity_id for specific activity, or start_date/end_date/metric for progress summary. Does not explicitly state when not to use or mention alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly explains behavioral traits beyond the readOnlyHint annotation: it covers pagination mechanics, response structure for both single date and range modes, and includes a concrete JSON schema. No contradictions with annotations.
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?
Well-structured with clear sections and front-loaded purpose. The pagination instructions are detailed but necessary for correct usage. Could be slightly more concise, but the trade-off for clarity is acceptable.
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?
Given the tool's complexity (9 parameters, pagination, rich output), the description is complete. It explains the output structure, pagination logic, and parameter combinations. No gaps are evident.
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 covers all 9 parameters with descriptions, achieving 100% coverage. The description adds value by explaining the interplay between parameters (e.g., date vs. start_date/end_date, cursor usage) and providing usage context that exceeds mere schema descriptions.
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 this tool retrieves a comprehensive daily health snapshot, listing included data types. While it distinguishes from sibling tools like query_sleep_data by being a summary, it could more explicitly state when to prefer this over other related queries.
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 guidance on when to use (for health snapshots, single date or range) and detailed pagination steps. However, it does not explicitly mention when not to use it or direct to alternative tools for specific metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the tool is safe. The description adds value by detailing the outputs (volume, breakdown, trends, insights), providing behavioral context beyond the annotation.
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 with a clear purpose statement, bulleted outputs, and examples. It is front-loaded and contains no unnecessary information.
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?
The description, combined with the input schema and output schema, fully covers the tool's functionality. All parameters are optional and well-documented, and the outputs are summarized. The context from siblings helps define its role.
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 coverage is 100%, so baseline is 3. The description adds example period formats, which clarifies the period parameter beyond the schema description, slightly increasing value.
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 the tool 'Analyze training over a specified period with comprehensive insights' and lists specific outputs (total volume, activity breakdown, trends, performance insights). It distinguishes itself from siblings like get_activity_details or compare_activities by focusing on period-level analysis.
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?
The description implies use for comprehensive period analysis, and the context of siblings suggests when not to use (e.g., for single activity details). However, it does not explicitly state exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and description adds similarity thresholds and output details (similarity scores, comparisons). Does not mention error cases or rate limits, but overall transparent.
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?
Concise, front-loaded with main purpose, then criteria listed, then output info. Every sentence adds value without redundancy.
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?
Has output schema, so return values not needed. Description covers what tool does, criteria, and output structure. Complete given complexity and schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. Description adds valuable details: similarity percentages (±20%, ±30%) and criteria format, going beyond schema.
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?
Description clearly states purpose: 'Find activities similar to a reference activity.' It lists specific criteria and their similarity thresholds, distinguishing it from siblings like compare_activities or query_activities.
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?
Description gives example and criteria but does not explicitly state when to use this tool over alternatives like query_activities or compare_activities. Adequate but lacks direct comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently mentions that the tool can delete entries, which is a destructive behavior. Given annotations set destructiveHint=false, the description adds useful context that deletion occurs. It does not elaborate on side effects, but the actions are straightforward.
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 extremely concise, using bullet points for actions with no extraneous words. Every sentence adds value, making it easy for an agent to parse quickly.
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 and the presence of an output schema, the description covers the essential information: actions and their required parameters. It does not detail error handling or return values, but for a basic CRUD tool, this is adequate.
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 coverage is 100%, so baseline is 3. The description adds value by mapping actions to parameters (e.g., 'provide weight' for add, 'provide weigh_in_ids' for delete), clarifying the conditional usage beyond the schema's standalone descriptions.
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 the tool's purpose: 'Add or delete weight entries.' It explicitly lists the two actions, distinguishing itself from sibling tools like query_weight_data which are read-only.
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?
The description provides explicit guidelines for each action, specifying which parameters to provide for 'add' (weight, optionally date) and 'delete' (weigh_in_ids). However, it does not explicitly state when not to use this tool (e.g., for reading data), relying on context from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description reinforces this by listing only query operations. It transparently describes pagination behavior, return structure, and filtering. No contradiction with annotations.
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 fairly long but well-organized with bullet points and sections for patterns, pagination, and return structure. It front-loads the core purpose. Minor redundancy (e.g., 'List mode only (when paginated)' could be clearer) but overall efficient.
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?
Given the output schema exists, the description covers return values. It addresses all common use cases (single, range, date, paginated, last) and filtering. Pagination guidelines are thorough. No gaps.
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 coverage is 100%, so baseline 3. The description groups parameters into meaningful patterns (e.g., activity_id for specific, start_date+end_date for range) and explains combined usage, adding semantic value beyond individual schema descriptions.
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 it queries activities with flexible parameters and pagination. It lists five distinct query patterns, making its purpose unambiguous and distinguishing it from sibling tools like get_activity_details (single activity) or analyze_training_period (analysis).
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?
The description explains when to use each query pattern (e.g., specific ID, date range, last activity). It provides pagination steps. However, it does not explicitly exclude cases where sibling tools are more appropriate, such as comparing activities or analyzing training periods.
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-connect-mcp MCP server](https://glama.ai/mcp/servers/eddmann/garmin-connect-mcp/badges/card.svg)](https://glama.ai/mcp/servers/eddmann/garmin-connect-mcp)

Score Badge

Copy to your README.md:

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

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

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