Strava MCP

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

With readOnlyHint=true, idempotentHint=true, and destructiveHint=false already present, the description still adds real behavioral value: the 500-point cap, full-resolution exact stats plus downsampled series, the 'never blows the context window' guarantee, and the explicit exclusion of GPS. No contradiction with annotations.

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

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

Four sentences, each adding distinct information: what it returns, why the cap exists, when to prefer alternatives, and what it never returns. Dense and front-loaded without 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?

For a read-only, idempotent tool with a rich input schema and an output schema, the description covers usage context, behavioral constraints, and an important negative (no GPS). Nothing an agent needs to select and invoke it correctly is 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?

Schema description coverage is 83%, so the input schema already documents most parameters in detail. The description adds context around the point budget ('capped at 500 points', 'never blows the context window') and the metric constraint (GPS never available), but it does not need to re-explain each parameter.

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, bounded resource — 'time-series for one activity metric' — and states it returns exact stats plus a downsampled series. It also differentiates from related tools by noting GPS is never returned and by naming strava_get_activity / zones as the preferred alternatives for full activity detail.

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?

It gives an explicit routing rule: 'Prefer strava_get_activity / zones first; reach for this when you need the shape of the effort.' This tells the agent both when not to use it and when to reach for it, which is exactly the guidance needed.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds meaningful behavioral context beyond annotations: the tool does not call Strava and does not expose secrets, plus it includes specific guidance content. This is useful and consistent with the annotations.

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

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

The description is three short sentences, each providing distinct value: what the tool is, what it contains, and what it deliberately avoids. It is front-loaded with the core purpose and contains no filler or redundant restatement of the title.

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

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

Given the tool's low complexity (2 optional enum parameters, no nested objects, and an output schema), the description is sufficient. It explains the tool's purpose, contents, and safety guarantees without needing to detail return formats since an output schema exists.

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 0% and the description provides no information about the 'client' or 'response_format' parameters. The schema itself is self-explanatory through enums and defaults, but because coverage is low, the description should compensate—it does not. The description's mention of Hermes names indirectly relates to the client parameter but never explicitly explains how parameters affect output.

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 tool as machine-readable guidance for AI agents, specifying its scope (install, runtime, client guidance) and contents (Hermes tool names, anti-gateway-restart guidance). It explicitly states it does not call Strava, which distinguishes it from the many sibling tools that do. This provides a specific, non-tautological purpose.

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 gives clear context for when to use the tool: when an agent needs machine-readable install/runtime/client guidance, especially Hermes-specific tool names and anti-gateway-restart instructions. The caveat 'Does not call Strava' implies it is not for Strava API operations, though it does not explicitly name alternative tools or state 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.

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the agent knows this is a safe read. The description adds that it concerns a local SQLite cache and how to enable it, which is useful configuration context. However, it does not disclose behavioral details like what status fields are returned or behavior when the cache is disabled, though annotations reduce the burden.

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 short sentences, front-loaded with the purpose. The second sentence about enabling is directly relevant to the tool's topic. 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?

For a simple read-only status tool with one optional parameter and an output schema, the description conveys the essential purpose and configuration context. It could mention the meaning of the status output or the effect of response_format, but the schema and annotations fill in some gaps. Given low complexity, 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 has one parameter (response_format) with an enum and default, but the description makes no mention of it. With schema description coverage at 0%, the description fails to compensate by explaining parameter semantics. The schema itself provides the enum, but the description adds no additional meaning.

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 'Show' and identifies the resource as 'optional local SQLite cache status,' which distinguishes it from sibling tools like connection status or privacy audit. However, it does not explicitly name alternatives or contrast with siblings, so it stops short of full differentiation.

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 this tool is for checking cache status, but it does not explicitly state when to use it versus other status tools. The mention of enabling with STRAVA_CACHE provides setup context rather than usage guidance, and there are no explicit exclusions or alternative tool references.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds 'Does not call Strava or expose secrets,' clarifying that it performs no external network calls and protects privacy. This goes beyond annotations by specifying the tool's boundary with the Strava API and secret handling.

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 short sentences: the first states the purpose and scope, the second adds a critical constraint. There is no filler or redundant phrasing.

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 capability/explanation tool, the description covers all advertised topics (data, privacy, GPS, workflow, links) and sets expectations with a non-call guarantee. Given the output schema exists and annotations cover side effects, the description is complete enough.

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 documents a single optional parameter (response_format) with enum and default, and the description provides no explanation of this parameter. With 0% schema coverage, the description fails to compensate, though the parameter is self-explanatory.

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 'Explain' and lists concrete topics: supported Strava data, privacy boundaries, GPS handling, recommended agent workflow, and project links. It also clearly states what it does not do ('Does not call Strava or expose secrets'), which distinguishes it from the many data-access 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 signals when to use it ('recommended agent workflow') and provides an exclusion ('Does not call Strava or expose secrets'), implying it is for orientation rather than live data access. However, it does not explicitly name alternative tools or state 'use this when...' so the guidance is clear but not fully 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context by stating 'without calling Strava or exposing secrets', which clarifies network behavior and data privacy. This exceeds the annotation baseline.

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 front-loads the primary action ('Check') and compresses a long list of status items into a compact phrase. No filler or repetition exists.

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?

