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

Beyond the annotations it discloses the important traits: it writes to the real Garmin calendar, validates every session before creating anything ('a mistake in session 40 leaves no half plan behind'), stores nothing outside Garmin, and encodes a plan code in every workout name that get_plan later relies on. Those are exactly the side effects and invariants an agent needs before a bulk write.

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

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

Front-loaded with purpose and confirmation requirement, then a structured Args block. It is long, but nearly every line carries information; the plan-code paragraph is slightly belabored for the space it takes.

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 6-parameter bulk mutation with nested free-form objects and an output schema, nothing essential is missing: validation behavior, naming convention, defaults, limits and the returned card are all covered, so the agent can call it correctly in one pass.

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

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

Schema coverage is 0%, so the description must carry the load and does: each arg is defined with examples, the sessions object's fields and defaults are spelled out (sport running, pool_length_meters 25, date range today to 30 weeks out, max 150), and the milestone object shape is given. This is well beyond what the bare schema provides.

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

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

Opens with a specific verb and resource plus scope: 'Create a whole training block at once: every session built and put on its date.' That immediately separates it from create_workout (one workout) and schedule_workout (one session), so the sibling distinction is clear without opening any schema.

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

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

Explicit about when to use it and what to do first: design from goal, fitness (naming get_fitness), readiness and history, then 'Show the user the plan and get their agreement first: it writes to their real calendar.' It also removes a follow-up call by stating the response is drawn like get_plan.

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?

Adds meaningful behavior beyond the annotations: it never edits or replaces an existing workout, and on an ambiguous exercise name it returns the candidate list rather than guessing — an important failure mode to know. This is real context an agent could not derive from `readOnlyHint: false` / `destructiveHint: false` alone.

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

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

Front-loaded with purpose and the one behavioral caveat, then a compact Args block and a single worked example. Every sentence does work — the example is the most efficient way to specify the nested structure.

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 described. Between the purpose, the routing to `schedule_workout`/`find_exercises`, the ambiguity behavior, and the full nested-parameter documentation, an agent has everything needed to call 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 coverage is 0%, so the description carries the full burden, and it delivers: all three params are documented, plus the nested block fields ('exercise', 'sets', 'reps', 'rest_seconds', 'weight_kg') with their defaults, backed by a concrete push-day example. This compensates completely for the empty 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 a specific verb and resource ('Create a strength training workout in Garmin Connect') and rules out editing or replacing existing workouts. It does not, however, distinguish itself from the sibling `create_workout`, so an agent still has to infer which creation tool to use for a generic vs. strength workout.

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

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

Explicitly routes the agent: 'Use schedule_workout afterwards to put it on a date so it syncs to the watch' and 'Call find_exercises to search.' These are named alternatives with conditions, not just implied usage.

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?

Goes well beyond annotations by explaining that this always creates a new workout, never edits, and that scheduling is a separate action. It also discloses important behavioral details such as default target assignment, automatic pace-range widening, watch beeping behavior, swim note handling, lap-button semantics, and repeat nesting limits.

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 opening sentence is front-loaded and the Args section is organized around the actual inputs. It is long, with substantial coaching heuristics and examples, but most of that detail is necessary for correctly constructing nested workout steps.

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

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

Given the complex nested steps schema, zero schema description coverage, and the existence of an output schema, the description is complete enough for an agent to construct valid workouts. It fills the schema gaps with detailed step semantics, examples, and sport-specific behavior.

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 steps parameter is a free-form array, so the description carries the full burden. It thoroughly documents every parameter and the nested step grammar, including types, duration/distance/until_lap, target formats, repeat structure, sport defaults, and pool length.

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: creates a structured workout in Garmin Connect. It also explicitly distinguishes creation from editing with "always a new one, never an edit," making it clearly different from update_workout.

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?

Makes the create-vs-edit boundary clear and explains that schedule_workout is the next step to put the workout on a date. It also references get_fitness and get_activities for target-setting context, though it does not explicitly name update_workout or create_strength_workout as 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 flag destructiveHint=true; the description goes well beyond that by disclosing the two-call confirmation gate, that the first call is a non-destructive read returning the workout name, and that deletion is permanent. It also disambiguates the blast radius by excluding recorded activities.

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 permanence warning is front-loaded and the Args block is tight. The sentence "This asks before it acts, and the check is real rather than advisory" is somewhat redundant with the explanation that follows, costing a little efficiency without losing clarity.

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

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

