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

With no annotations provided, the description carries the full burden. It discloses the return shape ('same shape as a list_activities entry') and an important limitation: 'does not currently surface fields list_activities omits'. This is meaningful behavioral context, though it does not address errors, authentication, or side effects.

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

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

Three tight sentences, each earning its place: one for what it returns, one for when to use it, and one for what it intentionally does not return. The key usage guidance is front-loaded, and there is zero 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 single-parameter read tool with no output schema and no annotations, the description is complete enough. It specifies the return shape via reference to list_activities, explains when to use it, and clarifies the limitation on additional fields. Nothing essential is missing 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?

The schema only defines activity_id as a required string, with 0% description coverage. The description compensates by explaining that the id is the identifier already obtained from list_activities, an event, or the athlete. It provides provenance but does not give format or example values.

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 operation: 'One activity by id', naming the resource and the lookup key. It also distinguishes itself from list_activities by specifying 'same shape as a list_activities entry' and that it retrieves a single activity rather than a whole window.

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 states when to use the tool: when you 'already have an id (from list_activities, an event, or the athlete)' and want that one activity 'without re-listing a whole window'. This gives clear context and implies the alternative case where list_activities would be more appropriate.

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 behavioral burden. It discloses the data content and that intervals are 'detected' (implying derivation), but does not state read-only nature, pagination, limits, or behavior when no intervals exist. 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 two tight paragraphs, front-loading the core purpose and adding useful context without fluff. 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 no output schema, the description lists the returned metrics and explains the tool's utility. It is largely complete for a lookup tool, but could specify the return structure (e.g., an array of lap objects) and edge cases (e.g., activity without intervals).

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 tool description does not explicitly explain the activity_id parameter beyond the phrase 'inside one activity'. It implies the parameter identifies the activity but doesn't clarify format or source, failing to compensate for the schema gap.

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 'laps and detected intervals inside one activity' and lists specific metrics (distance, duration, pace, HR, power, zone). It distinguishes itself from siblings like get_activity (summary) and get_activity_streams (raw streams) by focusing on structured lap/interval 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?

Provides clear guidance on when to use it: 'Use it to see how a session was structured' and 'This is where interval execution shows up.' It implies a specific use case but does not explicitly name alternatives or exclusions, so it stops 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 disclosure burden and largely succeeds: it reveals downsampling, points bounds, rejection behavior, the full-series caveat, and the latlng anomaly. It also states the summary statistics returned. This is strong behavioral 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?

Front-loaded one-line purpose, then details in compact paragraphs. Every sentence adds operational value, including edge cases. There is no 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?

Given no annotations and no output schema, the description gives the essential return shape (points plus min/mean/max) and critical caveats. It stops short of documenting all possible errors or the exact latlng-note representation, but is adequate for safe 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 coverage is 0%, so the description must compensate. It explains types format with examples, points as evenly spaced samples with bounds, full semantics, and the activity scope. It does not fully define full's exact return shape or activity_id format, but covers the core parameters well.

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?

Opens with a crisp definition: time series inside one activity, downsampled. This clearly distinguishes it from broader get/list tools and from raw interval tools, even though no sibling is named. The example stream types reinforce the resource being retrieved.

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 when-to-use versus alternatives is given; tool selection is only implied by 'inside one activity, downsampled.' It does provide clear parameter-level guidance on when full=true is appropriate and warns against small points values. Missing explicit sibling routing or exclusions keeps this at a 3.

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 behavioral disclosure burden. It does disclose the contents of the response and a practical use case, which is helpful. However, it does not explicitly state read-only behavior, timezone format, possible null values, or any error cases—though these are minor for a zero-parameter profile lookup.

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: two sentences, no filler. The primary content is front-loaded immediately, and the usage guidance is a natural second sentence. Every word contributes to helping an agent decide whether and how to call the 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 zero-parameter lookup with no output schema, the description adequately lists the returned fields and gives a usage trigger. It does not specify exact value formats or edge cases, but nothing essential is missing for selecting and invoking 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 tool has no parameters, so the schema imposes no semantic burden. Baseline for zero parameters is 4; the description does not need to explain parameters and does not. No additional parameter context is necessary.

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 resource as the athlete's profile and enumerates the fields it contains: name, location, timezone, and sex. While it lacks an explicit verb, the tool name and structure make the action obvious. It distinguishes itself from the athlete-focused siblings by scope, though it does not name any alternatives.

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 explicit guidance on when to read this tool first: when interpreting local times or addressing the athlete by name. This gives the agent a clear context for invocation. It does not mention when not to use it or point to a specific sibling alternative, but the instruction is still actionable.

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 behavioral disclosure burden. It discloses that the return value is a PNG, that the chart is log-scaled, and that it aligns with the sibling's `kind` semantics. It does not explicitly state read-only or describe edge-case behavior, but for a chart-retrieval tool the disclosed format and scaling are meaningful behavioral context beyond the bare 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 about 50 words, front-loaded with the core definition and immediately followed by the use-case and alternative routing. Every sentence earns its place; there is no fluff or repetition of schema fields.

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 4 parameters, no output schema, and no annotations, so the description is the sole source for call semantics. It provides clear purpose and usage, but does not explain the date-range parameters (`newest`, `oldest`) or `sport_type` filtering, and gives no details about how the PNG is returned. This is adequate for a first approximation but incomplete for reliable 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 0%, so the description must compensate for all four parameters. It only explains `kind` (hr, pace, power) and mentions duration/distance as chart axes, not parameter meanings. The `newest`, `oldest`, and `sport_type` parameters are left entirely undocumented, leaving the agent to infer their roles from defaults or sibling tools.

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 defines the output as 'A PNG of the best-effort curve' and specifies the plotted variables (HR, pace, power vs duration/distance) plus the log-scaled x-axis. It also distinguishes itself from the sibling get_best_efforts by contrasting the full curve with 'ten named points', giving an agent a precise sense of what this tool produces.

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 states when to use this tool: 'Use this when the shape of the curve -- a plateau, a cliff past some duration -- says more than the ten named points get_best_efforts returns.' This names the alternative tool directly and provides a clear decision rule, so an agent can route correctly.

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 behavioral disclosure and does a solid job: it names the exact durations returned, states that the window defaults to the last 12 months, and clarifies kind values. It does not describe read-only safety or response format, but it 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 compact and front-loaded: it opens with the core output, then lists kind, durations, window default, and purpose. Every sentence contributes useful information and there is no 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?

