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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the agent knows this is a non-destructive write. The description adds no further behavioral context such as duplicate handling, overwrite behavior, or what happens when a day is omitted; it merely restates the logging action.

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

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for the simple action being described.

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

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

The tool is simple with three parameters and an output schema, and annotations cover the safety profile. However, the description omits meaningful context about the required weight value, unit selection, and date behavior, leaving some gaps despite the low-complexity nature of 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 low at 33%, and the description only implies the weight parameter without explaining the day or unit parameters. The schema does describe day as 'YYYY-MM-DD; defaults to today' and unit has an enum, but the description does not compensate for the undocumented weight parameter or clarify unit semantics.

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

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

The description states a specific verb and resource: 'Log a weight measurement.' This is clear and immediately understandable. It does not differentiate itself from sibling tools such as get_body_composition, but the write action is distinct enough for an agent to identify.

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?

There is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. The intended usage is implied only by the word 'Log', leaving the agent to infer the appropriate context.

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

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

With annotations already indicating a non-read-only, non-destructive, open-world write, the description adds useful behavioral context: the workout syncs to the user's watch on the next sync and writes require GARMIN_ALLOW_WRITES=true. It does not cover failure modes or idempotency, but it meaningfully supplements the annotations.

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

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

The description is two concise sentences, front-loading the purpose and then adding required behavior and permission context. There is no wasted text.

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

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

For a write tool with a complex nested schema, output schema, and annotations, the description is nearly complete: it covers purpose, optional scheduling, sync behavior, and required write permission. Slightly more guidance on when to prefer this over schedule_workout would make it fully complete.

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

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

Schema description coverage is 100%, including a detailed nested spec object. The description only reiterates that scheduling is optional and does not add syntax or constraints beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Create a structured workout in Garmin Connect.' It also clarifies that scheduling is optional, which helps distinguish it from sibling tools like schedule_workout, though it does not name those siblings explicitly.

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 key prerequisite ('Requires GARMIN_ALLOW_WRITES=true') but does not explain when to use this tool versus schedule_workout, update_activity, or other workout-related siblings. Usage is implied rather than explicitly guided.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so safety profile is covered structurally. The description adds nothing beyond restating deletion: it doesn't say whether deletion is permanent or reversible, what happens to already-scheduled occurrences of the workout, or whether confirmation/ownership checks apply. With annotations carrying the safety signal the bar is lower, but this adds essentially zero extra context.

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

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

One sentence with no waste, appropriately front-loaded. But the brevity is under-specification rather than economy — the sentence is short because it omits necessary detail, not because it is dense.

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?

