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 discloses that the tool tests the API key and returns rate limit headroom, implying a read-only, non-destructive operation. It does not detail error responses or output structure, but for a zero-parameter health check, the essential behavior is 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?

The description is a single focused sentence with no filler. It front-loads the core action ('verify the API key works') and the secondary result ('report rate limit headroom'), earning its place entirely.

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

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

For a zero-parameter tool with no output schema, the description provides the core purpose and the key output concept. It lacks explicit return field names or failure behavior, but for a simple connection check the description is sufficiently complete.

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

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

The input schema has zero properties, so there are no parameters to document. Achieves the baseline 4 for a zero-parameter tool since no parameter description is needed.

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

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

The description states a specific verb ('verify'), a resource ('API key'), and the outcome ('report rate limit headroom'). This clearly distinguishes it from sibling tools like list_activities or get_athlete_profile, which concern data retrieval rather than connection status.

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

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

The description implies the tool is for checking API connectivity and rate limits, which is distinct from all siblings. There is no explicit 'use when' or alternative routing, but the unique purpose provides clear context without needing exclusions.

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

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

With no annotations present, the description carries the full behavioral burden and does so thoroughly: it discloses the Garmin side-effect, idempotent behavior when external_id is reused, forced 00:00:00 start time, and optional moving_time derivation. This goes well beyond the bare schema and helps the agent anticipate real-world consequences.

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 long but tightly organized into a purpose paragraph, a compact Args list, and a syntax example with rules. Every section adds operational knowledge an agent needs, so the length is justified rather than bloated.

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 parameter-heavy creation tool with no output schema and no annotations, this is essentially complete: it covers all inputs, the domain-specific syntax, idempotency, and a real-world caveat. The only omission is a description of the return payload, but that is not required for correct invocation.

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

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

Schema description coverage is 0%, yet the Args section explains all eight parameters with formats, defaults, and reasoning, and the workout-syntax block gives essential semantics for the free-form description parameter. The description fully compensates for the schema's 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 opening line names the exact action ('create'), the resource ('structured planned workout'), and the target system ('Intervals.icu calendar'), and the Garmin sync clause separates it from the read/list/delete siblings. This is a specific verb+resource statement, not a tautology or vague paraphrase.

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 first paragraph explicitly frames the tool as the path for getting a session onto a Garmin watch and warns to verify the first sync before relying on it in a training block. It gives clear situational context and even a target-selection rule ('Use HR for trail and hiking work'), though it does not name alternative tools or state an explicit when-not-to-use condition.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action (delete) but does not disclose whether deletion is permanent, reversible, or requires confirmation, nor what happens to associated data. For a destructive operation with zero annotation coverage, this is a significant gap.

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

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

The description is a single sentence with no wasted words. It front-loads the action and resource, then provides the key parameter source. Every word earns its place.

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

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

For a simple one-parameter delete tool, the description is mostly complete: it names the action, the resource, and where to get the id. However, it lacks any mention of return behavior or error conditions, and with no annotations or output schema, an agent cannot know what to expect after a successful deletion.

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 by specifying that event_id is a 'numeric id' and that it comes from list_planned_workouts, which is helpful. However, it does not explain the format, range, or any constraints beyond the schema's integer type.

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 ('Delete') and resource ('a calendar event'), and identifies the id source ('from list_planned_workouts'), which distinguishes it from sibling tools like create_planned_workout and list_planned_workouts. It is clear but does not explicitly name sibling alternatives.

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

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

The description implies usage context by referencing list_planned_workouts as the source of the id, which tells the agent where to get the required parameter. However, it does not explicitly state when to use this tool versus alternatives or mention any prerequisites or consequences.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It reveals that the tool returns detailed activity data and optionally detected intervals/laps, and it gives an id format hint. However, it does not describe response structure, errors, or access requirements, which would matter without an output schema.

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

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

Three concise sentences with no filler: the first states the action, the second gives the usage context, and the third provides an id format example. 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 two-parameter read tool, the description covers core purpose and parameters well. But with no output schema and no annotations, it leaves the return shape unspecified and doesn't point to list_activities for finding activity ids, which is a meaningful gap.

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

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

Schema description coverage is 0%, but the description compensates by explaining activity_id format with the example 'i55751783' and clarifying include_intervals as toggling detected intervals/laps. Both parameters receive meaningful semantic context beyond their bare schema definitions.

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

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

Description names a specific verb and resource: 'Get one activity in detail' with optional 'detected intervals/laps.' This clearly distinguishes it from list_activities and get_activity_streams, and the mention of post-session analysis adds purpose beyond a generic fetch.

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

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

