Allows AI agents to access and analyze Strava training data, including activities, training load, power curves, heart rate zones, gear maintenance, and more.
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., "@Strava MCP Server How is my training load looking?"
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.
Connect your Strava training data to Claude. This MCP server turns Claude into your personal training coach — analyzing your training load, planning workouts, and tracking your progress. Works with cycling, running, and any sport you track on Strava.
Works with Claude Desktop and claude.ai on any plan. Free plans can add 1 custom connector (remove any existing connector first), Pro and Max are unlimited.
This takes about 2 minutes. You need a free Strava API app so Claude can access your data.
Go to strava.com/settings/api
Fill in the form — Application Name, Category, and Description can be anything (e.g. "My Claude connector")
Set Authorization Callback Domain to strava-mcp-web.vercel.app
Click Create and note your Client ID and Client Secret
Open Claude Desktop or claude.ai
Go to Settings → Connectors → Add custom connector
Paste this URL and save:
https://strava-mcp-web.vercel.app/mcpClick Connect on the newly added connector. This opens a page where you enter your Strava Client ID and Client Secret, then authorize with Strava.
That's it! Ask Claude about your training.
Related MCP server: Strava MCP Server
The server exposes 10 tools:
Tool | Description |
| Your last activities with distance, duration, and heart rate |
| Deep dive into a specific activity — power, HR, speed, suffer score |
| ATL, CTL, TSB with training advice and 8-week trends |
| Weekly volume — activities, kilometers, hours |
| Weekly plan based on current fitness and fatigue |
| Bike/shoe km totals with chain, cassette, tire warnings |
| Best power outputs (5s–60min), FTP estimate, monthly comparison |
| Time in each HR zone with polarized training advice |
| Cardiac drift in steady rides — aerobic efficiency indicator |
| Interval consistency, power decoupling, recovery scoring |
"I want to ride tonight, what should I do?" "How is my training load looking?" "Check the quality of my last interval workout" "When do I need to replace my chain?" "What's my FTP and how does it compare to last month?" "Am I spending enough time in zone 2?" "I'm training for a 150km race in April — am I on track?"
Claude pulls your Strava data in real-time and reasons about it in context — your recent rides, fitness trend, fatigue level, and goals.
Training load analysis uses the standard PMC model:
ATL (7-day) — how tired you are now
CTL (42-day) — your fitness level
TSB — CTL minus ATL. Positive = fresh, negative = fatigued
Ramp rate — week-over-week load change, with injury risk warnings
Gear maintenance tracks km on each bike and shoe, warning when chain (3000km), cassette (6000km), tires (5000km), or cables (8000km) need attention.
Power curve finds your best efforts across durations and estimates FTP at 95% of your 20-minute power.
HR analysis covers zone distribution (are you polarizing enough?) and cardiac drift (is your aerobic base improving?).
Training load uses suffer score / HR — it underestimates fatigue from strength training or activities where HR stays low
Power features require a power meter or smart trainer
The weekly plan is a heuristic, not a replacement for a certified coach
Connector not working? Remove and re-add the connector in Settings → Connectors.
Authentication error?
Check that your Strava API app has strava-mcp-web.vercel.app as the callback domain.
Model Context Protocol (MCP) — Anthropic's open standard for connecting AI to external tools
Strava API v3 — Access to athlete activities and metrics
MIT
Analyze interval consistency, power decoupling, and recovery for a specific activity
| Name | Required | Description | Default |
|---|---|---|---|
| activity_id | Yes | Activity ID to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose whether the tool is read-only, what output format to expect, or any prerequisites (e.g., activity must contain power data).
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 unnecessary words. Every part 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?
For a tool with one parameter and no annotations or output schema, the description is adequate but lacks details on return format, prerequisites, or usage conditions to be fully 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% with clear parameter description. The description adds context about what the tool analyzes but does not enhance parameter semantics 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 the specific analyses it performs (interval consistency, power decoupling, recovery) and distinguishes it from sibling tools like get_activity_details or get_hr_drift_analysis.
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 when to use (for a specific activity analysis) but does not provide explicit guidance on when not to use or how it differs from similar tools like get_power_curve or get_hr_drift_analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed info for a specific activity
| Name | Required | Description | Default |
|---|---|---|---|
| activity_id | Yes | Activity ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Get detailed info' without disclosing behavior such as whether it is read-only, data source, or what 'detailed' entails.
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 with no unnecessary words, perfectly sized 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?
For a simple one-parameter tool with no output schema, the description is adequate but lacks detail on return values or data scope, which could leave an agent uncertain about what 'detailed info' includes.
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% coverage with one parameter described as 'Activity ID'. The description adds no extra meaning beyond the schema, so a 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' and resource 'detailed info for a specific activity', distinguishing it from sibling tools like get_recent_activities which return lists, and analysis tools which process 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?
The description implies usage when needing details for one activity, but provides no explicit guidance on when to use vs alternatives or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all bikes and shoes with total km and maintenance warnings
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations. Description implies read-only operation, but doesn't explicitly state behavioral traits like authentication needs or side effects. Adequate but 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?
Single sentence with no redundant words. Front-loaded with key action and resources.
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; description lacks detail on output format (e.g., what constitutes a maintenance warning). Adequate for a simple list, but could be more informative.
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?
No parameters; baseline score of 4. Description adds no parameter info, but none 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 it lists bikes and shoes with total km and maintenance warnings. Specific verb 'list' and resource 'gear maintenance', 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 explicit guidance on when to use or alternatives. Sibling tools are unrelated, so implied usage, but no 'when not to' or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Measure cardiac drift in steady rides — indicator of aerobic efficiency
| 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 says 'measure', implying a read operation, but offers no details on what the output contains, any side effects, or required permissions. This is insufficient for a tool with no annotations.
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 that front-loads the purpose. It is concise but could include a bit more detail without becoming wordy.
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 no output schema and no parameters, the description is simple. However, it fails to explain what the tool returns (e.g., a drift percentage, a graph, etc.), leaving the agent without complete knowledge of the tool's outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so there is nothing for the description to add. Baseline for 0 parameters is 4, and the description does not detract.
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 'measure' and the resource 'cardiac drift in steady rides', and the phrase 'indicator of aerobic efficiency' adds context. This distinguishes it from sibling tools like get_hr_zone_distribution or get_training_load_analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage during steady rides for aerobic efficiency but provides no explicit guidance on when to use this tool over siblings, nor mentions any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze time spent in each HR zone (last 4 weeks) with training balance advice
| 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 must carry the full burden. It indicates a read-only analysis and mentions the 4-week timeframe, but does not disclose data requirements (e.g., need for heart rate data from workouts) or the nature of the 'training balance advice'.
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 of 12 words that front-loads the core action and context. Every word contributes meaning without 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 parameterless tool without output schema, the description covers the key function and timeframe. However, it does not specify the output format or what 'training balance advice' entails, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to describe. Per evaluation rules, 0 parameters yields a baseline of 4. The description adds no parameter info, but none is 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?
The description clearly states the tool analyzes time spent in each heart rate zone over the last 4 weeks and provides training balance advice. The verb 'analyze' and resource 'HR zone distribution' are specific, and it distinguishes itself from siblings like 'get_hr_drift_analysis' and 'get_training_load_analysis'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when HR zone distribution analysis is needed, but it does not explicitly state when to use this tool over alternatives or provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze best power outputs (5s, 1min, 5min, 20min, 60min), estimate FTP, and compare with previous month
| 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 the full burden of behavioral disclosure. It describes the analysis scope (power outputs, FTP estimation, monthly comparison) but does not state whether the operation is read-only, if authentication is needed, or any side effects. It does not contradict annotations since none exist.
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 that efficiently lists the key analysis points (specific durations, FTP estimation, monthly comparison). No unnecessary words; every part 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?
Given the tool has no inputs and no output schema, the description provides a clear overview of what it does. It covers the main analytical goals but stops short of describing the return format or how the comparison is presented, which would be helpful for 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?
There are zero parameters, so the baseline is 4. The description does not need to add parameter semantics as none exist. Schema coverage is 100% (empty properties), so no compensation is required.
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 analyzes best power outputs for specific durations (5s, 1min, 5min, 20min, 60min), estimates FTP, and compares with the previous month. It uses a specific verb ('analyze') and resource (power outputs), and distinguishes itself from siblings like get_training_load_analysis by focusing on power curve 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?
The description implies usage for power curve analysis but does not explicitly state when to use this tool versus alternatives like get_training_load_analysis or get_hr_drift_analysis. No when-not or comparative guidance is provided, leaving the agent to infer from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent Strava activities (default: last 10)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of activities (max 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose that the tool is read-only, lacks rate limit or authentication hints, and does not specify what happens if the limit exceeds 30. The minimal description fails to convey behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It efficiently conveys the essential information. Every word earns its place, making it extremely 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 the tool is simple (1 parameter, no output schema, no nested objects), the description is minimally sufficient. However, it lacks details about the output structure (e.g., order, fields) and does not clarify if the tool requires authentication, which would help the agent. Slightly incomplete for a tool with no annotations.
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 'limit'. The description's mention of 'default: last 10' merely echoes the schema default. It adds no additional semantic meaning beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific: 'Get recent Strava activities' clearly states the verb and resource, and includes a default value. It distinguishes from sibling tools like get_activity_details and analysis tools, as it is the only tool for listing 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 on when to use this tool versus alternatives. There is no mention of context or exclusions. The description simply states what it does without advising when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze training load with ATL, CTL, TSB and get REST or TRAIN advice
| 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 fully disclose behavior. It states analysis and advice generation but does not mention side effects, data requirements, or that it is a read-only operation. Lacks detail on how advice is derived.
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 with no extraneous words. Front-loaded with key actions and metrics.
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 no parameters and no output schema, description provides enough context for a simple analysis tool. Could mention return format but not critical.
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 0 parameters, so description does not need to add parameter meaning. Baseline 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?
Clearly states analysis of training load using specific metrics (ATL, CTL, TSB) and output of advice (REST or TRAIN). Distinguishes from sibling analysis tools like get_power_curve or get_hr_drift_analysis.
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?
Implies usage for training load advice but lacks explicit guidance on when to use this tool over alternatives or prerequisites. Does not specify context like user or activity scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Weekly training statistics (distance, time, training load)
| Name | Required | Description | Default |
|---|---|---|---|
| weeks | No | Number of weeks back (default: 4) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only lists the returned metrics but does not describe side effects (presumably none), data freshness, authentication requirements, or any limitations. For a read-only tool, basic transparency about its idempotent nature is missing.
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, well-structured sentence that conveys the core purpose without any extraneous information. Every word earns its place, making it highly 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's simplicity (one optional parameter, no output schema), the description provides the essential return metrics. However, it could be improved by noting the output format (e.g., array of weekly objects) or units. Still, for a straightforward stat retrieval, it is largely 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?
The input schema covers the single parameter 'weeks' with a description and default, achieving 100% coverage. The tool description adds no further parameter semantics but does clarify what metrics are returned, which indirectly contextualizes the parameter. Per the baseline rule, a 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?
The description clearly states the tool retrieves weekly training statistics for distance, time, and training load. This distinguishes it from siblings like get_training_load_analysis (which focuses on load exclusively) and get_activity_details (which is per-activity). The verb is implied (retrieve), and the resource is well-defined.
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 guidelines are provided about when to use this tool versus alternatives. With many sibling tools (e.g., get_weekly_training_plan, get_training_load_analysis), explicit usage context would help the agent decide. The description offers no such guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a weekly plan with recommended hours, workout types and intensities based on your current status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It mentions the plan is based on 'current status' but does not explain how status is determined, what data is used, or any side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous information, efficiently conveying the tool's core function.
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 or output schema, the description is minimally adequate. However, it lacks detail on what 'current status' means, leaving some ambiguity about prerequisites or data sources.
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?
No parameters exist, and schema coverage is 100% (empty). The description adds context by stating the plan is based on current status, meeting the baseline 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?
Description clearly states the tool retrieves a weekly plan, specifying recommended hours, workout types, and intensities. It distinguishes itself from sibling tools like get_weekly_stats and get_training_load_analysis, which focus on different 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 explicit guidance on when to use this tool versus alternatives. The description does not mention when not to use it or provide comparative context with sibling tools, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct analysis or information retrieval function, such as workout quality, gear maintenance, heart rate drift, power curve, and training load. No two tools have overlapping purposes, making it clear which tool to use for a given query.
All tools follow a verb_noun pattern using snake_case, with most starting with 'get'. One tool uses 'check' instead of 'get', and a few use abbreviations like 'hr' and 'stats', but these are minor deviations that don't affect readability.
With 10 tools, the set is well-scoped for a Strava analysis server covering key metrics like heart rate, power, training load, and gear maintenance. It's not too many to be overwhelming nor too few to be trivial.
The tool set comprehensively covers training analytics (HR, power, load, weekly stats, planning) and basic activity retrieval. Minor gaps exist, such as no tool for updating activity details or managing goals, but the core analysis workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect Claude to your Intervals.icu watch data for fitness, workout review, and plan writing.
Turn Claude or ChatGPT into a cycling coach that plans your week, grades it, and adapts. Free beta.
Garmin data in Claude & ChatGPT via the Garmin Health API. OAuth sign-in, no password sharing.
Garmin data in Claude: 135 tools — activities, sleep, HRV, training, workouts. Free, open source.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ArjanLig/strava-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