For a destructive two-parameter tool with an output schema, everything needed is present: mutation semantics, the confirmation protocol, the failure mode of an unconfirmed call, and the exact value to pass. Return-value detail is correctly left to the output schema apart from the one fact the workflow depends on.

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 carries the full burden and does it: workout_id is sourced from list_workouts or create_workout, and confirm is defined precisely as "the workout's exact name, which the first call returns" — including that it is empty on the first call. No ambiguity remains about either 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 verb and resource ("Delete a workout") and immediately scopes it: it removes a workout-library plan, not a recorded activity, which separates it from update_activity and get_activity_details. The two-step confirm behavior also distinguishes it from sibling mutations like update_workout and unschedule_workout.

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

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

Explicitly states when the tool acts and when it does not ("the first call never deletes"), plus the required human-in-the-loop protocol ("Show the person what is about to go"). It also gives a negative case ("Recorded activities are untouchable here") and points at list_workouts / create_workout for sourcing the ID.

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 read-only, non-destructive, closed-world behavior. The description adds useful matching behavior—hyphens and spacing are ignored, so variant spellings work—but does not cover result ordering or pagination behavior beyond the 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?

The description is front-loaded with the core purpose, followed by usage context and parameter notes. Every sentence adds actionable information with no redundancy.

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

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

