strava-openapi-mcp

by Arbodgad

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action, with clear entity-specific names (e.g., get_activity_by_id vs get_activity_streams vs get_comments_by_activity_id). Even similar operations like route exports are distinguished by format (GPX vs TCX). No overlap or ambiguity exists.
Naming Consistency5/5
All tools follow a uniform verb_noun pattern using HTTP method prefixes (get_, put_, post_) followed by the resource and optional identifier (e.g., put_update_activity_by_id, post_create_upload). The naming is entirely consistent across the set.
Tool Count2/5
With 34 tools, the server far exceeds the typical well-scoped range (3-15) and even the borderline heavy range (16-25). While the Strava API is broad, this many tools makes the surface overweight and risks overwhelming agents during tool selection.
Completeness3/5
The tool set covers major resources (athlete, activities, segments, routes, clubs, gear, uploads, streams) with read and some write operations, but lacks delete operations for activities and uploads, creating lifecycle gaps. Additionally, creation is missing for some resources like routes, although these may not be API-supported. Overall, notable gaps exist but the core workflows are covered.
Average 3.5/5 across 34 of 34 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits 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?
The description notes it modifies Strava data and lists required scopes, but with no annotations it carries the full behavioral burden. It does not disclose whether unspecified fields are preserved (partial vs. full update), what the response returns, or error behavior on invalid IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The structure is mostly clear but includes redundant scope information ('Requires activity:write...' repeated as 'Scopes: required: activity:write...'). The endpoint line is redundant with the tool name, making the description slightly less concise than it could be.
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?
For a mutation tool with 9 parameters, no output schema, and no annotations, the description omits critical behavioral details. It does not explain whether the update replaces or merges fields, what the response contains, or how missing IDs are handled, leaving an agent under-informed.
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 coverage is 100%, so all parameters are already described in the input schema. The description adds no extra meaning to parameters, which meets the baseline for this dimension.
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 states a specific verb and resource ('Updates the given activity') and clarifies that the activity must be owned by the authenticated athlete. This clearly distinguishes it from the sibling create tool (post_create_activity) and read tools like get_activity_by_id.
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 ownership and scope requirements but gives no guidance on when to use this tool versus alternatives. It does not mention that create should be used for new activities or that read tools retrieve activities, leaving usage context implicit.
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, the description must fully disclose behavior. It states 'This operation modifies Strava data' and 'Requires profile:write scope', which provides some transparency about side effects and auth. However, it does not explain what happens to other athlete fields, whether the operation is reversible, or what the response contains. This is minimal disclosure 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with clear sections (Endpoint, Description, Scopes), but it contains redundancy: 'Requires profile:write scope' and 'Scopes: required: profile:write' are repeated. The purpose statement is front-loaded, but the duplication wastes space. It is not overlong but could be trimmed.
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?
For a mutation tool with no output schema and no annotations, the description is incomplete. It does not describe the response format, whether the update is partial or full replacement, or any side effects beyond modifying data. The single parameter is documented, but the overall behavior on the resource is insufficiently specified for an agent to know what to expect.
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% – the weight parameter is fully described as 'The weight of the athlete in kilograms'. The description adds no additional parameter meaning beyond that, so the baseline of 3 is appropriate when the schema already documents the parameter clearly.
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 'Update' and the specific resource 'the currently authenticated athlete'. It distinguishes from siblings like put_update_activity_by_id by specifying the target is the authenticated athlete, not just 'athlete'. The endpoint PUT /athlete reinforces the resource.
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. The description mentions the required scope 'profile:write', which is a prerequisite, not a usage condition. It does not describe when to choose this over other update tools or mention any exclusions, leaving the agent to infer usage purely from the name.
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, the description carries the behavioral disclosure burden. It explicitly states 'Read-only operation' and 'Requires subscription,' which are useful. However, it does not mention any rate limiting, authentication specifics, or that results are paginated via per_page. The description is not misleading but under-communicates operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but includes redundant information such as the endpoint string ('GET /segment_efforts') that is not actionable for an AI agent, and it repeats the tool's title. The structure is front-loaded with the core verb, but the extra endpoint line wastes space. It is not excessively long, but not optimally crafted.
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?
The description states what it returns ('a set'), and given the lack of an output schema, that is important. It also covers subscription and read-only. However, it omits practical context like pagination behavior, error conditions, or how the date parameters modify the result set. For a list tool with filters, more explicit behavioral context would be expected.
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 parameters are fully documented in the structured schema. The description repeats the segment context but adds no semantic detail about how start_date_local or end_date_local filter results, or how per_page interacts with pagination. Thus it adds minimal value beyond the schema, warranting a baseline 3.
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 states a clear verb ('List') and resource ('segment efforts') and qualifies it with 'for a given segment.' It identifies the endpoint and mentions the return set. However, it does not explicitly differentiate from the sibling get_segment_effort_by_id, which retrieves a single effort, so the distinction is left to inference.
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 guidance is given on when to use this tool versus alternatives like get_segment_effort_by_id, get_segment_by_id, or get_explore_segments. The only usage hint is the subscription requirement, but there is no mention of date filtering, pagination, or when this list is preferable to other segment-related endpoints.
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 the full burden. It discloses read-only nature and scope requirements, which is useful. It also hints at visibility filtering ('Only Me activities will be filtered out unless requested by a token with activity:read_all'), but this is confusingly worded and does not clearly explain behavior. It does not mention pagination or response structure, leaving some gaps.
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 organized with an endpoint header, a brief description, and scope/read-only notes. It is concise and front-loaded with the main purpose. It avoids fluff, though the phrase 'for a specific identifier' is unnecessary and adds ambiguity.
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?
The tool is a list operation with optional parameters and no output schema. The description omits key context: it does not clarify that the athlete is the logged-in user, nor does it explain the filtering behavior clearly. It also lacks details on pagination results or default ordering. For a simple read operation, more clarity on what the response contains would be expected.
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% parameter description coverage, so the schema already documents page, after, before, and per_page. The description adds no additional parameter semantics, so the baseline score of 3 applies.
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 states the tool lists athlete activities and provides the endpoint. However, it says 'for a specific identifier' without clarifying that the identifier is the logged-in athlete, which is only implied by the tool name. It is reasonably distinct from siblings like get_activity_by_id, which fetches a single activity.
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 mentions required scopes (activity:read or activity:read_all) but gives no guidance on when to use this tool vs alternatives like get_activity_by_id or get_efforts_by_segment_id. It does not state to use this for a list of activities vs a single one. There is no explicit when-not or alternative mention.
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?
The description discloses that the operation is read-only and that read_all scope is required for private routes, which are useful behavioral cues. It also specifies the HTTP GET method in the endpoint, adding to transparency. However, it does not elaborate on the structure of the returned streams, error behavior, or pagination. With no annotations provided, the description carries the full burden, so this partial disclosure merits a 3.
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 compact and well-structured, with the endpoint, description, and scopes on separate lines. It front-loads the primary purpose. A minor inefficiency is the redundant header 'Get Route Streams' that repeats the tool name, but it does not detract significantly. Overall it is concise and easy to scan.
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?
For a tool with no output schema and no annotations, the description should provide more context about what streams are and the expected return format. It only says 'returns the given route's streams' without defining stream types, data structure, or examples. The scope requirement is helpful, but the tool is not fully self-described. An agent unfamiliar with the API would not know what a 'stream' is, making this incomplete for a seemingly simple but domain-specific tool.
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 fully documents the single parameter 'id' with a description, so schema coverage is 100%. The description adds no additional semantic information about the parameter beyond what the schema already states, such as where the ID comes from or any constraints. Given high coverage, a baseline of 3 is appropriate.
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 states that the tool returns the given route's streams, which is a specific verb and resource. It is clear that this is for fetching streams for a specific route. However, it does not explicitly differentiate from sibling tools like get_activity_streams or get_segment_streams, though the route-specific reference provides some distinction. The purpose is unambiguous and not a tautology, so it earns a 4.
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 does not provide guidance on when to use this tool relative to alternatives. It mentions that read_all scope is required for private routes, which is an access condition, but does not explain when to choose this over get_activity_streams or get_route_as_gpx. There is no explicit comparison or situational advice, leaving the agent to infer usage context. This is a significant gap for a tool with many similar 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?
With no annotations, the description must carry the burden. It explicitly states 'This operation modifies Strava data', which discloses mutation. It also mentions the required scope. However, it does not discuss reversibility, side effects, error behavior, or what happens on success/failure, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but somewhat repetitive, including redundant sections like 'Star Segment' and 'Description:' that restate the title. The structure could be cleaner, but it is not overly verbose.
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 simple tool with two parameters and no output schema, the description covers purpose, scope, and mutation. However, it omits details about the response, error conditions, or any preconditions beyond scope, leaving some gaps for an agent.
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 already fully documents both parameters (id and starred) with clear descriptions. The tool description adds no extra parameter context beyond that, so it does not elevate above the schema-driven baseline.
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 performs star/unstar operations on a segment for the authenticated athlete, with a specific endpoint. It distinguishes itself from getters and other put tools by its unique resource/action. However, it does not explicitly compare to any sibling tool, so it isn't a perfect 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 mentions the required scope but does not explain when a user would want to star/unstar a segment or how this differs from other segment-related tools. No exclusions or alternative instructions are given.
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 the full burden of behavioral disclosure. It does state 'Read-only operation,' which is helpful, but it omits other behavioral aspects such as pagination behavior (implied by page/per_page params), error conditions (e.g., club not found), or authentication requirements. The minimal disclosure covers the safety profile but not richer behavioral 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 compact and to the point, including the endpoint and a clear one-line explanation. It avoids unnecessary verbosity and front-loads the essential purpose. The inclusion of the endpoint is a bonus, though not strictly required. Only a slight inefficiency is the repetition of 'Returns a list' and 'List Club Administrators' which are redundant.
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 simple read-only list operation, the description, combined with the schema, provides enough for an agent to call it correctly. It specifies the resource (club admin list), and the schema covers parameters and pagination defaults. The absence of an output schema means the description needn't detail return values. It might lack mention of error handling or authentication, but these are typically implicit for API tools and not required for basic usability.
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 provides descriptions for all three parameters (id, page, per_page) with 100% coverage. The description itself adds no parameter-specific information, which is acceptable given the schema already documents them. However, it doesn't clarify the relationship between the parameters and the returned data, such as explaining that admins are paginated. This is baseline behavior for 100% 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 tool 'lists club administrators' with a specific verb and resource. It names the endpoint GET /clubs/{id}/admins and describes the return as a list of admins for a given club. While it doesn't explicitly differentiate from sibling tools like get_club_members_by_id, the focus on 'administrators' is distinct enough for most agents.
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 does not mention scenarios where get_club_members_by_id or get_club_activities_by_id might be more appropriate, nor any prerequisites or conditions. The agent is left to infer usage from the name and description 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?
With no annotations, the description must disclose behavioral traits. It only states 'Read-only operation,' which is a basic safety indicator. It omits pagination behavior, authorization requirements, error handling, or any side effects. This is minimal disclosure 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded with the title and endpoint, but it contains redundancy: 'List Club Members' is repeated as 'Returns a list of the athletes...'. It is still within acceptable length and structured with clear sections.
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?
The description covers the basic purpose and read-only nature, but lacks any mention of response format, pagination behavior beyond parameters, or prerequisites (e.g., club existence). Given no annotations and no output schema, it is minimally adequate but not fully complete for a callable tool.
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 coverage is 100% and each parameter has a clear description (id, page, per_page). The description adds no additional parameter meaning beyond what the schema already provides. Baseline 3 is appropriate because the schema carries the semantic load.
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 'Returns' and the resource 'a list of the athletes who are members of a given club', which distinguishes it from sibling tools like get_club_admins_by_id or get_club_activities_by_id. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context (e.g., when a club ID is known) or exclusions. An agent gets no help in choosing this over related club 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?
With no annotations provided, the description carries the full burden. It does state it is a read-only operation and requires read_all scope for private routes, which is useful. However, it doesn't disclose response format details, potential errors, or behavior for non-private routes, and there is no mention of rate limits or other side effects beyond being read-only. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. The endpoint line and bullet points are efficient, though the formatting splits information across lines unnecessarily. Every sentence contributes value with no fluff, earning a solid 4.
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 simple export with one parameter and no output schema, the description covers the essential actions and scope requirements. However, it omits usage guidance relative to sibling tools (e.g., when to choose GPX over TCX) and doesn't mention response content type or error handling. The gaps are minor but present, so a 3 is appropriate.
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 single required parameter 'id' is fully described in the schema ('The identifier of the route.') with 100% coverage. The tool description adds no additional semantic context beyond reinforcing the id's role. Baseline score of 3 applies because the schema already handles parameter documentation.
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 'Export' and the resource 'Route GPX', and notes it returns a GPX file. It differentiates from siblings by format (GPX vs TCX) implicitly through the name, but doesn't explicitly name alternatives like get_route_as_tcx. The endpoint and read-only nature add clarity.
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 is given about when to use this tool versus alternatives such as get_route_as_tcx or get_route_streams. The only usage-related information is the scope requirement for private routes (read_all), but no context on selection criteria or conditions, leaving the agent to infer.
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?
The description discloses that it is a read-only operation and mentions the required scope for private routes, which is useful. However, with no annotations provided, the description carries the full burden of behavioral disclosure. It omits details on response format, error handling, or rate limits, leaving some uncertainty. The disclosed information adds context but is not comprehensive.
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 separate Endpoint and Description sections, concise, and front-loads the core purpose. There is slight redundancy with the title 'Get Route' and the opening line, but overall it is efficient and easy to parse.
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 simple GET-by-id tool, the description covers the essential purpose, endpoint, scope, and read-only nature. However, it does not describe the returned route object structure or possible error scenarios, which could be important for correct usage. Since there is no output schema, the description carries more responsibility for completeness than it fulfills.
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 fully describes the id parameter with a clear description ('The identifier of the route.') and 100% coverage. The description merely restates 'using its identifier' without adding new semantic details such as constraints, format nuances, or usage examples. It provides no value beyond what the schema already offers.
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: 'Returns a route using its identifier.' The verb and resource are specific, and it is distinct from sibling tools like get_route_as_gpx or get_route_streams, though it does not explicitly name them. It distinguishes itself well enough for an agent to understand it fetches the route object itself.
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 gives no guidance on when to prefer this tool over alternative route-related tools (e.g., get_route_as_gpx, get_route_streams). It only mentions a scope requirement for private routes, which is a permission constraint rather than a decision guide. No exclusions or alternative conditions are 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?
With no annotations provided, the description carries the full burden. It explicitly discloses 'Read-only operation' (a mutability signal) and the scope requirement. It adds nothing beyond that — no pagination, error behavior, or return characteristics, though for a simple read tool this is a reasonable baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short but redundant: the scope requirement appears twice ('Requires read_all scope for private segments' and 'Scopes: required: read_all'), and the heading 'Get Segment Streams' merely restates the tool name. Several lines repeat information rather than adding new value.
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 3-parameter, no-nested-object tool with 100% schema coverage, the necessary arguments are documented. However, there is no output schema and no annotations, so the description must carry more disclosure weight — and while it covers read-only status and scope, it omits any description of what the returned streams look like or how failures surface. Adequate but not thorough.
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 baseline is 3. The description adds no parameter meaning beyond the schema's own documentation of id, keys (stream types), and key_by_type ('Must be true'). Schema carries the load here and does so 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 states 'Returns the given segment's streams' — a clear verb plus resource. It distinguishes itself from its sibling 'streams' tools (get_activity_streams, get_segment_effort_streams, get_route_streams) by targeting segment streams specifically. However, it doesn't explicitly name those alternatives, leaving the differentiation implicit.
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?
Provides a prerequisite ('Requires read_all scope for private segments') which is usage-relevant. But it gives no guidance on when to choose this over the other three stream-returning siblings, nor any when-not-to-use conditions. Context is present; exclusions and alternative routing are absent.
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, the description carries the burden. It explicitly states 'Read-only operation' and lists required scopes, which is useful. However, it does not describe the response structure, error cases, or any Summit-specific limitations. The 'Summit Feature' hint is present but underdeveloped.
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 organized with endpoint, purpose, and scopes. It is front-loaded with the purpose and avoids fluff. The structure is clear and compact, though it could be tightened by merging the endpoint with the description.
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 simple GET with one parameter and no output schema, the description covers the basics. It lacks response shape details and any caveats about Summit availability. Given the low complexity, it is adequate but not comprehensive; an agent might need to fetch the activity to understand zones.
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 coverage is 100% and the parameter 'id' is described as 'The identifier of the activity.' The description reinforces this by referencing 'a given activity' but adds no new semantic detail. Baseline of 3 is appropriate since the schema handles it.
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 'Returns the zones of a given activity' and names the endpoint. It is distinct from sibling tools like get_laps_by_activity_id, though it does not explicitly contrast them. The 'Summit Feature' label adds context. Clear verb+resource, but could be more explicit about what zones are.
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?
There is no guidance on when to use this tool versus alternatives. It provides access requirements (activity:read vs activity:read_all) but not usage context or exclusions. The description does not mention sibling tools or when to prefer another endpoint.
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 the full burden, and it does disclose that the operation 'modifies Strava data' and requires the 'activity:write' scope. However, it does not explain the asynchronous nature of uploads, whether an upload ID is returned, or what happens if the file is invalid. It provides a basic warning about modification but lacks depth on process and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it redundantly states the scope requirement twice: 'Requires activity:write scope' and 'Scopes: required: activity:write.' This duplication wastes space without adding value. The structure is otherwise straightforward, but the repetition makes it less polished than a single, well-phrased scope statement.
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 that this is a mutation tool with no annotations and no output schema, the description should provide more context about what happens after the upload: return format, processing time, relationship to the 'activity' that gets created, and potential error cases. It only states the basic action and modifies-data warning, leaving an agent uncertain about expected behavior. For a 7-parameter tool with a file upload, this is insufficient.
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 covers 100% of parameters with descriptions, so the schema itself provides the meaning for each field. The tool description adds no additional parameter context, such as how 'data_type' affects parsing or what 'commute' and 'trainer' do to the resulting activity. Since schema coverage is high, a baseline score of 3 is appropriate; the description does not compensate with extra semantics.
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 states a specific verb ('Uploads') and resource ('a new data file to create an activity from'), making the core purpose clear. It implicitly distinguishes from direct activity creation (post_create_activity) by focusing on file upload, but does not explicitly name the sibling or contrast the two. The purpose is not a tautology and is understandable.
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 when to use this tool: when you have a data file to upload and create an activity from. However, it provides no explicit guidance on when not to use it or how it differs from alternatives like post_create_activity. There is no mention of prerequisites, sequencing, or fallback scenarios, so an agent would have to infer the appropriate context.
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 of behavioral disclosure. It explicitly states 'Read-only operation' and requires the scope 'profile:read_all', which are important for an agent to know before invoking. It does not cover rate limits or error behavior, but for a simple read-only GET, this is sufficient. The description adds meaningful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description begins with 'Get Zones', which merely restates the tool name and adds little value. It then repeats the scope requirement twice ('Requires profile:read_all' and 'Scopes: required: profile:read_all'). While the information is accurate, the structure is not tightly front-loaded and includes redundancy. It is verbose for such a simple operation, but not excessively long.
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 parameterless GET with no output schema, the description covers the key facts: what is returned (heart rate and power zones for the authenticated athlete), the scopes needed, and the read-only nature. There is no missing information that an agent would need to decide whether and how to call this tool. It is complete for its simplicity, though a brief note on output format would slightly improve it.
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?
There are zero parameters, so the schema fully covers them (100% coverage). The baseline for 0 parameters is 4, and the description does not need to add parameter details. It correctly omits any parameter-based explanation, so no deduction is warranted.
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 identifies the resource as the authenticated athlete's heart rate and power zones. The name itself is specific enough to distinguish from sibling get_zones_by_activity_id, and the description reinforces that it is for the logged-in athlete. However, it does not explicitly contrast with activity-specific zones, which would make differentiation more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention get_zones_by_activity_id or any condition that would select one over the other. An agent is left to infer usage purely from the name and endpoint, which is inadequate for clear routing.
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?
Since annotations are absent, the description carries the burden. It discloses that the operation modifies Strava data and requires the activity:write scope, which is useful. However, it does not describe what the response will be (e.g., the created activity object), whether the operation is reversible, or any rate limits. The core behavior (creating a manual activity) is clear, but the side effects and success semantics are under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but includes redundant lines: 'Create an Activity' is repeated as 'Creates a manual activity', and the endpoint 'POST /activities' is redundant given the tool name. The key scoping requirement (activity:write) is present. The structure is acceptable but could be tightened by removing the repeated title and endpoint, making it more 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?
For a create operation with nine parameters and no output schema, the description provides only the essential behavior. It does not explain what the API returns (likely the created activity), which an agent would need to know. It also does not clarify the distinction between 'type' and 'sport_type' or any validation rules. Given the complexity, the description is adequate but not comprehensive.
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 coverage is 100%, so each parameter already has a description. The tool description adds no parameter-specific context beyond the schema. It does not clarify the relationship between 'type' and 'sport_type' or explain expected formats, but the schema handles those. Per the rubric, the baseline is 3 when schema coverage is high, and the description does not enhance this further.
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 states a specific verb ('Create') and resource ('Activity'), clarifying it creates a manual activity for an athlete. It distinguishes itself from siblings like put_update_activity_by_id (update) and post_create_upload (upload) through the 'manual activity' phrasing and the explicit endpoint. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only states what the tool does, not when to use it versus alternatives. It mentions 'manual activity' which implies it is for direct entry rather than file upload, but it does not explicitly say 'use this instead of post_create_upload' or provide any exclusion criteria. No guidance on prerequisites beyond the scope requirement, and no mention of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It explicitly states 'Read-only operation' and discloses the 'top 10' result limit, which are key behavioral traits beyond just returning segments. It does not mention authentication or other potential side effects, but for a read-only operation these are minor gaps.
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 short and to the point, containing only the necessary information: a title, endpoint reference, return behavior, and read-only flag. The structure is clean but includes some redundancy ('Explore segments' title vs. description), and the read-only note is placed last. Overall, it is efficient with no wasted sentences.
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?
The description conveys the core purpose and the read-only nature, but it omits details about the return format (e.g., that it returns segment summaries, not full segment details) and any potential errors or edge cases. Given the absence of an output schema, a bit more context on what the response contains would be helpful. It is adequate but not complete.
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% parameter description coverage, including bounds, min_cat, max_cat, and activity_type. The tool description does not add any additional parameter meaning—it only vaguely refers to 'a specified query', which is less informative than the schema itself. Baseline 3 applies because the schema already documents parameters well.
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 it returns the top 10 segments matching a query, which is a specific verb+resource with a scope. It identifies the tool as an exploration/search endpoint, distinguishing it from segment-specific tools like get_segment_by_id. However, it does not explicitly name an alternative, so it falls short of a 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?
There is no explicit guidance on when to use this tool versus alternatives like get_segment_by_id or other segment-related endpoints. The phrase 'matching a specified query' implies a search use case, but no when/when-not conditions or alternative recommendations are given, leaving the agent to infer usage from context.
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 the full burden. It does disclose 'Read-only operation.' and privacy filtering ('Private routes are filtered out unless requested by a token with read_all scope.'), which adds behavioral context beyond the schema. However, it omits pagination behavior, error conditions, and response format, leaving gaps for a tool with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. However, it begins with 'List Athlete Routes,' which is redundant with the tool name get_routes_by_athlete_id, wasting a line. The rest is well-structured with the endpoint and description but could be tightened by removing the redundant heading.
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 output schema, the description provides only a vague return type ('a list of the routes'). It does not describe the structure of route objects, error responses, or how pagination parameters affect the returned data. While adequate for a basic listing tool, an agent might need more detail on response handling, especially since there is no output schema to fill the gap.
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%; id, page, and per_page are all described with defaults and meanings. The tool description adds no additional parameter semantics, such as how pagination affects results or how id relates to the authenticated athlete. Since the schema already covers parameters, the baseline of 3 applies.
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 states a specific verb ('List') and resource ('athlete routes'), and clearly distinguishes from siblings like get_route_by_id (singular) and route export tools. However, the phrase 'created by the authenticated athlete' is ambiguous given the id path parameter could refer to any athlete, which may confuse an agent about whether the endpoint is restricted to the current user.
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?
Usage is implied: the description says it returns a list of routes for an athlete, so an agent would naturally use it when that need arises. But it never explicitly mentions alternatives or conditions for choosing this over get_route_by_id, get_route_as_gpx, etc. No when-not guidance is provided.
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 of behavioral disclosure. It explicitly states 'Read-only operation,' covering the safety aspect, and discloses the filtering behavior for private segments unless read_all scope is present. This is more transparent than a bare one-liner, though it could mention pagination behavior or return format limitations, which are only weakly implied.
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 concise and well-structured, starting with a clear title, then the endpoint, a brief description, and a final read-only note. Each line serves a purpose, though the endpoint line is somewhat redundant given the tool name and description. Overall, it is efficiently written without unnecessary fluff, earning a high score.
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 simple list operation with pagination, the description covers the essential aspects: what is returned (a list of starred segments), the scope (authenticated athlete), and a specific behavior (private segment filtering). No output schema exists, but the term 'List' implies an array. It could mention the format of the items (e.g., summary objects), but that is inferred. Missing details like error handling or rate limits are not critical for this straightforward read operation.
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 already provides 100% coverage for both parameters (page and per_page) with clear descriptions and defaults. The tool description adds no additional meaning or usage examples for these parameters, so it stays at the baseline of 3. The description does not clarify the interaction between pagination and the private segment filtering, but the schema is sufficient.
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 'List' and the resource 'Starred Segments' for the authenticated athlete, distinguishing it from segment search or segment-by-id tools. It also notes private segments are filtered unless read_all scope, which adds specificity. However, it does not explicitly contrast with sibling tools like get_explore_segments, so it lacks that extra differentiation.
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 explains what it does but does not mention any conditions that would make this tool the preferred choice, nor does it reference any other tools for different segment-related queries. The only usage hint is the scope requirement for private segments, but that is a permission detail, not a selection criterion.
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 the behavioral burden. It explicitly states the operation is read-only and requires read_all scope for private routes, which is useful. However, it does not disclose potential error behavior, response handling, or any other side effects. The coverage is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose. It uses clear section headings and avoids excessive verbosity. Minor redundancy exists in repeating 'Read-only operation' and scope information, but it remains well-structured and easy to scan.
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 a simple tool with one parameter and no output schema, the description covers the essential elements: what it does, the auth requirement for private routes, and that it's read-only. This is sufficient for an agent to call it correctly. The lack of details about the response format is minor since the TCX file type is inherently understood.
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 already fully documents the single 'id' parameter (100% coverage) with a clear description. The tool description adds no additional meaning about the parameter beyond referring to the route context. Baseline 3 is appropriate since 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 tool exports a route as a TCX file, using a specific verb ('Export') and resource ('Route TCX'). It distinguishes from sibling get_route_as_gpx by specifying the TCX format, leaving no ambiguity about what is returned.
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 gives no guidance on when to use this tool over alternatives like get_route_as_gpx or get_route_by_id. It mentions scope requirements but does not explain selection criteria or cases where another tool would be more appropriate, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the safety burden. It explicitly states 'Read-only operation,' which is a positive behavioral trait. However, it lacks disclosure about authentication requirements, error handling (e.g., 404), or rate limits, which are important for a non-annotated tool. The read-only note alone is minimal but sufficient for basic safety awareness.
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 compact, starting with the resource name 'Get Club' and including endpoint and read-only status in a few lines. It is slightly redundant with the separate 'Description' line that repeats the purpose, but overall it is efficient and front-loaded. No extraneous information is present.
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 (one parameter, no output schema), the description clearly identifies the returned object as a club. However, it does not elaborate on the structure of the returned club or any error responses, which could be helpful since no output schema is present. For a straightforward GET-by-id, this is adequate but not comprehensive.
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 already provides full coverage of the single parameter with the description 'The identifier of the club.' The tool description adds no parameter-specific meaning beyond what the schema states, so the baseline of 3 applies. There is no additional context about format or constraints that the schema doesn't already include.
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 states 'Get Club' and 'Returns a given a club using its identifier,' which clearly identifies the resource (club) and the verb (get). It distinguishes itself from siblings like get_club_members_by_id and get_club_activities_by_id by focusing on the club itself, and the read-only note separates it from mutation tools.
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 the tool is used when you have a club identifier and want the club details, but it does not explicitly mention alternatives or state when not to use it (e.g., 'for members, use get_club_members_by_id'). The 'Read-only operation' hint is the only guidance, so usage context is only 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.
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 of behavioral disclosure. It explicitly states 'Read-only operation' and details the required scopes (activity:read vs activity:read_all) depending on the activity's privacy setting. This adds valuable context beyond the raw schema and helps the agent anticipate authorization requirements.
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: it starts with a clear title and endpoint, then a one-line summary, followed by scopes and a read-only note. It is compact and front-loaded with the essential purpose. No unnecessary repetition or filler.
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 list endpoint with no output schema, the description covers the core behavior (returns comments), permission requirements, and indicates the operation is read-only. Pagination parameters are documented in the schema, so the description need not repeat them. The only minor gap is not describing the response format, but this is acceptable given the absence of an output schema and the straightforward nature of the tool.
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 all five parameters are already documented. The description does not add any additional parameter-level guidance beyond what the schema provides, which meets the baseline for high-coverage schemas. It does not introduce ambiguity or conflict with the schema.
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 states a clear verb-resource pair: 'Returns the comments on the given activity.' The tool name itself is equally explicit, and the endpoint is provided. It does not explicitly contrast with sibling tools (e.g., get_kudoers_by_activity_id), but its purpose is unambiguous and distinguishable by name.
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?
It is implied that this tool is used to fetch comments for a specific activity, and no alternative tools are mentioned. It does not provide explicit when-to-use or when-not-to-use guidance, but the purpose is obvious enough that an agent would correctly select it without further context.
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 of behavioral disclosure. It explicitly states 'Read-only operation', which indicates the tool does not modify data. It also discloses that ownership and subscription are required. This goes beyond many descriptions, though it does not mention error behaviors when those conditions are not met. Still, it effectively conveys the safety profile and prerequisites.
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 reasonably concise and structured. It begins with a clear purpose, then gives the endpoint (which is useful since the endpoint is not in the schema), followed by the description and read-only note. It contains the necessary information without excessive verbosity. Minor redundancy exists between the first line and the 'Description:' section, but overall it is well-organized.
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 simple GET tool with a single parameter, the description covers the core purpose, ownership constraint, subscription requirement, and read-only nature. It lacks explicit error handling details, but those are not commonly expected for a read-only operation. The description is sufficient for an agent to understand what the tool does and when to use it, though it does not describe alternatives.
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 id parameter documented as 'The identifier of the segment effort.' The tool description adds no additional meaning about the id parameter beyond what the schema already provides. Since the schema fully describes the parameter, the baseline of 3 is appropriate.
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 'Returns' and the resource 'segment effort'. It specifies that the effort must be owned by the authenticated athlete, which adds context. While it doesn't explicitly differentiate from get_efforts_by_segment_id (which returns multiple efforts for a segment), the tool name itself is specific enough to avoid confusion. A clearer mention of alternatives would make it a 5.
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 states that the effort must be owned by the authenticated athlete and that a subscription is required, which provides important context for when the tool is applicable. However, it does not explicitly say when to use this tool versus alternatives like get_efforts_by_segment_id. The usage context is implied rather than explicitly contrasted with 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It declares 'Read-only operation,' which is a key trait. It also notes 'Athlete profile visibility is respected for all activities,' implying the result set may be filtered based on visibility. However, it omits details like error behavior when the user is not a member, sorting order, or rate limits. The visibility note adds context but the description is not exhaustive.
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 structured with an endpoint line, a description paragraph, and a read-only note. It is reasonably concise, though it repeats the core idea ('List Club Activities' vs. 'Retrieve recent activities...'). The structure is front-loaded with the resource and then provides context. No unnecessary fluff, but slight redundancy keeps it from a 5.
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 has 3 parameters, pagination, and no output schema, the description covers key operational details: membership requirement, read-only nature, pagination support, and visibility filtering. However, it does not describe the response structure or what fields are returned, nor does it explain potential errors (e.g., non-member access). The description is functional but not fully comprehensive.
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%—all three parameters (id, page, per_page) already have clear descriptions. The description adds no additional parameter semantics beyond what the schema provides (e.g., it just references pagination generally, while schema specifies defaults). Per the guideline, 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 'List Club Activities' and elaborates with 'Retrieve recent activities from members of a specific club.' This specifies the verb (retrieve/list) and the resource (club activities), distinguishing it from sibling tools like get_club_members_by_id or get_activity_by_id. The resource is unambiguous.
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 explicitly states a prerequisite: 'The authenticated athlete must belong to the requested club in order to hit this endpoint.' It also mentions 'Pagination is supported,' giving some usage context. However, it does not explicitly contrast with alternative tools (e.g., when to use get_activity_by_id vs. this), but the membership requirement provides clear context for when this tool is applicable.
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 the full burden. It does disclose 'Read-only operation' and lists required scopes, which are important behavioral traits. However, it does not mention pagination behavior (though page/per_page are in the schema), rate limits, or error handling. Given the absence of annotations, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose: it includes the endpoint, a 'Description:' label, and separate lines for scopes and read-only status. While it is front-loaded with a clear title, there is redundancy (e.g., 'Description:' is unnecessary, and the phrase 'activity identified by an identifier' is repetitive). It is not badly structured but is not tight either.
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 straightforward list endpoint with pagination, the description covers the core: it gives the endpoint, the purpose, the required scopes, and notes it is read-only. Pagination is handled in the schema, and the return value (the athletes) is stated. It does not mention response format details, but for this simple case that is acceptable. It is reasonably complete given the tool's simplicity.
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% (all three parameters have descriptions), so the baseline is 3. The description adds no extra meaning beyond what the schema provides—it merely restates that an activity is identified by an id and does not elaborate on page or per_page semantics. Thus, it adds minimal value.
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 a specific verb ('List') and resource ('Activity Kudoers'), and explicitly says it returns 'the athletes who kudoed an activity identified by an identifier'. This distinguishes it from sibling tools like get_comments_by_activity_id and get_laps_by_activity_id, so an agent can easily separate it without opening schemas.
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 usage context by specifying the required scopes for different activity visibility levels ('activity:read for Everyone and Followers activities', 'activity:read_all for Only Me activities'), which is essential for determining when this tool can be used. However, it does not explicitly contrast with alternative tools or state when not to use it, so it misses a full 5.
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 the full burden of behavioral transparency. It declares the operation is read-only and requires read_all scope, which is valuable. However, it does not disclose the response format, potential errors, rate limits, or any special handling of the streams. The lack of detail about what the streams contain or how they are structured leaves the user partially uninformed.
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 concise, front-loading the main purpose and then providing scope and read-only notes. The endpoint URL is repeated, which is slightly redundant, but the overall structure is efficient and easy to scan. Each sentence serves a purpose without 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?
The tool is relatively simple, but given there is no output schema, the description should provide some context about what a stream contains or how the response looks. It does mention that the segment effort was completed by the authenticated athlete, which is essential. However, it omits any explanation of the stream data structure (e.g., arrays of data points keyed by type) and does not mention that key_by_type must be true, though the schema covers that. Some additional 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?
The input schema provides 100% coverage of parameter descriptions, including the enum for keys, the required boolean default for key_by_type, and clear text for id and keys. The description adds no additional parameter context or elaboration beyond the schema, so the baseline of 3 is appropriate.
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 states the specific operation: 'Get Segment Effort Streams' and clarifies 'Returns a set of streams for a segment effort completed by the authenticated athlete.' This clearly identifies the resource (segment effort) and differentiates from sibling tools like get_segment_streams (for a segment) and get_activity_streams (for an activity).
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 key usage context: it is for a segment effort (not a segment or activity), requires the read_all scope, and is read-only. It does not explicitly contrast with alternative stream tools, but the clear resource identification makes the intended use unambiguous. The read-only and scope guidance are useful for callers to know when this tool is appropriate.
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 must disclose behaviors itself. It states 'Read-only operation' and that only activities with 'Everyone' visibility are included, which are important constraints. However, it does not mention response format, potential empty results, or authentication requirements beyond the schema, so it is thorough but not exhaustive.
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 concise and structured, with a clear title, endpoint, and key details front-loaded. It avoids fluff and each line serves a purpose, though the title and description overlap slightly.
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 absence of an output schema, the description does not explain the structure or content of the returned stats (e.g., distance, time, elevation). It also omits any error scenarios or rate-limit notes. For a simple read-only endpoint this is a moderate gap that could impact an agent's ability to interpret results correctly.
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 has 100% coverage, and the single parameter 'id' is described as 'Must match the authenticated athlete.' The tool description adds no additional semantic nuance about the parameter. This meets the baseline but offers no extra value.
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 identifies the resource ('activity stats of an athlete') and the specific action (GET). It also notes the visibility filter, which distinguishes it from other stats-related tools like zones or segments. While it doesn't name siblings, the scope is explicit enough for an agent to differentiate.
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 athlete stats but does not explicitly state when to choose this tool over alternatives. The visibility note provides context about data scope but no direct guidance on tool selection among the many sibling getters. This is a clear but not fully specified usage context.
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?
The description explicitly states 'Read-only operation' and lists required scopes (activity:read, activity:read_all), which are crucial behavioral traits that an agent needs to know. Since no annotations are provided, the description carries the burden and does well by disclosing mutation safety and authentication needs. It does not detail error handling or response format, but for a read-only GET, this is sufficient for a 4.
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 structured with headers and is reasonably concise, but it contains redundancy: it repeats the scope information ('Requires activity:read scope...' and later 'Scopes: one of: activity:read, activity:read_all'). This minor duplication prevents a perfect score, but overall it is well-organized and front-loaded with the purpose and key constraints, earning a 4.
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?
The tool is a simple GET for activity streams, with all parameters documented and the purpose clear. It includes authentication scope requirements and read-only status. It does not explain the response structure (no output schema exists), but the description's high-level 'returns the given activity's streams' is adequate for an agent to understand what it will get. Given the simplicity, it is largely complete, though it could mention when to choose this over segment/route stream tools.
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%, so all three parameters (id, keys, key_by_type) are already described in the schema with clear definitions and enums. The tool description adds no additional parameter semantics. Per the rubric, with high schema coverage, a baseline of 3 is appropriate; the description does not compensate or enhance beyond the schema.
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 it returns the given activity's streams, with a specific verb and resource (GET /activities/{id}/streams). This distinguishes it from other stream tools like get_segment_streams and get_route_streams, even though no direct comparison is made. The purpose is unambiguous and the endpoint adds precision.
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 does not explicitly say when to use this tool versus alternatives like get_segment_streams or get_route_streams. It implies usage by naming the resource ('activity's streams'), but lacks explicit exclusions or alternatives. The scope requirements are about permissions, not usage selection. Thus, it provides a clear purpose but no explicit comparative guidance, rating a 3.
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 does state 'Read-only operation,' which is a key behavioral disclosure (no side effects). However, it does not mention any authentication requirements, error behavior (e.g., 404 if not found), or the response format. The read-only note provides some value, but the description remains minimal in disclosing other behavioral aspects.
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 concise and well-structured, with separate lines for endpoint and read-only status. It is slightly redundant ('Get Equipment' and 'Returns an equipment...' both state the purpose), but it avoids unnecessary fluff and stays focused. The key information is front-loaded.
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 simple get-by-id tool with a single required parameter and no output schema, the description provides enough to call it correctly: it states the input (id), the action (returns equipment), and the side-effect profile (read-only). It does not elaborate on the response contents, but that is often acceptable for such tools, especially given the sibling context where get-by-id tools are common. It is complete enough for an agent to make the call.
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 coverage is 100% and the only parameter 'id' is described as 'The identifier of the gear,' which is clear and sufficient. The description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 applies.
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 operation ('Returns an equipment using its identifier') with a specific resource (equipment) and an access method (by id). It distinguishes itself from sibling get_*_by_id tools by naming the resource 'gear' rather than activity or segment. The title 'Get Equipment' reinforces the purpose without ambiguity.
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 makes it obvious that this tool is for fetching a single piece of equipment by its identifier, and there is no competing gear tool among siblings. While it doesn't explicitly say 'use this when you have a gear id' or list exclusions, the unambiguous resource specificity makes the usage clear. It could be improved by explicitly stating that this is the tool for gear lookups, but the context is sufficient.
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 of behavioral disclosure. It clearly states 'Read-only operation' and details required scopes, which informs the agent about safety and authentication. However, it does not describe response shape, pagination, or error cases, leaving some behavioral aspects unspecified, but for a simple GET this is acceptable.
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 compact and uses clear sections (Endpoint, Description, Read-only operation, Scopes). It front-loads the key action. There is a minor redundancy: the title 'List Activity Laps' duplicates the description 'Returns the laps...' but overall the length is appropriate and well-structured.
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 simplicity (one parameter, no output schema), the description covers the essential aspects: what it does, endpoint, permissions, and read-only nature. It does not explain the return format, but without an output schema, the need for such detail is limited. For a basic list operation with clear scoping, the description is complete enough for an agent to call it correctly.
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 fully describes the only parameter 'id' as 'The identifier of the activity' (schema coverage 100%). The description adds no additional meaning, merely restating 'identified by an identifier.' Since the schema already covers the parameter, the baseline score of 3 is appropriate; the description does not enhance understanding beyond the schema.
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: 'Returns the laps of an activity identified by an identifier.' This specifies the exact resource (laps) and the operation (list/return), which distinguishes it from sibling tools like get_comments_by_activity_id or get_kudoers_by_activity_id. The inclusion of the endpoint reinforces the action and resource.
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 when to use the tool (when you need an activity's laps) but does not explicitly contrast it with alternatives or state limitations. It mentions permission requirements (activity:read vs. activity:read_all) but not when to choose this tool over others. Given the large set of sibling tools, more explicit routing guidance would be beneficial.
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. It explicitly states 'Read-only operation' and the required scope, which are key behavioral traits. It also notes that private segments require read_all, adding useful context. It does not describe error handling or response format, but for a simple retrieval this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat repetitive (the title 'Get Segment' is echoed in the description) but remains concise and well-structured. It front-loads the purpose and includes endpoint and scopes in a clean format. Minor redundancy prevents a perfect score.
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 simple GET by id, the description covers the essential operational details (scope, read-only nature). While it does not describe the return format, given the lack of an output schema and the simplicity of the resource, the description is sufficient for an agent to make the call correctly. Slightly more context on response handling would push it to 5.
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 coverage is 100% and the description does not add any parameter-specific details beyond what the schema already provides. The 'id' parameter is fully described in the schema, and the description only repeats the scope requirement. Baseline of 3 is appropriate.
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 'Returns the specified segment.' with a specific verb and resource. The endpoint GET /segments/{id} makes it unambiguous. It naturally distinguishes from sibling tools like get_efforts_by_segment_id or get_segment_streams, which return related data rather than the segment itself.
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 mentions the read_all scope requirement for athlete-specific or private segments, providing some contextual guidance. However, it does not explicitly state when to use this tool versus alternatives (e.g., when to use get_efforts_by_segment_id instead), nor does it describe any exclusion conditions. It implies usage for retrieving a segment by id but lacks comparative routing.
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, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only operation' and lists the OAuth scopes, which covers safety and permissions. It also adds attribution requirements for displaying data, which is extra context beyond a simple fetch. It does not describe the response format, but for a simple GET-by-ID that is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is concise, but the inclusion of a full attribution example with an image reference adds length without functional value for tool selection. The key information (endpoint, scopes, read-only) is front-loaded, but the attribution section is extraneous and could be trimmed.
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?
The description covers endpoint, authentication requirements, read-only nature, and attribution guidance, which is sufficient for a simple get-by-ID operation. It doesn't mention error handling or return value shape, but with no output schema, stating 'returns the given activity' is adequate. It is complete given the tool's simplicity.
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 coverage is 100% with both parameters ('id', 'include_all_efforts') described in the schema. The description does not add any meaning beyond the schema—it doesn't explain semantics, defaults, or interaction between parameters. The baseline for high coverage is 3, and the description does not elevate it.
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 'Get Activity' and specifies it returns the activity owned by the authenticated athlete, distinguishing it from sibling tools like get_laps_by_activity_id or get_zones_by_activity_id. The verb+resource is specific and unambiguous.
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?
It provides clear context by specifying the required scopes (activity:read vs activity:read_all) based on activity visibility, which tells the agent when access is granted. It doesn't explicitly name alternatives or say 'instead use X', but the scope logic and endpoint path imply this is the primary activity retrieval tool. This is adequate but lacks explicit routing to 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only operation,' which conveys safety, and implies authentication via 'authenticated athlete.' However, it does not mention pagination behavior, potential empty results, or response format, leaving some transparency 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 extremely concise, with a clear structure: title, endpoint, description, and read-only flag. Every sentence earns its place, and there is no redundant or extraneous text.
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 low complexity (only two optional parameters, no output schema) and the presence of a clear description of purpose and safety, the description is adequate. It omits details like response structure or error handling, but these are not essential for the agent to invoke the tool correctly.
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?
Both parameters (page, per_page) are fully described in the input schema (100% coverage), so the baseline is 3. The description adds no additional meaning about these parameters, merely relying on the schema for their semantics.
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 lists clubs for the authenticated athlete, using specific verbs ('List', 'Returns a list') and a precise resource ('clubs whose membership includes the authenticated athlete'). It stands apart from sibling tools like get_club_by_id by focusing on the athlete's own memberships.
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 the tool: to retrieve clubs associated with the logged-in athlete. It does not explicitly mention alternatives or exclusions, but the context is unambiguous enough for an agent to infer its appropriate use.
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. It explicitly states 'Read-only operation' and explains that the representation detail depends on the profile:read_all scope. This discloses key behavioral aspects beyond the simple GET request, though it could mention authentication requirements more directly. Still, it does not contradict anything and provides solid transparency.
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 concise, with the purpose front-loaded and the endpoint line providing slight redundancy (the title already says 'Get Authenticated Athlete'). It wastes little space and is structured clearly, though it could drop the endpoint label without losing meaning. It earns a 4 for being appropriately sized.
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 simple GET with no parameters and no output schema, the description covers the essential: what it returns, the scope-based representation difference, and that it is read-only. It does not explain error handling or rate limits, but those are minor given the tool's simplicity. Overall, it is complete enough for an agent to invoke it correctly.
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 zero parameters, so schema coverage is trivially 100%. The description adds no parameter information because there are none. Per the rubric, a zero-parameter tool gets a baseline of 4, and the description does not need to compensate for missing parameter docs.
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 a specific verb ('Returns') and resource ('currently authenticated athlete'), and distinguishes it from siblings that fetch zones, stats, or activities. The resource and scope are unambiguous, so an agent can easily identify what this tool does.
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 provides clear context that it returns the authenticated athlete and notes the scope-dependent representation, but it does not explicitly contrast with alternatives like get_stats or get_logged_in_athlete_activities. Usage is implied by the name and description, but no explicit when-to-use or when-not-to-use guidance is given, so it falls short of a 4.
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, the description carries the behavioral burden. It explicitly states 'Read-only operation' and required scope 'activity:write', which are important behavioral traits. It also includes the HTTP method and path. It could add what the response contains or error behavior, but for a simple get this is sufficient.
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 lean and to the point. It leads with 'Get Upload', then provides the endpoint, purpose, scope, and read-only note in a compact format. Every line adds value with no redundancy.
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 one-parameter, no-output-schema tool, the description provides essential context: endpoint, read-only nature, and required scope. It does not cover error cases or return format, but these are not explicitly needed given the simplicity. Overall it is adequate.
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 already describes uploadId as 'The identifier of the upload', providing 100% coverage. The description does not add additional semantic detail beyond that, so the baseline of 3 applies.
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 states a clear verb and resource: 'Returns an upload for a given identifier.' This is specific to uploads and distinguishes from sibling tools like get_activity_by_id or get_gear_by_id. The endpoint and ID are explicit, leaving no ambiguity about what the tool does.
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 clearly indicates the tool is for retrieving an upload by ID, which implies when to use it. However, it does not explicitly mention when not to use it or compare with alternatives like post_create_upload. Despite that, the context is unambiguous for a simple get operation.
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-openapi-mcp MCP server](https://glama.ai/mcp/servers/Arbodgad/strava-openapi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Arbodgad/strava-openapi-mcp)

Score Badge

Copy to your README.md:

[![strava-openapi-mcp MCP server](https://glama.ai/mcp/servers/Arbodgad/strava-openapi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Arbodgad/strava-openapi-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/Arbodgad/strava-openapi-mcp'

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