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

With no annotations provided, the description carries full behavioral burden and does so well: it discloses read-only behavior, states derived values never overwrite provider-supplied values, and explains null return conditions with caveats. This gives an agent confidence about side effects and edge cases.

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 dense but efficient: it front-loads the core computation, explains the metric formulas in parentheses, then moves to edge-case behavior, side-effect safety, and prerequisite. Every sentence contributes information, with no filler or repetition.

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

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

Given there is no output schema, the description covers return edge cases, side-effect safety, data requirements, and a prerequisite. It does not describe the shape of a successful return or clarify the optional includeGap behavior, but the overall call context is sufficiently composed for an agent to proceed.

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 adds the useful fact that athleteId comes from list_athletes and clarifies the data source, but it never explicitly introduces the activityId parameter and many of its details are qualitative. The optional includeGap parameter is entirely unexplained, leaving a meaningful 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 names a specific verb ('derive') and resource ('one activity'), and specifies the metrics: aerobic decoupling with sport-specific formulas and grade-adjusted pace. It is clearly distinguishable from sibling tools that read series, analyze trends, or manage syncs.

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 states a clear prerequisite ('Requires athleteId from list_athletes') and implies this is the tool for deriving decoupling/GAP from stored samples for a single activity. It does not explicitly mention when NOT to use it or name alternatives, but the context is clear enough for correct 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful non-obvious behavior, such as timeBucket adding a time_bucket field usable in orderBy, and it clarifies limitations. However, it does not disclose the return format, pagination behavior, authorization needs, or whether any side effects exist.

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 each short sentence earning its place: core purpose, a valuable behavioral detail, limitations, and a required dependency. 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?

Despite having 10 parameters, nested objects, enums, and no output schema or annotations, the description only provides a high-level purpose and a couple of parameter hints. It is not complete enough for an agent to confidently construct complex metric/filter/dimension/orderBy requests or understand the result shape.

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 the 10 parameters. It only adds meaningful semantics for timeBucket (creates a time_bucket field for orderBy) and athleteId (obtain from list_athletes). Metrics, dimensions, filters, orderBy, date ranges, and limit remain unexplained, leaving most parameters underdocumented.

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 clear verb and resource: declarative aggregation over one cataloged dataset. It also distinguishes the tool from broader query/analysis siblings by explicitly excluding joins, arbitrary expressions, and file paths, so an agent can tell it apart from tools like read_series or query_read_only_data.

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

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

The description gives clear context for when to use this tool: for declarative aggregation over a single cataloged dataset. It also states exclusions (no joins, arbitrary expressions, file paths) and a prerequisite (athleteId from list_athletes), but it does not explicitly name alternative tools or say 'use X instead', so it just misses 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 provided, the description bears the full burden of disclosing side effects, output shape, pagination, or read-only behavior. It adds only the word 'deterministic' as a behavioral trait and mentions nothing about how results are returned or whether this is a read-only operation. This is a significant gap for a tool with no annotation coverage.

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

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

The description is two sentences with no filler, front-loading the primary purpose and then giving a key prerequisite. It is appropriately compact, though the brevity comes at the cost of needed detail.

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

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

Given the tool's complexity (13 parameters, 4 required, no annotations, no output schema), the description is far from complete. The schema provides enums for analysis and resolution, which helps, but the description fails to explain how to choose a dataset, what metrics mean, how filters work, or what the output contains. An agent would still be guessing for a 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 0%, and there are 13 parameters, so the description must compensate by explaining required and key optional parameters. It does not define 'dataset,' 'metrics,' 'analysis,' 'window,' 'compareMetric,' or 'resolution,' nor explain how they relate to the listed analyses. The description merely restates the general analysis categories without mapping them to schema fields.

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 names a specific action ('Run deterministic rolling statistics, baselines, correlations, seasonal comparisons, or trends') on a specific resource ('a cataloged series'), giving a clear sense of what the tool does. However, it does not explicitly distinguish itself from siblings like read_series, aggregate_data, describe_data, or fit_series_model, so it stops short of a 5.

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

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

The only guidance is 'Requires athleteId from list_athletes,' which tells the agent a prerequisite but not when to prefer this tool over alternatives like read_series or describe_dataset. No explicit when-to-use, when-not-to-use, or comparison with sibling tools 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?

With no annotations provided, the description carries the full burden and it does state 'Read-only,' which transparently conveys a non-mutating side-effect profile. It also discloses that athleteId must come from list_athletes, giving the agent a clear prerequisite. It does not describe error handling or interpretation of 'retrieval-index freshness,' but the key behavioral traits are covered.

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

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

The description is two compact sentences with no filler. The first sentence front-loads the full object list, and the second adds read-only status and the input prerequisite. Every phrase 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 single-parameter status tool with no output schema, the description is mostly complete: it says what is read, that the operation is safe, and where to obtain the required athleteId. The vague 'retrieval-index freshness' and lack of any return-shape guidance are minor gaps, but the agent can select and invoke the tool confidently.

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 the sole parameter. It adds the useful semantic that athleteId comes from list_athletes, but it does not explain what athleteId represents in the Catence context beyond what the parameter name and schema pattern already imply. This partial compensation earns a 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 states a clear verb ('Read') and enumerates specific status aspects: sync state, data coverage, entity counts, stream availability, unresolved errors, and retrieval-index freshness. This makes the core purpose understandable, though it does not explicitly distinguish itself from sibling catence_sync_progress, so it falls short of a 5.

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

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

The description gives a useful prerequisite: 'Requires athleteId from list_athletes.' However, it does not explain when to choose this tool over alternatives such as catence_sync_progress or query_read_only_data, nor does it state exclusions or preference conditions. The usage context is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only,' clearly indicating no mutation side effects, and details the scope of data returned (live heartbeats plus recent completed/interrupted runs). It stops short of describing output format or any rate/pagination limits, but the primary behavioral trait is covered.

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

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

