Click on "Deploy 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., "@Coros MCP Server Show me my last 10 runs"
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 powerful Model Context Protocol (MCP) server that provides seamless access to your Coros watch data through AI assistants like Claude Desktop and Gemini CLI.
🚨 THIS IS AN UNOFFICIAL APPLICATION
This MCP server uses unofficial, reverse-engineered Coros API endpoints that are not publicly documented or officially supported by Coros.
Use at your own risk:
❌ Not endorsed or supported by Coros
❌ API endpoints may change without notice
❌ Your account could potentially be affected
❌ No guarantees of functionality or data accuracy
By using this software, you acknowledge these risks and agree that the authors are not responsible for any issues that may arise.
Related MCP server: TrainingPeaks MCP Server
This project was inspired by and built upon the excellent work of:
strava-mcp by @r-huijts - MCP server architecture and OAuth flow patterns
coros-api by @xballoy - Coros API endpoint research and implementation
Special thanks to these projects for paving the way! 🙏
🔐 Browser-Based Authentication - Secure login flow that opens in your browser
📊 8 Powerful Tools - Comprehensive access to all your Coros data
🏃 Activity Data - Recent activities, detailed metrics, lap-by-lap analysis
💪 EvoLab Metrics - Fitness scores, training status, recovery data
📅 Training Calendar - View scheduled workouts and training plans
❤️ Training Zones - Heart rate and pace zone information
🌤️ Weather Data - Environmental conditions for outdoor activities
📈 Time-Series Data - 1Hz GPS and biometric data for deep analysis
Node.js 18.0.0 or higher
npm or yarn
A Coros account with activity data
# Clone the repository
git clone https://github.com/yourusername/coros-mcp-server.git
cd coros-mcp-server
# Install dependencies
npm install
# Build the project
npm run build
# Install globally
npm linkAfter installation, the coros-mcp-server command will be available globally.
which coros-mcp-server
# Should output: /path/to/node/bin/coros-mcp-serverFor Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"coros": {
"command": "coros-mcp-server"
}
}
}For Gemini CLI:
{
"mcpServers": {
"coros": {
"command": "coros-mcp-server"
}
}
}Close and reopen Claude Desktop or restart Gemini CLI.
In your AI assistant, simply say:
"Login to my Coros account"
The server will:
✅ Open your browser to http://localhost:8111
✅ Display a login form
✅ Save your credentials securely to ~/.config/coros-mcp/credentials.json
After logging in, tell the assistant:
"I'm logged in"
You're ready to use all the tools!
loginStart the authentication process by opening a web browser.
Parameters: None
Example:
"Login to my Coros account"
get_recent_activitiesGet a list of recent Coros activities.
Parameters:
limit (optional): Maximum number of activities (default: 20)
sportTypes (optional): Filter by sport types (e.g., ["103"] for runs)
fromDate (optional): Start date in ISO format
toDate (optional): End date in ISO format
Example:
"Show me my last 10 runs"
get_activity_file_urlGet download URL for activity files in FIT, TCX, or GPX format.
Parameters:
labelId (required): Activity ID
sportType (required): Sport type number
fileType (required): "fit", "tcx", or "gpx"
Example:
"Get the FIT file for activity 474723165319233737"
get_profileGet user profile including training zones.
Parameters: None
Returns:
Personal metrics (height, weight, age, sex)
Heart rate zones (5-6 zones with ranges)
Pace zones (lactate threshold pace)
Example:
"What are my heart rate training zones?"
get_evolab_metricsGet EvoLab fitness and recovery data.
Parameters: None
Returns:
Running fitness scores (endurance, threshold, speed, sprint)
Training status (base fitness, load impact, intensity trend)
Recovery data (percentage and remaining time)
Efficiency trends (7-day scores)
Example:
"Show me my EvoLab fitness scores and recovery status"
get_training_calendarGet training schedule for a date range.
Parameters:
startDate (required): Start date in YYYYMMDD format
endDate (required): End date in YYYYMMDD format
Returns: Scheduled workouts, rest days, completion status
Example:
"What workouts are scheduled for this week?"
get_sport_typesGet a mapping of all supported sport types.
Parameters: None
Returns: Dictionary of sport type IDs to names (e.g., 103: "Run")
Example:
"What sport types are available?"
get_activity_detailsGet comprehensive activity analysis.
Parameters:
labelId (required): Activity ID
sportType (required): Sport type number
Returns:
Summary metrics (distance, HR, power, cadence, calories, training load)
Training effect (aerobic/anaerobic), VO2 Max, efficiency
Lap-by-lap data with advanced metrics
1Hz time-series data (GPS + biometrics)
Zone distribution (HR/pace/power)
Weather conditions
Advanced running metrics (ground contact time, vertical stride ratio)
Example:
"Show me detailed metrics for my last run including lap splits and heart rate zones"
Edit config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add server configuration:
{
"mcpServers": {
"coros": {
"command": "coros-mcp-server"
}
}
}Restart Claude Desktop
Add to your Gemini CLI configuration
Restart Gemini CLI
npx @modelcontextprotocol/inspector coros-mcp-serverOpens a web interface at http://localhost:6274 for interactive testing.
User: "What are my current heart rate zones?"
Assistant: [Uses get_profile]
Response:
- Zone 1 (Recovery): 120-135 bpm
- Zone 2 (Aerobic): 135-150 bpm
- Zone 3 (Tempo): 150-165 bpm
- Zone 4 (Threshold): 165-175 bpm
- Zone 5 (VO2 Max): 175+ bpmUser: "How's my fitness and recovery?"
Assistant: [Uses get_evolab_metrics]
Response:
- Endurance: 85/100
- Recovery: 78% (5 hours remaining)
- Training Load: OptimalUser: "Analyze my last run with lap splits"
Assistant: [Uses get_recent_activities, then get_activity_details]
Response: Detailed breakdown including:
- Overall stats (distance, pace, HR)
- Lap-by-lap splits
- Heart rate zone distribution
- Weather conditionsUser: "What workouts are scheduled for next week?"
Assistant: [Uses get_training_calendar]
Response: List of scheduled workouts with dates and typesThe server communicates with the following Coros API endpoints:
Endpoint | Method | Purpose |
| POST | Authentication |
| GET | List activities |
| POST | Detailed activity data |
| POST | File download URLs |
| POST | User profile & zones |
| POST | EvoLab metrics |
| POST | Training calendar |
| GET | Sport type mappings |
Base URLs:
America: https://teamapi.coros.com
Europe: https://teameuapi.coros.com
China: https://teamcnapi.coros.com
coros-mcp-server/
├── src/
│ ├── index.ts # MCP server entry point
│ ├── lib/
│ │ ├── coros-client.ts # Coros API client
│ │ ├── config-manager.ts # Credential storage
│ │ ├── auth-server.ts # Browser-based auth
│ │ └── types.ts # TypeScript types
│ ├── config-server.ts # Alternative config UI
│ └── auth-server.ts # Standalone auth server
├── scripts/
│ └── debug-coros.ts # Debug/testing script
├── dist/ # Compiled JavaScript
├── package.json
├── tsconfig.json
└── README.md# Install dependencies
npm install
# Build TypeScript
npm run build
# Start MCP server (for testing)
npm start
# Run in development mode
npm run dev
# Debug Coros API calls
npm run debug
# Open browser-based auth
npm run auth
# Open alternative config UI
npm run config# Test with MCP Inspector
npx @modelcontextprotocol/inspector coros-mcp-server
# Test individual API calls
npm run debugAdd method to src/lib/coros-client.ts
Define tool schema in src/index.ts tools array
Add handler in the switch statement
Update this README
Build and test
# Re-link the package
cd /path/to/coros-mcp-server
npm link# Delete saved credentials
rm ~/.config/coros-mcp/credentials.json
# Login again through the browserThe auth server uses port 8111. If it's in use:
# Find and kill the process
lsof -ti:8111 | xargs kill -9# Kill any running instances
pkill -f coros-mcp-server
pkill -f inspector
# Start fresh
npx @modelcontextprotocol/inspector coros-mcp-serverCommon errors and solutions:
"Not authenticated" - Run the login tool first
"Service exceptions" - Activity ID might be invalid or too old
"Invalid credentials" - Check email/password, try logging in again
Network errors - Check internet connection and API region
# Run debug script to test API calls
npm run debug
# Check MCP server logs
# Logs are written to stderrCredentials are stored in ~/.config/coros-mcp/credentials.json
File permissions are set to 600 (owner read/write only)
Password is MD5 hashed before transmission (Coros API requirement)
User initiates login through MCP tool
Browser opens to http://localhost:8111 (local only)
User enters credentials in browser
Credentials are tested against Coros API
If successful, saved to local config file
Access token obtained and cached in memory
⚠️ Important:
This uses an unofficial Coros API
Credentials are stored locally on your machine
The auth server only runs on localhost
No data is sent to third parties
Use at your own risk
Don't share your credentials.json file
Use a strong, unique password for your Coros account
Regularly update the MCP server
Review the code before running if security is a concern
MIT License - see LICENSE file for details
Contributions are welcome! Please:
Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
Model Context Protocol by Anthropic
Coros for their fitness tracking platform
The MCP community for tools and inspiration
Issues: GitHub Issues
Discussions: GitHub Discussions
Add caching for frequently accessed data
Support for token refresh
Export data to common formats
Workout analysis and recommendations
Integration with other fitness platforms
Web dashboard for data visualization
Made with ❤️ for the Coros and MCP communities
Get comprehensive activity data including summary metrics, laps, time-series data, zones, and weather
| Name | Required | Description | Default |
|---|---|---|---|
| labelId | Yes | The activity label ID | |
| sportType | Yes | The sport type number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only lists data types included (summary metrics, laps, etc.). No disclosure of side effects, authentication needs, rate limits, or return format.
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, 12 words, no waste. Front-loaded with key verb and resource. Achieves high density of information with zero filler.
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 output schema and no annotations, the description is incomplete. It does not mention pagination, limits, or response structure, despite likely returning a complex object.
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 parameters are already described. Description adds no meaning beyond schema; it only lists outputs. 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?
Description clearly states the action 'Get' and the resource 'comprehensive activity data', listing specific data types. This distinguishes it from siblings like get_recent_activities (list) and get_activity_file_url (file download).
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. Does not mention that it is for a single activity, while get_recent_activities lists all. Lacks any when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the download URL for a specific activity file (FIT, TCX, or GPX format)
| Name | Required | Description | Default |
|---|---|---|---|
| labelId | Yes | The activity label ID | |
| fileType | Yes | File type: fit, tcx, or gpx | |
| sportType | Yes | The sport type number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but fails to disclose essential behavioral traits such as idempotency, authentication needs, or error states (e.g., what happens if the file doesn't exist). It implies a read operation but does not explicitly confirm safety.
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 redundant words. Every part contributes meaning.
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 retrieval tool with no output schema, the description adequately states the purpose but omits details about the return value format (e.g., whether the URL is temporary or direct). It is minimally 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%, so the description adds little beyond restating file type formats. It provides no additional semantics for labelId or sportType beyond what the schema already describes.
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 the resource (download URL for a specific activity file), and specifies the supported formats (FIT, TCX, GPX). This distinguishes it clearly from sibling tools like login or get_recent_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?
No guidance is provided on when to use this tool, prerequisites, or alternatives. It simply describes what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get EvoLab metrics including running fitness scores, training status, recovery data, and efficiency trends
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behaviors. It lists metric categories but does not mention any side effects, data freshness, rate limits, or whether it's a read-only operation. Minimal behavioral info.
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, well-structured, no extraneous words. Efficiently communicates the tool's scope.
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 simple tool, description lists categories but lacks return format details. Provides enough for a basic understanding, but missing clarity on data structure.
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?
Input schema has no parameters; description adds no parameter info. With 100% schema coverage, baseline 3 is appropriate. No additional meaning needed.
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 verb 'Get' and resource 'EvoLab metrics' with explicit examples (running fitness scores, training status, recovery data, efficiency trends). Distinct from siblings, no ambiguity.
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 or when not to use this tool. No mention of prerequisites, context, or alternatives among sibling tools. Agent has to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user profile including personal metrics and training zones (heart rate zones, pace zones)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation but lacks details on authentication, rate limits, or what exactly is returned beyond the mentioned metrics. Since no annotations are provided, the description carries full burden but is minimally 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?
One sentence that is front-loaded with the verb and resource, containing no extraneous information. Every word adds value.
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?
While the description mentions personal metrics and training zones, it does not specify the format or exact fields. With no output schema, more detail on return values would improve 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?
The tool has no parameters, so the description does not need to add parameter information beyond the schema. Baseline 4 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 tool retrieves user profile with personal metrics and training zones. It is specific and distinguishes from siblings like get_recent_activities or get_activity_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no context about prerequisites, exclusions, or when not to use it. Implied usage is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent Coros activities. Returns a list of workouts with basic information like date, name, and sport type.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of activities to return (default: 20) | |
| toDate | No | End date in ISO format (optional) | |
| fromDate | No | Start date in ISO format (optional) | |
| sportTypes | No | Filter by sport types (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description bears full burden. It only states return content (list of workouts with basic info) but does not disclose ordering, pagination behavior, rate limits, or that the tool is read-only. For example, it doesn't specify default sort order (likely most recent first) or what 'recent' means in absence of date filters.
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?
Description is two sentences, front-loaded with the main action, no filler. Every word serves a purpose: states what it gets and what it returns. Efficient and to the point.
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 4 optional parameters and no output schema, the description is insufficient. It doesn't explain default behavior for limit, meaning of 'recent', ordering of results, or any constraints. The agent lacks enough context to fully understand the tool's behavior without additional schema reading.
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% as every parameter has a description. The tool description adds no extra meaning beyond the schema; it does not elaborate on parameters like limit or toDate. Baseline score of 3 is appropriate since schema already documents 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?
Description clearly states 'Get recent Coros activities' with specific verb and resource, and mentions return of basic info like date, name, sport type. This distinguishes it from siblings like get_activity_details (likely full details) and get_activity_file_url (specific file). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention that for full activity details one should use get_activity_details, or for file URLs use get_activity_file_url. Context for tool selection is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a mapping of all supported sport types and their IDs
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the retrieval of a mapping without disclosing behavioral traits such as authorization needs, rate limits, or caching behavior. This lack of context is a gap for a simple read 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, front-loaded sentence. Every word adds value, with no redundancy or wasted structure.
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 minimal but adequate for a parameterless tool. However, it could reveal the return format (e.g., 'dictionary of sport type names to IDs') to improve completeness. Current version leaves agents guessing about the mapping structure.
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?
With zero parameters in the input schema and 100% schema description coverage, the description adds no parameter info but is not expected to. The baseline for zero parameters is 4, and the description properly states the tool's function without needing parameter details.
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 uses a specific verb 'Get' and a clear resource 'mapping of all supported sport types and their IDs', leaving no ambiguity about the tool's purpose. It distinguishes itself from sibling tools, which focus on activities, profiles, or login.
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. Among siblings like get_recent_activities or get_activity_details, there is no comparison or mention of context. The description only states functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get training schedule and calendar for a date range
| Name | Required | Description | Default |
|---|---|---|---|
| endDate | Yes | End date in YYYYMMDD format | |
| startDate | Yes | Start date in YYYYMMDD format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states what the tool does, but omits behavioral traits such as authentication requirements, rate limits, or handling of invalid date ranges.
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 extraneous words. It is perfectly efficient for 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 no output schema and no annotations, the description is somewhat lacking. It does not mention return format or pagination, but for a simple calendar retrieval tool, it is minimally viable.
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 both parameters described in the input schema (format YYYYMMDD). The description adds no additional meaning beyond the schema, so 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 the verb 'Get' and the resource 'training schedule and calendar' with a scope of date range. It is specific and distinguishes the tool's purpose from siblings like get_recent_activities or get_activity_details, though not explicitly differentiated.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it provide context like prerequisites or excluded use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the authentication process by opening a web browser. The user will complete login in the browser and then confirm when done.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool opens a browser and requires user interaction, which is key behavioral information. However, it does not specify what happens after confirmation (e.g., token/session management), leaving a minor gap.
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 two concise sentences that front-load the main action. Every sentence adds value with no 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?
For a simple tool with no parameters and no output schema, the description covers the essential flow. It could be more explicit about the return value or next steps, but it is largely complete for an agent to understand the process.
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?
There are no parameters, so schema coverage is trivially 100%. The description needs no param details, earning the baseline score of 4 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 it starts the authentication process with a specific verb ('Start') and resource ('authentication process'). It distinguishes from sibling tools (all getters) by describing an interactive login flow.
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 the tool is for initial authentication but does not explicitly state when to use it (e.g., before other tools) or mention alternatives. No exclusions are provided.
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.
v1.0.0get_activity_detailsget_activity_file_urlget_evolab_metricsget_profileget_recent_activitiesget_sport_typesget_training_calendarloginScored across 8 tools
All tools have clearly distinct purposes: login, listing activities, downloading files, profile, metrics, calendar, sport types, and activity details. No overlaps.
Most tools follow 'get_' prefix pattern. One exception is 'login', which is a different action. Overall consistent and predictable.
8 tools is well-scoped for a fitness server, covering authentication, data retrieval, and analytics without being excessive or too few.
Covers profile, activities list/details, metrics, calendar, file downloads. Missing create/update/delete, but likely acceptable for a read-focused API. Minor gap.
Garmin data in Claude & ChatGPT via the Garmin Health API. OAuth sign-in, no password sharing.
Your endurance training data in your AI assistant: activities, recovery, plan, workout edits.
Connect your wearables, rings and training apps, then ask your AI about your own health data.
Connect your health, fitness, nutrition, sleep, and wearable data to your AI assistant.