It is adequate for a basic default call because the required kind parameter is explained and other parameters are optional. However, with no output schema, no annotations, and no date-format guidance for newest/oldest, an agent cannot fully anticipate custom-window behavior without guessing.

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 0% description coverage, so the description must compensate. It only documents kind ('hr, pace or power') and vaguely hints at the window default; newest, oldest, and sport_type are left entirely to inference from their names/default values.

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 resource and output: an athlete's best-effort curve with peak sustained values for hr, pace, or power, over named durations. It is specific enough to understand the tool, but it does not explicitly distinguish it from the close sibling get_best_effort_chart.

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 offers a concrete intended use: 'Use it to compare current form against past peaks.' However, it gives no when-not-to-use guidance and does not mention any alternative tool, so an agent is left to infer routing among 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 burden and discloses useful behaviors: default range, backwards-expandable window, and empty-list semantics. It omits sorting/timezone/date-format details, but for a simple read-only calendar tool these are not critical.

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?

Three short sentences, front-loaded with the core subject, then default behavior, then edge-case semantics. Every sentence contributes.

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 low-complexity tool with two optional parameters and no annotations, the description covers the main call patterns and empty-result interpretation. It is not fully complete because 'newest' and date formatting are left unspecified.

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 explains the default range and how to use 'oldest', but it never explicitly describes the 'newest' parameter or expected date format, leaving a real gap.

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 resource as planned calendar entries and enumerates content types (future workouts, races, goals), which distinguishes it from activity-history siblings like list_activities and list_workouts. It lacks an explicit verb, relying on the tool name, but the intent 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 gives clear operational context: the default date window (today to 28 days ahead), how to retrieve past planned entries via an earlier oldest, and how to interpret an empty result. It does not name alternative tools or exclusion conditions, so it stops short of 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. It discloses that only registered gear is returned and that an empty list means the athlete tracks no gear, which is a useful non-obvious behavior. For a zero-parameter read-only tool, this is meaningful transparency; it does not need to discuss side effects or mutation.

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 short and every sentence earns its place: the first identifies the resource, the second provides a use case, and the third explains empty-list semantics. It is front-loaded and easy to parse, though the first sentence is a noun-phrase fragment rather than a complete sentence.

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 an extremely simple tool with zero parameters and no output schema, the description gives enough context: what gear is returned, a typical use case, and the meaning of an empty response. It could be more explicit about the exact return shape, but the description covers the essential information an agent needs.

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 no parameters defined in the schema, so the baseline is 4. The description adds relevant context about what the returned data represents, even though it does not clarify parameter usage. Since no parameters exist, there is nothing more needed 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 clearly identifies the resource (registered gear like shoes and bikes) and a key attribute (accumulated distance), making it easy to distinguish from the activity and profile tools in the sibling list. It lacks an explicit verb such as 'list' or 'retrieve,' relying on the tool name 'get_gear' to convey the action, so it does not earn a 5.

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 a concrete use case: checking mileage on a given pair of shoes. It also clarifies the meaning of an empty result, which helps an agent interpret the response and decide whether to use this tool. It does not explicitly mention alternatives, but no sibling tool covers gear, so this 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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. Since the tool is a read operation (implied by 'get' and the noun 'settings'), it doesn't need to warn about destructive effects, but it also doesn't explicitly state read-only behavior or any limitations (e.g., which sports are covered, whether it returns all zones at once). The description adds the context that zone boundaries are sport-specific, which is valuable, but it leaves out return format details (like units or structure). A score of 3 is appropriate because it covers the essential 'what' but not the 'how' of the response.

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 plus a trailing note, totaling under 30 words. It front-loads the core content (zone types) and immediately provides the critical usage context ('Read this before judging...') with no redundancy. Every clause adds value and is tightly 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?