Given the simple two-parameter search nature, existing annotations, and the presence of an output schema, the description provides everything needed to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does: query is described as part of an exercise name with examples like 'bench press' and 'row', and limit is explained as the number of matches with its default of 25.

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 (Search) and resource (Garmin's exercise catalogue) along with the search dimension (by name). It is clearly distinguishable from sibling workout creation 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 explicitly says when to use this tool: before create_strength_workout when unsure of an exercise name, or when that tool reports ambiguity. This directly ties usage to a sibling tool's 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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine context beyond that: swims return pace per 100 m, pool length, SWOLF and stroke rate instead of pace per km, plus the 'recent' ordering implication and the end_date-relative-to-today behavior. What it doesn't disclose is whether 50 is a hard ceiling, what happens with a very wide date range, or anything about ordering/tie-breaking.

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

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

Front-loaded purpose sentence, then the swim exception, then a compact Args block. Every line carries information the schema lacks; nothing is repeated from annotations or the JSON 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, there is no obligation to describe return fields, and the args are fully covered. The remaining gap is pagination: for a listing tool capped at 50 there is no statement about how to page past the limit or whether ordering is newest-first, which matters for a tool returning 'recent' items.

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 carries the full burden and does so: limit range (1-50) with default 10, both dates as YYYY-MM-DD, and the non-obvious conditional default that end_date becomes today when start_date is supplied. That conditional behavior is not derivable from the schema's anyOf/default:null at all.

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

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

States a specific verb (list) plus the resource (recent runs, rides, swims, workouts) and the fields returned (distance, duration, pace, HR zones), and notes the swim-specific variant. It does not explicitly distinguish itself from get_activity_details or list_workouts, so the agent must infer that this is the activity feed rather than planned workouts or a single-activity drill-down.

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: the word 'recent' plus the limit/date-range args signal this is the default feed query, but there is no explicit 'use this when...' or 'for per-activity detail use get_activity_details' routing. An agent can infer usage from the sibling list but the description does no work to route it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds the non-obvious trait that the response shape varies substantially by sport (run/ride/swim get different fields). It omits behavior on invalid IDs and payload size, which keeps it off a 5.

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

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

Purpose and the ID source are front-loaded, but the three sport-specific paragraphs are long and largely enumerate return values, which is redundant with the output schema. The content is useful but not efficiently sized for what the structured fields already carry.

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 a one-parameter, read-only tool with an output schema, an agent has everything needed to call it and know what each sport returns. The missing piece is failure behavior (unknown activity_id) and whether the ID must come from the authenticated user's account.

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% for the single parameter, and the raw schema is just an anyOf integer/string with no description, so the description must compensate. It does by naming the source (the activityId from get_activities), which is the key thing an agent needs; it doesn't clarify why both an integer and a string are accepted.

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

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

Opens with a specific verb+resource+scope: "Splits and heart-rate detail for one activity." That cleanly distinguishes it from the sibling get_activities (which lists many), and the body makes clear the payload expands per sport type. An agent can tell exactly what this returns without opening either schema.

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

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

It gives an explicit usage instruction — "Use these to explain a run rather than guessing why it was slow or hard" — and states the dependency via "The activityId from get_activities," implicitly routing from the list tool. It does not name when NOT to use it or compare against siblings like get_heart_rate, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: it discloses the sensitivity handling ('Never returns the password or the cached token itself') and that it inspects credential presence plus cached session usability, which an agent could not infer from annotations alone.

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

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

Two short sentences, with the core purpose front-loaded and the security guarantee following as a secondary clause. Nothing is padded or repeated from the annotations.

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 needn't enumerate return fields, and the annotations cover safety. It says enough about what is inspected (credentials present, cached session usable) to set expectations, though a hint about what to do when the check fails would complete it.

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

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

There are zero parameters, so the baseline is 4. The description correctly adds no parameter detail that would be redundant, and the empty schema is self-explanatory.

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

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

States a specific verb and resource: 'Check whether the server is logged in to Garmin Connect.' This is unmistakably an auth/session status check, which sets it apart from every sibling (get_activities, get_profile, etc.), all of which fetch data rather than report login state.

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 explains what is reported but never states when to call it — e.g. before other tools, or after an authentication error. Usage is only implied by the tool's nature, and no alternatives or prerequisites 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the analytical content of the response – body-battery charge/drain drivers and longest stressful spells – which is behavioral detail annotations cannot express. An output schema exists, so no penalty for not detailing the return shape further.

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

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

Front-loaded with the resource and metric list, then use cases, then an Args block – a clean structure with no filler. The mid-sentence fragment "With what charged or drained Body Battery and the longest stressful spells" is slightly clunky but still short.

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

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

For a single-optional-parameter read tool with full annotations and an output schema, everything an agent needs is present: what it returns, when to reach for it, and exactly how to format the date argument. No material gap remains.

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 carries the full burden, and it does: the accepted formats (YYYY-MM-DD, 'today', 'yesterday', offset like '-3') plus the default of today are all stated. This goes well beyond the bare string/null schema and removes any ambiguity about valid input.

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 first line names the resource precisely (daily health summary) and enumerates the exact metrics returned: steps, calories, resting heart rate, body battery and stress. That enumeration lets an agent separate it from siblings such as get_heart_rate, get_readiness, get_sleep_data and get_recovery_trends without opening any schema.

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

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

The quoted user questions ("why is my Body Battery low", "when was I stressed") give concrete trigger scenarios, which is real usage guidance. It stops short of naming an alternative or an exclusion, so an agent must infer whether to prefer this over get_heart_rate for a heart-rate question.

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 readOnlyHint/destructiveHint/openWorldHint already declared, the description still adds real value: classifications are present only 'where Garmin gives one', watts-per-kilo appears only when the user's weight is set, and the returned zones are the ones workouts can target as 'z2'. It stops short of covering missing-device/no-data behavior, so not a 5.

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

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

Mostly front-loaded with the payload inventory first and the sibling routing last, and every clause carries information. Slightly jumbled by the 'Also the heart rate and power zones' insertion after the opening paragraph, which interrupts the flow before the FTP follow-up.

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?

No parameters, read-only annotations, and an output schema that already documents return shape – yet the description still explains the marker set well enough for an agent to decide this is the right call. Nothing needed to invoke it correctly is missing.

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

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

The tool takes zero parameters, so the schema baseline of 4 applies; there is nothing further the description could add on argument 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 names a specific resource (Garmin fitness markers) and enumerates exactly what comes back – VO2 max, fitness age, race predictions, lactate threshold, endurance/hill score, running tolerance, HR/power zones, FTP. 'Read on the user's current fitness, as markers rather than history' crisply separates it from the trend-oriented 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?

Gives explicit when-to-use ('set goals and training paces from evidence') and names two alternatives with the condition that selects each: get_plan for a general 'how's my training going' and get_fitness_trends for improvement over months. No inference required.

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

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

Annotations already declare readOnly/no-destructive/closed-world, and the description adds real behavioural context beyond them: the change is computed from the first month to now, each marker is classified improving/steady/declining, and the missing-data case is specified ('With no weigh-ins logged, say so and that weighing in through Garmin Connect or a Garmin scale is what fills it'). That is the kind of edge-case disclosure agents need to avoid fabricating weight trends.

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

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

Front-loaded with the core purpose and the marker list before the usage guidance, and every clause carries information. It runs long however — dense multi-line paragraphs plus a quoted-phrasings list and response-format instructions — which costs some scannability for an agent parsing quickly.

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 shape need not be explained, and the description still covers the main edge case (no weigh-ins) and routing to siblings. The remaining gap is the case of no fitness-marker data at all (e.g. a device that never recorded VO2 max), which the description does not address.

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 carry the parameter, and it does: the 'Args' block states the range 1-12, the default of 6, and the non-obvious nuance that the window is inclusive of the current month. No ambiguity remains about what 'months' means.

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

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

Opens with a specific framing ('Whether the user is getting fitter') and then enumerates exactly what is returned: VO2 max, race predictions, lactate threshold, endurance/hill score, cycling FTP, plus weight/body composition, each as a monthly value with change since the first month. It explicitly contrasts itself with siblings ('For where they stand today, get_fitness is enough'), so an agent can distinguish it without opening schemas.

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?

Names concrete triggering questions ('am I getting fitter', 'is my VO2 max going up', 'was I faster when I was lighter') and gives explicit alternatives with conditions: get_fitness for today's snapshot, get_recovery_trends for recovery. It also prescribes the analysis pattern (name markers that moved and by how much; correlate weight with markers as pattern not cause).

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

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so safety is covered. The description adds genuinely non-obvious behavior: gaps are defined as 10+ minutes without a reading, and output is blocks with low/average/high plus extremes. It doesn't mention data-availability or wear-time prerequisites (e.g. what if the watch wasn't worn), which is the remaining 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?