Two tight sentences with no fluff. The core behavior is front-loaded, the read-only caveat is clearly placed, and the parameter prerequisite is provided in the second sentence without unnecessary detail.

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

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

For a simple tool with one parameter, no annotations, and no output schema, the description provides the essential operational context: what it reads, that it is safe, and where to obtain the required ID. It is slightly incomplete in that it does not characterize the returned heartbeat payload or note any real-time streaming behavior, but the tool's low complexity keeps the gap small.

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 declares athleteId as a string with a pattern, and schema description coverage is 0%. The description compensates by specifying that athleteId comes from list_athletes, giving the agent actionable provenance for the parameter. It does not elaborate on the ID's meaning beyond its name, but for a single obvious parameter this is sufficient.

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') with a clear resource: 'live progress heartbeats for active sync runs, plus the most recent completed or interrupted runs.' This distinguishes it from related sync tools like start_detached_sync and catence_status in intent, even without naming them.

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 states a useful prerequisite ('Requires athleteId from list_athletes') and declares read-only nature, which helps an agent know when it is appropriate. However, it does not explicitly say when to prefer this tool over catence_status or start_detached_sync, leaving some usage selection 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, the description does useful work by declaring the operation 'Read-only and descriptive,' so the agent knows it has no mutation side effects. It also surfaces the athleteId prerequisite. It does not disclose output format, date-range behavior, or any data-source caveats behind 'source-aware.'

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 definition is two tight sentences with the core operation front-loaded and no filler. The prerequisite is supplied as a short standalone sentence that is easy to parse.

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?

This is a composite report tool with no output schema and no annotations, and the date-window parameters are undocumented. The description names the report's content areas but does not explain what inputs control the time range or what shape the returned report takes.

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 explain the parameters, but it only clarifies athleteId ('Requires athleteId from list_athletes'). startDate and endDate are not mentioned, and the report period is only vaguely implied by 'monthly canonical volume/load.'

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 names a specific action ('Combine') and a clear deliverable: a cycling progress report built from FTP, VO₂max, volume/load, and power-curve histories. This distinguishes it from sibling point-data tools like get_ftp_history, get_vo2max_history, and power_curve_trend by framing it as a composite report.

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 prerequisite ('Requires athleteId from list_athletes') and labels the tool 'Read-only and descriptive,' which implies safe, report-oriented use. However, it does not state when to prefer this composite report over individual history or trend tools, nor 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly marks the operation as 'Read-only,' which is a critical safety signal, and clarifies the expected output content. It does not discuss possible errors or result size, but for a metadata-listing tool this is reasonably transparent.

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

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

Two sentences carry distinct, high-value information: the tool's output scope and its prerequisite. There is no filler or repetition; the most important purpose statement is front-loaded and the read-only/usage clarifiers follow compactly.

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 — one required parameter, no output schema, and a data-cataloging purpose — the description covers the essential content and prerequisite. It could improve by directly addressing how this tool differs from `describe_dataset`, but for most calling scenarios the agent has enough to invoke it correctly.

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

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

The schema has 0% description coverage and only documents `athleteId` with a pattern, so the description is responsible for parameter meaning. It adds that the ID comes from `list_athletes`, which is useful provenance, but it does not explain that the parameter identifies whose datasets are being described or any additional constraints. This is adequate but not rich.

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 action ('List cataloged datasets') and enumerates meaningful content dimensions: fields, units, permitted filters/groupings, providers, and time coverage. It is clear about what the tool returns, though it does not explicitly differentiate itself from the sibling `describe_dataset`, so it stops short of a 5.

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

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

The description provides a direct usage precondition: 'Requires athleteId from list_athletes.' This tells the agent when in the workflow this tool can be invoked. It does not discuss exclusions or mention alternative tools for similar metadata needs, but the provided context is clear and 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 present, the description carries the burden, and it explicitly declares 'Read-only,' which is strong transparency for a read operation. It also scopes the operation to one cataloged dataset, though it does not mention errors, rate limits, or response structure.

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 wasted words. The core action and read-only trait are front-loaded, and the prerequisite is placed at the end without disrupting clarity.

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 two-parameter tool, the description covers purpose, safety, and prerequisites, and even lists the returned content areas. However, the ambiguous 'dataset' parameter and absence of an output schema leave a meaningful gap for an agent that must call this 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 0%, so the description must compensate. It clarifies that athleteId comes from list_athletes, but the 'dataset' parameter is only referred to as 'one cataloged dataset' without explaining what values are valid, where they come from, or how they are formatted.

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 reads schema, filters, provenance, and coverage for one dataset, and marks it read-only. It is specific about the resource and verb, but it does not differentiate itself from the sibling tool 'describe_data' by name.

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 a useful prerequisite by saying athleteId must come from list_athletes, implying a call order. However, it gives no explicit guidance on when to use this tool versus the similar-sounding describe_data or other data-description 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 provided, the description carries the full burden and does well: it discloses read-only behavior, pagination, and that race flags are 'likely-race signals' not provider-confirmed metadata. This is meaningful behavioral context. It stops short of explaining 'canonical' semantics or error behavior, so it is not a perfect 5.

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—three short sentences—and every sentence supplies information: core purpose, behavioral nuance, read-only safety, and a prerequisite. It is front-loaded with the main action and avoids 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?

Given ten parameters, no output schema, and no annotations, the description covers the key points: purpose, pagination, read-only nature, and preprocessing with list_athletes. However, it leaves gaps around cursor mechanics, sorting, default limit, and the shape of returned data, so the agent cannot fully predict the result format without additional inference.

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 ten parameters. It only names filter categories ('sport, distance, name, and date') rather than mapping to actual parameters or explaining sort, limit, cursor, sports, and athleteId. This is insufficient for an agent to correctly construct a request using the less obvious parameters.

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

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