Given the tool's simplicity (no params, no output schema), the description covers the essential information: what data is returned and when to use it. It could be more complete by describing the output format or any assumptions (e.g., whether it returns all sports or a specific one), but those are minor gaps. The description is sufficient for an agent to correctly invoke and interpret the data.

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 0 parameters, so the schema itself is trivially covered (100% coverage). The description adds meaning by listing the specific metrics (FTP, LTHR, etc.) that the output will contain, which is helpful beyond the empty schema. Per the baseline for 0 params, a score of 4 is warranted since the description enriches the otherwise empty parameter context.

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/resource combination: it retrieves training zones and thresholds per sport, enumerating FTP, LTHR, max HR, and various zone types. This is distinct from sibling tools like get_athlete_profile or get_training_load_chart, which focus on other data domains. The mention of 'per sport' sets it apart clearly.

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 guides when to use this tool: 'Read this before judging whether a session was easy or hard' and explains why (zone boundaries differ per sport). While it doesn't explicitly name alternative tools for exclusion, the guidance is clear and actionable. It could strengthen by mentioning that this complements activity analysis tools, but it's sufficient.

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 responsibility for behavioral disclosure. It does mention the default time window (90 days) and the chart output (PNG), but it does not explicitly state that this is a read-only operation, nor does it describe any edge cases (e.g., empty data, timezone handling). For a chart tool, this is adequate but not thorough; a 3 reflects the missing details beyond the basic output type.

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 compact, consisting of two sentences, and the most critical information (chart type and metrics) is front-loaded. The second sentence provides a useful use-case metaphor but adds a bit of flourish that could be trimmed. Overall, it is efficient and well-structured, with 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 relatively simple chart tool with only two optional parameters, the description covers the output type, default window, and usage context. However, it lacks explicit parameter documentation and any mention of error handling or response format details beyond 'PNG'. Given no output schema or annotations, the description is only minimally complete; an agent could call it correctly with defaults but would need to guess at custom date ranges.

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% – the description does not mention the 'newest' and 'oldest' parameters at all. It only hints at a default 90-day window, implying customization is possible, but it never explains what these parameters control or their format (e.g., date strings, relative dates). Since the schema coverage is low, the description should compensate, but it fails to do so, leaving agents to guess parameter semantics. The default hint saves it from a 1.

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 generates a PNG chart of specific performance metrics (CTL, ATL, TSB) over time, which distinguishes it from sibling tools like get_training_readiness or get_wellness. The verb 'get' and resource 'training load chart' are explicit, and the mention of the chart type and metrics leaves no ambiguity about what it does.

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 a clear contextual trigger: use when the shape of the data (spike, plateau, climb) is more informative than raw numbers. This is a good usage hint, though it does not explicitly name alternatives or state when NOT to use it. The guidance is useful but leaves the selection between this and numeric data tools to inference.

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 and handles it well. It reveals the default six-week window, explains how TSB is classified, describes the ramp-rate read, and specifies the HRV threshold and comparison window. This gives an agent a strong mental model of what will happen when the tool is called.

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 detailed yet efficient, front-loading the core purpose and then elaborating on defaults and return values. Every sentence adds meaningful behavioral or output information without redundancy or fluff.

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 absence of an output schema, the description thoroughly explains return values, classification bands, and conditional behavior. The main missing piece is explicit parameter semantics, but overall the description is complete enough for an agent to understand what the tool returns and how the default window behaves.

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 the six-week default window, which implies that newest and oldest are optional date-range overrides, but it never explicitly explains those parameters or their expected format. This is minimally helpful but leaves a clear gap.

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: assessing current training form from CTL/ATL/ramp rate and recent HRV. It goes beyond a simple verb+resource by specifying the computed metrics, output classification bands, and the HRV comparison logic, making it easy to distinguish from siblings like get_training_load_chart or get_wellness.

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 the tool—when a coach-style readiness assessment based on training load and HRV is needed. It does not explicitly name alternatives or exclusion conditions, but the detailed output description makes the appropriate use case obvious.

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 behavioral disclosure burden. It usefully states that it defaults to the last 30 days and describes the per-day fields. However, it does not disclose date-range application details, limits, output structure, or authentication/error behavior.

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 compact and front-loaded with the core purpose, followed by useful detail and a practical usage note. It is appropriately sized without redundant phrasing, though it could tighten the final sentence slightly.

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 no annotations and no output schema, the description leaves important gaps: how to request a specific range, accepted date formats, maximum range, and the exact response shape. It gives a good overview but is not fully complete for an agent to invoke it correctly in all reasonable 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 0%, and the description never mentions the newest/oldest parameters. 'Defaults to the last 30 days' implies these optional parameters serve as range bounds, but the agent is left to infer their format, whether both must be supplied, and how they interact.

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 resource as daily wellness and training-load history and enumerates the main metric groups (CTL, ATL, ramp rate, athlete logs). It conveys this is the record to read when evaluating load sustainability, which helps distinguish it from siblings like get_training_readiness, though it does not explicitly name any alternative.

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: 'This is the record to read before judging whether load is sustainable.' It implies the historical, broad wellness scope without explicitly listing when not to use it or naming alternative tools such as get_training_readiness or get_training_load_chart.

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 and performs well: it states this is read-only, returns raw unshaped payloads, warns that raw payloads are large, and discloses redaction of credentials and personal contact information. These are precisely the behavioral traits an agent needs to anticipate before invoking an arbitrary API escape hatch.

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?