An output schema exists, so return values needn't be explained, and annotations cover destructiveness. Still missing for a destructive tool: irreversibility, effect on scheduled workouts, prerequisites, and any pointer to the correct ID source. The unresolved overlap with unschedule_workout is the largest 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%, so the description must compensate for the single parameter and does not. An agent has no textual indication that workout_id is the identifier returned by list_workouts/create_workout, nor what format or range is valid.

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 (delete) and resource (saved workout in the user's Garmin library), which distinguishes it from list_workouts, create_workout, and schedule_workout. It stops short of clarifying how it differs from unschedule_workout, the sibling an agent is most likely to confuse it with.

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

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

No when-to-use guidance and no explicit alternative named. The most consequential routing decision here — delete_workout vs unschedule_workout (removing from the library vs removing from the calendar) — is left entirely unaddressed.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered and the bar is lower. The description adds that extra sections (splits, HR zones, weather) are optional and layered on top of a base summary, which is genuine value, but it says nothing about payload size, the cost of raw=true, or default sections.

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

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

A single front-loaded clause that names the resource first and the optional extras second — nothing wasted. It leans toward terse rather than verbose, which is the right trade-off here.

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?

An output schema exists, so return values needn't be explained, and the tool is a simple read with one required param. Still, the description leaves the ID source and the raw-vs-summary trade-off undocumented, which are the two things an agent actually needs to choose 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?

At 67% schema coverage the baseline is 3, and the description largely restates the include options rather than adding syntax or behavior. It omits any mention of raw mode or where activity_id originates, so it does not compensate for the uncovered parameter.

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

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

States a specific resource and scope: one activity in detail, with the optional add-ons named (laps/splits, HR zone time, weather). This implicitly separates it from the list_activities/get_recent_activities siblings, though it never names them, so an agent has to infer the single-vs-many split.

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 (fetch detail for one activity) but there is no explicit when-to-use guidance, no mention that activity_id comes from list_activities, and no note on when raw mode is preferable. The agent must infer the workflow.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful scope context (default 7-day window, per-day granularity) but says nothing about missing-day handling, timezone/date interpretation, or how the summary relates to the raw JSON. Note a soft conflict: the description promises a 7-day default while the schema declares start and end each default to today.

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

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

A single front-loaded sentence where the resource leads and the default range is parenthetical. It earns its place, though it is telegraphic to the point of under-specification for a data-returning tool with an output 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?

With an output schema present, return-value detail is legitimately omitted, and annotations cover the read-only profile. What remains missing is disambiguation from the crowded sibling set and a coherent statement of the default date window, which the schema and description currently describe differently.

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

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

Schema description coverage is 100%, so start/end formats and the raw flag are already documented, anchoring this at a 3 baseline. The description's 'defaults to the last 7 days' arguably adds range semantics, but it sits in tension with the schema's per-parameter 'defaults to today', leaving the actual default window ambiguous rather than clarified.

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

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

Names a specific resource (Body Battery) and the exact metrics returned (charged/drained/high/low) at a per-day granularity, which is enough to tell it apart from generic siblings like get_daily_summary. The verb 'get' is implied rather than stated, and no sibling is named for contrast, keeping it 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 usage context is the implicit 'defaults to the last 7 days' range; there is no statement of when to prefer this over the many related siblings (get_daily_summary, get_stress, get_hrv, get_health_range), nor any exclusions. An agent must infer the choice from the tool name alone.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is clear without the description. The description's one behavioral claim—that it defaults to the last 30 days—conflicts with the schema, where start and end both default to today, which could mislead an agent about the default scope.

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

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

The description is a single front-loaded sentence with no filler. Every part of it contributes either the resource identity or the default range context.

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

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

With an output schema and annotations present, the description need not explain return values or safety. Still, it is thin for selecting among many health-data siblings: it does not say whether this returns raw measurements, summaries, or how it relates to add_weigh_in or get_daily_summary.

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 100%, so the schema already documents the start, end, and raw parameters thoroughly. The description adds only a default range statement, and that statement conflicts with the schema's documented defaults rather than clarifying parameter 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 the resource as weight and body composition entries, which lets an agent distinguish it from most sibling tools like get_sleep or get_hrv. It is slightly weaker than a 5 because it omits an explicit verb like 'retrieve' and does not explicitly contrast with add_weigh_in or get_daily_summary.

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

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

The parenthetical default range gives useful context for what happens when no dates are supplied, implying the tool is for recent body composition history. However, it does not state when to use this tool versus get_daily_summary, get_profile, or add_weigh_in, nor does it describe any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds essentially nothing beyond a metric list. It does not say what happens when no data exists for the day, whether a missing day defaults to today (that is only in the schema), or how the aggregate relates to the per-metric tools.

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 terse fragment with zero wasted words, but it is under-specified rather than concise: no verb, no usage framing, and no front-loaded statement of what the tool actually does.

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?

An output schema exists and parameters are fully described, so return values and inputs need not be repeated. However, against a crowded sibling set of overlapping single-metric tools, the description omits the disambiguation an agent needs to pick this one 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 coverage is 100% and both parameters ('day' with YYYY-MM-DD default today, and 'raw' for full Garmin JSON) are fully documented in the schema. The description adds no parameter meaning of its own, so the baseline 3 applies.

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

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

Names the resource (a one-day aggregate) and enumerates the metrics it covers (steps, calories, resting HR, stress, Body Battery, intensity minutes, SpO2). This implicitly distinguishes it from the single-metric siblings like get_stress and get_body_battery, though it never states the aggregation explicitly or uses a verb.

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

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

No statement of when to use this versus the many single-metric siblings (get_body_battery, get_stress, get_heart_rate, get_sleep) that overlap its content. The agent must infer from the metric list that this is the one-call aggregate.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context: the output is one row per day, the default window is the last 7 days, and it is explicitly cheaper than looping over day tools. It does not mention rate limits or auth, but those are not essential here.

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

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

Two short sentences, both front-loaded with the key use case and the efficiency rationale. There is no redundant phrasing or filler.

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

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

An output schema exists and the annotations cover the read-only/open-world safety profile, so the description need not explain return values. It adequately covers the core invocation context, though the default date-range ambiguity and the lack of explicit single-day exclusion leave a small 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 coverage is 100%, so the baseline is 3. The description adds a valuable default-range note ('defaults to the last 7 days'), but the schema says start and end each default to today, which creates ambiguity about whether omitting both yields a 7-day window or a single day. That tension keeps it from scoring higher.

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

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

The description states a specific resource (per-day table of health metrics) and a specific use case (trend questions), and it distinguishes itself from the day-based sibling tools by offering a cheaper batched alternative. An agent can immediately tell this is the range/trend variant rather than a single-day 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 gives clear when-to-use guidance ('for trend questions') and names the alternative approach it replaces ('calling the day tools in a loop'). It does not explicitly state when not to use it, such as for single-day queries, but the trend framing is strong enough to route most decisions.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the agent knows this is a safe, external-data read. The description adds that raw=true yields the intraday series rather than just a fuller JSON blob, which is genuine context, but it says nothing about empty/missing days, timezone handling, or data availability.

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

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

One sentence, front-loaded with the returned metrics and day scope, with the parameter nuance tucked into a parenthetical. Nothing is wasted and nothing needs to be re-read.

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?

An output schema exists, so the description needn't document return shape, and the tool's scope is narrow enough for a single sentence. The only real omissions are edge-case behavior (no data for the day, timezone of 'today'), which a careful agent would still want.

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 100%, so the baseline is 3. The parenthetical still earns above baseline by explaining what raw=true actually produces behaviorally — the intraday series — rather than merely repeating the schema's 'full JSON instead of a summary' wording.

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 resource (heart rate) and enumerates the metrics returned — resting, min, max — scoped to a single day, which cleanly separates it from siblings like get_hrv and get_stress. It doesn't explicitly contrast itself with those siblings, 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?

Usage is implied rather than stated: 'for one day' plus the schema default of today tells the agent the scope, and the parenthetical hints that raw=true is the intraday path. There is no explicit when-to-use/when-not guidance or named alternative for intraday vs summary queries.

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

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

Annotations already establish readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the meaningful constraint that this is overnight-only data, but says nothing about latency, data availability (e.g., what happens on a night with no reading), or how it differs from the sibling heart-rate tools.

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

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

A single front-loaded sentence with no filler. It is efficient, though the list of returned metrics is largely redundant with the existing output 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?

With an output schema present, the description need not enumerate return values, and annotations cover safety. What remains missing is the usage context and edge-case behavior (no data, timezone for 'day'), which leaves it merely adequate for a simple read 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 100%, with 'day' (YYYY-MM-DD, defaults to today) and 'raw' fully documented in the schema. The description adds nothing about either parameter, so the baseline of 3 is correct.

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 the resource (HRV) and narrows scope to overnight, which separates it from get_heart_rate and get_stress without needing the schema. It stays a fragment rather than a verb+resource statement, but the intent is unambiguous.

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

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

There is no guidance on when to call this versus get_sleep, get_heart_rate, or get_health_range, and no prerequisites or exclusions. The agent must infer selection from the resource name alone.

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

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

Annotations already state readOnlyHint=true and openWorldHint=true, so safety and external-data traits are covered. However, the description adds no behavioral context beyond the resource name: it does not clarify what 'records' means (personal bests vs. stored user records), how fresh the data is, or what sports/record types are included.

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

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

The description is a single short sentence with no wasted words and is front-loaded with the resource scope. It is slightly under-specified for a tool definition, but it is not verbose or badly structured.

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

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

For a zero-parameter read-only tool with an output schema and annotations, the definition is minimally adequate. The output schema can explain return values, but the description still leaves ambiguity around what 'personal records' refers to and gives no usage context.

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 there are no parameter semantics to explain and the baseline is 4. The description appropriately does not mention parameters because none exist.

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

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

The description clearly identifies the resource as the user's personal records and adds scope with 'across sports.' It lacks an explicit verb and does not distinguish itself from siblings, but no sibling tool covers personal records, so the intent is still clear from the name and description together.

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?

There is no guidance on when to use this tool versus related tools such as get_profile, get_race_predictions, or activity tools. It also does not note prerequisites, data availability, or whether it should be used only when personal-best data is needed.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety profile is covered. The description adds only a field inventory, which the existing output schema already supplies, and says nothing about auth requirements, caching, or whether values reflect live or cached settings.

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 short sentence with no filler, and the most identifying content (name, units, devices, HR zones) is front-loaded. It is under-specified rather than verbose.

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?

An output schema exists, so return values need not be explained, and a zero-param read is simple to invoke. The missing piece is the usage context — whether this is meant as a setup/context call — leaving the agent to guess why it would call get_profile instead of the metric tools.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema is empty and fully 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 enumerates the exact contents retrieved — name, unit system, devices, heart-rate zones — which clearly separates it from the daily-metric siblings (sleep, HRV, stress, etc.). However it is a bare noun phrase with no verb, so the retrieval action is only implied by the tool 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?

There is no statement of when to call this tool, no mention of it being a prerequisite/context call for other tools, and no exclusions. The agent must infer usage entirely from the tool name and the field list.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that: it does not say whether predictions are current/derived from recent activities, whether they can be empty for users without enough data, or what units/format to expect. For an open-world data tool this leaves real 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?

One short, waste-free sentence that is front-loaded with the key content. It is efficient but also under-specified — the same word count could have carried a verb and a scope qualifier instead of only an enumeration of distances.

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?

An output schema exists, so return values need not be explained, and with no parameters the call mechanics are trivial. Still, for an open-world read tool the description omits the one thing that would matter to an agent: whether predictions reflect current fitness and may be absent for some users.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. There is genuinely no parameter semantics burden here.

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

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

The description names the specific resource (predicted 5K/10K/half/marathon times) and thereby tells the agent what data comes back, which is more than a bare restatement of the name. However, it is a noun phrase with no verb and no scope qualifier (whose predictions, from which device), so the agent must infer that this is a read of the authenticated user's predictions.

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?

There is no guidance on when to use this instead of siblings such as get_training_status, get_personal_records, or get_profile, all of which an agent could plausibly pick for fitness-related questions. Nothing is misleading, but the agent is left to infer selection from the name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no ordering guarantee (newest-first?), no mention that limit caps results at 50 or defaults to 10, and no hint that the raw flag switches to unstructured Garmin JSON.

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

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

One short sentence means no verbosity, but it is under-specified rather than concise; there is no front-loaded purpose, scope, or call guidance an agent could act on.

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?

An output schema exists and annotations cover safety, so return format need not be explained. However, for a tool sitting alongside list_activities, get_activity, and a dozen other read tools, the description leaves the essential disambiguation and limit semantics unaddressed.

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

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

Schema description coverage is only 50% – the limit parameter has no schema description at all beyond min/max/default – and the description compensates for none of it. It does not explain what the count refers to or how ordering interacts with limit, adding zero value over the schema it accompanies.

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 is a near-restatement of the tool name ('The most recent activities'), adding only the vague qualifier 'most recent'. It does not specify a verb, data source, or how it differs from the sibling list_activities or get_activity, which an agent must distinguish to select correctly.

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?

There is no guidance on when to use this tool instead of list_activities or get_activity, despite those siblings being obvious alternatives. The word 'recent' weakly implies recency filtering but no threshold or selection condition is stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful scope by clarifying that it covers Garmin calendar entries for a month, including 'other items,' but it does not disclose pagination, calendar semantics, or whether completed/planned items are included.

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

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

The description is a single, front-loaded sentence with no wasted text. For a simple two-parameter read tool, this is appropriately sized and 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?

With a rich schema, an output schema, and annotations covering safety and openness, the description supplies enough context to call the tool correctly. Its main remaining gap is sibling differentiation, since it does not explicitly contrast itself with list_workouts or scheduling tools.

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

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

Schema description coverage is 100%, and the schema itself documents that year and month default to the current values. The description reinforces the monthly scope but adds no parameter syntax or meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description identifies a specific resource: workouts and other items on the Garmin calendar. It implies retrieval for a month, which distinguishes it from workout-template tools like list_workouts, but it lacks an explicit verb and the phrase 'other items' is vague.

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 what the tool returns but gives no when-to-use guidance, no exclusions, and no comparison to siblings such as list_workouts or schedule_workout. The monthly calendar context implies its purpose but does not explicitly guide selection among alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the tool returns sleep summary metrics and implies a daily night-ending scope, but it does not disclose missing-data behavior, permissions, rate limits, or the raw flag's effect.

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

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

The description is a single front-loaded sentence with no wasted words. It states the resource, scope, and key returned fields immediately.

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

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

An output schema exists, annotations cover safety, and the input schema fully documents both parameters, so the description does not need to explain return structure. It covers the tool's purpose and scope well, though it omits the `raw` option and any sibling-tool routing that could help an agent choose 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 100%, with both `day` and `raw` fully documented in the schema. The description reinforces the `day` semantics as 'night ending on day' but does not mention `raw`, so it stays at the baseline for high-coverage schemas.

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 resource and scope: sleep for the night ending on `day`, and enumerates returned metrics such as duration, stages, score, HRV, SpO2, and respiration. This distinguishes it as a sleep-data tool, but it does not explicitly contrast with sibling tools like get_hrv or get_heart_rate.

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?

There is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or related-tool routing. The only implied usage is that it returns sleep data for a given day, which is evident from the name and schema.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the return granularity (average and max over a single day), which is genuine context, but says nothing about data availability, missing-day behavior, or how the summary differs from the raw JSON option.

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

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

A single front-loaded sentence with no filler; every word earns its place. It is on the terse side but not padded, and the core metric is stated first.

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?

An output schema exists, so return values needn't be explained, but for a health-metric read tool with many overlapping siblings the description gives no guidance on scope, data freshness, or when this is the right endpoint. An agent choosing among get_hrv, get_body_battery, and get_stress has to guess.

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

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

Schema description coverage is 100%, with both 'day' (YYYY-MM-DD, defaults to today) and 'raw' fully documented in the schema. The description's phrase 'for one day' loosely echoes the day parameter but adds no format or semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific resource (stress) and the exact metrics returned (average and max) scoped to one day, so an agent knows precisely what it gets. It does not distinguish itself from health-metric siblings like get_body_battery or get_health_range, which could plausibly include stress 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?

No statement of when to use this versus alternatives, and no prerequisites or exclusions. The day-defaulting behavior is only visible in the schema, not the description.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. Beyond that the description adds nothing: no note on what the 'contributing factors' include, no indication that raw=true returns full Garmin JSON (that lives only in the schema), and no failure/empty-data behavior for days with no wearable data.

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

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

A single front-loaded sentence with zero filler. It is efficient, though its brevity reflects under-specification rather than economy of 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?

An output schema exists, so return-value explanation is not required, and the read-only nature is annotated. However, for a tool sitting in a dense cluster of health-metric siblings, the description provides no routing signal or domain vocabulary for what 'contributing factors' comprises, leaving the agent to choose between several similar tools on name alone.

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 100% and both parameters are documented there (day as YYYY-MM-DD defaulting to today, raw toggling Garmin's full JSON). The description only echoes the day dimension ('for a day') and says nothing about raw, so it adds no meaning beyond the schema — baseline 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 names the resource (training readiness score and contributing factors) and its granularity (a day), but it is a noun phrase with no verb and no explicit distinction from the closely-named sibling get_training_status. An agent can infer it's a read of readiness data, but must guess how it differs from adjacent readiness/status 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?

No when-to-use guidance is given: nothing says to call this instead of get_training_status, get_body_battery, or get_hrv, all of which touch recovery/readiness concepts. The only implicit cue is 'for a day', which is already encoded in the schema default.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds some behavioral value by enumerating the metrics returned, but it does not mention the raw JSON mode, the day-based snapshot behavior, or any caveats around data availability.

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 compact sentence with no redundant filler, and the metric list is front-loaded. It is appropriately sized, though it is a fragment rather than a fully structured explanation.

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?

An output schema exists, so return values need not be explained in detail, and annotations cover the read-only safety profile. However, the description omits when to choose this tool over get_training_readiness and does not clarify the day-scoped nature of the status, leaving meaningful context gaps for an agent selecting among many health endpoints.

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

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

Schema description coverage is 100%, and both parameters are documented in the schema as a date input defaulting to today and a raw boolean returning Garmin JSON. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

The description is a noun phrase listing returned metrics rather than a verb-led statement of what the tool does. It identifies the resource as training status and enumerates acute/chronic load, load focus, VO2max, and fitness age, so the purpose is inferable, but it does not distinguish this tool from related siblings like get_training_readiness.

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?

There is no explicit guidance on when to use this tool, when not to, or which sibling to choose instead. The agent must infer that this is a daily training-status retrieval tool from the name and schema alone.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds useful behavior — newest-first ordering and a 14-day default window — but says nothing about pagination, limits, or volume of results 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 front-loaded sentence with the scope first and the default as a parenthetical. Nothing redundant.

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?

An output schema exists and the input schema is fully documented, so the description needn't explain returns or params. However, for a list tool sitting among several activity siblings, it omits the routing information an agent needs to pick 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 100%, so every parameter including the raw flag and activity_type is already documented. The description only restates the date-range semantics and default window, adding no syntax or format detail beyond the schema.

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

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

States the resource (activities) with a date-range scope and default ordering, so an agent can tell what it returns. It does not differentiate from the close sibling get_recent_activities, which is easy to confuse with this tool.

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

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

No statement of when to use this versus get_recent_activities or get_activity. The default 14-day window hints at typical use but constitutes no explicit guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered, and the description adds only that these are the user's saved workouts. It says nothing about ordering, pagination behavior, truncation at the limit, or empty-library behavior for a listing endpoint whose results can be capped.

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?

It is a single short fragment with zero waste, but it is under-specified rather than deliberately concise – there is no leading verb and no second sentence to carry usage or pagination 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 output schema covers return values and annotations cover the read-only profile, so the description need not explain those. However, for a paginated list tool with a capped limit it should at least mention that results are capped and how to see more.

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% for the single 'limit' parameter, and the description never mentions it. The schema shows a default of 30 and a maximum of 100, but nothing explains what the limit counts or what happens when the library exceeds it, so the description fails to compensate for the coverage 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 phrase 'Saved workouts in the user's Garmin library' identifies the resource and implicitly the retrieval act, and the word 'Saved' hints at a distinction from get_scheduled_workouts. But there is no verb (list/fetch) and no explicit statement of what is returned or how it differs from list_activities or get_scheduled_workouts, leaving purpose merely inferable.

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?

Nothing states when to call this versus get_scheduled_workouts, list_activities, or get_activity, despite those siblings being obvious alternatives in the same library. No prerequisites or context of use are given.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write/remote-effect profile is covered. The description adds only that the target is the calendar, and says nothing about duplicate scheduling, whether the workout definition is modified, or idempotency.

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

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

A single front-loaded sentence with zero filler; every word carries meaning and the action is stated before anything else.

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?

Low-complexity, two-parameter tool with an output schema and annotations covering safety, so the description does not need to explain return values. Minor gaps remain around duplicate scheduling and the timezone basis for "today".

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 50%: `day` is documented in the schema, while `workout_id` is not. The description's "existing saved workout" partly compensates by implying workout_id must reference a previously created workout, but adds no detail on the day/today default or timezone 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?

States a specific verb ("Put") and resource ("existing saved workout") and destination ("Garmin calendar"). The qualifier "existing saved" implicitly separates it from create_workout, though no sibling is named explicitly.

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

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

The phrase "existing saved workout" hints at a prerequisite (the workout must already exist, so create_workout comes first), but there is no explicit when-to-use/when-not guidance and no named alternatives such as unschedule_workout or get_scheduled_workouts.

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

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

The annotations already declare destructiveHint=true, but the description adds valuable scope: only the calendar entry is removed and the saved workout remains. That clarifies exactly what the destructive action affects, though it does not mention permissions or response behavior.

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

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

The description is one compact sentence with the key distinction front-loaded in the parenthetical. Every part earns its place and there is no filler.

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

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

For a simple destructive tool, the description adequately conveys purpose and scope of destruction, and an output schema exists. However, it omits parameter sourcing/format guidance, which matters given 0% schema description coverage.

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 single required parameter, scheduled_workout_id. It does not explain the expected ID format or where to obtain it, leaving the parameter meaning to be inferred only from its name.

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: remove a workout from the calendar. The parenthetical '(the saved workout itself stays)' directly distinguishes this from delete_workout and other sibling mutation 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 clearly implies when to use this tool: when the user wants to take a workout off the calendar while preserving the saved workout. The distinction from delete_workout is clear but not stated with an explicit alternative name, 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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is carried structurally. The description adds that this is a partial update limited to name and description, but it never states what happens to omitted fields, whether existing values are preserved, or what errors occur for an invalid activity_id.

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

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

A single front-loaded sentence with no filler, and the action scope is stated before anything else. The brevity is appropriate, though the same terseness is what leaves behavioral gaps elsewhere.

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?

An output schema exists so return values needn't be explained, and annotations cover the mutation safety profile. Still, for a write tool with zero parameter descriptions, the definition omits partial-update semantics and validation expectations, leaving a moderate 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%, so the description must compensate. It implicitly maps 'rename' to name and 'set its description' to description, covering two of three parameters, but activity_id is never mentioned and nullability/default semantics are left entirely to the schema.

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

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

The description names a specific verb pair (rename / set description) against a specific resource (an activity), which is far clearer than the tool name alone. It does not explicitly contrast with get_activity or list_activities, but those are clearly read tools so the mutation intent is unambiguous.

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

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

There is no guidance on when to use this versus get_activity, no prerequisites (does the activity need to exist? does it need to be user-created?), and no note that only name/description are mutable while other fields are not. The agent must infer usage entirely.

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