The description uses a specific verb and resource: 'Find canonical activities by sport, distance, name, and date.' It also clarifies the 'likely-race signals' output, which adds distinctiveness beyond merely 'find activities.' However, it does not explicitly name or contrast a sibling tool, so it falls just 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 gives a clear prerequisite: 'Requires athleteId from list_athletes,' which tells the agent a necessary dependency. It also labels the tool as read-only, signaling safe usage. Yet it does not state when to choose this tool over alternatives such as latest_cycling_activities or review_activity_deep_dive, so the usage context is only implied.

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 for behavioral disclosure. It reveals that the model is 'bounded' and that athleteId is required, but it does not state whether the operation mutates data, requires specific permissions, returns coefficients or predictions, or has rate limits. This leaves significant behavioral ambiguity for a tool that 'fits' a model.

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 carry a surprising amount of signal: model family, boundedness, domain exclusion, and a prerequisite. There is no filler, and the most important differentiators are front-loaded.

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 13 parameters, 4 required fields, no output schema, and zero schema descriptions, this description is far from sufficient. An agent would not know how to populate dataset, metrics, model, date filters, or resolution correctly, making the tool effectively uncallable without external knowledge.

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 the 13 parameters. It only mentions athleteId and its source, leaving model, metrics, dataset, dates, filters, resolution, and cursor semantics unexplained. This is a major gap in practical usability.

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 clear action ('Fit') and a specific resource ('bounded OLS, Theil–Sen, quadratic, or cubic descriptive model'). It also explicitly disclaims being a sport-performance model, which helps differentiate it from related analysis tools. The prerequisite reference to list_athletes further narrows its identity.

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: this is for descriptive modeling, not sport-performance modeling, and it must be preceded by list_athletes. It does not name alternative tools or state explicit when-not-to-use conditions beyond the performance-model exclusion, but it is enough to route an agent toward appropriate 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 no annotations provided, the description carries the full burden. It does disclose a key behavioral trait: the tool automatically hydrates the Strava activity before returning persisted segment efforts. However, it does not clarify whether hydration involves external API calls, potential delays, side effects, or what happens when data cannot be hydrated.

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, front-loaded with the use case, and each sentence adds value: what it does, when to use it, and what prerequisite to satisfy. There is no filler or repetition.

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

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

The tool has no annotations, no output schema, and no parameter descriptions, yet the description does not explain the semantics of limit or refresh, nor describe what the returned segment efforts look like. It gives a solid high-level purpose but is insufficient for an agent to correctly configure and call the tool in all 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%, so the description must compensate, but it only explains that athleteId comes from list_athletes. It does not explain activityId, limit, or refresh semantics. A four-parameter tool with no schema descriptions leaves too much for the agent to infer.

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 specifies the verb and resource: it hydrates the matching Strava activity and returns persisted segment efforts. It also defines the intended scope—segments, climbs, KOM/PRs, or per-segment analysis—which distinguishes it from sibling hydration tools that focus on broader activities or history.

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 explicit guidance on when to use the tool: 'Use this before saying segment data is unavailable.' It also provides a prerequisite by noting that athleteId comes from list_athletes. It does not mention when not to use it or name alternative sibling tools, but the context is clear.

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 behavioral burden. It discloses 'Read-only', 'normalized', and 'source-aware preferred daily values', which adds useful context beyond the schema. However, it does not explain how source preference affects results, date-range behavior, or output shape.

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 tight sentences with no filler. The main behavior is front-loaded, followed by safety and prerequisite guidance. Every phrase 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?

Despite a small description, the context is incomplete for an agent making a correct call: no output schema, no annotations, zero schema descriptions, and no explanation of sourcePreference values, date range handling, or default behavior. An agent would need to guess several important 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 0%, so the description must compensate, but it only hints at athleteId provenance and source-aware preference. It does not explain startDate, endDate, sport, or sourcePreference semantics beyond what the bare schema fields imply.

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 resource ('cycling FTP settings and activity-summary observations') and the action ('Return normalized ... with source-aware preferred daily values'). It is more specific than the title, though it does not explicitly differentiate from siblings like get_vo2max_history or power_curve_trend.

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 an explicit prerequisite ('Requires athleteId from list_athletes') and notes the tool is read-only. It does not state when to choose this tool over sibling alternatives, but the prerequisite is useful routing context.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses source-awareness, reports missing length lists as unavailable, and explicitly guarantees no reconstruction from samples. It omits output structure and error behavior, but the core behavioral contract is unusually clear for a read 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?

Three dense sentences with no filler. Primary behavior is front-loaded, followed by an edge-case guarantee and a prerequisite. Every sentence adds distinct value.

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

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

For a tool with no output schema and no annotations, the description covers the main return concept, the unavailable case, and a key prerequisite. It omits provider-default behavior and activityId provenance, but those are moderate gaps rather than fatal ones.

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, but it only meaningfully documents athleteId via 'Requires athleteId from list_athletes' and indirectly hints at provider through the Garmin/Intervals.icu naming. The optional provider semantics, its default when omitted, and activityId are left undocumented.

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 names the exact resource ('source-aware swim lengths', 'Garmin detected and Intervals.icu auto-detected sets'), plus clarifies a key non-behavior ('laps are never reconstructed from samples'). This clearly distinguishes it from sibling read/analytics 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?

It states the triggering condition ('when a provider actually supplied them'), an exclusion ('never reconstructed from samples'), and a prerequisite ('Requires athleteId from list_athletes'). However, it does not name alternative tools such as get_activity_segments or swim_progress_report, so cross-tool routing is 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?

With no annotations provided, the description carries the behavioral burden. It clearly states the operation is read-only, that observations are normalized, and that running data preserves Garmin's raw 'sport generic' label while cycling remains separate. It does not disclose date-range semantics or output shape, but the safety profile and core data transformation are communicated well.

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: the main behavior appears first, followed by targeted caveats. Every sentence contributes unique information, and the read-only and prerequisite details are included without 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?