Each sentence earns its place: purpose, when to avoid, path construction, query-argument placement, read-only reassurance, and redaction behavior. The most important fact is front-loaded, and the description is compact given the amount of necessary context.

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 deliberately generic tool with no output schema and no annotations, the description covers all the essentials: base URL, path variables, params usage, read-only semantics, payload size expectations, and redaction. An agent has enough guidance to call this tool correctly for an arbitrary path, which is exactly the intent of an escape hatch.

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%, but the description compensates by explaining that 'path' is relative to https://intervals.icu/api/v1, gives a concrete example, and resolves the '{athlete}' placeholder to the configured athlete ID. It also clarifies that 'params' is for query arguments, which adds semantic meaning that is entirely absent from the bare 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 clearly states this tool performs an arbitrary GET against intervals.icu v1 paths and returns them unshaped, using the specific verb 'GET' and resource 'any intervals.icu v1 path'. It also distinguishes itself from dedicated sibling tools by framing it as a fallback escape hatch, so an agent can tell when this tool applies.

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 says to use this only when a dedicated tool cannot answer, which directly routes agents away from siblings and toward the right tool. It also gives concrete usage rules with an example path, explains the '{athlete}' expansion, and instructs that query arguments belong in params, not the path.

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 sorting, default date range, filtering options, and response contents (distance, duration, etc., and matched vs returned). It does not disclose read-only status, auth needs, or rate limits, but the level of detail is more than minimal.

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 three sentences that front-load the core functionality. It avoids fluff but could be more structured (e.g., bullet points for parameters). Overall 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?

Given no output schema and no annotations, the description does a decent job describing the return fields and the matched vs returned count. It lacks explicit details on pagination behavior, limit semantics, and error cases, but is adequate for a simple list operation.

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%, so the description must compensate. It adds meaning for activity_type (gives examples) and implies date range for newest/oldest via the default. However, limit is not mentioned, and date format is not specified. Partial coverage but not comprehensive.

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 lists completed activities in a date range, newest first, and mentions filtering by activity type. It distinguishes from single-activity or stream tools by scope, but does not explicitly name sibling alternatives, so it's not perfect.

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 usage context (default 30 days, filtering) but does not explicitly say when to use this tool versus alternatives like get_activity or get_activity_streams. No exclusions or alternative routing 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?

No annotations are provided, so the description must carry behavioral disclosure. It clarifies the resource is a template library organized in folders and that it excludes completed sessions. However, it does not describe read-only status, pagination, folder traversal behavior, or return format. Adequate but minimal for a zero-parameter list tool.

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 tightly written sentences with no redundancy. The core subject is front-loaded, and the clarifying contrast with list_activities immediately follows. 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?

For a zero-parameter, no-output-schema tool, the description covers what the resource is, what it is not, and how it relates to a sibling tool. Nothing essential for selecting or invoking this tool is missing given its simplicity.

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 per calibration rules the baseline is 4. There is nothing to document, and the description adds no parameter-specific information because none is needed.

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: 'The athlete's saved workout library and its folders.' It explicitly distinguishes itself from list_activities by clarifying these are templates, not completed sessions, making sibling differentiation clear.

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 provides explicit guidance on when NOT to use this tool: 'use list_activities for what was actually done.' This tells the agent the deciding criterion (templates vs. completed sessions) and names the correct alternative.

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