As a read-only status tool with no required parameters and an output schema, the description sufficiently outlines the scope. It misses parameter semantics and explicit usage differentiation, but the core behavior is clear. Given the presence of an output schema and strong annotations, it is fairly 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 0%, so the description must compensate. It mentions 'optional MCP client readiness' which obliquely relates to the 'client' parameter, but it does not explain the effect of 'client' or 'response_format' choices. The enum values are listed in the schema, but their semantics are not clarified.

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 'Check local Strava config, token file, Node version, privacy mode, cache readiness and optional MCP client readiness', providing a specific verb and a clear list of resources. It does not explicitly compare to sibling tools like strava_cache_status or strava_privacy_audit, but the scope is clearly a broader status check.

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 this is a diagnostic tool for local setup, but it does not state when to prefer it over more specific sibling tools like strava_cache_status or strava_privacy_audit. No exclusions or alternative guidance is provided.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds a 'non-medical' boundary and 'practical' framing, but does not disclose data sources, load calculation methods, or caching behavior. This adds some value beyond annotations but not rich 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 front-loaded sentence followed by a two-word disclaimer. Every word carries meaning, with no redundant filler or boilerplate.

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 moderately complex, but annotations and output schema cover safety and return structure. The description establishes the summary nature and 'recent' scope. Could mention relationship to strava_weekly_summary, but not essential for correct 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?

Schema description coverage is 67%, with days and timezone well-documented. The response_format parameter lacks a description but its enum and default clarify the options. The description adds no parameter-specific details beyond 'recent' which maps to days.

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 ('Build') and identifies the resource ('recent Strava activities') with a clear scope ('daily training/load summary'). It distinguishes itself from the sibling tool strava_weekly_summary by specifying 'daily.'

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 when-to-use guidance or alternatives. 'Read-only and non-medical' are safety/scope disclaimers, not usage directions. The agent must infer daily vs. weekly usage from the tool name alone.

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?

Annotations already mark it as read-only and non-destructive. The description adds crucial context that it does not call Strava APIs or expose user data, which is exactly the kind of behavioral disclosure that helps an agent set expectations.

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 the core purpose, then a critical caveat. No unnecessary 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 description covers the tool's function and limitations. An output schema exists for return values, so the description need not explain them. It does not describe when to choose this over sibling inventory tools, but the scope 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 coverage is 0% in the description. The only parameter (response_format) is fully defined in the schema, but the description does not compensate for low coverage by mentioning it or its effect on output. Since the parameter is trivial, the lack of description is a minor gap, but per the rule, low coverage requires compensation.

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 'Inventory' and lists concrete resources (data domains, auth scope requirements, privacy boundary, recommended first calls). It also differentiates by stating it does not call Strava APIs, distinguishing it from sibling tools that perform live operations.

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 is implied: this is an inventory for understanding supported domains and first calls. However, it does not explicitly mention when to use it vs alternatives like strava_capabilities or strava_quickstart, nor does it provide exclusions.

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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds critical behavior: the tool returns example or fake payloads, not real data, and serves as a contract preview. This is valuable context not conveyed by annotations alone, though it does not detail any additional behavior like response format or auth requirements.

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, front-loaded with the key action and resource. Every word adds value, and there is no redundant or filler content.

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

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