Given no annotations and no output schema, the description gives enough to call the tool correctly for the main cases: it identifies the required athleteId, explains sport usage, and notes the omit-sport introspection mode. The main gap is that neither the description nor the schema explains startDate/endDate semantics, and the return shape is only implied by 'observations'.

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 provides excellent guidance for the 'sport' parameter and says athleteId comes from list_athletes, but it completely omits 'startDate' and 'endDate' — their filtering behavior, inclusivity, or optionality beyond what the schema's date format implies.

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-resource pair: 'Return normalized Garmin VO₂max observations for exactly one sport.' It also clarifies sport semantics (running vs. cycling) and the 'omit sport only to inspect available source labels' behavior, which distinguishes it from generic series-reading or analysis siblings.

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 concrete when-to-do guidance: pass 'running' or 'run' for running, notes cycling is separate, and says to omit sport only for inspecting source labels. It also names the prerequisite athleteId source, list_athletes. It does not explicitly contrast against sibling tools like get_ftp_history, so it falls just short of full routing 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?

With no annotations, the description carries the transparency burden. It discloses that the operation is 'Write-only' and explains the execution model: 'hydrates one activity at a time and reports every outcome.' It also notes a dependency on athleteId. It does not mention idempotency, rate limits, or failure semantics, but still provides meaningful operational context beyond a bare verb.

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 critical qualifier ('Write-only targeted batch enrichment') is front-loaded, and each clause contributes distinct information: selection modes, execution model, outcome reporting, and prerequisite. The unexplained 'Catence' term is the only minor blemish.

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 7-parameter tool with no output schema and no annotations, the description covers selection modes and prerequisite but leaves semantics of limit and refresh unaddressed. It also does not warn against using this tool for single-activity hydration or indicate whether it is long-running and how that relates to sibling status tools. An agent would still have open invocation questions.

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 had to compensate. It successfully links the 'explicit list' mode to activityIds and the 'bounded date/sport window' mode to startDate/endDate/sports, and highlights athleteId as required. However, it leaves limit and refresh undefined, providing only partial compensation 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 names a specific verb ('hydrate') and resource ('recent Strava activities'), and explicitly characterizes the operation as 'targeted batch enrichment', distinguishing it from its singular sibling hydrate_strava_activity. It also identifies the two selection modes (explicit list vs bounded date/sport window), making the tool's purpose unmistakable.

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

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

It provides a concrete prerequisite ('Requires athleteId from list_athletes') and tells the agent how to choose between an explicit list and a date/sport window. It does not explicitly name the singular alternative or list exclusions for when not to use this tool, so it loses a point.

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 behavioral disclosure burden. It does reveal that the operation is write-only and that it archives and persists data, which is useful. However, it does not explain idempotency, reversibility, failure behavior, or what the refresh parameter changes, leaving important side-effect details opaque.

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 tightly written sentences, each earning its place. The main purpose and side-effect profile are front-loaded, followed by a routing note and a required prerequisite. 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?

The description covers purpose, main usage, and a prerequisite, which is enough for basic selection and invocation. However, with no output schema and no annotations, an agent cannot determine what the tool returns, how refresh behaves, or what failure modes exist. This is a notable completeness gap for a mutating 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 description coverage is 0%, so the description must explain parameters. It tells the agent that athleteId comes from list_athletes, but it does not explicitly define activityId's meaning and leaves the refresh boolean completely unexplained. This is only partial compensation for the empty schema 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 a specific action ('matches exactly one Catence activity/source to Strava, then archives and persists') and clearly names the affected resources: activity detail, gear assignment, and segment efforts. It also distinguishes itself from get_activity_segments by noting that the sibling invokes this tool automatically.

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 routes segment/climb requests to get_activity_segments, names the prerequisite for athleteId via list_athletes, and clarifies this is a targeted single-activity operation. This gives an agent clear when-to-use and when-to-avoid 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?

With no annotations, the description carries the behavioral burden. It discloses that the operation is 'write-only,' that work is resumable after interruption or throttling, and that it fetches paged historic efforts. This adds meaningful traits beyond the name and schema, even though it does not describe the exact output or side effects in 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 two sentences with no filler, and the key behavioral qualifier 'Write-only targeted enrichment' is front-loaded. Every sentence contributes either purpose, behavioral context, or a prerequisite.

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 core intent, resumability, and a prerequisite, but it lacks an output schema and leaves refresh and segmentId semantics unexplained. It is adequate for selecting the tool, but not fully complete for calling it correctly in all 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%, so the description must compensate for parameter meaning. It identifies athleteId and its source (list_athletes), but it does not describe segmentId beyond what the tool name implies, and it says nothing about the optional refresh boolean. This leaves two of three parameters underspecified.

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 names a specific verb and resource: it 'Fetches a persisted Strava segment and the authenticated athlete’s paged historic efforts.' The phrase 'targeted enrichment' and the title scope it to a single segment history, distinguishing it from sibling tools like hydrate_strava_activity and hydrate_recent_strava_activities.

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 a useful prerequisite by saying 'Requires athleteId from list_athletes,' but it does not explicitly state when to choose this tool over the nearby hydrate_strava_activity or hydrate_recent_strava_activities siblings. There is clear context, but no explicit alternative routing or exclusion.

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 uses it well: it explicitly declares the operation read-only and discloses two behaviors—deduplicating Intervals summaries and optionally flagging multisport parents. It does not describe output shape or pagination, but the safety/side-effect profile is clear.

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 compact sentences with the main verb first, no filler. Each clause adds useful information: source, dedupe behavior, multisport option, safety, and prerequisite.

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?

