Provides comprehensive access to Garmin Connect data including sleep analytics, health metrics (steps, heart rate, stress, body battery), activities, and training volume analysis.
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-connect-mcp Get my daily health overview for yesterday"
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 provides comprehensive access to Garmin Connect data including sleep analytics, health metrics, activities, and training volume analysis. Perfect for building AI-powered fitness insights, training analysis, and health tracking applications.
Related MCP server: mcp-garmin
This MCP server connects your AI assistant (Claude Desktop, Claude Code, or any MCP-compatible client) directly to your Garmin Connect account, enabling:
Real-time Health Insights: Access sleep, heart rate, steps, stress, and body battery data
Training Analytics: Aggregate training volume by week, month, or custom date ranges
Activity Analysis: Retrieve detailed activity data with filtering and pagination
Multi-metric Summaries: Get comprehensive daily health overviews
Tech Stack: TypeScript, Node.js 20+, MCP SDK, garmin-connect library
Detailed sleep stages (deep, light, REM, awake)
Sleep scores and quality metrics
Duration and timing analysis
Summary and detailed modes
Steps: Daily step counts, goals, and progress tracking
Heart Rate: Resting HR, max HR, zones, and time-series data
Body Composition: Weight tracking and body composition
Stress & Recovery: Stress levels and body battery metrics
Recent activity lists with filtering
Detailed activity information (splits, laps, metrics)
Activity-specific data (distance, duration, pace, elevation)
Pagination support for large datasets
Weekly training aggregation (ISO week standards)
Monthly training summaries
Custom date range analysis (up to 365 days)
Activity type filtering (running, cycling, swimming, etc.)
Trend analysis (week-over-week, month-over-month)
Sport-specific breakdowns
Garmin Connect Account: Active account with data from a compatible Garmin device
Node.js: Version 20 or higher
MCP Client: Claude Desktop, Claude Code, or another MCP-compatible application
No installation required! Configure directly in your MCP client:
Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"garmin-connect": {
"command": "npx",
"args": ["-y", "garmin-connect-mcp@latest"],
"env": {
"GARMIN_USERNAME": "your_username",
"GARMIN_PASSWORD": "your_password"
}
}
}
}Claude Code:
Using the Claude Code CLI (recommended):
claude mcp add garmin-connect npx garmin-connect-mcp@latest \
--env GARMIN_USERNAME=your_username \
--env GARMIN_PASSWORD=your_passwordOr manually configure (.claude/mcp.json in your project):
{
"mcpServers": {
"garmin-connect": {
"command": "npx",
"args": ["-y", "garmin-connect-mcp@latest"],
"env": {
"GARMIN_USERNAME": "your_username",
"GARMIN_PASSWORD": "your_password"
}
}
}
}The -y flag automatically accepts the npx prompt, ensuring smooth startup.
Install globally via npm:
npm install -g garmin-connect-mcp@latestThen configure without npx:
{
"mcpServers": {
"garmin-connect": {
"command": "garmin-connect-mcp",
"env": {
"GARMIN_USERNAME": "your_username",
"GARMIN_PASSWORD": "your_password"
}
}
}
}For development or testing local changes:
git clone <repository-url>
cd garmin-connect-mcp
pnpm install
pnpm buildConfigure with absolute path:
{
"mcpServers": {
"garmin-connect": {
"command": "node",
"args": ["/absolute/path/to/garmin-connect-mcp/dist/index.js"],
"env": {
"GARMIN_USERNAME": "your_username",
"GARMIN_PASSWORD": "your_password"
}
}
}
}Or use a .env file:
{
"mcpServers": {
"garmin-connect": {
"command": "node",
"args": ["/absolute/path/to/garmin-connect-mcp/dist/index.js"],
"envFile": "/absolute/path/to/garmin-connect-mcp/.env"
}
}
}get_daily_overviewGet a comprehensive daily summary including sleep, activities, and health metrics in one call.
Parameters:
date (optional): Date in YYYY-MM-DD format (defaults to today)
Example:
Show me my daily overview for yesterdayResponse includes:
Sleep summary (duration, quality, stages)
Activity summary (count, total duration, distance)
Health metrics (steps, heart rate, stress, body battery)
get_sleep_dataGet detailed sleep information including sleep stages, movements, and quality metrics.
Parameters:
date (optional): Date in YYYY-MM-DD format (defaults to today)
summary (optional): Return only summary data (default: false)
fields (optional): Specific fields to include (e.g., ['dailySleepDTO', 'wellnessEpochSummaryDTO'])
Example:
Get my detailed sleep data for 2025-01-15
Show me a sleep summary for last nightResponse includes:
Total sleep duration
Sleep stages (deep, light, REM, awake) with durations
Sleep scores and quality ratings
Start/end times
Movement data (when summary: false)
get_sleep_durationQuick access to total sleep duration for a specific date.
Parameters:
date (optional): Date in YYYY-MM-DD format (defaults to today)
Example:
How many hours did I sleep last night?get_health_metricsGet aggregated health metrics for a specific date.
Parameters:
date (optional): Date in YYYY-MM-DD format (defaults to today)
metrics (optional): Array of specific metrics ['steps', 'weight', 'heart_rate', 'stress', 'body_battery'] (defaults to all)
Example:
What are my health metrics for today?
Show me just my steps and heart rate for yesterdayResponse includes:
Steps data (count, goal, distance)
Heart rate (resting, max, zones)
Stress levels
Body battery percentage
Weight and body composition
get_steps_dataGet detailed step count and activity data.
Parameters:
date (optional): Date in YYYY-MM-DD format (defaults to today)
summary (optional): Return only summary data (default: false)
Example:
Show me my step data for today
How many steps did I take yesterday?Response includes:
Total steps
Daily goal and progress percentage
Distance covered
Active time
Hourly breakdown (when summary: false)
get_heart_rate_dataGet detailed heart rate measurements and zone data.
Parameters:
date (optional): Date in YYYY-MM-DD format (defaults to today)
summary (optional): Return only summary data (default: false)
Example:
What was my heart rate today?
Show me my heart rate zones for yesterdayResponse includes:
Resting heart rate
Maximum heart rate
Average heart rate
Heart rate zones and time in each zone
Time-series measurements (when summary: false)
get_weight_dataGet weight and body composition data.
Parameters:
date (optional): Date in YYYY-MM-DD format (defaults to today)
Example:
What's my current weight?
Show me my weight for last weekResponse includes:
Weight (kg/lbs)
BMI
Body fat percentage
Muscle mass
Body water percentage
get_activitiesGet a list of recent activities with optional filtering and pagination.
Parameters:
start (optional): Starting index for pagination (default: 0)
limit (optional): Number of activities to return, max 50 (default: 20)
summary (optional): Return compact summary format (default: false)
Example:
List my last 10 activities
Show me my recent runs
Get activities 20-40 (for pagination)Response includes:
Activity ID and name
Activity type (running, cycling, swimming, etc.)
Start time and duration
Distance, pace, speed
Calories and elevation gain
Heart rate data
Splits and laps (when summary: false)
get_activity_detailsGet comprehensive information for a specific activity.
Parameters:
activityId (required): The unique ID of the activity
Example:
Show me details for activity 12345678
Give me the full breakdown of my last runResponse includes:
Complete activity metadata
Detailed splits and laps
Heart rate zones
Cadence, power, and other sensor data
GPS/route information
Weather conditions
get_weekly_volumeGet aggregated training volume for a specific ISO week.
Parameters:
year (optional): Year (defaults to current year)
week (optional): ISO week number 1-53 (defaults to current week)
includeActivityBreakdown (optional): Include per-sport breakdown (default: true)
includeTrends (optional): Compare with previous week (default: false)
maxActivities (optional): Max activities to process, up to 2000 (default: 1000)
activityTypes (optional): Filter by activity types (e.g., ['running', 'cycling'])
Example:
What was my training volume this week?
Show me week 42 of 2024 with trends
Compare my running volume this week vs last weekResponse includes:
Week number and date range
Total metrics (duration, distance, calories, elevation)
Activity count
Breakdown by activity type
Week-over-week trends (when includeTrends: true)
get_monthly_volumeGet aggregated training volume for a specific month.
Parameters:
year (optional): Year (defaults to current year)
month (optional): Month number 1-12 (defaults to current month)
includeActivityBreakdown (optional): Include per-sport breakdown (default: true)
includeTrends (optional): Compare with previous month (default: false)
maxActivities (optional): Max activities to process, up to 2000 (default: 1000)
activityTypes (optional): Filter by activity types
Example:
What was my training volume in January?
Show me this month's cycling volume
Compare my training this month vs last monthResponse includes:
Month name and date range
Total metrics (duration, distance, calories, elevation)
Activity count
Breakdown by activity type
Month-over-month trends
get_custom_range_volumeGet training volume for any custom date range (up to 365 days).
Parameters:
dateRange (required): Date range as YYYY-MM-DD/YYYY-MM-DD
includeActivityBreakdown (optional): Include per-sport breakdown (default: true)
includeDailyBreakdown (optional): Include day-by-day breakdown (default: false)
maxActivities (optional): Max activities to process, up to 2000 (default: 1000)
activityTypes (optional): Filter by activity types
Example:
What was my training volume from 2025-01-01 to 2025-01-31?
Show me my running volume for the last 90 days
Give me a daily breakdown for the past 2 weeksResponse includes:
Date range and period length
Total metrics across the range
Activity count
Breakdown by activity type
Daily breakdown (when includeDailyBreakdown: true)
What's my daily overview for today?Show me my sleep quality for the past week
Compare my deep sleep from Monday vs TuesdayHow much did I run this month?
Compare my weekly volume: this week vs last week
What's my total training time for Q1 2025?List my last 20 activities
Show me all my runs from January with heart rate data
What was my fastest 5K in the past 6 months?Get my weekly running volume with trends for week 15 of 2025
Show me daily breakdown of cycling for 2025-03-01/2025-03-31
What are my health metrics (just steps and heart rate) for yesterday?For large activity lists, use pagination:
// Get activities 0-49
get_activities({ start: 0, limit: 50 })
// Get activities 50-99
get_activities({ start: 50, limit: 50 })Filter training volume by specific sports:
get_weekly_volume({
activityTypes: ['running', 'cycling'],
includeTrends: true
})Compare periods to track progress:
// Week-over-week comparison
get_weekly_volume({ includeTrends: true })
// Month-over-month comparison
get_monthly_volume({ includeTrends: true })Control response size and detail level:
// Quick summary
get_sleep_data({ summary: true })
// Full detailed breakdown with time-series
get_sleep_data({ summary: false })The server automatically validates response sizes and provides fallback summaries if data exceeds limits. For large date ranges, consider:
Using summary: true mode
Filtering by specific activity types
Reducing date ranges
Disabling detailed breakdowns
# Development
pnpm install # Install dependencies
pnpm build # Build for production
pnpm dev # Watch mode with auto-rebuild
# Quality Checks
pnpm typecheck # Run TypeScript type checking
pnpm lint # Lint code
pnpm lint:fix # Auto-fix linting issues
# Testing
pnpm test # Run tests in watch mode
pnpm test:run # Run tests once
pnpm test:coverage # Generate coverage reportgarmin-connect-mcp/
āāā src/
ā āāā client/ # Garmin Connect API client
ā āāā tools/ # MCP tool implementations
ā ā āāā overview-tools.ts
ā ā āāā sleep-tools.ts
ā ā āāā health-tools.ts
ā ā āāā activity-tools.ts
ā ā āāā activity-volume-tools.ts
ā āāā types/ # TypeScript type definitions
ā āāā utils/ # Helper functions
ā āāā index.ts # Main server entry point
āāā dist/ # Built output
āāā __tests__/ # Test files# Run all tests
pnpm test:run
# Run with coverage
pnpm test:coverage
# Watch mode for development
pnpm testBest Practices:
ā Use environment variables for credentials
ā
Use .env files (ensure .env is in .gitignore)
ā
Use MCP configuration env or envFile options
ā Never hardcode credentials in configuration files
ā Never commit credentials to version control
Create a .env file in the project root:
GARMIN_USERNAME=your_username
GARMIN_PASSWORD=your_passwordFor local development, use .mcp.json (gitignored):
{
"mcpServers": {
"garmin-connect": {
"command": "node",
"args": ["./dist/index.js"],
"envFile": ".env"
}
}
}The server includes automatic rate limiting and error handling for Garmin Connect API:
Small delays between batch requests (100ms)
Graceful error handling for failed requests
Maximum activity limits to prevent overwhelming the API
Authentication Failed
Verify credentials in .env file
Check that MCP configuration points to correct .env or has correct env values
Ensure Garmin account is active and accessible
No Data Returned
Verify your Garmin device has synced recently
Check that you're querying dates with actual data
Ensure your Garmin account has the requested data types
Response Too Large
Use summary: true for condensed results
Reduce date ranges for volume queries
Filter by specific activity types
Disable detailed breakdowns (includeActivityBreakdown: false)
Server Not Starting
Ensure Node.js version is 20 or higher
Run pnpm build to rebuild after changes
Check server logs for authentication errors
Contributions are welcome! Please ensure:
All tests pass (pnpm test:run)
Type checking passes (pnpm typecheck)
Code follows existing style guidelines
New features include tests
MIT
Current version: 0.1.0
For updates and changelog, see the releases page.
Create a structured running workout in Garmin Connect. Build workouts with warmup, intervals, recovery, cooldown, and repeat blocks. Supports time-based, distance-based, and lap-button durations. Supports pace, HR zone, and no-target intensity controls.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Workout name (required) | |
| description | No | Optional workout description | |
| steps | Yes | Array of workout steps (required, at least one step) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only lists features already present in the schema. It does not disclose behavioral traits such as permissions needed, side effects, rate limits, or what happens on success/failure.
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?
Three sentences, but the second and third merely list schema enum values (step types, duration types, target types). Could be more concise by omitting redundant details.
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 creation tool with no output schema, the description does not explain return values (e.g., created workout ID), error conditions, or integration context. The nested step structure is complex, but the description does not guide construction.
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 coverage is 100%, so baseline is 3. The description repeats enum values from the schema (step types, duration types, target types) but does not add new semantic meaning beyond what the schema already provides.
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 'Create a structured running workout in Garmin Connect' with specific details on supported features like warmup, intervals, and targets. It clearly distinguishes from sibling tools (e.g., delete_workout, schedule_workout).
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 explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use, or refer to sibling tools like get_workout_details for viewing existing workouts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a workout from Garmin Connect library. This also removes the workout from all calendar dates where it was scheduled. This operation cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| workoutId | Yes | The workout ID to delete (from create_running_workout or get_scheduled_workouts response) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states the operation is permanent, cannot be undone, and also removes the workout from all calendar dates. This provides good behavioral transparency for a delete action.
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?
Three sentences efficiently convey the main action, key side effect, and permanence. No wasted words, and the most important information is front-loaded.
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 simple single-parameter tool with no output schema, the description sufficiently covers behavior and side effects. Minor gap: does not hint at response format (e.g., success indicator), but overall complete.
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 coverage is 100%, and the schema description already specifies where to obtain the workoutId. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.
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 ('permanently delete') and resource ('workout from Garmin Connect library'). It distinguishes from sibling tools like create_running_workout (create), get_workout_details (read), and unschedule_workout (remove from calendar only), as it specifies permanent deletion and calendar removal.
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 does not provide explicit guidance on when to use this tool versus alternatives like unschedule_workout (which only removes from calendar) or when not to use it. No prerequisites or conditions are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of recent activities with optional filtering and pagination
| Name | Required | Description | Default |
|---|---|---|---|
| start | No | Starting index for pagination (default: 0) | |
| limit | No | Maximum number of activities to return (max 50, default: 20) | |
| includeSummaryOnly | No | Return compact summary format instead of detailed data (default: false) | |
| summary | No | [DEPRECATED: Use includeSummaryOnly] Return compact summary format instead of detailed data (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the tool lists activities with filters and pagination, lacking disclosure on read-only nature, definition of 'recent', or potential side effects. The behavior is under-described.
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?
Single sentence that is front-loaded with the verb and resource. No extraneous information. Every word serves a purpose.
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?
The description is minimal; it does not explain what 'activities' are, how they are sorted, or whether results are limited to a recent timeframe. Without an output schema, details about return format or behavior are missing, but complexity is low.
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 coverage is 100%, so each parameter is already documented in the schema. The description adds 'optional filtering and pagination' but does not provide additional meaning beyond the schema's descriptions. Baseline score of 3 is appropriate.
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?
Description clearly states the tool's function: 'Get list of recent activities with optional filtering and pagination'. It specifies a distinct resource ('activities') and differentiates from siblings like 'get_activity_details' or 'get_daily_overview'.
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?
Description implies usage for listing recent activities but provides no explicit guidance on when to use this tool over others (e.g., when to use 'get_activity_details' for a single activity). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information for a specific activity
| Name | Required | Description | Default |
|---|---|---|---|
| activityId | Yes | The unique ID of the activity to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states it retrieves information, but omits details about side effects, permissions, or what constitutes 'detailed information'. Minimal behavioral disclosure.
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 concise sentence with no unnecessary words. It is appropriately front-loaded but could benefit from slightly more detail without sacrificing conciseness.
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 output schema and many sibling tools, the description lacks completeness. It does not specify what kind of details are returned, making it hard for an agent to determine if this tool meets the need for specific data like metrics or workout details.
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% with a clear description for 'activityId'. The tool description adds no extra semantic value 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves detailed information for a specific activity. The verb 'Get' and resource 'detailed information for a specific activity' are specific, but it does not explicitly differentiate from siblings like 'get_activities' which likely returns a list. However, the tool name and parameter imply a single resource.
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 on when to use this tool versus alternatives like 'get_activities' or 'get_workout_details'. The description provides no contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive daily overview including sleep, activities, and health metrics
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date in YYYY-MM-DD format (defaults to today) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full behavioral burden. It only states what data is included but does not disclose behavioral traits such as authentication requirements, rate limits, or what happens on dates with missing data. Since it describes a read operation, destructive behavior is not an issue, but transparency is minimal.
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 (11 words) that front-loads the key action and scope. Every word is necessary. No redundant or verbose phrasing. This is an exemplar of conciseness given the tool's simplicity.
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 has one optional parameter, no output schema, and no annotations, the description is moderately complete. It lists high-level categories (sleep, activities, health metrics) but does not detail which specific health metrics are included. It provides a general idea but lacks precision on exact outputs, which is acceptable for a high-level overview 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?
Schema description coverage is 100% for the single parameter 'date', already including format and default behavior. The description adds no additional meaning beyond the schema. Baseline score of 3 applies because the parameter is well-documented in the schema, and the description provides no extra semantic 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 tool's purpose: 'Get a comprehensive daily overview including sleep, activities, and health metrics.' This specifies the action (get), resource (overview), and scope (sleep, activities, health metrics), distinguishing it from more granular sibling tools like get_sleep_data or get_activities.
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?
Usage guidelines are only implied: the description suggests using this when an overview of daily metrics is needed, but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, though siblings provide more specific data. The single optional parameter with a default makes usage simple but leaves room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregated health metrics for a specific date
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date in YYYY-MM-DD format (defaults to today) | |
| metrics | No | Specific metrics to include (defaults to all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only status, performance implications, or data aggregation method. It merely repeats the function name.
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 sentence with no wasted words. It is front-loaded and concise.
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 output schema and no annotations, the description is adequate but lacks details on output format or aggregation specifics. It could be more helpful for an agent to understand the returned data.
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 coverage is 100%, and parameters have descriptions in the schema. The tool description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.
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', resource 'aggregated health metrics', and constraint 'for a specific date'. It distinguishes itself from sibling tools like get_heart_rate_data or get_hydration_data, which focus on individual metrics.
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 such as individual metric tools. The description does not mention use cases or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed heart rate data for a specific date
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date in YYYY-MM-DD format (defaults to today) | |
| includeSummaryOnly | No | Return only summary data instead of detailed breakdown (default: false) | |
| summary | No | [DEPRECATED: Use includeSummaryOnly] Return only summary data instead of detailed breakdown (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'Get' (implying read-only) but does not disclose any other behavioral traits such as rate limits, authentication needs, or what 'detailed' vs 'summary' means in terms of output structure.
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?
A single sentence is very concise and front-loaded with the key action. However, it could be expanded slightly to cover key behavioral aspects without being verbose. It earns a 4 for efficiency but not a 5 due to the sacrifice of completeness.
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 output schema and no annotations, the description should explain return values and behavior (e.g., what detailed vs summary includes). It does not mention that 'date' defaults to today (though schema does). The description is too sparse to be considered complete for a tool with multiple parameters and possible outputs.
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. The description adds the word 'detailed' which relates to the includeSummaryOnly parameter, but this is minimal extra meaning. The baseline of 3 is appropriate as the description does not significantly enhance understanding beyond the schema.
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 'Get detailed heart rate data for a specific date', specifying the verb and resource. However, it does not differentiate from sibling tools like 'get_health_metrics' which might also return heart rate data, so it loses one point for lack of 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. There is no mention of prerequisites, context, or explicit exclusions. The agent has to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get daily hydration (water intake) data for a specific date
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date in YYYY-MM-DD format (defaults to today) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states 'get', implying read-only, but offers no details on permissions, side effects, or other behavioral traits beyond what the name suggests.
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?
A single sentence delivers the core purpose without any superfluous words. Every word earns its place.
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 (one optional parameter, no output schema), the description is reasonably complete. The schema covers the default behavior and format. However, a brief note about the output (e.g., total water volume) would enhance completeness.
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% (single 'date' parameter already described in input schema). The description ('for a specific date') adds no new meaning beyond the schema's 'Date in YYYY-MM-DD format (defaults to today)'. Baseline 3 applies.
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 'Get daily hydration (water intake) data for a specific date', specifying the verb, resource, and scope. It distinguishes from sibling tools like get_sleep_data by focusing on hydration, though it does not explicitly differentiate alternatives.
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 (e.g., get_health_metrics). It simply states what it does without context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get scheduled workouts from Garmin Connect calendar for a date range. Defaults to the current week (Monday to Sunday) if dates not provided. Returns list of scheduled workouts with details including scheduleId for unscheduling.
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | No | Start date in YYYY-MM-DD format (optional, defaults to current week Monday) | |
| endDate | No | End date in YYYY-MM-DD format (optional, defaults to current week Sunday) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It notes return includes scheduleId, but lacks details on rate limits, authentication, or response when no workouts found. Adequate but not rich.
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?
Two efficient sentences: first states purpose, second provides defaults and key return detail. No wasted words, front-loaded.
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?
No output schema, but description states return includes list with scheduleId. Covers usage for optional params and default behavior. Could mention more details about returned fields, but sufficient for typical retrieval.
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 has 100% description coverage, and description adds meaningful context about defaulting to current week (Monday to Sunday). This adds value beyond the schema's parameter descriptions.
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?
Clearly states verb 'Get', resource 'scheduled workouts', and scope 'for a date range'. Distinguishes from siblings like schedule_workout and unschedule_workout, and implies differentiation from get_workout_details.
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?
Provides context on default date range behavior, but does not explicitly contrast with other get tools like get_activities or get_workout_details. No clear when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed sleep data for a specific date from Garmin Connect
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date in YYYY-MM-DD format (defaults to today) | |
| includeSummaryOnly | No | Return only summary data instead of detailed breakdown (default: false) | |
| summary | No | [DEPRECATED: Use includeSummaryOnly] Return only summary data instead of detailed breakdown (default: false) | |
| fields | No | Specific fields to include (e.g., ['dailySleepDTO', 'wellnessEpochSummaryDTO']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It implies a read-only operation but does not disclose any behavioral traits such as side effects, rate limits, or error behavior. The description adds minimal value beyond the 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, clear sentence with no superfluous words. It is front-loaded and efficient.
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 has no output schema and four parameters, the description is minimal. It lacks information about return format, data structure, or edge cases. While the schema covers parameters, the agent may need more context on what 'sleep data' entails.
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 coverage is 100%, so baseline is 3. The description does not comment on parameters; it adds no semantic value beyond what the schema already provides.
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 identifies the tool as retrieving sleep data for a specific date from Garmin Connect. However, it does not differentiate from sibling tools like get_health_metrics or get_heart_rate_data, which also retrieve data by date.
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 other health-related get tools. The description lacks context for appropriate usage or conditions where it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get training stress balance (TSB), chronic training load (CTL), and acute training load (ATL) for a specific date. TSB = CTL - ATL indicates form/freshness. Uses HR-based TSS calculation when available, falls back to duration estimates.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Target date in YYYY-MM-DD format (defaults to today) | |
| days | No | Number of days of historical data to analyze (default: 90, min: 7, max: 365) | |
| includeTimeSeries | No | Include daily time series data showing TSS, CTL, ATL, TSB progression (default: true) | |
| includeSummaryOnly | No | Return only summary data without time-series (default: false) | |
| summary | No | [DEPRECATED: Use includeSummaryOnly] Return only summary data without time-series (default: false) | |
| restingHR | No | Custom resting heart rate for TSS calculation (default: 50 bpm) | |
| maxHR | No | Custom maximum heart rate for TSS calculation (default: 185 bpm) | |
| thresholdHR | No | Custom threshold heart rate for TSS calculation (default: 90% of maxHR) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the core behavior: TSB calculation, reliance on HR-based TSS with fallback to duration estimates. It does not cover potential side effects or auth needs, but the read-only nature is clear and the calculation logic is transparent.
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?
Two sentences that front-load the key outputs (TSB, CTL, ATL) and provide a concise explanation. Every word is meaningful, with no repetition or fluff.
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 8 optional parameters, no output schema, and no annotations, the description adequately covers the tool's functionality, calculations, and fallback behavior. An AI agent can determine when to use it and what to expect.
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 coverage is 100%, so baseline is 3. The description adds value by explaining the TSB formula and fallback calculation, which goes beyond the parameter descriptions. For example, it clarifies how the parameters like HR settings relate to the output metrics.
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 identifies the tool as retrieving training stress balance (TSB), chronic training load (CTL), and acute training load (ATL) for a specific date, and explains the formula TSB = CTL - ATL. This distinguishes it from siblings like get_activities or get_workout_details, which serve different purposes.
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 effectively communicates the tool's use case (assessing training form/freshness via TSB) and explains the calculation methods. While it doesn't explicitly state when not to use it or list alternatives, the sibling tools are sufficiently disparate that confusion is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get weekly training volume aggregation for a specific week
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year (defaults to current year) | |
| week | No | ISO week number (defaults to current week) | |
| includeActivityBreakdown | No | Include breakdown by activity type (default: true) | |
| includeTrends | No | Include comparison with previous week (default: false) | |
| maxActivities | No | Maximum number of activities to process (default: 1000) | |
| activityTypes | No | Filter by specific activity types (e.g., ['running', 'cycling']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as data freshness, authentication requirements, or processing limits. The tool's behavior (e.g., aggregation method) is unclear.
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?
Single sentence, front-loaded with verb and resource. No redundancy, though it could be slightly more specific without becoming verbose.
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?
With 6 parameters, no output schema, and no annotations, the description is too minimal. It does not explain what the aggregation returns (e.g., total distance, duration, count) or how parameters like 'includeTrends' affect 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?
Schema coverage is 100% with each parameter described inline. The description adds no additional meaning beyond the schema, such as how parameters interact or how 'maxActivities' affects volume calculation.
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?
Description clearly states the tool retrieves weekly training volume aggregation, distinguishing it from sibling tools like get_activities (individual activities) or get_daily_overview (daily data). The term 'volume aggregation' is unambiguous in 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?
No guidance on when to use this tool vs alternatives (e.g., get_activities for raw data, get_daily_overview for daily summaries). The description 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 weight and body composition data for a specific date
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date in YYYY-MM-DD format (defaults to today) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It indicates a read operation (Get) but does not disclose behavioral details such as handling of missing dates, multiple records, or error cases. The default behavior is only hinted in the parameter schema, not the description.
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, concise sentence with no redundant words, efficiently conveying the tool's purpose.
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?
Despite simplicity and no output schema, the description leaves the agent unaware of the return structure (e.g., which body composition fields). For a tool retrieving multiple metrics, this is incomplete.
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?
Parameter schema coverage is 100% with a clear description for the date parameter. The main description adds no extra meaning beyond what the schema already provides, so score is at baseline.
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 the resource 'weight and body composition data', and specifies the scope 'for a specific date'. This uniquely identifies the tool among siblings like get_heart_rate_data or get_hydration_data.
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 does not mention any conditions, prerequisites, or comparisons to sibling tools like get_health_metrics or get_daily_overview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information for a specific workout including steps, targets, and duration. Returns the complete workout structure with formatted step information.
| Name | Required | Description | Default |
|---|---|---|---|
| workoutId | Yes | The workout ID to retrieve details for (from create_running_workout or get_scheduled_workouts response) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description implies a read operation but adds minimal behavioral context beyond stating it returns 'complete workout structure'. It does not disclose potential errors, rate limits, or data freshness, but for a simple retrieval tool this is adequate.
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?
Two concise sentences front-load the purpose and immediately specify return content. No extraneous words or redundancy.
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 (one required parameter, no output schema), the description adequately conveys the returned data. It could mention error handling or existence guarantees, but the current level is sufficient for a straightforward retrieval.
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 coverage is 100% and the parameter description provides context by linking to other tools. The tool description adds no further semantic value beyond what the schema already provides, meeting the baseline.
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 retrieves detailed information for a specific workout, listing steps, targets, and duration. It distinguishes itself from sibling tools like 'get_activities' or 'get_daily_overview' by focusing on a single workout's structure.
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 such as 'get_scheduled_workouts' or 'get_activity_details'. The description does not mention prerequisites or scenarios where this tool is preferred, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a workout to a specific date in Garmin Connect calendar. Use the workoutId from create_running_workout response.
| Name | Required | Description | Default |
|---|---|---|---|
| workoutId | Yes | ID of the workout to schedule (from create_running_workout response) | |
| date | Yes | Date to schedule workout in YYYY-MM-DD format (e.g., '2025-10-13') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing behavioral traits such as whether it overwrites existing schedules, requires specific permissions, or has side effects. For a mutation tool, this is insufficient.
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, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose and key prerequisite.
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 simple tool with two parameters and no output schema, the description covers the necessary context: the action, the resource, and the dependency on create_running_workout. It is adequately complete for the tool's complexity.
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 coverage is 100%, so the schema already documents both parameters. The description reiterates the source of workoutId and the date format but adds minimal new semantic value beyond the schema.
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 'Schedule' and the resource 'workout to a specific date in Garmin Connect calendar'. It also references the prerequisite use of workoutId from create_running_workout, distinguishing it from siblings like delete_workout or unschedule_workout.
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 explicit context by instructing the agent to use the workoutId from create_running_workout response, indicating the workflow order. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a workout from Garmin Connect calendar. The workout remains in your library for future scheduling. Use the scheduleId from get_scheduled_workouts response.
| Name | Required | Description | Default |
|---|---|---|---|
| scheduleId | Yes | The schedule ID (from get_scheduled_workouts 'scheduleId' field) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses that the workout is removed from calendar but persists in library, indicating non-destructive behavior. However, no details on errors, permissions, or side effects are provided.
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?
Two sentences, front-loaded with the action, no wasted words. Every sentence contributes essential information.
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 low complexity (one parameter, no output schema), the description is adequately complete. It covers the purpose, parameter source, and effect on the library. Could be improved with failure scenarios, but not essential.
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 already describes scheduleId with 100% coverage. The description adds value by specifying the source ('from get_scheduled_workouts response'), clarifying where to obtain the ID.
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?
Description clearly states 'Remove a workout from Garmin Connect calendar' with a specific verb and resource, and distinguishes from siblings like delete_workout by noting the workout remains in library.
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?
Provides clear guidance to use 'scheduleId from get_scheduled_workouts response', which helps in correct invocation. Lacks explicit exclusion or when-not-to-use compared to delete_workout, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are mostly distinct, but get_daily_overview overlaps with multiple individual metric tools (e.g., get_sleep_data, get_health_metrics), potentially causing confusion about which to use for a specific metric.
All tools use a consistent snake_case verb_noun pattern (e.g., get_activities, create_running_workout, unschedule_workout), making the naming predictable and easy to navigate.
16 tools is slightly above the ideal range but still reasonable given the domain covers activities, workouts, health metrics, and scheduling; no tool feels superfluous.
The set lacks update functionality for any resource and omits some common Garmin metrics like steps or floors, though the core read/create/delete/schedule workflow for workouts is covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Remote MCP server for training, nutrition, wellness, and performance data with OAuth 2.0.
MCP server for Withings health data ā sleep, activity, heart, and body metrics.
Pace is a remote MCP server that exposes wearable and fitness data to Claude via the Model Context Protocol. It connects to Garmin, Oura, Whoop, Polar, Fitbit and 20+ devices and provides 15 tools for querying sleep, activity, recovery, and training data. Hosted on Google Cloud Run, OAuth 2.1 authentication, Streamable HTTP transport. Instructions: First you need to create an account at: https://pacetraining.co and connect your wearables. After that you can connect the remote Server via Custom Connector in Claude and OAuth 2.1 Flow startet.
Multi-tenant hosted MCP server for Oura Ring ā 21 read-only tools, OAuth per user.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/epodivilov/garmin-connect-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server