For a simple tool with one optional parameter and strong annotations, the description adequately covers its purpose, demo nature, and relationship to real APIs. It does not explicitly explain response_format, but the schema provides that information. The description is largely complete for an agent to use the tool 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 description does not mention the response_format parameter, and the schema has 0% description coverage for properties. The parameter's name and enum provide some intrinsic meaning, but the description fails to compensate for the lack of schema descriptions, leaving ambiguity about the markdown vs. json options and their implications.

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 that the tool returns realistic example payloads for three specific sibling tools (strava_daily_summary, strava_training_context, strava_list_activities), making its purpose distinct from the real API tools. The verb 'Returns' plus explicit resource names provides a precise, unambiguous definition.

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 gives clear context: use this tool to see the contract before calling real Strava APIs. It implicitly positions itself as a pre-call demo tool, though it does not explicitly state when not to use it or outline alternative scenarios. The guidance is useful enough for an agent to decide when to invoke it.

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?

The description goes beyond the annotations by disclosing critical behavioral details: 'Tokens are stored locally with 0600 permissions and are never returned.' It also warns agents not to invent codes, a crucial safety constraint. Annotations are minimal (readOnlyHint false, openWorldHint true), providing little on their own; the description shoulders the transparency burden effectively.

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 three sentences, each earning its place: first states the core function, second reveals token storage and permission details, third imposes a critical user-action requirement. No fluff, front-loaded with purpose. Ideal conciseness for the complexity.

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 essential context: prerequisites (user must complete OAuth), security behavior (local storage, 0600 permissions), and an output hint (tokens never returned). It does not explicitly describe failure modes or exact return format, but the output schema likely covers that. Given the tool's mutating nature and the minimal annotations, the description provides a solid but not exhaustive picture.

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 provides decent parameter documentation: 'code' has a description including the full redirect URL option, and 'response_format' has enum values and a default. The description only reinforces the 'code' parameter by mentioning 'supply the authorization code.' It does not elaborate on 'response_format,' but the enum is self-explanatory. With 50% schema coverage, the description adds minimal semantic value, hence the baseline score.

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: 'Exchange a Strava OAuth authorization code for local tokens.' This is a specific verb+resource pair, and it distinguishes the tool from siblings like strava_get_auth_url (which generates the auth URL) and strava_revoke_access (which revokes tokens). 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.

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

The description provides strong usage guidance: 'Requires explicit user action: the user must complete browser OAuth and supply the authorization code (agents must not invent codes).' This tells when to use the tool (after user OAuth completion) and when not to (never fabricate codes). It does not explicitly name alternative tools, but the context makes the workflow clear. Misses the explicit sibling mention, so not 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds a useful behavioral note that summary/structured modes protect raw GPS details, going beyond annotation data. However, it does not elaborate on other behaviors such as response format defaults or explicit_user_intent enforcement.

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, front-loaded with the core purpose, and every word contributes. It avoids fluff and is appropriately sized for a simple read 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 the tool's complexity (4 parameters, 2 enums) and the presence of a detailed schema and output schema, the description plus structured data collectively cover the essentials. The description could mention use cases or invocation context, but it is not seriously incomplete.

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 75%, meaning most parameters are already well-documented in the schema. The description adds a small amount of meaning by noting that summary/structured modes protect GPS details, but it does not significantly enrich parameter understanding beyond what the schema provides. With high coverage, baseline of 3 is appropriate.

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

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

The description clearly states 'Get detailed activity data by id', specifying the verb, resource, and required identifier. It does not explicitly differentiate from sibling tools like strava_get_activity_streams, but the resource scope is evident from the name and phrasing.

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 guidance on when to use this tool versus alternatives. It does not mention any preconditions, exclusions, or when a different tool might be more appropriate, despite having many sibling tools for various activity-related queries.

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?

Annotations already mark the operation as read-only, idempotent, non-destructive, and open-world. The description adds valuable context that GPS latlng is withheld unless explicit_user_intent is set, and that privacy_mode=raw returns upstream Strava JSON, which goes beyond annotation defaults.

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 with front-loaded action and result; no redundant phrases. The distinction from the sibling is integrated efficiently without extra 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 combination of high schema coverage, an output schema, and concise description covers purpose, alternatives, and key constraints. While some edge cases (e.g., resolution details) are left to the schema, the essential selection and invocation information is present.

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?