Complete enough for a read-only listing tool, but gaps remain: no output schema, no explanation of what 'latest' means or how startDate/endDate interact with it, and no stated default limit behavior. The explicit read-only and prerequisite help, but an agent still has to guess some invocation semantics.

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 adds meaning for athleteId (must come from list_athletes) and includeMultisport (flag multisport parent records), but gives no explicit semantics for limit, startDate, or endDate. With 0% schema description coverage this is a clear gap, though the remaining parameter names are reasonably 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 names a concrete verb and resource ('List Garmin cycling source records') and adds distinguishing details: it excludes duplicate Intervals summaries and can flag multisport parent records. This separates it from generic activity-search siblings like find_activities and cycling_progress_report.

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 states clear usage context and a prerequisite ('Read-only. Requires athleteId from list_athletes'), telling the agent to obtain an athlete ID first. It does not explicitly name when-not-to-use or alternative tools, so it stops short of full routing 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?

With no annotations, the description carries the behavioral disclosure burden. It communicates that the operation is a read-only enumeration, that results are scoped to this shared agent, and that personal metrics are excluded. This goes beyond the schema and directly manages expectations about what will and will not be returned.

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 immediately states the action and result, followed by a short clarifying exclusion. No filler or redundant phrasing, and the most important information is front-loaded.

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

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

For a parameterless tool with no output schema, the description fully covers what the agent needs: what is returned (IDs and labels), the scope (this shared agent), and a key boundary (no personal metrics). The low complexity and simple contract make additional detail unnecessary.

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

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

The tool has zero parameters, so the baseline is 4. There is nothing to document beyond noting that no input is required, which the empty schema already conveys. The description adds no unrelated parameter detail.

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 ('athlete IDs and labels'), and scope ('available to this shared Catence agent'). The explicit exclusion of personal metrics distinguishes this enumeration tool from the many sibling tools that return metric data.

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

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

The description implies the tool is for discovering available athlete identifiers before working with metrics, and explicitly says no personal metrics are returned. However, it does not name any sibling alternative or provide explicit when-to-use versus when-not-to-use 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?

With no annotations, the description carries the full burden. It explicitly states 'Read-only', which is critical, and mentions the data source and the requirement of athleteId. It does not describe output format or pagination, but it covers the key behavioral points. This is solid coverage given no annotations are provided.

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 concise sentences, front-loaded with the primary purpose. Each sentence adds distinct value: purpose, data source caveat, and operational constraints. No unnecessary words; it is efficiently structured for quick agent parsing.

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 has 6 parameters, no output schema, and no annotations, the description is incomplete. It does not clarify the range semantics of startDate/endDate, the meaning of sourceQuality options, or how sport and sportFamily interact. The phrase 'complete duration-best inventory' remains undefined, leaving an agent without enough context to confidently construct a correct call.

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 explain parameter meanings. It only mentions athleteId as required and alludes to 'sport or sport family', but does not explain startDate, endDate, sourceQuality, or the distinction between sport and sportFamily. This leaves a large semantic gap for a 6-parameter tool with no schema 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 reports powered activities and the complete duration-best inventory for an explicit sport or sport family. It uses specific terms like 'powered activities' and 'duration-best inventory', and explicitly notes the use of Garmin FIT-derived power, which distinguishes it from sparse activity summary tools. This provides a clear verb-resource-scope framing.

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 clear prerequisite ('Requires athleteId from list_athletes') and notes the data source ('Garmin FIT-derived power, not sparse activity summaries'), which helps an agent decide when to use this tool. However, it does not name explicit alternatives or state specific exclusions (e.g., 'use power_curve_trend for trends'), so the guidance is mostly implicit rather than prescriptive.

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's explicit 'Read-only' statement is valuable, and 'Requires athleteId from list_athletes' reveals a dependency. However, it does not disclose behavior for missing or conflicting optional parameters, date-range handling, or the exact return shape, leaving important operational behavior unstated.

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-load the main function and add only useful constraints: read-only behavior and the athleteId prerequisite. There is no redundant, vague, 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?

Given 7 parameters, no annotations, no output schema, and many neighboring report tools, the description is too thin for complete invocation. It omits date-range semantics, sport/sportFamily precedence, sourceQuality meaning, and output structure, so an agent would likely need to guess on several optional parameters.

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

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

Schema description coverage is 0%, so the description must add meaning. It provides semantic context for athleteId, durations ('selected power durations'), sport/sportFamily ('explicit sport or sport family'), and sourceQuality ('source type'). It does not explain startDate/endDate, durations units, or enum value meanings, so compensation is only partial.

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 operation ('Return monthly bests'), the resource ('power durations'), the required scope ('explicit sport or sport family'), and the enrichment ('supporting activity and source type'). This clearly distinguishes it from sibling report tools like power_coverage_report and get_ftp_history.

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 practical invocation context: it is read-only and requires an athleteId obtained from list_athletes. It does not explicitly name alternatives or state when not to use this tool, so it stops short of full route-selection 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?

With no annotations, the description carries the full burden, and it delivers: read-only scope, prohibited targets (information_schema, DuckDB system tables, uncataloged relations), rejected operations (filesystem access, extensions, DDL, mutation), and cursor pagination semantics. This is unusually thorough for an unannotated 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?

Dense and front-loaded: the core purpose appears in the first clause, followed by compact constraints and behavior. No filler or redundant restatement 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?

For a high-complexity SQL tool with no output schema, the description covers scope, safety boundaries, pagination, incompleteness reporting, and required input provenance. An agent has enough context to decide whether this is the right tool and to call it safely.

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 adds meaning for key parameters: 'sql' must be a SELECT/WITH over cataloged views, 'values' is implied by 'parameterized', 'cursor' is tied to deterministic pagination, and 'athleteId' is sourced from list_athletes. However, 'pageSize' is not explicitly addressed in the description.

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 resource ('cataloged views only') and the exact form of action ('one parameterized SELECT or WITH … SELECT'). It also positions itself as an 'Advanced fallback after describe_data/describe_dataset', distinguishing it from those siblings and making its role 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?

