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. The term 'check' and 'show' imply a non-mutating, read-only operation, which is sufficient for a simple status check. It does not explicitly state that no changes are made, but the nature of the action and the lack of parameters make this transparent enough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long and front-loaded with the primary purpose. Every word earns its place, with no repetition or fluff, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema tool, the description is complete. It clearly states what the tool does and when to use it, and the sibling context shows how it fits into the connection management workflow. There is no missing information that would hinder an agent from invoking it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The empty input schema requires no additional explanation, and the description appropriately does not attempt to document parameters that do not exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks and shows Strava connection status, using the specific verb 'check' and resource 'connection status'. This distinguishes it from sibling tools like connect-strava and disconnect-strava, which manage the connection, and data-fetching tools that retrieve stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this when the user asks about their connection status,' providing clear guidance on when to invoke the tool. It does not explicitly mention when not to use it or compare to alternatives, but the context is strong enough for an agent to differentiate it from connect/disconnect tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry full transparency burden. It discloses that authentication opens a browser window, which is helpful, but it does not explain what happens if the account is already connected, whether the 'force' option is necessary, or any side effects beyond the authentication flow. For a mutation-like action, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the action and followed by the usage condition. Every word serves a purpose, with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple OAuth connect tool with one optional parameter and no output schema, the description covers the core action and when to use it. However, it omits details about what happens after connection, such as success/failure indication or behavior when already authenticated, which is useful context for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully documents the single 'force' parameter with a clear description ('Force re-authentication even if already connected'). The description adds no further 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Connect your Strava account to enable activity tracking.' This specifies the verb and resource, and it naturally distinguishes from sibling tools like 'disconnect-strava' and 'check-strava-connection'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit usage guidance is provided: 'Use this when the user asks to connect, link, or authenticate their Strava account.' This gives clear context for when to invoke the tool, though it does not discuss exclusions or alternatives, which is acceptable given the tool's distinct purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full transparency burden. It explicitly discloses the key side effect: 'remove stored credentials.' This goes beyond the name and informs the agent of the security-relevant action. It doesn't detail irreversibility or effects on other services, but for a zero-parameter tool this is adequate and notably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each earning its place: the first states the action, the second states when to use it. Front-loaded and free of filler. Excellent structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple action tool with no parameters and no output schema, the description is complete: it covers what, why, when, and the side effect. Sibling tools help disambiguate, and the description is self-sufficient. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information because none is needed. It appropriately focuses on the action and usage context, which is all that matters here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Disconnect') and identifies the resource ('your Strava account') plus additional detail ('remove stored credentials'). It clearly distinguishes this tool from siblings like connect-strava and check-strava-connection, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance: 'Use this when the user wants to logout, disconnect, or remove their Strava connection.' This clearly states the intended use case. However, it lacks explicit 'when not to use' or alternative tool references, so it falls slightly short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 mentions 'popular segments' but does not clarify what 'popular' means, result limits, sorting, pagination, or authentication requirements. This leaves significant uncertainty for the agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the action and resource, includes the bounding box format, and mentions all optional filters. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has one required parameter and three optional ones, and the description covers the core purpose and filters. However, with no annotations and no output schema, it lacks behavioral details (e.g., what 'popular' means, pagination) and does not provide usage alternatives. 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage for all four parameters, so the description does not need to explain them. It only restates the optional filters (activity type, climb category) without adding new semantics like the dependency that minCat/maxCat require riding activityType, which is already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Returns' and clearly identifies the resource as 'popular segments' scoped by a geographic bounding box. It distinguishes this tool from siblings like get-segment or list-starred-segments by emphasizing geographic exploration rather than individual lookups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description conveys a clear use case: use when you need to discover segments within a geographic area. However, it does not explicitly mention alternatives or conditions when not to use it, so it lacks exclusions but provides clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of disclosing behavior. It does disclose a key side effect: 'saves it to a pre-configured local directory,' which is important for an agent to know. However, it does not mention authentication requirements, error handling, file naming, or whether the operation overwrites existing files. This is adequate but not rich behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise, front-loaded with the action, and contains no redundant information. Every phrase earns its place: specifies the export format, the resource, and the destination.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one required parameter and no output schema, the description covers the essential context: what it exports, in what format, and where it saves. It lacks information about return values (e.g., success message) and potential failure modes, but given the simple nature of the tool and the rich schema, the description is sufficiently complete. A score of 4 reflects that it could add a note about output or prerequisites but is otherwise adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameter semantics: routeId is described as 'The ID of the Strava route to export.' The description adds no additional parameter-level detail beyond the schema, but it reinforces the meaning by referring to 'a specific Strava route.' Per calibration, with schema coverage at 100%, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Exports a specific Strava route in GPX format and saves it to a pre-configured local directory.' It specifies the verb (exports), resource (specific Strava route), output format (GPX), and side effect (saving to a local directory). This distinguishes it from sibling tools like export-route-tcx (different format) and get-route (retrieval without file output).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (when a GPX export of a route is needed) but does not explicitly provide usage exclusions or name alternatives. Since sibling tools exist (e.g., export-route-tcx for TCX format), the description could have stated 'use this for GPX, export-route-tcx for TCX' to improve guidance. The context is clear but lacks explicit alternative comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses a key behavioral trait—saving to a pre-configured local directory—which implies a mutating side effect. However, it omits other useful behavioral context such as overwrite behavior, authentication requirements, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, tightly worded sentence that conveys the core purpose, format, and destination with no redundancy or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool, the description covers the essential elements: what is exported, the format, and the destination. It lacks minor details like return value or prerequisites, but given the absence of annotations and output schema, it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage for the single parameter routeId with a clear description. The tool description adds no additional meaning beyond what the schema states, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Exports... in TCX format'), the specific resource ('a specific Strava route'), and a unique side effect ('saves it to a pre-configured local directory'). It distinguishes the tool from the sibling export-route-gpx by format (TCX vs GPX).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for exporting a route in TCX format, but it does not explicitly mention when to use this over export-route-gpx or other route tools. No exclusions or alternative comparisons are provided, leaving usage guidance only implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It discloses the read-only nature and the core behavior (returns routes within distance) but does not mention pagination, sorting, authentication requirements, or potential errors. For a simple read operation, this 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, then usage. No filler or redundant information. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity (4 parameters, no output schema), the description covers the core purpose and usage. It does not describe return structure, but the phrase 'Returns the athlete's saved routes' is enough for basic use. Sibling differentiation is clear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each parameter has detailed descriptions including examples, defaults, and constraints. The description merely restates the input requirements ('Provide latitude and longitude...') without adding new semantics, which aligns with the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Returns') with a clear resource ('athlete's saved routes') and scope ('start within a given distance of a location'). It also provides usage phrasing ('nearby routes', 'routes in a specific area') that distinguishes it from siblings like list-athlete-routes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Use when the user asks for routes near a place, nearby routes, or routes in a specific area.' It does not mention alternatives or when not to use, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 simply says 'Returns detailed metrics,' which implies a read-only operation, but it does not state whether authentication is required, what happens if the activity does not exist, or any error conditions. It adds minimal behavioral context beyond what the tool name alone suggests.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that efficiently lists the key output metrics. Every word contributes to understanding the tool's functionality, with no unnecessary filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a simple interface (one parameter, no output schema), and the description lists what is returned. However, it does not specify the output structure (e.g., nested objects, units) or handling of not-found activities. For a tool of this complexity, it is minimally adequate but could benefit from additional context about output format and error scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage for the single parameter (activityId) with a clear description: 'The unique identifier of the activity to fetch details for.' The tool description does not add any additional parameter information, but per the baseline for high schema coverage, a score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Returns') and resource ('detailed metrics for an activity'), and enumerates the specific metric types (distance, time, elevation, pace, heart rate, cadence, power, effort scores). This distinguishes it from sibling tools like get-activity-streams (raw data) and get-activity-laps (lap-level data).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest any related tools. The usage context is only implied by the tool's name and the fact that it returns metrics for a single activity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the transparency burden. It discloses the data returned (per-lap metrics) but does not mention behavioral aspects such as whether the activity must have laps, error behavior, or any rate limits. The read-only nature is implicit in 'Returns' but not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the action and lists the key metrics. Every word earns its place; there is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one simple parameter and no output schema, the description provides a reasonable summary of the return content (per-lap metrics with listed fields). It could mention units or the fact that laps are returned as an array, but the information is adequate for an agent to infer the tool's purpose and basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully describes the single parameter (activityId) with 100% coverage. The description adds little beyond reinforcing that it is for a specific activity, which is already in the schema. No additional meaning or constraints are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns per-lap metrics for a specific activity, enumerating the metric types (time, distance, speed, heart rate, cadence, power). The verb 'Returns' plus resource 'per-lap metrics' distinguishes it from sibling tools like get-activity-details and get-activity-streams.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: use this tool when you need lap-level metrics for a specific activity, requiring an activityId. It does not explicitly name alternatives or state when not to use it, but the specificity of 'per-lap metrics' makes the use case obvious. No exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description discloses scope requirements (activity:read vs activity:read_all), the possibility of Instagram-sourced photos, and the empty-array behavior. It also explains the size parameter's default behavior, providing thorough transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections. It could be slightly tighter in the output-format section, but every part serves a purpose and is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with no annotations and no output schema, the description is exceptionally complete. It covers purpose, parameters, output structure, auth scopes, and edge cases, leaving no critical gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already covers both parameters, but the description adds value with size examples and the behavior when size is omitted (returns all sizes). This enhances understanding beyond the schema's bare definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Retrieves photos associated with a specific Strava activity.' This clearly distinguishes it from sibling tools like get-activity-details or get-activity-streams, which handle other types of activity data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Use cases explicitly state when to use the tool: fetching photos, getting URLs, and accessing metadata. While it doesn't name alternative tools, the context makes the appropriate scenario clear. A slight improvement would be explicitly contrasting with other activity-data tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility for disclosing behavior. It explains return type (time-series streams), key behavioral traits like configurable resolution, pagination, and intelligent downsampling for large datasets. This is substantive beyond the schema. It does not mention error conditions or auth requirements, but the core behavior is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys the core purpose and key features without waste. It lists relevant stream types and mentions resolution, pagination, and downsampling in a compact, readable format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there is no output schema and 9 parameters, the description helps by summarizing the key capabilities. It does not detail return shapes or edge cases, but the schema covers parameter semantics thoroughly, and the description orients the agent to the tool's main value. It is complete enough for an informed agent to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with detailed parameter descriptions for types, resolution, series_type, summary_only, points_per_page, etc. The tool description adds a high-level summary of resolution and pagination but does not provide additional meaning beyond what the schema already offers. Baseline 3 is appropriate because the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: returns time-series data streams (heart rate, power, GPS, pace, elevation) for an activity. It specifies the resource (activity streams) and key features (configurable resolution, pagination, downsampling), which distinguishes it from sibling tools like get-activity-details or get-activity-laps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for retrieving detailed time-series data for a specific activity, which is distinct from the other activity-related tools. It provides clear context (configurable resolution, pagination, downsampling) but does not explicitly mention alternatives or exclusions. Since siblings like get-activity-details are for metadata, the purpose is clear enough without explicit when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states the tool fetches history and can return either a list or summary statistics, but does not disclose that it may make multiple API calls (as indicated by maxApiCalls), pagination behavior, or the read-only nature beyond the verb 'Fetches'. It also doesn't mention potential quota impact or how results are limited.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at two sentences, front-loaded with the main verb and resource, and includes the key optional behavior (summaryMode) without unnecessary detail. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 8 parameters and no output schema, and the description alone is minimal. While the schema explains parameters well, the description does not explain pagination, how many API calls are made, or the exact return structure beyond 'list' or 'aggregated statistics'. It is adequate but not complete for a complex tool without annotations or an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema description coverage is 100% with detailed explanations for each parameter (e.g., maxApiCalls default and purpose, summaryMode behavior). The tool description adds a high-level summary of filtering by 'date range and activity type' but does not provide detail beyond what the schema already offers. Baseline of 3 is appropriate since the schema fully documents parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches activity history with optional filtering by date range and activity type, and describes the summaryMode alternative. The verb 'Fetches' plus resource 'activity history' is specific and distinguishes it from siblings like get-activity-details (specific activity) or get-recent-activities (recent vs all).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving activity history with filters, but does not explicitly mention when to use this tool over alternatives such as get-recent-activities or get-athlete-stats. No exclusions or alternative tools are named, leaving the agent 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.

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 correctly uses 'Fetches' to imply a read-only operation and notes that it returns an ID, but it does not disclose details such as authentication scope, rate limits, or the exact set of profile fields returned. This is adequate for a simple no-parameter read tool but falls short of rich transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the action and resource, immediately states the output's key value, and includes a concrete example of downstream usage. Every word contributes, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with no parameters and no output schema, the description is reasonably complete: it names the resource, identifies the primary output (numeric ID), and provides a usage link to other tools. However, it does not enumerate the full profile fields or specify any error conditions, so it stops short of a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the input schema is empty and no parameter documentation is required. The description adds meaningful context about the output (the numeric ID), which is more than the schema provides. Baseline for zero-parameter tools is 4, and this description meets that bar.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Fetches') and resource ('profile information for the authenticated athlete'). It also explicitly distinguishes the tool by highlighting the unique numeric ID that other tools (e.g., get-athlete-stats) depend on, which sets it apart from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context by stating the profile ID is needed for other tools like get-athlete-stats, implying this should be called first to obtain that ID. It does not explicitly mention when not to use it or list alternatives, but the guidance is practical and unambiguous for its intended role.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the burden of behavioral disclosure. It states the tool 'fetches' (implying read-only) and notes 'authenticated athlete', which hints at auth requirements. However, it does not disclose potential side effects, rate limits, or any required OAuth scopes, leaving some ambiguity for a simple read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with a clear verb-first structure and no unnecessary words. It front-loads the key information about the resource and included data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool with no output schema, the description covers the essential context: it names the resource, the auth scope, and the key returned fields (usage distance, primary flag). It could list all return fields, but 'including' suggests additional data is present, which is acceptable for this simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema has no properties, so the baseline is 4. The description appropriately focuses on what the tool returns rather than parameter syntax, which is unnecessary here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Fetches') and identifies the resource ('athlete's shoes'), clearly distinguishing it from sibling tools like get-athlete-stats or get-athlete-profile. It also scopes to the authenticated user and mentions key fields returned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives. It describes what the tool does but lacks any contextual 'when' or 'when not' scenarios, such as comparing with activity or profile tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It does disclose the primary output behavior: recent, year-to-date, and all-time totals across specific metrics and sports. However, it does not mention whether this is a read-only operation, any authorization/privacy constraints, units of measurement, or how 'recent' is defined. 'Returns' implies a safe read but does not explicitly confirm it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the action ('Returns') and immediately specifies the resource and scope. Every piece of information is relevant, and there is no wasted wording, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is mostly sufficient for a simple one-parameter tool: it explains what the tool returns and the key dimensions (time ranges, metrics, sports). However, with no output schema or annotations, it could be more complete by mentioning units, the definition of 'recent', or access restrictions. Despite these gaps, the core selection and invocation needs are met.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage: the only parameter, athleteId, is clearly described as 'The unique identifier of the athlete to fetch stats for.' The description adds no additional parameter-specific meaning beyond what the schema already provides. Therefore, the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Returns') and a clear resource ('activity totals') with scope details: recent/year-to-date/all-time, and distance/elevation/time for rides/runs/swims. This distinguishes it from sibling tools like get-athlete-profile or get-recent-activities, which focus on profile data or activity lists rather than aggregated totals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied: use this tool when you need aggregated activity totals for a given athlete. However, there are no explicit when-to-use or when-not-to-use instructions, and no alternative tool is named. The presence of similar siblings (get-all-activities, get-recent-activities) leaves room for ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Although no annotations exist, the description adds useful context by specifying that output includes both a formatted summary and raw JSON, and it implies authentication scope with 'authenticated athlete.' However, it does not explicitly confirm read-only semantics or discuss any caveats.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences deliver purpose and output details with no irrelevant content. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless read operation, the description covers what it does and what it returns. There is no output schema to elaborate, and the complexity is low, so this is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the description does not need to explain any inputs. The baseline of 4 applies, and the description adds no param-specific details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action (retrieves) and the resource (the athlete's configured heart rate and power zones). This distinguishes it from sibling tools like get-athlete-stats or get-athlete-profile, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is provided for when to use this tool instead of alternatives. The usage is implied by the clear purpose, but there are no exclusions or comparisons with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It clearly indicates a read operation ('Fetches'), which implies non-destructive behavior, but it does not disclose pagination behavior, rate limits, or what 'most recent' means in terms of time range. The verb provides basic transparency but not rich details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler or redundancy. It is front-loaded with the verb and resource, making it easy to parse and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one optional parameter and no output schema, so the description is largely adequate. However, it does not clarify how this differs from the sibling tool get-all-activities, which could lead to incorrect selection. Additionally, no behavioral edge cases are mentioned, leaving some context missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers the sole parameter (perPage) with a description and default value, yielding 100% schema coverage. The tool description does not mention the parameter, but the schema already explains it, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Fetches' and a clear resource: 'most recent activities' for the authenticated athlete. The scope ('most recent') helps distinguish it from siblings like get-all-activities and get-activity-details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as get-all-activities or get-activity-details. The description simply states what it does without giving context on when it is the preferred choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must carry behavioral information. 'Fetches' implies read-only, but the description does not mention authentication needs, error handling, or the exact nature of 'detailed information'. It adds minimal value beyond the obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, tightly written sentence that front-loads the verb and resource. Every word earns its place, with no fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter fetch, the description covers the core purpose. However, without an output schema, 'detailed information' is vague about what exactly is returned. It also omits prerequisites or failure scenarios, 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides a complete description of the only parameter (routeId) with pattern and explanation. The description's 'using its ID' simply restates the schema, adding no extra meaning. With 100% schema coverage, the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses 'fetches' with a specific resource ('a specific route') and method ('using its ID'), clearly distinguishing it from listing, searching, or exporting sibling tools. It 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.

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 like find-nearby-routes or list-athlete-routes. There are no exclusions, alternatives, or context for choosing this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden of behavioral disclosure. The word 'Returns' indicates a read-only operation, which is helpful, but it does not mention authentication needs, error behavior, or any constraints. For a simple getter, the transparency 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that immediately states the action and resource, then lists the key return fields. It is concise, front-loaded, and contains no superfluous words, earning a perfect score for structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one parameter and no output schema, the description provides sufficient context by listing the types of data returned (location, distance, grade, etc.). It gives an agent a clear idea of what to expect. It could be slightly more explicit about response units or format, but it is adequately complete for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully describes the only parameter 'segmentId' with 100% coverage. The description does not add any extra meaning to the parameter, so it stays at the baseline of 3 for high schema coverage. No additional parameter context is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Returns detailed information about a segment' and enumerates specific attributes (location, distance, grade, elevation, effort/athlete counts). This distinguishes it from sibling tools like get-segment-effort or get-segment-leaderboard, which focus on sub-resources. The verb+resource combination is precise and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for fetching detailed segment information, but it does not explicitly contrast with alternatives or state when not to use it. There is no mention of sibling tools or exclusions, so guidance is only implied by the purpose statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states the data returned and does not mention authentication requirements, request limits, error behavior, or the return format. For a read operation, this is a notable gap, though the description is not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the verb 'Returns' and clearly specifies the resource and data types. There is no extraneous information, making it highly efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with only one parameter and no output schema, so the description's list of return data types (timing, power, heart rate) provides moderate completeness. However, it does not describe the full response structure or error cases, and the absence of annotations means the description alone must cover safety and usage constraints, which it does not fully do.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides a complete description of the single parameter (effortId) with 100% coverage. The description adds no additional meaning beyond the schema, only referring to 'a specific segment effort' which directly maps to the effortId. 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: it returns timing, power, and heart rate data for a specific segment effort. The verb 'Returns' plus the resource 'specific segment effort' and data types distinguish it from siblings like list-segment-efforts (which lists multiple efforts) and get-segment (which focuses on segment details).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for a specific segment effort' implies this tool is for retrieving a single effort's data, giving clear context on the primary use case. However, it does not explicitly mention when to use this tool instead of list-segment-efforts or provide exclusions, so the guidance is 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It mentions the data returned (times/power/HR) and filters, but does not disclose pagination behavior, authentication needs, or error handling. It's 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with a short intro and a bulleted list of usage examples. No wasted sentences; each bullet adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's primary function and data returned, which is helpful since there is no output schema. However, it omits details about pagination limits or auth requirements, so it's not fully complete for a tool with 9 parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description summarizes filter categories but adds no new meaning beyond the schema's per-parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a leaderboard for a specific Strava segment, using a specific verb and resource. It distinguishes itself from sibling tools like get-segment and list-segment-efforts by focusing on the leaderboard aspect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use this to' bullets provide clear, actionable use cases for the tool. It doesn't explicitly mention alternatives or when not to use it, but the context is clear enough for an agent to decide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosing behavior. It says 'Returns,' implying a safe read operation, but does not explicitly state non-mutating behavior, authentication needs, or side effects. For a simple version check this is adequate yet not highly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with a clear verb and object, no filler. It is appropriately sized for a trivial utility tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no output schema, and a simple informational purpose, the description fully covers the necessary context. There is no missing information that would hinder correct invocation or interpretation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so no parameter details are needed. The 0-parameter baseline of 4 applies, since there is nothing for the description to add beyond what the schema already conveys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Returns' and clearly identifies the resource (Strava MCP server version and related metadata). This distinguishes it from sibling tools that focus on athlete data, activities, and segments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when you need server version info, but it does not explicitly state when to use this tool vs alternatives, nor does it mention any exclusions. Given no sibling provides this function, the lack of contrast is minor, but the guidance is still not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the burden of behavioral disclosure. It conveys that the operation is a read (List) and scoped to the authenticated athlete, but it does not mention pagination, required OAuth scopes, rate limits, or response format. This is basic transparency but 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence front-loaded with the verb 'Lists', followed by the resource and scope. No wasted words, clear and directly to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only list tool without an output schema, the description provides the essential information: what is listed and for whom. It could mention pagination or return type, but the simplicity of the tool makes the description adequately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and an empty input schema, so baseline for parameter semantics is 4. The description adds no parameter detail because there are none to explain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (Lists), the resource (clubs), and the scope (the authenticated athlete's memberships). It is specific and distinguishes itself from sibling tools since no other club-related tool exists.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool over alternatives or provide exclusions, but the usage is implied: it is the tool for retrieving the authenticated athlete's club memberships. No alternative club tool exists, so ambiguity is low, but explicit guidance is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses the read-only listing nature and pagination, but does not describe return format, ordering, or specific authentication needs beyond the phrase 'authenticated athlete'. This is acceptable for a low-risk list operation, but some behavioral details are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one concise sentence, front-loaded with the core purpose and including the key pagination detail. No wasted words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with two optional parameters and no output schema, the description provides sufficient context: it states what is listed, ownership, and pagination. It does not specify the response shape, but that is less critical for a standard list endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: both 'page' and 'perPage' have descriptions with defaults, ranges, and meanings. The tool description adds no additional parameter context beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'lists' and the resource 'routes', with scope 'created by the authenticated athlete'. This distinguishes it from siblings like 'get-route' (likely a single route) and 'list-athlete-clubs' (a different resource), making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving the authenticated athlete's routes, and the pagination mention indicates how to handle large result sets. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough for a simple listing tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosing behavior. It adds value by mentioning the returned data (time, distance, PR/KOM rank), but it does not address pagination, ordering, rate limits, or the exact scope of 'authenticated athlete's efforts' beyond what the name implies. It 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the specific action, resource, and key output details. No wasted words, and the structure is immediately scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with no output schema, the description adequately conveys purpose, scope (authenticated athlete), and result contents. It could be improved by explicitly noting pagination behavior or that it returns an array, but the perPage parameter partially covers this. Overall it is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all parameters are already documented structurally. The description only mentions 'optional date range filtering,' which maps to startDateLocal/endDateLocal, adding little beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the authenticated athlete's efforts on a segment, specifying the output includes time, distance, and PR/KOM rank. This verb+resource phrasing distinguishes it from siblings like get-segment-effort (single effort) and get-segment-leaderboard (global leaderboard).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for viewing a user's own segment efforts and optionally filtering by date range, but it does not explicitly specify when to choose this over alternatives (e.g., get-segment-effort) or mention exclusions. The context is clear enough for a self-explanatory tool, but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It indicates a read-only listing operation ('Lists') and ties data to the authenticated athlete, but does not disclose details about pagination, response format, or authorization requirements beyond the phrase 'authenticated athlete'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise sentence with no extraneous words; front-loaded and easily scanned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, no-parameter listing tool, the description adequately conveys the tool's main purpose. However, since there is no output schema, a bit more detail about the return value (e.g., array of segment summaries) could enhance completeness, but it's not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters and 100% coverage, so the baseline is 4. The description need not explain parameters, and it doesn't add conflicting information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Lists' and clearly identifies the resource ('segments') and scope ('starred by the authenticated athlete'), making its purpose unambiguous and distinct from sibling tools like 'get-segment' or 'explore-segments'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for viewing the authenticated athlete's starred segments but provides no explicit guidance on when to use this tool over alternatives or any exclusion criteria. The intended use case is clear from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries full responsibility for behavioral disclosure. It reveals the mutation (star/unstar) but does not disclose potential side effects, idempotency, required auth scopes, or what happens if the segment is already starred/unstarred. The mention of 'authenticated athlete' hints at authorization but lacks detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence: 'Stars or unstars a specific segment for the authenticated athlete.' It front-loads the action and contains no superfluous words, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter boolean action, the description covers the core purpose. However, since there is no output schema and no annotations, the agent receives no information about return values, errors, or behavioral nuances. It is minimally complete but leaves gaps around expected outcomes and edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both segmentId and starred having clear descriptions. The tool description adds no extra meaning beyond what the schema already provides, so the baseline of 3 is appropriate. The schema sufficiently explains each parameter's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: 'Stars or unstars a specific segment'. It specifies the resource (a specific segment) and the actor (the authenticated athlete). This distinguishes it from siblings like list-starred-segments, which lists segments rather than modifying their star status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly conveys usage: use this to change the starred status of a segment. However, it does not explicitly mention alternatives or when not to use, such as using list-starred-segments to view stars or get-segment for details. No exclusions are stated, so it is minimally sufficient but lacks explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.