With 86% schema description coverage, the schema documents most parameters. The description enriches this by linking include_gps, privacy_mode, and explicit_user_intent into a cohesive privacy rule, which is not fully captured in individual property 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 states 'Get raw Strava activity streams' and enumerates the specific data types (time, distance, heartrate, cadence, watts, altitude), making the tool's function immediately clear. It also distinguishes from the sibling strava_activity_series by explicitly naming it and describing its alternative purpose.

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?

It explicitly advises 'For agent work prefer strava_activity_series' and explains why (agent-safe-series/v1 with hard point caps and exact stats). This gives the agent clear decision guidance, and also explains GPS access conditions for when to use include_gps/privacy_mode.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the behavioral caveat 'when available', which is useful, but it does not disclose privacy_mode semantics or the explicit_user_intent requirement beyond what the schema provides. No contradiction with annotations.

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

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

The description is a single 9-word sentence, front-loaded with the core action and resource. No filler or redundant information. It is as concise as possible while conveying the essential purpose.

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 fairly rich schema (4 parameters, including a sensitive privacy_mode with explicit_user_intent) and an output schema, but the description does not hint at these complexities. It adequately states the core function but leaves the agent to discover privacy overrides and availability conditions through the schema. Given the annotations and output schema, this is minimally acceptable but incomplete for full contextual navigation.

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 75% (3 of 4 parameters have descriptions), so the schema carries most parameter meaning. The description's 'for an activity' reinforces the required 'id' parameter but adds no new semantics for privacy_mode, response_format, or explicit_user_intent. Given moderate coverage, the description does not meaningfully augment 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 a specific verb 'Get' with a clear resource 'heart-rate/power zones for an activity', which distinguishes it from sibling tools like strava_get_zones (athlete zones). The phrase 'for an activity' explicitly scopes the tool to activity-level data, 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?

The description provides some implied usage guidance via 'when available', indicating zones may not exist for all activities. However, it does not explicitly contrast with sibling tools like strava_get_zones or strava_get_activity_streams, nor does it mention the required activity ID or privacy mode considerations. The agent must infer context from the schema and sibling names.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds a useful detail about auth scope depending on requested fields, but nothing else about behavior, edge cases, or the effect of privacy_mode=raw. This is a modest addition beyond annotations.

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

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

The description is a single sentence that is front-loaded with the main purpose and includes a key requirement. No wasted words, appropriately sized for the tool's complexity.

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?

Although an output schema exists, the description lacks critical context: it doesn't explain when to use this tool vs siblings, the meaning of 'requested fields' in relation to scope, or the importance of explicit_user_intent for raw mode. The tool's behavior is not fully specified, leaving the agent to infer too much.

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 67%, and the description adds no meaningful parameter details. The phrase 'depending on requested fields' is vague and does not clarify the role of privacy_mode, response_format, or explicit_user_intent beyond what the schema already provides. The description fails to compensate for the missing 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 gets the authenticated athlete profile with a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like strava_profile_get or strava_get_athlete_stats, which may have similar 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?

The description mentions a prerequisite (read/profile scope) but gives no guidance on when to choose this tool over alternatives. There is no indication of exclusions or when to use a different tool, so the agent lacks sufficient context for tool selection.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context that stats are public-visible and aggregate, which is useful, but it does not mention privacy_mode handling, rate limits, or caching, so it adds limited behavioral detail beyond annotations.

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

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

A single sentence that is immediately clear and front-loaded with the verb and resource. Every word earns its place; 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 stats tool, the description covers the core action and scope, and an output schema likely documents return values. However, it omits guidance on privacy mode implications and when to use this vs. similar tools, leaving some contextual 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?

The schema documents privacy_mode and explicit_user_intent with descriptions, but response_format has no description. The tool description itself does not mention any parameters, so it does not fill that gap. With 67% schema coverage, the description adds no value to parameter understanding.

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 it retrieves public-visible aggregate Strava stats for the authenticated athlete, using the verb 'Get' and specifying the resource. It distinguishes from siblings like strava_get_athlete (profile) and strava_list_activities (raw list), though it doesn't enumerate which specific stats are included.

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 choose this tool over alternatives. The description doesn't mention use cases, exclusions, or relations to other Strava tools such as strava_daily_summary or strava_get_athlete.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it's the first step when no token exists, but doesn't elaborate on return format or side effects (such as opening a browser). Given the simple nature and existing annotations, the description adds minimal but consistent context.

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 short sentences with no redundant wording. The first sentence delivers the core purpose immediately, and the second adds a concise usage condition.

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 a simple URL-generation tool, good annotations, and an output schema, the description covers the essential use case. It clearly indicates when to use it first, though it doesn't explicitly mention the follow-up exchange step. Still, context is 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?