Front-loaded one-line purpose, then answering questions, then output shape, then sibling routing, then a clearly delimited Args block. Every sentence carries information an agent would otherwise have to guess; nothing is padding.

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?

Three optional params, no required fields, and an output schema exists — yet the description still covers purpose, routing, time-window edge cases, and gap semantics. An agent could call this correctly from the description 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 0%, so the description carries the full burden and does so: 'date' is the day the window starts with a today default and a noted last-night idiom, 'start'/'end' are local HH:MM defaulting to midnight, and 'end' before 'start' rolls into the next day. This is exactly the semantics missing from a bare anyOf/string 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 a specific verb+resource+scope: heart rate over a day or night window sourced from the watch's all-day readings. Crucially it distinguishes itself from a near-neighbor by noting 'A run's heart rate is get_activity_details', so the agent can separate all-day HR from workout HR without reading either schema.

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

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

Gives concrete user questions it answers ('was there a gap overnight', 'when did my heart rate settle', 'how low did it go') and names the alternative tool for run-level HR. The date/start semantics for 'last night' are also tied to a usage scenario, not just a 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?

Annotations already mark it read-only/non-destructive, and the description layers on substantial operational context: the freshness/staleness model ('runs sync through the day, so the earlier answer goes stale'), the matching semantics for what counts as 'done' (within a day either side, watch-started, strength-in-own-week), and the card-drawing side effect plus the instruction not to re-list the plan.

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?