It explicitly says to use this for post-session analysis and gives concrete examples: how intervals went, HR drift, and elevation gained. It doesn't name alternatives or exclusion conditions, but the intended 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 full burden and does so unusually well. It discloses downsampling to ~200 points, the return of min/max/mean per stream, and the deliberate non-return of full per-second data with a concrete rationale. This gives an agent accurate expectations about output shape and data volume.

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 layout is clear: purpose sentence, Args section, then Returns section. The explanation about coaching shape is slightly editorial but earns its place by clarifying why the data is truncated.

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 only two parameters and no output schema, the description covers input format, defaults, valid options, output summary, and a key limitation. Nothing critical is missing for an agent to invoke it correctly.

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

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, and it does. It provides a concrete example for activity_id and enumerates valid stream names with defaults and alternatives, giving an agent everything needed to construct valid arguments.

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 ('Get time-series streams for an activity') plus the downsampling qualifier. It is distinct enough from siblings like get_activity, but it does not explicitly name or contrast any sibling, 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 helpful context about default stream types and explains why full per-second data is intentionally omitted, which implies when the tool is appropriate. However, it never explicitly says when to prefer this tool over get_activity or another sibling, nor does it provide any exclusion criteria.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It conveys that this is a retrieval-style call and adds useful context about zone boundaries being prerequisites, but it does not describe return shape, authentication needs, or edge-case behavior. This is adequate for a simple getter but not rich.

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

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

Two tight, front-loaded sentences: the first enumerates the payload, the second gives actionable sequencing rationale. 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?

For a zero-parameter retrieval tool, the description covers what is returned and when to call it. It lacks an explicit return-format statement, and there is no output schema or annotations to fill that gap, but the field list and sequencing guidance are sufficient for correct invocation.

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

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

The tool has zero parameters and schema coverage is 100%, so there is nothing the description needs to add about arguments. The zero-parameter baseline of 4 applies.

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

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

The description names a specific verb ('Get') and resource ('athlete profile') and lists distinctive contents: thresholds, HR/pace zones, FTP, weight, sport settings. This clearly distinguishes it from activity/workout-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 instructs to call this first in a coaching session and explains why zone boundaries are needed to interpret other numbers and write workouts. This gives strong contextual guidance, though it does not explicitly name alternative tools or 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, the description carries the burden of explaining behavior. It states the kind of data returned and frames it as baseline-relative, which is useful. However, it doesn't disclose return format, units, missing-data behavior, or date-range semantics, leaving some 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 compact and front-loaded: the first sentence states exactly what the tool returns, and the second provides actionable usage guidance. Every sentence earns its place 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?

The description is helpful for understanding the tool's role, but it is incomplete for correct invocation: it fails to explain how the date-range parameters work, what the default behavior is, or what the response structure looks like. Since there is no output schema and no annotations, these gaps matter.

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 makes no mention of the three parameters (newest, oldest, days_back). It doesn't explain how to specify date ranges or how days_back interacts with the other parameters, so the description provides no added meaning beyond the bare schema names and defaults.

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

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

The description opens with a specific verb and resource ('Get daily wellness') and enumerates the concrete metrics returned (HRV, resting HR, sleep, weight, CTL/ATL, soreness). This clearly differentiates it from sibling tools focused on activities, workouts, and athlete profile.

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 identifies this as the autoregulation input and directs the agent to check it before prescribing a hard session, and to compare HRV/resting HR against the athlete's own recent baseline. It gives clear context for when to use it, though it doesn't mention alternatives or explicit when-not-to-use 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does state that only completed activities are listed and what metrics are included, but it omits read-only safety, pagination, ordering, and behavior when no activities match. For a list operation with zero annotation coverage, this is a significant gap.

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

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

The first sentence front-loads the tool's purpose, and the Args block is compact with each line adding necessary semantics. There is no filler or repetition, and the structure makes parameters easy to scan.

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

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

For a tool with four optional parameters and no output schema, the description covers all inputs and states what data will be returned (training load, HR, elevation). It omits ordering and pagination details, but these are minor for an agent deciding whether and how to invoke this 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 coverage is 0%, but the description fully compensates: it defines the date format (YYYY-MM-DD), the inclusive semantics of newest, the default of oldest relative to days_back, the condition for days_back being used, and activity_type as a case-insensitive filter with examples. Every parameter is given meaningful 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 opens with 'List completed activities with training load, HR and elevation', which states a specific verb and resource. The word 'completed' distinguishes it from list_planned_workouts, and the enumerated metrics clarify what the tool returns. It does not explicitly name siblings, so it stops short of full differentiation.

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

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

The description implies usage for fetching historical activity data and documents defaults and filters, but it never explicitly states when to prefer this tool over get_activity or list_planned_workouts. No alternatives or exclusion conditions are named.

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 communicates a read-style operation ('List') and adds a useful integration detail: event IDs can be passed to delete_planned_workout. However, it does not disclose time-window behavior, defaults, or the 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?

Three tight sentences: what the tool does, when to use it, and how results connect to another tool. No filler, and the core behavior 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?

The description gives a clear use case and an integration hint, making a default zero-argument call viable. However, three parameters are undocumented and there is no output schema, so an agent wanting to customize the time window or understand the full return payload is left without guidance.

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 adds no meaning for newest, oldest, or days_ahead. An agent cannot tell from the description what date formats or semantics these parameters expect, so the description fails to compensate for the schema gap.

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

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

States a specific verb and resource: 'List calendar events' and enumerates the content (planned workouts, notes, races). This clearly distinguishes it from siblings like list_activities, which concern a different kind of data.

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

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

Provides explicit guidance: 'Use before writing a new week so existing plan entries are not duplicated.' This tells an agent when to call it. It does not explicitly contrast with list_activities or state when not to use it, so it stops short of a full 5.

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