Schema descriptions cover 2 of 3 parameters, and response_format is self-explanatory via its enum and default. The description itself doesn't add any parameter-specific details, so it stays at the baseline of 3.

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 'Generate' and names the exact resource ('Strava OAuth authorization URL'), clearly distinguishing this from sibling tools like strava_exchange_code. It also positions it as the first step in the OAuth flow.

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 'Use this first when no local token exists,' providing a clear condition for when to invoke this tool. While it doesn't name alternative tools, it implies that other tools are used after token acquisition, which is sufficient 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond the basic get operation, such as how privacy_mode affects returned data or that explicit_user_intent is required for raw mode; these details exist only in 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.

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

The description is a single short sentence, extremely concise and front-loaded with the core purpose. Every word earns its place, 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?

While the description is minimal, the rich annotations and detailed input schema (with privacy_mode and explicit_user_intent) fill in crucial context. An output schema is present, so return values need no explanation. The description is adequate for a simple read-only getter, but it does not explicitly mention privacy modes or escalation, leaving some contextual gaps that the schema fortunately covers.

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 covers 75% of parameters with descriptions (id, privacy_mode, explicit_user_intent), while response_format only has an enum/default. The description itself contributes no parameter meaning, and this modest schema coverage justifies a baseline score of 3 rather than higher.

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 'Get gear/equipment details by id' uses a specific verb and resource, clearly indicating a retrieval operation for a gear entity. It distinguishes itself from sibling tools like strava_get_activity or strava_get_route by the resource type (gear).

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 guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The usage is only implied by the verb 'Get' and the presence of an 'id' parameter, but there is no explicit contextual instruction.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds useful behavioral context by explaining that summary/structured modes avoid full route geometry, which is a privacy-relevant behavior beyond what annotations provide. No contradictions.

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 short sentences, immediately front-loaded with the core purpose. Every word adds value, with no fluff 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?

For a simple get-by-id tool with an output schema and robust annotations, the description is fairly complete. It covers the primary purpose and the key mode distinction. It could be improved by explicitly noting that raw mode requires explicit_user_intent, but that is already in the schema, so the description does not need to repeat it.

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 75%, with most parameters described. The description adds limited parameter insight beyond the schema; the phrase 'avoid full route geometry' clarifies privacy_mode behavior, but other parameters like response_format and explicit_user_intent are not addressed in the description. Baseline of 3 is appropriate.

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

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

The description clearly states 'Get route details by id', using a specific verb and resource. It distinguishes from sibling tools like strava_list_routes by focusing on retrieving a single route by ID. The mention of modes adds clarity without confusion.

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 have a route ID and need its details, but does not explicitly contrast with alternatives like strava_list_routes for finding routes. The note about summary/structured modes provides some usage context for privacy settings, but no explicit when/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?

Annotations already declare the tool as read-only and idempotent, so the description does not need to restate those traits. It adds the nuance that zones are returned 'when available,' which is a useful behavioral detail, but it does not explain what happens if zones are unavailable (e.g., empty response or error) or any privacy implications related to the privacy_mode parameter.

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 and free of extraneous words. It efficiently conveys the core function without redundancy, making it highly concise and well-structured.

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

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

The tool has an output schema and strong annotations, so the description does not need to detail return values or safety. However, it lacks guidance on when to prefer this over strava_get_activity_zones, and does not clarify the optional parameters' effects or the 'when available' caveat. This makes it adequate but not fully complete for safe and correct 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 description makes no mention of parameters. The schema covers two of three parameters (privacy_mode and explicit_user_intent) with useful descriptions, but response_format lacks a description, leaving a gap. Since comprehensive schema coverage is not high (67%) and the description adds zero parameter context, the tool's description does not help compensate for the missing parameter semantics.

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 gets the authenticated athlete's heart-rate and power zones, using a specific verb and resource. However, it does not distinguish itself from the sibling tool strava_get_activity_zones, which likely serves a different purpose (activity-specific zones), creating potential ambiguity.

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

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