Long but justified by the amount of routing and state-management behavior it has to encode, and it is front-loaded with purpose then usage before edge cases. There is some redundancy ('don't guess' restated, repeated emphasis on what counts as done) that could be tightened without losing 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 values need not be described, and the description still covers what the schema cannot: cross-tool handoff for session details (get_workout with workout_id), the caching contract, how to reconcile Garmin data with the user's claim of having done a session, and when to probe about how a hard session felt. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 0%, so the description must carry the single parameter, and the Args block does: 'the code of a plan made with create_plan, e.g. "HM"' and 'Omit it for the plan running now, or the calendar.' This adds real meaning over a bare nullable string, though 'the calendar' as a fallback is left somewhat underspecified.

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

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

States a specific verb and resource ('How the user's training is going, drawn as an interactive plan card') and enumerates exactly what the card contains: plan week by week, each session done/missed/ahead, next session. It explicitly separates itself from get_workout (session steps/paces) and from the recovery/readiness/fitness siblings, so an agent can pick it without opening the schema.

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

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

Gives explicit trigger phrases ('how's my training going', 'this week', 'what's next'), states 'Call it first for any general question about training', and names the exclusions ('Don't call it for a specific question about a run, sleep, readiness, recovery, fitness or shoes'). It also states when to re-call versus answering from the prior result (session done, workout moved, new day, user asks to see it again).

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real value beyond that by disclosing a data-coverage limitation: records only exist if Garmin itself recorded them, so watchless races or pre-device history will be absent. This is exactly the kind of caveat an agent needs to avoid over-claiming.

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

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

Three short sentences: what it returns, when to use it, and the one caveat that changes interpretation. Front-loaded with the payload and 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?

With no parameters, an output schema, and annotations covering the safety profile, the remaining burden is the domain caveat, which the description handles well. The only gap is that it says nothing about behavior when no device or data is present, a plausible case for 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?

The tool takes zero parameters, which sets the baseline at 4. Schema coverage is 100% and an output schema exists, so there is no parameter semantics for the description to carry.

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 first sentence names the resource and its contents concretely: 'Fitness profile: VO2 max and personal records.' That is more specific than the sibling names alone (get_fitness, get_fitness_trends, get_progress), though the description never explicitly contrasts itself with those siblings, so an agent must infer the boundary.

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

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

It gives an explicit positive directive — 'Use this instead of asking the user for their PBs' — which tells the agent when to reach for it rather than prompting the user. It does not name a competing sibling tool or state when-not-to-use, 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 only cover the read-only safety profile; the description adds the matching algorithm (within a day either side, roughly the planned duration) and the rationale (shifted sessions still count as a good week), which is the key behavioral surprise. It also discloses the rendering side effect — an interactive plan card is drawn and calling again re-draws it — that no annotation conveys.

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

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

Front-loaded with the core answer, then eligibility rules, then usage routing — structure is good. Slight redundancy in 'Read those back when something looks wrong: a mismatch is visible there rather than hidden' and in restating the card-drawing consequence twice, which costs a bit of tightness.

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 values need not be enumerated, yet the description still flags the per-session plain-English reason field and points to get_activity_details for intensity. Combined with the card-rendering caveat and the sibling routing, an agent has everything needed to call and re-call 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 coverage is 0% (the single 'weeks' property has no description, minimum, or maximum), so the description carries the full burden and does: 'How many weeks back to report, including this one (1-12)' supplies both the inclusive-count semantics and the valid range that the schema omits.

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 states a precise verb+resource: which planned sessions were completed, aggregated week by week. It explicitly separates itself from get_plan (plan overview) and get_activity_details (intensity assessment), so an agent can pick it out of a 25-tool family without opening a schema.

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

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

Gives explicit when-to-use ('am I keeping up'), when-not-to ('For "how is my plan going", get_plan is the better first call'), and a re-fetch rule ('fetch it fresh only when a session may have been done since'). Alternatives are named and the condition that selects each 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds valuable scope context by listing the bundled metrics (readiness score/factors, training status, acute vs chronic load, four-week load focus, sleep, HRV, body battery, stress, resting heart rate) and noting it subsumes sleep and daily-summary tools; however, it does not discuss data freshness, failure modes, or other operational behavior. The output schema carries the return structure, so a 4 reflects useful added context without full behavioral disclosure.

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 front-loaded with the core decision and then gives alternatives and parameter details. It is slightly dense in the long run-on sentence listing all included metrics, but every sentence contributes useful selection or invocation information; no filler or repetition is present.

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 a one-parameter read-only tool with an output schema, the description covers purpose, when to use and avoid, sibling alternatives, data included, and accepted parameter formats. Nothing an agent needs to select or call the tool correctly is missing.

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

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

Schema description coverage is 0% and the schema only defines `date` as an unconstrained string/null. The description fully compensates by documenting accepted formats ('YYYY-MM-DD', 'today', 'yesterday', or an offset like '-1') and the default ('Defaults to today'), which is essential for correct invocation.

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 immediately states the decision it supports ('Whether the user should train hard today or hold back') and then enumerates the exact Garmin metrics it returns. It explicitly distinguishes itself from siblings like get_plan, the activity tools, get_sleep_data, and get_daily_summary, so an agent can route correctly without opening any schema.

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

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

It gives both the positive trigger ('For that question, and for checking today before prescribing a hard session') and explicit exclusions ('Not for reviewing a week, a run or how training is going: get_plan and the activity tools answer those'). It also states that get_sleep_data and get_daily_summary are unnecessary alongside it, which is precise alternative 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 destructiveHint=false, so the safety profile is covered; the description adds the useful behavioral detail that results include flagging of markers that have drifted outside their usual range (resting HR up, HRV down, short sleep, load jump). It says nothing about caching, latency or data freshness, so it stops short of a 5.

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

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

The main statement comes first, then the returned-metric list, then routing guidance, then the arg note — a sensible front-loaded order. It is a few lines longer than strictly necessary, with the metric enumeration and the get_plan coda partially overlapping in purpose, but no sentence is filler.

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

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

For a single-optional-parameter read tool with an output schema and read-only annotations, an agent has everything needed: what window it covers, what it returns conceptually, which questions it answers, and which siblings to use instead. The return-value enumeration is arguably redundant with the output schema but costs little.

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

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

Schema coverage is 0%, so the description has to carry the parameter, and it does: 'weeks: Weeks to look back, including this one (1-12). Defaults to 4.' It adds a hard range constraint and clarifies that the current partial week counts, neither of which is in the schema (which only shows type integer and default 4).

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 resource and the scope precisely ('how the user is recovering across weeks, beside the training that caused it') and then enumerates the concrete metrics returned (HRV, resting HR, sleep, Body Battery, load). It explicitly differentiates itself from two siblings: get_readiness for today's training decision and get_plan for general training 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?

It supplies three verbatim user questions that should route here ('am I recovering well', 'is this block too much', 'why do I feel flat'), states the condition that selects a sibling instead ('For whether to train hard today, get_readiness is the one'), and positions itself relative to get_plan as a follow-on call rather than a starting point.

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

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

Annotations already declare readOnly=true, destructive=false, openWorld=false, so the safety profile is covered; the description adds genuine behavior, notably the 650 km fallback limit when Garmin has none set and the fact that pairs near end-of-life are flagged. That fallback rule is non-obvious domain logic an agent could not infer from the schema or 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?

Front-loaded with a one-line purpose, then the per-pair payload, then usage prompts — a sensible order with no filler sentences. It is slightly long because it enumerates return fields that the existing output schema already documents, which is mild redundancy rather than waste.

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 zero parameters, a present output schema, and rich annotations, the only things the description must supply are the domain rules — the 650 km default, the end-of-life flagging, and how retired pairs appear. It supplies all three, so an agent can call and interpret the result without further 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?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly implies a no-argument call returning the whole shoe roster rather than hinting at hidden filters.

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 (the user's running shoes) and states exactly what is reported per pair: km so far, runs, limit, km left, recent km, last worn date, and default-assignment status. No sibling tool touches shoe/gear data, so the resource alone cleanly separates it from get_activities, get_fitness, and the rest.

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

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

Gives two concrete triggering questions — "do I need new shoes" and "which shoes do I run in most" — which map directly to the reported fields and make selection easy. It does not state any when-not condition or name an alternative, but no sibling overlaps this domain, so the omission is minor.

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

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

Annotations already declare readOnly, non-destructive, and closed-world, so the safety profile is covered. The description adds meaningful context beyond that: the data includes a comparison against the user's usual baseline, which tells the agent the output is interpretive rather than raw. It doesn't discuss data availability (e.g., missing nights), keeping it short of a 5.

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

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

Two tight parts: a one-sentence summary of returned data, then a focused Args block for the single parameter. Front-loaded, no filler, and the wake-up-date clarification is stated before the accepted formats.

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 needn't describe return structure, and the sole parameter is fully specified. The only gap is sibling differentiation against get_daily_summary and other daily metrics; otherwise it is complete for a simple single-parameter 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 coverage is 0% and the parameter is a bare optional string, so the description carries the full burden — and it does: it defines the anchor as the wake-up date, lists accepted formats (YYYY-MM-DD, 'today', 'yesterday', offset like '-3'), and states the default. This is exactly the guidance an agent needs to avoid the common mistake of passing the sleep-onset date.

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 (sleep stages, sleep score, overnight breathing rate and SpO2) scoped to a single night, which is clearly distinct from siblings like get_readiness and get_heart_rate. The verb is implicit but the returned data is named precisely enough that an agent knows exactly what this retrieves.

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?

Implied use case is clear — fetch last night's or a specific night's sleep report — but the description never states when to prefer this over get_daily_summary or other daily-metric siblings, nor any exclusions. Adequate but leaves routing decisions to inference.

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

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

Annotations already mark this readOnly, non-destructive, closed-world, so the safety bar is met; the description goes further by disclosing the response shape an agent would otherwise have to discover: each step's distance-or-time and target, that repeats keep their nested structure (8 x [1 km at target, 60 s recovery]), and that warm-up/cool-down are part of the answer. That is meaningful behavioral context beyond the structured fields.

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

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

Front-loaded with the core statement, then usage, then the repeat-structure detail, then Args. Slightly long for one parameter, and the three quoted example queries overlap somewhat, but every sentence still carries routing or output-structure information rather than 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, so return values need no full prose, yet the description still gives the one structural fact worth knowing (repeats nest). Combined with id provenance, the never-guess warning and the clear read-only framing, nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 0% and the single property has no description, so the description must compensate; it does by stating the id comes from get_plan or list_workouts rather than being guessed, and repeats this in the Args block. It stops short of saying the id is an integer or what happens on an invalid id, so it earns a 4 rather than a 5.

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

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

Opens with a specific verb+resource ('The steps of one workout, saved or scheduled') and states the scope precisely: each step with distance/time and target. This clearly separates it from get_plan (plan-level sessions) and list_workouts (enumeration), even though the description never has to name them as competitors explicitly, the wording does the 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?

Explicitly says 'Use it for any question about what a session involves' and gives three paraphrased example queries that map to real user phrasing. It also names exactly where the workout_id comes from ('from get_plan's sessions or from list_workouts') and issues a clear exclusion: never guess paces, recoveries or warm-up from other sessions.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without description help. The description adds useful scope context ('structured workouts saved in the account') and the limit's range, but says nothing about ordering, pagination beyond limit, or whether full workout detail is returned (an output schema exists, so the latter is forgivable).

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 of purpose plus a compact arg note; nothing is wasted and the purpose is front-loaded. The args block is not redundant here because the schema has zero description coverage.

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 one-parameter read tool with annotations and an output schema, the description is serviceable but thin. It omits result ordering and any indication of how many workouts typically exist or how to page past 100, which is the main thing an agent would need beyond the schema.

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 carries the burden for the single parameter, and it does: 'Maximum workouts to return (1-100). Defaults to 20' supplies both bounds and default that the bare integer schema lacks. It does not say what order results are returned in or whether limit is the only paging control.

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

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

States a specific verb ('List') and resource ('structured workouts saved in the Garmin account'), which is unambiguous against siblings like get_workout, create_workout, and schedule_workout. It does not explicitly name those siblings, but the list-vs-single-item distinction is inferable from the 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?

Usage is implied: this is the enumeration call in a family that also has get_workout (single item) and get_activities (activities, not workouts). No sentence states when to use this instead of get_workout or what happens when there are no workouts, so the agent must infer routing from tool names 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 flag destructiveHint=true, but the description adds the crucial scope detail: only sessions from today onward are removed and past ones are kept, so the audit trail survives. It also discloses the two-phase dry-run/confirm safety flow, which no annotation covers.

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

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

Front-loaded with the outcome, then scope, then the confirmation protocol, then args. Dense and largely waste-free, though the args section restates param names already covered in prose ('The plan code again'), a mild duplication.

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 and annotations exist, so the description need not explain return values, and it doesn't. What it must cover for a destructive two-step tool — scope limits, reversibility of past data, and the confirm handshake — is fully addressed.

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 carries the full burden and does so: label is defined as the plan code with an example ('HM'), and confirm as the same code repeated to proceed. It also explains that omitting confirm produces a dry run, which the schema's empty-string default does not convey.

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?

Uses a specific verb and resource ('take the rest of a plan off the calendar and out of the workout library'), and the phrase 'rest of a plan' plus 'workout library' implicitly separates it from session-level siblings like delete_workout or unschedule_workout. An agent can identify the scope of the operation without opening the schema.

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

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

Explicitly states the intent ('for starting again or abandoning a block') and, more importantly, prescribes the exact call sequence: a first report-only call, then a second call with confirm after the user agrees. That routing guidance is what an agent needs to decide when and how to invoke it.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the bar is lower, and the description still adds the non-obvious behavioral fact that scheduling triggers watch sync. It omits whether re-scheduling overwrites, whether duplicates are allowed, and any auth/connection requirement.

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 front-loaded paragraphs plus an Args block; the watch-sync rationale lands before the parameter detail. No filler sentences, and the format examples are placed exactly where an agent would look.

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 two required params, an output schema that covers return values, and annotations covering safety, the description is nearly sufficient for correct invocation. The remaining gap is edge-case behavior on repeated scheduling and whether the workout must already exist on the account.

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 carry parameter meaning and does: it explains workout_id's provenance and constrains date to four concrete formats (YYYY-MM-DD, 'today', 'tomorrow', '+3'). This is information an agent could not infer from the bare string/integer 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?

Specific verb ('Put/schedule') plus specific resource ('existing workout on a date in the Garmin calendar'), and 'existing' implicitly separates it from create_workout while the sibling unschedule_workout covers the inverse. An agent can route between create_workout, schedule_workout, and unschedule_workout from the text alone.

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

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

Gives the key usage fact that scheduling is what makes a workout sync to the watch, which explains why you'd call this rather than stopping at create_workout. It also names the two sources of workout_id (create_workout, list_workouts). It does not state what happens if a workout is already scheduled on that date, nor any 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?

Beyond the annotations, the description explains the critical behavior: only the scheduled entry is removed, while the workout itself is kept and can be scheduled again. It also discloses what happens when multiple workouts sit on a date, listing them rather than guessing. This does not contradict destructiveHint=true because removing a schedule entry is still a destructive update, even if reversible.

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 front-loaded with the key reversible distinction and then uses a clear Args section. Every sentence adds useful behavioral or parameter context without 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 two-optional-parameter mutation tool with an output schema and annotations, the description is nearly complete. It covers the main semantic ambiguities and alternatives, but omits default/no-argument behavior.

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 carry parameter meaning. It does well by documenting accepted date formats, listing behaviors, schedule_id provenance, and precedence. It does not explain what happens when neither optional parameter is supplied, leaving a small but real gap.

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

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

The description states a specific verb and resource: taking a workout off a day in the Garmin calendar. It explicitly distinguishes this from delete_workout and implicitly from schedule_workout, so an agent can identify the correct operation without opening sibling schemas.

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 says when to use this tool: to clear a session the watch should no longer show. It also names the alternative delete_workout for outright deletion and explains schedule_id precedence over date.

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 establish this is a non-read-only, non-destructive mutation; the description adds crucial semantics annotations cannot convey: notes are replaced rather than appended, shoes overwrite the existing pair, and "none" removes shoes entirely. It also states the response reports prior values, which matters for a mutation tool.

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

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

The core behavior and partial-update rule are front-loaded in one sentence, and the Args block gives one tight line per parameter. Slightly list-heavy but every line carries real information, with no repetition of the 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?

For a five-parameter mutation tool with an output schema already present, nothing essential is missing: overwrite vs append semantics, the removal sentinel, valid type values, and cross-tool references are all covered. Return-format explanation is rightly not duplicated.

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 carries the full burden and does: it documents all five parameters, gives the source for activity_id and shoes, explains the string sentinel "none" for removal, and provides concrete activity_type values (trail_running, indoor_cycling, walking) that the schema's free-form string otherwise leaves open.

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

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

Opens with a specific verb and resource ("Change a recorded run or ride") and enumerates the exact editable fields, so it is instantly distinguishable from read-only siblings like get_activity_details or get_activities. The scope (per-activity metadata edit) 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?

Explicitly says to pass only changed fields (partial update) and routes the agent to get_activities for activity_id, get_shoes for shoe names, and get_activity_details for reading current notes. It stops short of stating when not to use it (e.g. for workouts, use update_workout), but the context is otherwise 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?

Annotations already flag destructiveHint=true; the description supplies the crucial nuance the annotation cannot — the workout keeps its id, scheduled dates survive, the watch picks up changes at next sync, and the steps list is replaced wholesale rather than merged. It even notes the response echoes the replaced steps, which is behavior an agent cannot infer from the schema.

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

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

Front-loaded with purpose, then behavior, then the replacement caveat, then a clean Args block — the ordering is exactly what an agent needs. It is on the long side and the mid-sentence line breaks add noise, but no sentence is redundant given the empty schema descriptions.

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?

A destructive mutation tool with six undocumented parameters and no schema descriptions would normally be under-specified, but this description covers id/scheduling side effects, replacement semantics, field-by-field argument meaning, and the prerequisite read step. Return values are left to the output schema, which is appropriate.

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

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

Schema coverage is 0%, so the description carries the full burden and does: every one of the six parameters is explained, including the 'omit to keep current value' convention that the schema's nullable defaults do not convey, plus the conditional rule that sport is only meaningful alongside steps. It also points steps at the create_workout shape, filling a real gap for a free-form object array.

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

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

Opens with a specific verb+resource ('Change an existing workout in place') and immediately scopes what can be changed (name, steps, or both). It is clearly distinguishable from create_workout, delete_workout, and get_workout, all of which appear in the sibling list.

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

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

Explicitly says to retune existing workouts rather than delete-and-recreate, and prescribes the read-with-get_workout-then-resend-all-steps procedure for partial edits. It also states when to omit optional fields, so the agent never has to guess between update and delete/create.

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