Strava MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation4/5
Most tools have distinct purposes targeting specific Strava resources like activities, segments, routes, or athlete data, with clear boundaries. However, some overlap exists between get-all-activities and get-recent-activities, which could cause confusion about which to use for general activity retrieval, though descriptions help differentiate them by scope.
Naming Consistency4/5
Tool names follow a consistent verb-noun pattern with hyphens (e.g., get-activity-details, list-athlete-clubs), making them predictable and readable. Minor deviations include check-strava-connection and export-route-gpx, which slightly break the pattern but maintain overall coherence.
Tool Count3/5
With 24 tools, the count is borderline high for a Strava integration, potentially overwhelming for agents. While it covers many aspects of the Strava API, some tools like get-server-version or check-strava-connection might be considered non-essential, contributing to a slightly bloated set.
Completeness5/5
The tool set provides comprehensive coverage of the Strava domain, including athlete management, activities, segments, routes, and data export. It supports full CRUD-like operations (e.g., connect/disconnect, star/unstar, get/list) and handles key workflows like activity analysis and segment tracking without obvious gaps.
Average 3.6/5 across 24 of 24 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 9 community issues answered or closed in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions searching for 'popular segments' but doesn't specify what makes a segment 'popular' (e.g., based on usage, ratings, or other metrics), nor does it describe the return format, pagination, or any rate limits or authentication requirements. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core functionality without unnecessary words. It is front-loaded with the main action and resource, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., how popularity is determined, result format), usage context, and differentiation from siblings. This makes it inadequate for an AI agent to fully understand when and how to invoke the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond implying a geographical search, which is already covered by the 'bounds' parameter description. Thus, it meets the baseline score of 3 without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('searches') and resource ('popular segments'), and specifies the geographical scope. However, it doesn't differentiate from sibling tools like 'list-starred-segments' or 'get-segment', which might also retrieve segments but with different criteria or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list-starred-segments' or 'get-segment', nor does it mention prerequisites such as requiring a connected Strava account. It only states what the tool does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'fetches detailed information' without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, what permissions are needed, rate limits, error conditions, or what format/details are returned. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple lookup tool and front-loads the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what 'detailed information' includes, the response format, or any behavioral aspects. For a tool in a complex domain (Strava activities) with many sibling tools, more context is needed to understand its specific role and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% with the single parameter 'activityId' well-documented in the schema. The description adds no additional parameter semantics beyond implying the ID is used to fetch details. Since the schema does the heavy lifting, the baseline score of 3 is appropriate even though the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'fetches' and resource 'detailed information about a specific activity', making the purpose understandable. It distinguishes from siblings like 'get-all-activities' by specifying 'specific activity using its ID', but doesn't explicitly contrast with similar tools like 'get-activity-laps' or 'get-activity-streams' that also fetch activity-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to siblings like 'get-all-activities' for listing activities or 'get-activity-streams' for different types of activity data. There's no context about prerequisites, timing, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'fetches' which implies a read operation, but doesn't cover important aspects like authentication requirements (though hinted by 'authenticated athlete'), rate limits, pagination behavior, or what 'most recent' means (e.g., time-based cutoff). This leaves significant gaps for a tool that likely interacts with an external API.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of fetching activities from what appears to be a Strava API (based on sibling tools), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'activities' include, the return format, error conditions, or how 'most recent' is determined, leaving too many unknowns for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'perPage' well-documented in the schema. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('fetches') and resource ('most recent activities for the authenticated athlete'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-all-activities' or 'get-activity-details', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-all-activities' or 'get-activity-details'. It mentions 'most recent activities' but doesn't clarify if this is a subset of all activities or a different endpoint, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'fetches detailed information' but doesn't specify what 'detailed' includes, whether it's a read-only operation, if it requires authentication, or any rate limits. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, potential error cases, or authentication requirements. For a tool in a context with many siblings and no structured output, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'segmentId' fully documented in the schema. The description adds no additional semantic context beyond implying it's used to fetch a segment, which aligns with the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('fetches') and resource ('detailed information about a specific segment'), making the purpose understandable. However, it doesn't distinguish this tool from similar siblings like 'get-segment-effort' or 'list-segment-efforts', which reduces its differentiation value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-segment-effort' or 'list-segment-efforts'. It mentions using a segment ID but doesn't specify prerequisites, such as needing an authenticated connection or when this is the appropriate fetch method.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'fetches' information, implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, error handling, or what 'detailed information' entails (e.g., fields returned, format). This leaves gaps for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('fetches detailed information') without unnecessary words. Every part earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes (e.g., fields like time, distance, athlete details), which is critical for a tool with one parameter and no structured output documentation. This leaves significant gaps for an agent to understand the tool's behavior and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'effortId' well-documented in the schema. The description adds minimal value beyond the schema by mentioning 'using its ID', which aligns with but doesn't expand on the schema's description. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('fetches detailed information') and resource ('about a specific segment effort using its ID'), which distinguishes it from siblings like 'list-segment-efforts' (plural listing) and 'get-segment' (segment vs. segment effort). However, it doesn't specify what 'detailed information' includes, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 is provided. It doesn't mention prerequisites (e.g., needing an effort ID from 'list-segment-efforts'), contrast with 'get-segment' (which fetches segment metadata), or specify use cases like retrieving performance data for analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool performs a mutation ('stars or unstars'), but fails to describe side effects (e.g., whether starring affects other data), authentication requirements beyond mentioning 'authenticated athlete', or error conditions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded with the core action and resource, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, or error handling, which are crucial for an agent to use this tool correctly in context with its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('segmentId' and 'starred'). The description does not add any additional meaning or context beyond what the schema provides, such as explaining what 'starring' entails or format details. Thus, it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('stars or unstars') and the resource ('a specific segment for the authenticated athlete'), making the purpose immediately understandable. However, it does not differentiate this tool from sibling tools like 'list-starred-segments', which is a related but distinct operation, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as how it relates to 'list-starred-segments' or other segment-related tools. It mentions 'authenticated athlete' but does not specify prerequisites or exclusions, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'fetches detailed information' which implies a read-only operation, but doesn't specify authentication requirements, rate limits, error handling, or what 'detailed information' includes. For a tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core action. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema with full coverage and no output schema, the description is minimally adequate. It explains what the tool does but lacks details about return values, authentication, or error cases. For a read operation with no annotations, it should ideally provide more context about what 'detailed information' includes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'routeId' well-documented in the schema. The description adds no additional parameter semantics beyond what's in the schema ('using its ID' merely restates the parameter's purpose). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'fetches' and resource 'detailed information about a specific route', making the purpose understandable. It doesn't explicitly distinguish from siblings like 'list-athlete-routes' or 'export-route-gpx', but the specificity of 'using its ID' provides some differentiation. This is clear but lacks explicit sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list-athlete-routes' or 'export-route-gpx'. It mentions 'using its ID' which implies you need a route ID, but doesn't state prerequisites or compare to sibling tools. This is minimal guidance without explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists clubs but doesn't cover critical aspects like whether it requires authentication (implied but not explicit), pagination behavior, rate limits, error conditions, or return format. This leaves significant gaps for a tool that likely interacts with an external API.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and efficiently conveys the essential information without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient for a tool that likely returns a list of clubs. It doesn't explain what data is returned (e.g., club names, IDs, membership details), how results are structured, or any limitations (e.g., max clubs returned). For a list operation in an API context, this leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a high baseline score for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lists') and resource ('clubs the authenticated athlete is a member of'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list-athlete-routes' or 'list-starred-segments' beyond the resource type, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication status), use cases, or comparisons to other list tools, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'pagination' and 'authenticated athlete', which adds some context about authentication and data handling. However, it doesn't cover critical aspects like rate limits, error conditions, response format, or whether it's a read-only operation, making it insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Lists the routes created by the authenticated athlete') and includes key behavioral context ('with pagination'). There is no wasted text, and it's appropriately sized for the tool's complexity, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and pagination but lacks details on authentication requirements, response structure, error handling, or integration with sibling tools. Without annotations or output schema, more context would be beneficial for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('page' and 'perPage') well-documented in the schema. The description doesn't add any parameter-specific details beyond what's in the schema, such as default behavior or usage tips. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lists') and resource ('routes created by the authenticated athlete'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from siblings like 'get-route' (which fetches a single route) or 'explore-segments' (which explores public segments), leaving room for improvement in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'authenticated athlete' and 'pagination', suggesting it's for retrieving multiple routes with pagination. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get-route' (for a single route) or 'get-all-activities' (for activities instead of routes), leaving usage context somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that the tool retrieves data (implying read-only) and describes the output format (formatted summary and raw JSON), which is useful. However, it lacks details on authentication requirements, rate limits, or error handling, leaving gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and adds output details in the second. Both sentences earn their place by providing essential information without redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is moderately complete. It covers the purpose and output format but misses authentication context and behavioral details. For a read-only tool with no structured data, it should do more to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is high. The description adds value by specifying that it retrieves data for the 'authenticated athlete', clarifying the implicit context. No parameters need explanation, so this compensates adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Retrieves') and resource ('authenticated athlete's configured heart rate and power zones'). It distinguishes from siblings like 'get-athlete-profile' or 'get-athlete-stats' by focusing specifically on zones. However, it doesn't explicitly mention how it differs from all siblings, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing authentication via 'connect-strava'), nor does it compare to similar tools like 'get-athlete-profile' that might include zone data. Without any usage context, this scores low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a list operation but doesn't describe return format, pagination behavior, rate limits, or authentication requirements beyond the implied 'authenticated athlete'. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered about how the tool actually behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the essential purpose without any wasted words. It's front-loaded with the core functionality and appropriately sized for a simple list tool. Every word earns its place in conveying what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description provides the minimum viable information about what the tool returns (starred segments). However, it doesn't address format, structure, or limitations of the returned data. Given the simplicity of the tool (no parameters, no complex schema), the description is adequate but leaves questions about the actual output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (empty schema is fully described). The description appropriately doesn't waste space discussing non-existent parameters. With no parameters to document, the baseline score of 4 reflects that the description correctly focuses on the tool's purpose rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lists') and resource ('segments starred by the authenticated athlete'), making the tool's purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get-segment' or 'explore-segments', but the focus on 'starred' segments provides natural distinction. The description avoids tautology by specifying what kind of segments are listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'authenticated athlete', suggesting this requires Strava authentication. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'explore-segments' (for discovery) or 'get-segment' (for specific segment details). No when-not-to-use scenarios or prerequisites beyond authentication are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses pagination support and filtering capabilities, which is helpful. However, it doesn't mention authentication requirements, rate limits, error conditions, or what 'complete activity history' entails (e.g., all-time vs. limited period). The behavioral context is partially covered but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states core functionality, the second adds important behavioral detail about pagination. Every word earns its place with zero redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations and no output schema, the description provides basic functional context but lacks details about authentication, error handling, return format, or performance characteristics. It's minimally adequate given the schema handles parameter documentation, but more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description adds minimal value beyond the schema by mentioning 'optional filtering by date range and activity type' and 'pagination', but doesn't provide additional semantic context about parameter interactions or usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'fetches complete activity history' with filtering capabilities, providing a specific verb ('fetches') and resource ('activity history'). It distinguishes from sibling tools like 'get-recent-activities' by emphasizing 'complete' history, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving comprehensive activity data with filtering, but doesn't explicitly state when to use this versus alternatives like 'get-recent-activities' or 'get-activity-details'. No guidance on prerequisites, exclusions, or specific scenarios is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Lists' and 'filtering by date', but does not describe pagination behavior (implied by 'perPage' in schema but not explained), authentication requirements, rate limits, or what the output looks like. For a tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Lists the authenticated athlete's efforts on a specific segment') and adds optional filtering information. Every word earns its place with zero waste, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 100% schema coverage but no annotations and no output schema, the description is adequate for a read-only list tool but incomplete. It covers the purpose and basic filtering, but lacks details on authentication, pagination behavior, error handling, or return format, which are important for a tool with no structured output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by implying date filtering, but does not provide additional semantics or usage context for parameters. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Lists'), the resource ('the authenticated athlete's efforts on a specific segment'), and includes optional filtering by date. It distinguishes this tool from siblings like 'get-segment-effort' (singular) and 'get-all-activities' (broader scope), making the purpose precise and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing efforts on a segment with optional date filtering, but does not explicitly state when to use this tool versus alternatives like 'get-all-activities' or 'get-segment-effort'. It provides some context (filtering by date) but lacks guidance on exclusions or specific scenarios where this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool checks and shows status, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, if it has rate limits, what the output format is, or if it performs any network calls. For a tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the purpose and followed by usage guidance. Every sentence earns its place with no wasted words, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what the tool does and when to use it, but lacks details on behavioral aspects like output format or authentication needs, which are important for a connection-checking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for 0 parameters is 4, as the description appropriately doesn't discuss parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if Strava is connected and show the current connection status.' This is a specific verb ('check') and resource ('Strava connection'), but it doesn't explicitly differentiate from siblings like 'connect-strava' or 'disconnect-strava' beyond the action type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it: 'Use this when the user asks about their connection status.' This gives explicit guidance on the triggering condition, though it doesn't mention when NOT to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that the tool exports and saves to a local directory, which is useful behavioral context. However, it lacks details on permissions, rate limits, file naming, or what happens if the directory is inaccessible. The description adds some value but is incomplete for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and includes essential details like format and destination. There is no wasted wording, and it directly communicates the tool's function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete for a tool with one parameter. It covers the action, format, and destination, but lacks details on error handling, output confirmation, or integration with other tools like 'check-strava-connection'. For a write operation, more behavioral context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'routeId' fully documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'exports' and resource 'a specific Strava route in GPX format', and distinguishes it from sibling 'export-route-tcx' by specifying the GPX format. It adds destination context with 'saves it to a pre-configured local directory', making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a GPX export is needed, but does not explicitly state when to use this tool versus alternatives like 'export-route-tcx' (which likely exports TCX format) or 'get-route' (which might retrieve route data without export). No explicit exclusions or prerequisites are mentioned, leaving usage context partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: format conversion (TCX) and file saving to local directory. However, it doesn't mention authentication requirements, rate limits, error conditions, or what happens if the directory doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys purpose, format, and destination without redundancy. Every word earns its place, and the information is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a single parameter, the description covers the basic operation well. However, it lacks details on authentication needs, error handling, and file naming conventions, which are important for a file export tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'routeId', so baseline is 3. The description adds value by contextualizing the parameter as 'a specific Strava route' and implying it's used for export, elevating the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Exports'), resource ('a specific Strava route'), format ('in TCX format'), and destination ('saves it to a pre-configured local directory'). It distinguishes from sibling 'export-route-gpx' by specifying TCX format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when exporting a route in TCX format, but doesn't explicitly state when to use this versus 'export-route-gpx' or other route-related tools. No guidance on prerequisites like authentication or directory configuration is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the tool's behavior as returning metadata, which is useful context, but lacks details on potential errors, rate limits, or authentication needs. Since it's a read-only operation with no parameters, the description is adequate but not rich in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('Returns') and resource. It wastes no words and directly communicates the tool's function, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no annotations, no output schema), the description is complete enough for its purpose. It explains what the tool does without needing to detail parameters or outputs, though it could slightly improve by hinting at use cases. The lack of output schema is not a major issue here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description does not add or need to add parameter semantics, but it appropriately focuses on the tool's purpose without redundancy, meeting the baseline for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('Returns') and resource ('the Strava MCP server version and related metadata'), making the purpose explicit. It distinguishes itself from all sibling tools, which focus on athlete data, activities, segments, or connections, whereas this tool is about server metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'server version and related metadata,' suggesting it's for checking server status or compatibility. However, it does not explicitly state when to use this tool versus alternatives (e.g., for debugging vs. data retrieval) or provide any exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the action ('remove stored credentials') but lacks details on behavioral traits such as whether this is reversible, requires confirmation, affects other data, or has authentication or rate limit implications, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by usage guidance in the second, with no wasted words. Both sentences earn their place by providing essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with no parameters) and lack of annotations or output schema, the description covers purpose and usage well but is incomplete in behavioral transparency, such as not specifying if the action is permanent or has side effects, which is important for user-facing operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the schema fully documents the lack of inputs. The description does not need to add parameter details, so it meets the baseline for this condition without compensation required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Disconnect your Strava account') and the resource affected ('remove stored credentials'), distinguishing it from sibling tools like 'connect-strava' or 'check-strava-connection' which involve connection management rather than disconnection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'when the user wants to logout, disconnect, or remove their Strava connection,' providing clear context and distinguishing it from alternatives like maintaining or checking the connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that it fetches profile information and the ID, which is useful context, but lacks details on authentication requirements, rate limits, or response format. The description doesn't contradict annotations (none exist), but it's minimal for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and includes essential context without waste. Every part earns its place by clarifying the tool's role and its relationship to other tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what it does and why it's useful, but for a tool with no annotations, it should ideally mention authentication or response details to be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is high. The description adds value by explaining that it fetches profile information and the ID, which compensates for the lack of output schema. No parameters need documentation, so this exceeds the minimal requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Fetches') and resource ('profile information for the authenticated athlete'), distinguishing it from siblings like 'get-athlete-stats' by focusing on profile data rather than statistics. It explicitly mentions the inclusion of the unique numeric ID, which is a key differentiator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying it's for the 'authenticated athlete' and notes that the ID is needed for other tools like 'get-athlete-stats', implying usage as a prerequisite. However, it doesn't explicitly state when not to use it or name direct alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: authentication requirements ('Requires activity:read scope'), data sources ('Photos may come from Strava uploads or linked Instagram posts'), and edge-case behavior ('Returns empty array if activity has no photos'). It doesn't mention rate limits or pagination, but covers essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Use Cases, Parameters, Output Format, Notes) and front-loads the core purpose. Some sentences in the Output Format section could be more concise, but overall it's efficient and organized, with each section adding meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is highly complete. It covers purpose, usage, parameters, output format, authentication, data sources, and edge cases. The 'Output Format' section effectively substitutes for a missing output schema by detailing what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters thoroughly. The description adds minimal value beyond the schema: it clarifies that the 'size' parameter returns 'all available sizes' if unspecified, but this is implied by the schema's optional nature. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('photos associated with a specific Strava activity'), making the purpose explicit. It distinguishes from sibling tools like 'get-activity-details' or 'get-activity-streams' by focusing specifically on photos, not general activity data or performance metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use Cases' section provides clear context for when to use this tool (fetching photos, getting URLs, accessing metadata). However, it doesn't explicitly state when NOT to use it or name alternatives among sibling tools, such as when needing general activity data instead of photos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing important behavioral traits: authentication requirements ('Requires activity:read scope...'), data completeness ('Returns complete data... without omissions'), and precision handling ('All numeric values are preserved...'). It doesn't mention rate limits or error conditions, keeping it from a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure with clear sections (Description, Use Cases, Parameters, Output Format, Notes). Every sentence earns its place by adding specific value - no redundant information. The description is appropriately sized and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with no output schema, the description provides exceptional completeness. It covers authentication requirements, data scope, output format details (both human-readable and JSON), and specific data fields returned. This gives the agent sufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the single 'id' parameter adequately. The description adds minimal value beyond the schema by specifying it's for 'a specific Strava activity' and listing it in the Parameters section, but doesn't provide additional syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Retrieves') and resource ('detailed lap data for a specific Strava activity'). It distinguishes from siblings like 'get-activity-details' by focusing exclusively on lap data rather than general activity information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use Cases' section provides clear context for when to use this tool (detailed lap analysis, visualization, comparison). However, it doesn't explicitly state when NOT to use it or name specific alternatives among sibling tools, though the focus on lap data implies differentiation from general activity tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the prerequisite (athleteId requirement) which is useful context, but doesn't disclose other behavioral traits like rate limits, authentication needs, error conditions, or what the output format looks like (since no output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence states purpose and scope, the second provides critical prerequisite information. Every word earns its place and the description is appropriately sized for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 100% schema coverage but no annotations and no output schema, the description provides adequate purpose and usage guidance. However, it lacks information about return values (what the stats actually contain) and other behavioral context that would be helpful given the absence of structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 the single parameter. The description adds value by explaining where to obtain the athleteId ('from the get-athlete-profile tool'), which provides practical guidance beyond the schema's technical specification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('fetches') and resource ('activity statistics for a specific athlete'), specifying the types of statistics (recent, YTD, all-time). It distinguishes from siblings like 'get-athlete-profile' by focusing on stats rather than profile data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('for a specific athlete using their ID') and provides a prerequisite ('Requires the athleteId obtained from the get-athlete-profile tool'), clearly differentiating it from alternatives that don't require this ID or fetch different data types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses key behavioral traits: it opens a browser window for secure authentication and enables activity tracking. It doesn't mention rate limits, error handling, or what happens post-authentication, but covers the core interaction well 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with the core purpose, followed by behavioral details and usage guidelines in two efficient sentences with zero wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a simple input schema, the description is mostly complete—it explains what the tool does, how it behaves, and when to use it. It could improve by mentioning what data is accessed post-connection or error cases, but it's sufficient given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for its single parameter 'force', so the baseline is 3. The description adds value by implicitly contextualizing the parameter's use (re-authentication when already connected), though it doesn't explicitly mention the parameter. This elevates it above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Connect your Strava account') and the purpose ('to enable activity tracking'), distinguishing it from sibling tools like check-strava-connection or disconnect-strava by focusing on initial authentication rather than status checking or disconnection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage guidance with 'Use this when the user asks to connect, link, or authenticate their Strava account,' clearly indicating when to invoke this tool versus alternatives like check-strava-connection for verifying existing connections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels by disclosing key behavioral traits: it requires 'activity:read scope', notes 'not all streams are available for all activities', warns 'older activities might have limited data', explains 'large activities are automatically chunked to ~50KB per message', and describes intelligent downsampling for large datasets. This covers permissions, data availability, limitations, and performance considerations thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections like 'Key Features', 'Format Options', 'Common Use Cases', 'Output Format', and 'Notes', making it easy to scan. However, it is lengthy with multiple bullet points and detailed explanations, which, while informative, could be more concise. Every sentence adds value, but some redundancy exists (e.g., repeating format details).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters, no annotations, and no output schema, the description is highly complete. It covers purpose, usage, behavioral traits, parameter semantics, output format details, and limitations. The 'Output Format' section compensates for the lack of output schema by describing metadata, statistics, and data structure, making it sufficient for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description adds significant value by explaining parameter implications beyond the schema: it details how 'resolution' affects data points (~100 to ~10000), describes 'smart pagination' for 'page' and 'points_per_page', explains 'intelligent downsampling' for 'max_points', and elaborates on 'format' options (compact vs verbose) with payload size impacts. This enhances understanding but doesn't fully cover all 8 parameters in depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'retrieves detailed time-series data streams from a Strava activity' with specific verbs ('retrieves', 'analyzing', 'visualizing') and resources ('Strava activity', 'workout metrics', 'routes'). It distinguishes from siblings like get-activity-details (which likely provides summary info) and get-activity-laps (which focuses on lap segments) by emphasizing time-series data streams for analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Perfect for analyzing workout metrics, visualizing routes, or performing detailed activity analysis' and lists common use cases like analyzing heart rate zones, calculating power metrics, and visualizing GPS coordinates. It distinguishes from siblings by focusing on time-series data streams rather than summary details, photos, or segments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![strava-mcp MCP server](https://glama.ai/mcp/servers/r-huijts/strava-mcp/badges/card.svg)](https://glama.ai/mcp/servers/r-huijts/strava-mcp)

Score Badge

Copy to your README.md:

[![strava-mcp MCP server](https://glama.ai/mcp/servers/r-huijts/strava-mcp/badges/score.svg)](https://glama.ai/mcp/servers/r-huijts/strava-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/r-huijts/strava-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server