No explicit guidance is provided on when to use this tool versus alternatives like strava_get_activity_zones or other zone-related tools. The phrase 'when available' implies a conditional outcome, but there is no clarification of prerequisites, such as whether zones must be configured, nor any direction to alternative tools for activity-level zones.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by stating the required permission scopes and that Strava pagination is supported, but it omits other behavioral details such as privacy-mode handling, rate limits, or pagination caps. No contradiction exists between description and annotations.

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

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

The description is three short sentences, each earning its place: it states the operation, the key filtering/pagination capabilities, and the required authorization. It is front-loaded and contains no filler or redundant restatements of the tool name.

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 rich parameter schema, the output schema, and the safe read-only annotations, the description is mostly complete for invoking the tool correctly. It captures the core purpose, filtering, pagination, and auth requirements. It does not surface the privacy_mode, response_format, or all_pages options at a high level, but those are well documented in the schema, so the gap is minor.

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 high at 89%, so the schema already explains most parameters in detail. The description's mention of after/before filters and pagination loosely maps to those parameters but doesn't add meaning beyond the schema. With such high coverage, the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'List authenticated athlete activities.' It also names key capabilities (after/before filters, Strava pagination), making the tool's purpose clear. It doesn't explicitly contrast itself with sibling list tools like strava_list_routes or strava_get_activity, so the full rubric's sibling-differentiation bar isn't met.

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 gives useful context: it lists authenticated athlete activities and mentions the required OAuth scopes (activity:read or activity:read_all). However, it doesn't say when an agent should choose this tool over alternatives or when not to use it, and there are many sibling tools in the same domain.

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?

Annotations already establish that this is read-only, idempotent, and non-destructive. The description adds the authenticated-athlete scoping, which is useful, but it does not disclose pagination behavior, response shape, or privacy-redaction effects beyond what the schema and output schema provide.

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, front-loaded sentence conveys the essential purpose with no filler. Everything present 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?

For a read-only list tool, the rich annotations, high schema coverage, and presence of an output schema mean the description does not need to explain return values or safety. The main gap is the lack of usage guidance, but for tool selection the purpose is clear enough to invoke 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?

Schema description coverage is 89%, so the schema already documents nearly all parameter semantics. The description adds no parameter-level meaning, which is acceptable given the high schema coverage, but it also does not compensate for the small undocumented remainder.

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 states a specific verb ('List'), resource ('clubs'), and scope ('joined by the authenticated athlete'). It clearly distinguishes this tool from sibling list tools like strava_list_activities and strava_list_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?

The description gives no guidance about when to use this tool versus alternatives, and it names no exclusions or competing tools. An agent must infer usage solely from the tool name and description.

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?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context about GPS/map geometry redaction unless raw mode is requested, which is not inferable from annotations alone.

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 with no filler. The core purpose is front-loaded, and the redaction caveat is placed where it matters for agent decision-making.

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 read-only listing tool with rich schema coverage, output schema, and safety annotations, the description covers the essential behavioral caveat. An agent has enough to call the tool correctly without needing return-value details.

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 high (89%), so the schema carries most parameter meaning. The description's 'raw mode' reference aligns with the privacy_mode parameter but adds little beyond what the schema already documents.

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?

States a specific verb ('List') and resource ('authenticated athlete routes'), which clearly distinguishes it from the singular get_route tool and the activity-oriented list_activities tool. The scope is precise and an agent can tell what it does immediately.

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

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

No explicit guidance on when to use this tool versus alternatives such as strava_get_route or strava_list_activities. The redaction note hints at behavior but does not provide selection criteria or exclusions.

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?

While annotations already declare readOnlyHint=true and destructiveHint=false, the description adds valuable context by noting 'Strava continues to redact GPS by default — onboarding does not change that.' This clarifies the tool's non-effect on privacy settings, which goes beyond the structured annotations. The description does not contradict the annotations.

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

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