Gives explicit sequencing ('fallback after describe_data/describe_dataset') and a prerequisite ('Requires athleteId from list_athletes'). It does not name other sibling alternatives or explicitly state when not to use this tool, but the fallback context provides reasonable 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?

With no annotations, the description carries the burden of explaining behavior. It does clarify that this is a read/combine call requiring athleteId and that it returns trends. But it does not state whether there are side effects, how much historical data is needed, or how the response is structured.

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 with no filler. The first sentence front-loads the core behavior and enumerates the included indicators, the second gives usage guidance, and the third states the prerequisite. 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?

For a tool with no annotations, no output schema, and 0% parameter documentation, this description leaves three optional parameters unexplained and never describes the response. The usage cue is helpful, but an agent still lacks enough information to call the tool correctly for non-default sport or date inputs.

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 the lack of parameter documentation. It only mentions athleteId and where it comes from; sport, startDate, and endDate are never explained, and their role in producing trends is left entirely implicit.

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, 'Combine', with a clearly identified resource: the full performance-indicator set presented as trends in one call. It also distinguishes itself from single-activity comparison tools by positioning this as the aggregate, readiness-level call.

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: 'before any single-activity comparison for race-readiness or fitness-target questions.' It also names the prerequisite required for invocation: athleteId from list_athletes. However, it does not name specific alternative siblings 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?

With no annotations provided, the description carries the behavioral disclosure burden. It reveals non-obvious behaviors: deterministic cursor pagination and automatic stream downsampling, which go beyond the schema. It does not mention auth, rate limits, or return envelope, but the disclosed traits are material and genuinely helpful.

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 dense sentences with every clause earning its place. The main operation is front-loaded, followed by constraints and prerequisites, with no filler or repetition of schema details.

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 10 parameters, no output schema, and no annotations, the description covers critical prerequisites and key constraints, making it minimally viable for straightforward reads. However, return shape, pagination limits, default downsampling behavior, and dataset naming conventions remain undocumented, which are notable gaps at this complexity level.

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 10 parameters. It usefully explains metrics, filters, and athleteId sourcing, but leaves cursor, pageSize, resolution, dataset, activityId, startDate, and endDate to be inferred from names and enums. This is only partial 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?

States a specific verb ('Read') and resource ('cataloged numeric series'), immediately distinguishing it from analysis, aggregation, and description siblings. 'Bounded time series' plus pagination and downsampling adds concrete operational specificity.

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 usage conditions: metrics must be numeric catalog columns, identifiers and strings belong in filters, call describe_dataset for uncertainty, and athleteId comes from list_athletes. It lacks explicit 'when not to use' guidance or direct comparison with analyze_series/aggregate_data, 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 behavioral burden and does well: it discloses that absent geometry produces an explicit caveat to prevent stale reuse, and that the result reports whether geometry was synced. It does not explicitly state read-only behavior or error handling, but the 'resolve and return' framing plus the safety caveat is meaningfully transparent.

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

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

Three dense sentences deliver the result, the safety caveat, the optional diff behavior, and the prerequisite. There is no filler or repetition of the title; 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?

The description covers inputs, high-level outputs, the stale-geometry caveat, and the prerequisite data source. The lack of an output schema means the description is responsible for return semantics, and it provides the key return elements (courseId, sync status, caveat) even if it does not detail the exact shape or the diff output structure.

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 fully compensates: eventId is identified as a Garmin/Intervals eventId, pastActivityId is explained as the activity to diff against, and athleteId is explained as a required value from list_athletes. Every parameter gains meaning beyond the raw schema types.

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 ('resolve'), a specific resource (race event course), and the exact result (courseId plus sync status). It is clearly distinct from all sibling tools, which focus on recovery, hydration, or data analysis rather than event course resolution.

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 invocation context: pass a Garmin/Intervals eventId, optionally pass pastActivityId for a diff, and obtain athleteId from list_athletes. It does not name explicit alternatives or when-not-to-use cases, but the prerequisite and scenario are concrete enough for an agent to select this tool appropriately.

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; it conveys a read-style return of identity, summaries, and intervals, and a dependency on athleteId. However, it does not disclose potential costs, failure modes, or whether data is freshly sourced versus cached, leaving some behavioral ambiguity.

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 front-loaded sentences accomplish the job: first states the output contract, second gives the alternative and the prerequisite. There is no filler or repetition.

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

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

Given no output schema and no annotations, it names the main return categories and routing guidance, but leaves 'canonical activity identity' and 'structured intervals' underspecified. Enough to select the tool, but not fully enough to anticipate the exact response shape.

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 only adds meaning for athleteId (source from list_athletes). activityId is left entirely to its property name and minLength, so the description does not compensate for the missing schema documentation.

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-resource pair ('Return canonical activity identity, source summaries, and structured intervals') and the title scopes it to 'one activity in depth'. It is distinguishable from broad listing tools but does not fully disambiguate from segment-focused siblings.

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 names read_series as the alternative and gives the exact condition for choosing it ('only when a specific sampled metric is required'). It also states a prerequisite: athleteId must come from list_athletes.

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 transparency burden. It discloses that the tool returns 'source-cited' facts and explicitly avoids prescribing a training plan, indicating a read-only, informational behavior. However, it does not mention what happens when no data exists, whether there are any side effects or costs, or the shape/format of the returned facts.

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 with no filler. The core return behavior is front-loaded, followed by a key exclusion and a required-input hint. 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?

