Integrates with Garmin Connect to retrieve activity data, health metrics (heart rate, sleep, stress, body battery), provide activity insights and performance analysis, and generate AI-powered training suggestions based on workout history and health data.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Garmin MCP Server analyze my running performance from the last week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that integrates with Garmin Connect to provide activity insights and training suggestions for Claude Desktop.
Activity Tracking: Retrieve recent activities from Garmin Connect
Activity Insights: Get detailed analysis of individual activities or activity patterns
Training Suggestions: AI-powered recommendations based on your training data and health metrics
Health Metrics: Access to comprehensive health data including heart rate, sleep, stress, and body battery
Performance Analysis: Automated analysis of training load, recovery, and performance trends
Related MCP server: garmin-mcp
Clone or download this repository
Install dependencies:
cd garmin-mcp
npm installBuild the TypeScript code:
npm run buildFor security and convenience, you can store your Garmin Connect credentials in environment variables:
Create a .env file:
touch .envAdd your credentials to the .env file:
# .env
GARMIN_USERNAME=your.email@example.com
GARMIN_PASSWORD=your_secure_password
GARMIN_AUTO_AUTH=trueSecure the file:
chmod 600 .envWith environment variables configured, the MCP server will:
Automatically authenticate on startup (if GARMIN_AUTO_AUTH=true)
Use your stored credentials as fallback for authentication commands
Keep your credentials secure and out of version control
Add the MCP server to your Claude Desktop configuration:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\\Claude\\claude_desktop_config.json
{
"mcpServers": {
"garmin": {
"command": "node",
"args": ["path/to/garmin-mcp/dist/index.js"]
}
}
}For the best coaching experience, add the triathlon expert prompt to your Claude project:
Create or open your project in Claude Desktop
Add the expert prompt by copying the contents of TRIATHLON_EXPERT_PROMPT.md to your project's context
Enable code execution in your project settings for accurate calculations
This prompt transforms Claude into a world-class triathlon coach that:
Uses code for all calculations to prevent estimation errors
Provides data-driven training insights
Offers personalized coaching based on your Garmin data
Analyzes performance trends with scientific accuracy
The MCP server supports multiple authentication methods:
Set up your .env file as described above. The server will automatically authenticate on startup.
Use the authenticate_garmin tool within Claude Desktop. If you have environment variables set, you can simply call:
"Please authenticate with Garmin Connect" (uses env vars)
Or provide credentials manually: "Authenticate with username X and password Y"
Important: Credentials are only stored in memory during the session and are not persisted to disk.
authenticate_garminAuthenticate with Garmin Connect using your username and password.
Parameters:
username: Your Garmin Connect username
password: Your Garmin Connect password
get_activitiesRetrieve recent activities from Garmin Connect.
Parameters:
days (optional): Number of days to look back (default: 30)
limit (optional): Maximum number of activities to return (default: 50)
get_activity_insightsGet detailed insights for a specific activity or recent activities.
Parameters:
activityId (optional): Specific activity ID to analyze
days (optional): Number of days to analyze if no activity ID specified (default: 7)
get_training_suggestionsGet AI-powered training suggestions based on recent activities and performance.
Parameters:
activityType (optional): Type of activity to focus on ('running', 'cycling', 'swimming', 'strength', 'all')
days (optional): Number of days of history to consider (default: 14)
get_health_metricsGet health and wellness metrics from Garmin Connect.
Parameters:
startDate (optional): Start date in YYYY-MM-DD format
endDate (optional): End date in YYYY-MM-DD format
metrics (optional): Specific metrics to retrieve (['heartRate', 'stress', 'sleep', 'bodyBattery', 'vo2Max'])
Authenticate: "Please authenticate with my Garmin Connect account"
View Recent Activities: "Show me my recent activities"
Get Insights: "Analyze my running performance from the last week"
Training Advice: "Give me training suggestions based on my recent workouts"
"What are my sleep patterns and how do they affect my recovery?"
"Analyze my heart rate trends during cycling activities"
"Give me specific recommendations for improving my running pace"
"How is my training load compared to my recovery metrics?"
This MCP server accesses your Garmin Connect data only during active sessions
No data is stored permanently on your device
Authentication credentials are not persisted between sessions
All data processing happens locally on your machine
@modelcontextprotocol/sdk: MCP SDK for TypeScript
garmin-connect: Unofficial Garmin Connect API client
zod: Schema validation
To run in development mode:
npm run devTo build:
npm run buildRequires valid Garmin Connect credentials
Depends on the unofficial Garmin Connect API (may break with Garmin updates)
Some advanced metrics may not be available depending on your Garmin device
Rate limiting by Garmin Connect may apply
Ensure your Garmin Connect credentials are correct
Check if your account requires two-factor authentication (not currently supported)
Verify your account is not locked or suspended
Some metrics require specific Garmin devices
Ensure your device is synced with Garmin Connect
Check that the requested date range contains activities
Verify your internet connection
Check if Garmin Connect services are operational
Try authenticating again if the session has expired
MIT License - see LICENSE file for details
Authenticate with Garmin Connect using username and password (can use environment variables)
| Name | Required | Description | Default |
|---|---|---|---|
| username | No | Garmin Connect username (optional if GARMIN_USERNAME env var is set) | |
| password | No | Garmin Connect password (optional if GARMIN_PASSWORD env var is set) |
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 authentication and environment variable usage, but fails to describe critical behaviors such as what happens on success (e.g., session token storage), error handling, rate limits, security implications, or whether this is a one-time or recurring operation. This leaves significant gaps for an AI agent to understand the tool's full behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose and key feature (environment variable support). It is front-loaded with essential information and contains no redundant or unnecessary details, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of authentication (a critical operation with security implications), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral outcomes (e.g., what is returned, how sessions are managed), error cases, prerequisites, or integration with sibling tools. This leaves the AI agent with insufficient context to use the tool effectively and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters as optional with environment variable fallbacks. The description adds minimal value beyond this by reiterating the use of username and password with environment variables, but does not provide additional semantic context (e.g., format requirements, authentication flow details). This meets the baseline score since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Authenticate with Garmin Connect') and the method ('using username and password'), which is specific and actionable. However, it does not explicitly differentiate this authentication tool from other sibling tools that might also require authentication or handle credentials differently, such as 'custom_garmin_request' which could involve authentication in a broader context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when authentication is needed, as it mentions environment variables as an alternative, but it does not provide explicit guidance on when to use this tool versus other tools (e.g., whether other tools automatically handle authentication or require this tool first). No exclusions or clear alternatives are stated, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new running workout plan
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the workout | |
| distance | Yes | Distance in meters | |
| description | Yes | Description of the workout |
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. 'Create' implies a write/mutation operation, but the description doesn't disclose any behavioral traits: no information about authentication requirements, whether this is a destructive operation, rate limits, what happens on success/failure, or what the response contains. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple creation tool and front-loads the essential information. Every word earns its place in this concise statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address what happens after creation, what the response looks like, error conditions, or any behavioral context. For a tool that presumably modifies data in a fitness tracking system, more contextual information would be helpful for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with all three parameters (name, distance, description) clearly documented in the schema. The description adds no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new running workout plan'), making the purpose immediately understandable. It distinguishes this as a creation tool rather than a retrieval or update operation. However, it doesn't explicitly differentiate from potential sibling creation tools (though none appear in the sibling list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There's no mention of prerequisites (like authentication), when this tool is appropriate versus other workout-related tools, or any constraints on its usage. The sibling list includes several workout-related tools (get_workouts, get_workout_detail, manage_activities) but no guidance is given about their relationship.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make custom API requests to Garmin Connect (advanced users)
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | HTTP method | |
| endpoint | Yes | API endpoint URL | |
| data | No | Request data (for POST requests) | |
| params | No | Query parameters (for GET requests) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'advanced users' hinting at complexity, but doesn't disclose critical behavioral traits such as authentication requirements (though 'authenticate_garmin' is a sibling), rate limits, error handling, or what types of endpoints are supported. The description is too minimal to inform safe or effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function. However, the 'advanced users' qualifier is somewhat vague and doesn't add actionable value, slightly reducing conciseness. It's front-loaded with the core purpose but could be more precise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a custom API request tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error cases, or provide context on how to construct valid requests. The minimal description leaves significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters (method, endpoint, data, params). The description adds no parameter-specific information beyond what's in the schema, such as endpoint examples or data format details. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Make custom API requests to Garmin Connect' which provides a verb ('Make custom API requests') and resource ('Garmin Connect'), but it's vague about what specific operations are possible. It distinguishes from siblings by being a generic request tool versus specific operations like 'get_activities' or 'create_running_workout', but the 'advanced users' qualifier adds ambiguity rather than clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the more specific sibling tools. It mentions 'advanced users' which implies complexity but doesn't specify scenarios where custom requests are necessary or preferable over the dedicated tools. There's no mention of prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent activities from Garmin Connect
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days to look back (default: 30) | |
| limit | No | Maximum number of activities to return (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Get recent activities' but fails to specify whether this is a read-only operation, if authentication is required, rate limits, or what the return format looks like. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient. It does not address behavioral aspects like authentication needs, rate limits, or return format, which are critical for a tool that interacts with an external service like Garmin Connect. This leaves the agent with incomplete context for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters with defaults. The description does not add any semantic details beyond what the schema provides, such as explaining the context of 'days' or 'limit'. Thus, it meets the baseline for adequate but not enhanced parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('recent activities from Garmin Connect'), making the purpose evident. However, it does not explicitly differentiate this tool from sibling tools like 'get_workouts' or 'get_activity_stats', which might also retrieve activity-related data, so it falls 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.
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 siblings like 'get_workouts' and 'get_activity_stats' available, there is no indication of context, prerequisites, or exclusions for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed insights for a specific activity or recent activities
| Name | Required | Description | Default |
|---|---|---|---|
| activityId | No | Specific activity ID to analyze (optional) | |
| days | No | Number of days to analyze if no activity ID specified (default: 7) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without disclosing behavioral traits. It doesn't mention permissions, rate limits, data freshness, or response format (e.g., JSON structure, error handling). This leaves critical operational details unspecified for a tool that likely involves data retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words, but could be slightly more structured (e.g., separating use cases). Overall, it's appropriately sized with no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely returns complex insights. It doesn't explain what 'detailed insights' include (e.g., metrics, graphs), how results are formatted, or any prerequisites (e.g., authentication). For a data analysis tool, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters. The description adds minimal value by implying the tool can handle either a specific activity ID or a time range, but doesn't provide additional context like format examples or edge cases. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get detailed insights for a specific activity or recent activities', which provides a clear verb ('Get') and resource ('insights'), but it's vague about what 'insights' entail (e.g., performance metrics, trends) and doesn't distinguish it from siblings like 'get_activity_stats' or 'get_activities'. It avoids tautology but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It mentions 'specific activity or recent activities' but doesn't clarify scenarios (e.g., use for deep analysis vs. summary stats) or exclusions, leaving the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive activity statistics and counts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read-only operation ('get'), but doesn't disclose permissions, rate limits, data freshness, or output format. This is inadequate for a tool with zero parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence without wasted words. It's appropriately sized for a simple tool, though it could be more front-loaded with critical details given the lack of annotations and output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema) but lack of annotations, the description is incomplete. It doesn't explain what 'comprehensive activity statistics' entails, how data is returned, or any behavioral constraints, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, but this is acceptable given the absence of inputs, aligning with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as retrieving 'activity statistics and counts', which is clear but vague. It specifies the resource ('activity statistics') and verb ('get'), but lacks detail on scope or type of statistics, and doesn't differentiate from sibling tools like 'get_activities' or 'get_activity_insights'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't mention context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone among many activity-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get golf performance data and scorecards
| Name | Required | Description | Default |
|---|---|---|---|
| scorecardId | No | Specific scorecard ID to retrieve (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data, implying a read-only operation, but lacks details on permissions, rate limits, data format, or error handling, which are critical for a data-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, clear sentence that front-loads the core purpose. There is no wasted language, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a data retrieval tool. It doesn't specify what 'golf performance data' entails, the format of returned data, or any behavioral constraints, leaving significant gaps in understanding how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting the optional 'scorecardId' parameter. The description adds no additional parameter semantics beyond what the schema provides, such as explaining what 'golf performance data' includes or how to interpret results, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('golf performance data and scorecards'), making it immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_activities' or 'get_workout_detail' that also retrieve data, missing full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings like 'get_activities' and 'get_workouts' that might overlap, there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get health and wellness metrics from Garmin Connect
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | No | Start date in YYYY-MM-DD format (optional) | |
| endDate | No | End date in YYYY-MM-DD format (optional) | |
| metrics | No | Specific metrics to retrieve (optional) |
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 but only states what the tool does without mentioning permissions, rate limits, data freshness, or response format. It doesn't clarify if this is a read-only operation or has side effects, which is critical 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what metrics are available (though hinted in schema), how data is returned, or authentication requirements, leaving significant gaps for the agent to understand the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting all parameters (startDate, endDate, metrics) with formats and optionality. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('health and wellness metrics from Garmin Connect'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_activities' or 'get_activity_stats', which also retrieve Garmin data but for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_activities' or 'update_health_data'. It lacks context about prerequisites (e.g., authentication) or typical use cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get AI-powered training suggestions based on recent activities and performance
| Name | Required | Description | Default |
|---|---|---|---|
| activityType | No | Type of activity to focus suggestions on (default: all) | all |
| days | No | Number of days of history to consider (default: 14) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is 'AI-powered' and based on 'recent activities and performance', but doesn't describe what the suggestions entail, how they're generated, whether they require specific permissions, or what the response format looks like. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. Every word earns its place, making it easy to scan and understand quickly. No waste or redundancy is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (AI-powered suggestions with 2 parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, or output format. It meets the minimum viable standard but has clear gaps in providing a complete picture for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters (activityType and days), including enums and defaults. The description doesn't add any parameter-specific information beyond what the schema provides, such as explaining how 'activityType' influences suggestions or what 'days' means in practice. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get AI-powered training suggestions based on recent activities and performance'. It specifies the verb ('Get'), resource ('training suggestions'), and basis ('recent activities and performance'). However, it doesn't explicitly differentiate from sibling tools like 'get_activity_insights' or 'get_workouts', which might also provide related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_activity_insights' or 'get_workouts', nor does it specify prerequisites (e.g., needing authentication or recent activity data). Usage is implied by the purpose but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed user profile and settings from Garmin Connect
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this requires authentication (though 'authenticate_garmin' exists as a sibling), what data format is returned, or if there are rate limits. The description adds minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the essential purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the key information about what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and multiple sibling tools retrieving similar data, the description is insufficient. It doesn't explain what 'detailed user profile and settings' includes, how this differs from other user data tools, or what authentication requirements exist despite 'authenticate_garmin' being a sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. This meets the baseline expectation for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and target resource ('detailed user profile and settings from Garmin Connect'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_health_metrics' or 'get_activity_stats', which also retrieve user data from the same platform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_health_metrics' and 'get_activity_stats' available, there's no indication of what distinguishes this profile retrieval from other user data queries, nor any mention of prerequisites like authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific workout
| Name | Required | Description | Default |
|---|---|---|---|
| workoutId | Yes | ID of the workout to get details for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information (implying read-only), but doesn't specify aspects like authentication requirements, rate limits, error handling, or what 'detailed information' includes (e.g., format, fields). This is a significant gap for a tool with potential dependencies and data complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with every part contributing to the core purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral traits (e.g., auth needs), output details, or usage context relative to siblings. For a tool that likely returns structured workout data, more guidance is needed to help an agent use it effectively in this server's ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'workoutId' clearly documented. The description adds no additional meaning beyond the schema (e.g., it doesn't explain ID format, sourcing, or examples). According to the rules, with high schema coverage, the baseline is 3 even without param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose ('Get detailed information about a specific workout') with a clear verb ('Get') and resource ('workout'), but it's vague about what 'detailed information' entails. It doesn't distinguish this tool from potential siblings like 'get_workouts' (which might list workouts) or 'get_activities' (which might cover broader activity data), leaving ambiguity in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing authentication via 'authenticate_garmin'), exclusions, or comparisons to siblings like 'get_workouts' (for lists) or 'get_activity_insights' (for analytical data), leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get workout plans and schedules from Garmin Connect
| Name | Required | Description | Default |
|---|---|---|---|
| start | No | Start index for pagination (default: 0) | |
| limit | No | Number of workouts to return (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't mention whether this is a read-only operation, requires authentication, has rate limits, or what the return format looks like (e.g., list of workouts). This leaves significant gaps for a tool that likely interacts with external APIs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of interacting with Garmin Connect (an external service), no annotations, and no output schema, the description is insufficient. It doesn't cover authentication needs, error handling, response structure, or how it differs from sibling tools, leaving the agent with incomplete context for proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters (start and limit) with defaults and purposes. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('workout plans and schedules from Garmin Connect'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_workout_detail' or 'get_activities', which likely retrieve different types of workout-related data, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_workout_detail' for detailed workout info or 'get_activities' for broader activity data. It lacks explicit context, prerequisites, or exclusions, leaving usage unclear relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload, delete, or modify activities
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform | |
| activityId | No | Activity ID (required for delete action) | |
| filePath | No | Path to activity file (required for upload action) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'upload, delete, or modify' implies mutation capabilities, it doesn't specify permissions required, whether operations are reversible, rate limits, or what happens on success/failure. For a tool with multiple actions including destructive ones, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, front-loaded with the core actions. There's no wasted text, though it could benefit from slightly more context given the tool's complexity. Every word earns its place by listing the key operations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions including destructive operations), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral traits, usage context, or return values, leaving significant gaps for an AI agent to understand when and how to invoke it safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters with their types, enums, and requirements. The description adds no additional meaning about parameters beyond what's in the schema (e.g., it doesn't explain what 'modify' entails or how 'count' differs from other actions). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Upload, delete, or modify activities' clearly states the tool's purpose with specific verbs (upload, delete, modify) and resource (activities). However, it doesn't distinguish this tool from its siblings like 'get_activities' or 'create_running_workout', leaving ambiguity about its specific role versus other activity-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings like 'get_activities' (for retrieval), 'create_running_workout' (for specific creation), and 'update_health_data' (for modifications), there's no indication of when this multi-action tool is preferred over more specialized ones or what prerequisites might be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update weight or hydration data in Garmin Connect
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Type of data to update | |
| value | Yes | Value to set (weight in lbs, hydration in oz) | |
| date | No | Date in YYYY-MM-DD format (optional, defaults to today) | |
| timezone | No | Timezone (optional, defaults to America/Los_Angeles) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Update' implies a mutation, but fails to describe critical aspects such as required permissions, whether the operation is idempotent, error handling, or rate limits. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, auth needs), usage context, and return values, which are essential for safe and effective tool invocation in this scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional semantic context beyond what the schema provides (e.g., it doesn't explain units or date formatting further). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the target resources ('weight or hydration data in Garmin Connect'), making the purpose immediately understandable. However, it does not explicitly differentiate this tool from potential sibling tools like 'manage_activities' or 'get_health_metrics', which could also involve health data operations, so it misses the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 prerequisites (e.g., authentication), exclusions, or comparisons to sibling tools like 'get_health_metrics' for reading data or 'manage_activities' for other updates, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0authenticate_garmincreate_running_workoutcustom_garmin_requestget_activitiesget_activity_insightsget_activity_statsget_golf_dataget_health_metricsget_training_suggestionsget_user_profileget_workout_detailget_workoutsmanage_activitiesupdate_health_dataMost tools have distinct purposes, but some overlap exists between get_activities and get_activity_insights, and between get_workouts and get_workout_detail, which could cause minor confusion. However, descriptions clarify their specific focuses, and other tools like create_running_workout and manage_activities are clearly differentiated.
The naming follows a consistent verb_noun pattern (e.g., get_activities, create_running_workout) with one exception: custom_garmin_request uses 'custom' as an adjective, slightly deviating from the pattern. Overall, it's mostly predictable and readable.
With 14 tools, the count is well-scoped for a Garmin fitness and health data server, covering authentication, activities, workouts, health metrics, and golf data. Each tool appears to serve a specific function without redundancy, fitting the domain's complexity.
The tool set provides broad coverage for Garmin Connect operations, including CRUD for activities and health data, plus specialized features like training suggestions and golf data. Minor gaps might include lack of direct workout modification or more granular health metric updates, but core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect your wearables, rings and training apps, then ask your AI about your own health data.
Garmin data in Claude & ChatGPT via the Garmin Health API. OAuth sign-in, no password sharing.
AI running coach. Reads Strava, Suunto, Polar, Apple Health or Health Connect. Adapts to your feel.
Your AI writes training plans that arrive as structured workouts on iPhone and Apple Watch.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/j4sun/garmin-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