The description is concise and front-loaded with the key information ('Read-only. Return...'), then expands on use case and a privacy note. Each sentence serves a purpose, though the inclusion of the field list ('preferred_name, goals, devices, training context, nutrition, preferences, and safety') makes it slightly dense. Still, it's 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 description covers what the tool returns (11-question flow, current profile, missing fields, connector hint), the use case, and the privacy implication. With no output schema, this is sufficient for an agent to understand what to expect. It lacks a mention of response_format handling in the description, but the schema covers that, and the overall context is 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 50%, with 'locale' described in the schema and 'response_format' missing a description. The description adds 'en or pt-BR' which repeats the enum values for locale but doesn't clarify response_format's meaning. The description provides some context (e.g., defaults) but doesn't fully compensate for the missing parameter doc. With 50% 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 states exactly what the tool does: 'Return the 11-question Delx Wellness onboarding flow (en or pt-BR), the current shared profile, missing critical fields, and a cross-connector hint.' This is a specific verb ('Return') with a clear resource and scope, and it distinguishes itself from sibling tools by focusing on the onboarding flow for wellness sessions.

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 starts a fresh wellness session and you need to fill out preferred_name, goals, devices, training context, nutrition, preferences, and safety.' This provides clear context for when to invoke the tool. It doesn't explicitly name alternatives or when not to use it, but the use case is well-defined.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable context beyond annotations by emphasizing that secret values are never revealed, and it lists the categories of posture information returned. This adds meaningful behavioral transparency without contradicting annotations.

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

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

The description is a single, concise sentence that front-loads the action and scopes the result without redundancy. Every element adds value and nothing is wasted.

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 an output schema and clear annotations; the description sufficiently enumerates the key aspects returned and the privacy guarantee. It could optionally clarify 'env-presence' or 'local privacy' further, but the provided detail is adequate for a straightforward audit 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?

Schema description coverage is 0%, and the description does not mention the response_format parameter. While the parameter's schema has an enum and default that make it self-explanatory, the description fails to compensate for the schema's lack of explanatory text, so it adds no additional meaning.

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 'Return' and clearly enumerates the resource dimensions: local privacy, cache, token-path, GPS redaction, env-presence posture. This distinguishes it from sibling status and data inventory tools by focusing on an audit of privacy-related configuration.

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 as a privacy audit or assessment, but no explicit when-to-use, when-not-to-use, or alternative sibling tools are mentioned. It is not misleading, but guidance is left to inference from the tool name and description.

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?

Beyond the readOnlyHint, the description discloses important privacy details (no OAuth tokens, API keys, or biomarkers) and a critical behavioral caveat that reading this profile does not change Strava's GPS-redaction default. This adds significant context about data contents and side effects that annotations do not cover.

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 and front-loaded, with each sentence earning its place. It covers purpose, data contents, and a caveat without fluff, and is appropriately sized for a simple read-only 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?

For a simple tool with one optional parameter and no output schema, the description gives sufficient context: it explains what the profile is, what it contains, and a key caveat about GPS redaction. It does not explicitly describe the return structure or the response_format behavior, but the schema's enum partially covers that gap.

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 description does not mention the response_format parameter at all, despite the schema having 0% description coverage on properties. While the schema includes an enum and default, the description fails to compensate by explaining how the agent might control output format, making the parameter semantics less discoverable in the narrative.

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 ('Read') and resource ('canonical Delx Wellness profile'), and clarifies it is the shared profile across wellness MCP connectors. It also notes what data it contains (onboarding input only), which distinguishes it from sibling tools like strava_get_athlete or strava_profile_update.

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 for when to use this tool: to access the shared wellness profile across connectors. It does not explicitly state when not to use it or name alternatives, but the mention of 'shared with other wellness MCP connectors' and the contrast with Strava GPS redaction imply a distinct role from Strava-specific 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?

It discloses important behavioral traits beyond annotations: requires explicit user intent, rejects secret-like fields, and notes GPS-redaction default is unaffected. These are safety-relevant details that the annotations (all false) do not convey. No contradiction with annotations.

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

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

The description is three sentences, each earning its place: purpose, intent requirement, and key constraints. It is front-loaded with the action verb and avoids 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 write operation with no output schema, the description covers the essential context: purpose, when to use (user confirmation), and key constraints. It does not describe the return format, but that is not critical for a patch tool given the schema details.

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

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