For a tool with no output schema and no annotations, the description is adequate but leaves gaps. It tells the agent what data domain is covered and the required input, but not the exact return structure, the date default/optionality behavior, or caveats about data availability. These gaps matter given the absence of structured metadata elsewhere.

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 clarifies athleteId's origin with 'Requires athleteId from list_athletes,' which is valuable. The 'date' parameter is not explicitly described, though the tool's 'daily' framing and schema's date format imply its meaning. This is partial compensation, not full.

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 names a specific verb and resource: 'Return source-cited daily health, training, and nutrition facts for a recovery/load review.' It also adds a useful boundary with 'It does not prescribe a training plan.' However, it does not explicitly differentiate itself from close siblings like review_weekly_training or review_activity_deep_dive beyond the word '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 gives a clear prerequisite: 'Requires athleteId from list_athletes,' which tells the agent how to obtain required input. It also states a negative use case with 'does not prescribe a training plan,' helping the agent avoid misuse. It stops short of naming alternative tools for cases where a training plan or weekly view is desired.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool returns facts, covers a seven-day window, is source-cited, and does not prescribe a training plan. However, it does not describe output structure, default behavior when endDate is omitted, error conditions, or whether any side effects exist, leaving meaningful behavioral gaps.

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

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

The description is two concise sentences with no filler. It front-loads the core function ('Return source-cited... facts'), then adds a clarifying exclusion and the required prerequisite. Every sentence contributes useful information.

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-style report tool with two parameters and no output schema, the description covers the purpose, time window, prerequisite, and the key limitation that it does not prescribe a training plan. It leaves minor gaps such as the default end date and the shape of the returned facts, but these are not critical for an agent deciding whether to call the 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%, so the description must add parameter meaning. It does add context for both parameters: athleteId is identified as coming from list_athletes, and endDate is described as an optional date marking the end of the seven-day reporting period. This goes beyond the raw schema, although it could be even more explicit about the endDate parameter name and default behavior.

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 a specific action and resource: returning 'source-cited health, training, and nutrition facts' for a seven-day period. It adds scope ('seven-day period ending on an optional date') and explicitly clarifies that it 'does not prescribe a training plan.' However, it does not explicitly differentiate itself from sibling tools like review_daily_recovery_load or review_activity_deep_dive, so it falls just short of a 5.

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

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

The description gives useful usage context by naming the prerequisite 'Requires athleteId from list_athletes' and by indicating that the tool is for obtaining facts rather than a plan. It does not explicitly state when to prefer this tool over alternatives or mention any exclusions among the sibling tools, so the guidance is implied rather than 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?

With no annotations, the description carries the behavioral burden. It does disclose a meaningful behavioral trait: results are tool recommendations, not numeric claims. It also notes a required dependency on list_athletes. However, it does not reveal result shape, pagination, rate limits, or explicitly state read-only 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?

Two sentences, front-loaded with the core action and immediately followed by the key behavioral result. No filler or redundant restating 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?

The tool has no annotations, no output schema, and a nested filter parameter with enum choices. The description explains the high-level purpose and a prerequisite, but omits practical details like how to build the query, valid filter columns/operators, and what the response resembles, making it insufficient 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 the four parameters. It explains that athleteId comes from list_athletes, which is valuable, but it gives no meaning for query, limit, or filters, and no guidance on valid filter columns or operators.

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 specific resource: compact generated activity, plan, nutrition, and message context. It also distinguishes the tool's role by stating that results identify authoritative follow-up tools rather than making numerical claims, which separates it from the numeric analysis siblings.

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 for when to use the tool: when a routing decision to follow-up tools is needed, and it calls out the prerequisite of athleteId from list_athletes. It does not explicitly name alternative tools or list exclusion conditions, so it stops short of full separation 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?

With no annotations provided, the description carries the full burden of disclosing behavior, and it does so thoroughly: it is write-only, detached, non-blocking, lock-guarded against concurrent runs, returns a handle and log file, and implies side effects. This is unusually transparent for a mutation tool.

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

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

Four dense sentences, no filler, with the most important behavior ('write-only', 'detached', 'returns immediately') front-loaded. Every sentence adds a distinct piece of information, and the structure is easy to scan.

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

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

The description covers workflow, concurrency, return artifacts, and the prerequisite data source, but the absence of parameter guidance for three of the four parameters leaves the tool incomplete for correct invocation. Given no output schema, the return-value mention helps, but the parameter gap prevents a higher score.

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 only clarifies athleteId's provenance ('from list_athletes') and says nothing about from, refresh, or provider, leaving their meaning and interactions unexplained. For a 4-parameter tool, this is a material 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 states a specific verb ('spawns'), the resource ('detached catence-data sync process'), and the immediate return behavior ('run handle and log file'), which clearly differentiates this from the sibling progress-tracking tool. The 'write-only sync trigger' framing also signals its role among the write 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 gives concrete usage context: it refuses when another sync is active, never waits for completion, should be tracked via catence_sync_progress, and requires athleteId from list_athletes. It does not explicitly enumerate when not to use this tool versus every alternative, but the key routing decisions are covered.

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 present, the description carries the behavioral disclosure burden. It adds a useful boundary by stating it does not derive pace trends from moving time divided by distance. However, it does not clarify whether the operation is read-only, what output format to expect, how data completeness is determined, or what happens when no matching swim data exists.

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, no filler, and each sentence adds value: the first states the operation and scope, the second clarifies a non-behavior and the prerequisite. The most important information is front-loaded.

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?

