Strava MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STRAVA_CLIENT_ID | Yes | Your Strava API application client ID obtained from https://www.strava.com/settings/api | |
| STRAVA_CLIENT_SECRET | Yes | Your Strava API application client secret obtained from https://www.strava.com/settings/api |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_user_activitiesB | Get the authenticated user's activities. Args: ctx: The MCP request context before: An epoch timestamp for filtering activities before a certain time after: An epoch timestamp for filtering activities after a certain time page: Page number per_page: Number of items per page Returns: List of activities |
| get_activityC | Get details of a specific activity. Args: ctx: The MCP request context activity_id: The ID of the activity include_all_efforts: Whether to include all segment efforts Returns: The activity details |
| get_activity_segmentsC | Get the segments of a specific activity. Args: ctx: The MCP request context activity_id: The ID of the activity Returns: List of segment efforts for the activity |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose with no overlap: get_activity retrieves details of a specific activity, get_activity_segments focuses on segments within an activity, and get_user_activities lists the user's activities. The descriptions clearly differentiate these functions, making tool selection unambiguous for an agent.
All tool names follow a consistent verb_noun pattern with snake_case (get_activity, get_activity_segments, get_user_activities). The naming is predictable and readable, using 'get' as the verb throughout, which aligns well with the read-only nature of these tools.
With only 3 tools, this server feels under-scoped for a Strava integration, which typically involves activities, segments, athletes, and more. While the tools cover some read operations, the count is too low to support comprehensive agent workflows, such as creating or updating activities, which are common in fitness tracking domains.
The tool surface is severely incomplete for a Strava server, as it only includes read operations (get) with no support for create, update, or delete actions. There are significant gaps, such as missing tools for managing segments, athletes, or uploading activities, which will likely cause agent failures when attempting full interactions with the Strava API.