Schema coverage is 67%, so the baseline is 3. The description adds valuable meaning by clarifying that 'patch' is partial (not full replacement) and by listing prohibited field categories, which enriches understanding of the patch parameter beyond 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 opens with a specific verb and resource: 'Persist a partial patch to the canonical Delx Wellness profile.' This clearly states the tool's action and target, distinguishing it from the read-only sibling strava_profile_get.

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 explicit_user_intent=true is required after user confirmation. It implies this tool is for write operations, contrasting with read siblings, though it doesn't explicitly name alternatives or exclusions.

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?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds that it 'adapts to current state (env vars set? token present? what's next?)', which is useful behavioral context beyond the annotations. No contradictions.

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 and usage. Every word earns its place with no redundant content. 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 simple tool with rich annotations and no output schema, the description covers purpose, usage, and adaptive behavior. It could explicitly differentiate from 'strava_onboarding' but still provides enough context for agent selection and 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 description does not mention the sole parameter 'response_format'. With schema description coverage at 0%, the description fails to compensate, leaving the agent to infer semantics solely from the enum and default. The parameter is simple, but the rubric requires the description to help when schema coverage is low.

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 this is a 'Personalized 3-step setup walkthrough' with a specific trigger: 'Call this first when the user asks "how do I connect Strava?"'. This distinguishes it from sibling tools like strava_get_auth_url and strava_onboarding by positioning it as the entry point.

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: 'Call this first when the user asks how do I connect Strava?'. This tells the agent exactly when to invoke this tool and indicates it is the initial step, effectively excluding alternatives.

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?

Description discloses both the revoke action and the deletion of the local token file, adding specificity beyond the annotations' destructiveHint. It also explains the gating requirement of explicit_user_intent, providing important safety context about the destructive nature.

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 the action, no filler. 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?

Covers the action, usage condition, and gating mechanism. The destructive nature is clear, though it doesn't explicitly mention irreversibility or re-authentication steps; the output schema covers return values.

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 provides descriptions for explicit_user_intent but not response_format, leaving 50% coverage. The description reinforces the intent-gating semantics but doesn't add information about response_format, though the schema's enum and default partially compensate.

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

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

Description uses specific verb 'revoke' and identifies the precise resources: the OAuth access grant and the local token file. This clearly distinguishes it from sibling tools like strava_get_auth_url or strava_connection_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?

Explicitly states 'Use only when the user explicitly wants to disconnect Strava,' providing a clear condition for use. It doesn't name alternative tools but the condition is strong and unambiguous, covering both when and when-not to use.

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 annotations already declaring readOnly, idempotent, and non-destructive behavior, the description adds behavioral context by explaining the normalization process and mentioning fallback guidance when activity data is missing. However, it does not detail what the normalization entails or what the fallback guidance contains, so it provides moderate added 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 two concise, front-loaded sentences with no filler. Every clause adds information, and the key verb and resource appear immediately.

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 six optional parameters, an output schema, and sibling tools, the description provides only a high-level purpose and fallback note. It lacks usage context, parameter semantics, and behavioral details needed to fully understand and select the tool, leaving significant 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 description coverage is only 33%, and the tool description does not explain any of the six parameters beyond implying a lookback via 'recent'. Params like soreness, injury_flags, and response_format receive no semantic guidance, so the description fails to compensate for the sparse 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 a specific verb ('Normalize') and resource ('recent Strava activity load into a compact training_context'), clearly distinguishing it from sibling summary and inventory tools. The mention of fallback guidance adds further specificity about its purpose.

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 workout recommendation engines needing normalized training context, but it does not explicitly state when to choose this tool over siblings like strava_daily_summary or strava_weekly_summary. No alternatives or exclusion criteria are provided.

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?

Annotations already declare readOnlyHint=true, so the description's 'Read-only' is redundant. It adds 'non-medical' as a scope disclaimer but provides no additional behavioral context such as data source, caching, or rate limits. Since annotations cover the safety profile, the description meets the baseline without adding significant value beyond them.

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, front-loaded with the main action and key deliverables. No unnecessary words or fluff. It is appropriately concise for the tool's simplicity.

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

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

For a read-only summary tool with no required parameters, an output schema, and comprehensive annotations, the description provides sufficient context. Missing prerequisites (e.g., authentication) are implied by the surrounding sibling tools. The description could mention that it aggregates historical data, but overall it is complete given the structured fields.

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 75%, with days, timezone, and compare_days well described. The description adds no parameter-level information, but the schema handles most of the semantics. response_format lacks a description but has an enum, so the absence of description detail is acceptable.

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: building a weekly Strava scorecard with specific components (volume, intensity, sport mix, bottlenecks, next-week actions). The verb 'build' and the resource 'weekly Strava scorecard' are specific, and the weekly scope distinguishes it from the sibling strava_daily_summary.

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 guidance on when to use this tool versus alternatives. It does not mention strava_daily_summary for daily needs or other analysis tools like strava_get_athlete_stats. The word 'weekly' implies usage, but that's not explicit enough for an agent to make a selection decision.

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