There is no output schema and no annotations, so the description should explain what the report contains. It does not describe return values, date range handling, source-awareness details, or edge cases like missing Garmin data, making it incomplete for a 4-parameter reporting 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%, so the description must compensate for missing parameter meaning. It maps athleteId, startDate, endDate, and poolLengthM to broad concepts ('requires athleteId', 'date range', 'optionally within one pool length'), but it does not explain ordering, defaults, optionality semantics, or the meaning/units of poolLengthM beyond the schema constraint.

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: 'Compare Garmin swimming summaries and data completeness over a date range, optionally within one pool length.' It distinguishes itself from siblings by naming what it does and explicitly stating what it does not do ('does not derive pace trends from moving time divided by distance').

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 a clear usage context (comparing swimming summaries and data completeness over a date range) and a prerequisite ('Requires athleteId from list_athletes'). However, it does not say when to prefer this tool over alternatives such as get_swim_laps or cycling_progress_report, nor does it give exclusion conditions.

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 most of the behavioral disclosure burden. It usefully states that the tool 'does not diagnose or prescribe' and that it groups anomalous dates across signals. It does not explain return format, default date ranges, or what happens when no anomalies are found, so transparency is partial.

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 with no filler. The primary purpose and behavior are front-loaded, followed by an essential caveat and prerequisite. Every sentence contributes meaningful guidance.

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

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

The description is incomplete relative to the tool's complexity: five undocumented parameters, no output schema, and no annotations. It omits date range semantics, default metric or threshold behavior, and return value shape. The non-diagnostic caveat and grouping detail are helpful but not enough for reliable invocation in ambiguous 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?

The schema provides no parameter descriptions, so the description must compensate for five parameters. It adds meaning by explaining the z-score approach, implying metric selection through 'multiple signals,' and sourcing athleteId 'from list_athletes.' It does not explain startDate, endDate, zThreshold defaults, or the specific metrics enum, leaving gaps.

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 action, 'Find daily recovery and wellness outliers by z-score,' and a clear output behavior, 'group dates with anomalies across multiple signals.' It distinguishes the tool from generic data or activity tools, though it does not explicitly contrast it with sibling wellness tools like wellness_baselines or wellness_correlate.

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 useful prerequisite, 'Requires athleteId from list_athletes,' which tells the agent where to source a required value. However, it does not state when to prefer this tool over alternative wellness or anomaly-related siblings, nor does it give exclusions or explicit when-not-to-use 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?

With no annotations, the description carries the burden and does add useful behavior: it says missing values remain missing and that athleteId is required. It does not state read-only/side-effect status, default calculation windows, or behavior when no data exists, so transparency is adequate but incomplete.

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

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

Two concise sentences front-load the output contents and then add missingness and prerequisite notes. Every clause contributes information, with no redundant restatement of the title or schema.

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 adequately covers what the tool returns and its one hard prerequisite, and the schema supplies value constraints, so a minimal call is invocable. However, with no output schema and no parameter descriptions, an agent is left guessing about output shape, default windows, and whether metrics/endDate affect the returned statistics.

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 only explains the athleteId prerequisite; it does not explain the meaning or effects of endDate, windowDays, or the metrics array. The schema's enum and numeric bounds help constrain values, but the description does not compensate for the lack of parameter documentation.

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 names a specific action ('Return') and precise resource/output: trailing means, standard-deviation bands, latest values, and latest z-scores for recovery/training metrics. This concrete output set distinguishes it from sibling wellness tools like wellness_anomalies or wellness_correlate without needing to open the schema.

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: call this when you need baseline statistics for wellness metrics, and the description gives the prerequisite that athleteId must come from list_athletes. It does not explicitly state when not to use it or name an alternative tool for related needs.

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 behavioral burden. It adds useful transparency with 'Descriptive only' and the optional lag-scan behavior, which signals a read-only analytical purpose. However, it does not explicitly state read-only status, how missing data is handled, what 'compact daily' means in terms of output, or whether date defaults apply.

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 only two sentences, starts with the core action, and every clause adds information: method, metric relationship, lag behavior, descriptive intent, and a prerequisite. There is no filler or repetition 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 8 parameters, no annotations, and no output schema, the description is incomplete for safe invocation. It does not describe the expected output shape, the meaning of 'compact daily correlation,' the behavior of optional date ranges, or the interaction between scanLags and lagDays. An agent would still need to make assumptions about several important execution 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 0%, so the description must compensate. It explains the method choices (Pearson/Spearman), the lag idea, and the athleteId source. But it does not clarify the distinction between lagDays and scanLags, does not mention startDate/endDate at all, and the stated '-7 through +7 day lag scan' does not match the schema's broader -30..30 lagDays range.

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 and resource: 'Calculate a compact daily Pearson or Spearman correlation between curated wellness and training metrics.' It also names the optional lag-scan behavior and explicitly labels the operation 'Descriptive only,' which helps distinguish it from predictive or modeling siblings like fit_series_model and analyze_series.

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 a descriptive correlation between wellness and training metrics is needed. It also gives a prerequisite, 'Requires athleteId from list_athletes.' However, it does not explicitly name alternative tools or state when a different tool should be preferred.

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 full behavioral burden and does well: it states the tool reports existence/absence of data, discloses unresolved errors, and explicitly warns that missing data is never interpreted as rest or a health outcome. It does not state side effects, but 'Report' strongly implies a read-only operation.

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

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

Two sentences with no filler. The primary output is front-loaded, the critical interpretive caveat about missing data is included, and the cross-tool dependency is stated compactly. 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?

The description covers purpose and the most important semantic caveat, but with no output schema and no annotations, it leaves gaps: optional parameter behavior (default date ranges, default metrics), output shape, and how unresolved extraction errors are reported. An agent could call it correctly with the required athleteId, but may not know how to narrow or interpret results.

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, but it only explains athleteId provenance ('from list_athletes'). It does not clarify startDate/endDate semantics, default date ranges, or what metrics are covered, leaving the agent to infer from the schema's enums and formats.

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 ('Report') with a clear resource scope ('present and missing dates for curated wellness/training metrics') and adds the unique output of 'unresolved extraction errors'. This distinguishes it from siblings like read_series or describe_data, which focus on values rather than coverage gaps.

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 clearly conveys this tool is for coverage inspection, not for analyzing trends or values, and it explicitly routes the agent to list_athletes for the required athleteId. It lacks explicit 'do not use when...' exclusions, but the purpose statement is strong enough to suggest appropriate use.

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