LiftTrack

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

Annotations already cover the write/safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false), so the added behavioral context is a bonus: it discloses the training-max failure mode ('the call fails with a clear error if the exercise has no training max set') and the folder side effect (creates the folder if none matches). It does not mention duplicate-name behavior or overall size limits in prose, but the core failure/side-effect behavior is covered.

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

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

Front-loads purpose, then groups set/rest/load/superset rules into discrete paragraphs and closes with a worked superset example. It is long but densely informative; a few sentences restate schema-level detail (weight units, rest modes), which is the only real slack.

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 complex nested-payload create tool with an output schema present, the description covers required field relationships, conditional requirements, rest semantics, superset constraints, folder behavior, and failure modes, plus a full example. Only minor edge cases (duplicate workout names, whether creation is idempotent) are left 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?

With 67% schema coverage, the description meaningfully supplements the schema: it clarifies that percent is 'the percentage of training max itself... not a computed weight', that weight=0 means bodyweight, the 'off' vs 'lap' rest semantics, and superset rules the schema omits (at least two exercises must share a label, max 16 distinct labels). Some of this overlaps schema descriptions, keeping it short of 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 precise verb and resource ('Create a workout template') and enumerates the payload it accepts (exercises, sets, loads, rest modes, supersets). It is clearly distinguishable from update_workout/delete_workout, though it never explicitly names which sibling it differs from or routes to.

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 implied guidance ('Exercise names must be exact display names from the catalog or the user's custom exercises'), which hints that a lookup/validation step should precede the call, but no sibling such as search_exercises or validate_exercise_names is named. No when-to-use vs. when-to-update framing is 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 destructiveHint=true, but the description adds valuable behavioral detail beyond them: permanence and irreversibility, the side effect of removal from schedules and the Garmin device, the prohibition on deleting app default workouts, and the exact failure behavior when names collide (fails and lists matches without deleting). This is well beyond what the annotations convey.

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 critical facts (permanent, cannot be undone, cascading effects, defaults protected) are front-loaded before the args, and every sentence carries distinct information about behavior or parameters. 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?

An output schema exists, so return values need not be explained, and the description still covers the crucial edge case of duplicate names through the failure-and-list behavior. Combined with annotations covering the safety profile, an agent has everything needed to call this destructive 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 coverage is 100%, so the schema already documents both parameters, setting a baseline of 3. The description adds meaning beyond schema: it specifies that workout_name matching is case insensitive and clarifies the special 'My Workouts' sentinel value for folder_name, which the schema description also mentions but the description reinforces with an example of disambiguation.

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

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

The description opens with a specific verb+resource ('Permanently delete a workout template') and the word 'permanently' plus 'template' distinguishes it from siblings like create_workout, update_workout, and schedule_workout. An agent can immediately tell this is the destructive removal operation.

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 context: deletion removes the workout from schedules and from the device, and app default workouts cannot be deleted, which functions as a 'when-not' exclusion. However it never names sibling alternatives (e.g., update_workout or unschedule_workout) for cases where the user wants a softer action.

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, idempotentHint, non-destructive and closed-world, so the safety bar is low. The description adds genuinely useful behavior: the summary/full payload distinction (implied cost of detail='full'), the 30-day default window, and the 100-result cap. It does not mention auth or rate limits, but those are minor against the annotation coverage.

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

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

Front-loads purpose in the first sentence, then the detail-mode semantics, then the args list — a sensible order with no wasted prose. The Args block is redundant with a 100%-covered schema, which is the only structural inefficiency.

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 explained, and the description covers date defaults, the result cap, filtering, and the summary/full tradeoff. An agent has enough to call it correctly; only explicit sibling routing 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 100%, so the schema already documents all five parameters and the baseline is 3. The description largely restates the same fields and defaults; its only modest addition is enumerating the fields returned under each detail mode, which is not parameter-level syntax the schema lacks.

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 — 'Get completed workout sessions' — and the detail-mode elaboration (name/date/duration/sets) makes the payload scope concrete. It doesn't explicitly name which sibling to use instead (get_workout_detail, get_exercise_history), leaving differentiation to inference from the resource phrase.

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

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

The description implies context through date-range defaults and a workout_name filter, and explains what the detail modes yield, which helps choose a mode. But there is no explicit when-to-use/when-not guidance or naming of alternatives among the many get_* siblings.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing the empty-object edge case when no profile exists, which annotations cannot convey; it stops short of noting any auth or scope requirements.

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

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

Two sentences, purpose first, edge case second — well front-loaded with no filler. The long enumeration of returned fields slightly overlaps the output schema, but it is readable and not wasteful.

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 with an output schema present, the description need not explain return values, and it correctly spends its words on the empty-profile case. It is complete enough to invoke correctly; only sibling differentiation is absent.

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 is the baseline-4 case; there is nothing for the description to disambiguate. The schema is empty by design, so no semantic gap exists.

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 ('Get the user's saved Coach Profile') and enumerates exactly what is returned, so the agent knows what data it yields. It does not, however, differentiate itself from lookalike siblings such as get_user_settings or get_training_maxes, leaving the agent to 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?

There is no guidance on when to reach for this tool versus get_user_settings or get_training_maxes, nor any stated preconditions. The only condition mentioned ('empty object when the user has not set up a profile yet') describes an outcome, not when to use the tool.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the shape of the result (per-session sets, volume, estimated 1RM, heaviest set, trends) and the timezone semantics distinguishing local_date from the UTC date.

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 focused sentences, front-loaded with the purpose, then return content, then the one non-obvious semantic (date vs local_date). No filler, though the timezone sentence is dense and slightly tangential to selecting the tool.

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

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

With a 2-parameter schema at full coverage, a read-only annotation profile, and an output schema, the description covers all that is needed to call and interpret the tool. The only gap is deciding when this tool is preferred over sibling lookups, which is a minor omission.

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% – both exercise_name (exact, case-insensitive, no partial matching) and limit (default 10, max 50) are fully documented in the schema. The description adds no parameter-level detail, 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 verb and resource ('Get performance history for a specific exercise across sessions') and immediately enumerates the returned metrics, which clearly differentiates it from search_exercises and validate_exercise_names. An agent can identify this as the historical-performance lookup 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?

Usage is implied: fetch history for a named exercise that the agent already knows. There is no explicit when-to-use/when-not, no mention of prerequisites such as validating the exercise name first (validate_exercise_names exists as a sibling), and no routing to 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only that names are exact and counts are included, which is output detail rather than behavioral context such as scoping or pagination 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?

A single short sentence that front-loads the verb and resource with zero filler. Every word earns its place.

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

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

With a full output schema present, return values need no explanation, annotations cover safety, and there are no parameters to document. The description is nearly complete; the only minor omission is any hint about folder scope or ordering.

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 and schema description coverage is 100%, so there is nothing for the description to disambiguate. The baseline of 4 applies for a parameterless tool.

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

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

The description states a specific verb ('List') and resource ('the user's workout folders'), and even names the returned fields (exact name and workout count). It is clear enough to distinguish from get_programs, get_workout_templates, and get_workout_detail, though it never explicitly contrasts itself with those 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?

There is no statement of when to call this versus alternatives such as get_programs or get_workout_templates, and no prerequisites or exclusions are given. Usage is only implied by the tool name and the word '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, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds small value by noting the response is the 'complete' article plus a source URL, but no rate limits, pagination, or missing-article behavior are described.

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

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

Two compact sentences with zero filler, and the purpose is front-loaded before the return-value sentence. Every clause earns its place.

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

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

An output schema exists, so return values need not be detailed, and the description still sketches the payload (full instructions plus source URL). For a one-parameter read tool this is nearly complete; only the origin/format of the article ID is left to inference.

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

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

Schema description coverage is 100% for the single article_id parameter, so the baseline is 3. The phrase 'by its identifier' merely restates the schema and adds no format, source, or validity meaning beyond it.

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

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

States a specific verb (Read) and resource (Help Center article/FAQ) scoped to a single item by identifier, which implicitly contrasts with a search tool. It does not explicitly name or differentiate from the sibling search_help_center, so it stops short of a 5.

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

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

Usage is only implied: 'by its identifier' suggests the agent must already have an article ID, typically from search_help_center. There is no explicit statement of when to use this versus search_help_center or any other prerequisite.

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 cover the safety profile (readOnly, idempotent, non-destructive) and openWorldHint=false, so the bar is lower. The description still adds real behavioral detail beyond them: no pagination regardless of week count, how repeated workout_id uses collapse into one item with day labels, and that the same workout_id across weeks denotes reuse of one saved workout.

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 sentences, front-loaded with the core action, and every sentence carries information: scope, no-pagination guarantee, and the grouping/reuse semantics of the returned structure. 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 an output schema present, return-shape explanation is optional yet the description usefully clarifies the compact grouping model. The only real gap is failure behavior for an unknown program_id, which is minor for a read-only single-resource fetch.

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 program_id's type, minLength and 'Stable id of the saved program' meaning are already documented. The description adds nothing about the parameter (e.g., where the id comes from), 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 verb+resource: fetching one saved program's complete plan. The word 'one' and 'complete' implicitly contrasts with the sibling get_programs listing tool, but no sibling is named explicitly, so it stops short of a 5.

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

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

Usage is only implied by the word 'one saved program': an agent infers this is the drill-down after get_programs. There is no explicit when-to-use, when-not, or named alternative such as get_programs or get_workout_detail.

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 the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description is not obligated to restate it. It adds a genuine behavioral guarantee not found in annotations or schema: 'Internal program lifecycle ids are never returned,' plus the enumerated status vocabulary.

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 dense sentence front-loads the scope and then enumerates returned fields; every clause carries information. It is slightly list-heavy and leans on the LiftTrack UI metaphor ('program cards'), which costs a little clarity for no benefit.

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 and annotations covering the safety profile, the description need not explain return values, and it doesn't over-explain. It supplies the status enum and the lifecycle-id exclusion, which is enough for an agent to call and interpret this correctly.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify about inputs, and it correctly doesn't invent any.

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 (user's saved programs) and pins down the altitude: summary level, not detail. That wording implicitly separates it from the sibling get_program_detail, which returns the full record.

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 by 'summary level ... as LiftTrack's program cards' versus the detail-oriented sibling, but there is no explicit when-to-use statement, no condition selecting this tool over get_program_detail, and no mention of prerequisites (e.g. auth or empty-state behavior).

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, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: dates are plain calendar dates exactly as scheduled (no timezone/offset drift), and entries carry an ownership type (one_off, routine, program). That is meaningful semantic disclosure beyond 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 core purpose is in the first sentence, followed by the two pieces of information that actually matter (date semantics, entry types), then the argument. Efficient and front-loaded, though the type enumeration is slightly verbose for a definition that also has 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, the description needn't enumerate return fields, and it correctly focuses on the non-obvious semantics (calendar-date representation, ownership types, look-ahead range). Annotations cover the safety profile, so nothing an agent needs to invoke 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 description coverage is 100%, so the single days_ahead parameter is already fully documented with its default and max. The description's Args block simply restates that text verbatim, adding no syntax or format detail beyond the schema. 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?

Front-loads a specific verb and resource: 'Get upcoming scheduled workouts, starting with today.' The scope (forward-looking calendar, starting today) is unambiguous and separates it from sibling readers like get_workout_detail or get_programs, which return a single workout or program catalogue rather than a dated schedule.

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 comes back but never says when to reach for this instead of get_weekly_training_status, get_workout_detail, or the schedule_workout/unschedule_workout mutators. There are no conditions, prerequisites, or exclusions, so the agent must infer selection 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 declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered by structured data. The description adds only that results are either the full set or filtered, which is useful scope context but not deep behavioral disclosure. Output schema handles return format.

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

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

Two tight sentences front-load the purpose and scope. The Args section duplicates the schema parameter description without adding value, which is mild redundancy, but overall the text is compact.

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 handling return structure and annotations covering the safety profile, the description supplies enough for an agent to invoke this single-parameter read correctly. Only explicit sibling routing 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 100% for the single optional parameter, so the schema already documents it fully. The description's Args block restates the same text and example ('Barbell Back Squat') verbatim, adding no meaning beyond the schema. 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 verb and resource ('Get training max (1RM estimate) values for exercises'), and the parenthetical clarifies what a training max is. It is distinguishable from siblings like get_exercise_history or set_training_max, though it never names them 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 implies usage ('Returns all training maxes, or filter by exercise name') but gives no explicit when-to-use condition, prerequisites, or guidance on choosing between this and set_training_max/get_exercise_history. Adequate but thin.

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, idempotentHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the shape of the returned data (unit preference, rounding), which is modest value beyond what annotations provide.

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 naming the resource first, then the returned fields. No filler, no repetition of the tool name or 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?

An output schema exists so return values need no elaboration, and with zero parameters and full annotation coverage there is little left to document. It is nearly complete; the only missing piece is any hint of when this is the right call versus similar getters.

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 baseline of 4 applies; there are no parameter semantics to explain and the description correctly does not invent any.

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+resource ('Get the user's workout settings') with examples of the returned fields (unit preference lbs/kg, weight rounding). It does not differentiate from potentially overlapping siblings like get_coach_profile, so it stops short of a 5.

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

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

No statement of when to use this versus alternatives, no prerequisites, no exclusions. Usage is only inferable from the name, which is the minimum needed for a zero-parameter getter but still counts as no 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 readOnly/idempotent/non-destructive/openWorld=false, so safety is covered. The description adds non-obvious behavior beyond the annotations: the three-tier timezone precedence (client-reported > argument > UTC) and that the resolved timezone is echoed in week.timezone. No rate limits or pagination notes, but the added context is meaningful.

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 summary contents are front-loaded in the first sentence, followed by behavioral rules and then args. It is well organized with no filler, though the trailing Args block partially duplicates the fully-documented schema, slightly blunting conciseness.

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 documented, and the annotations carry the safety profile. The description still enumerates the returned summary components and resolves the timezone ambiguity that would otherwise trip up an agent. 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?

Schema description coverage is 100%, so the schema already documents both parameters including the same timezone precedence rule. The description's Args block largely restates the schema (Monday format, defaults, precedence) and adds little syntax or meaning the schema doesn't already carry. Baseline 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?

States a specific verb (Get) and resource (weekly training status) and then enumerates exactly what the coaching summary contains: workouts vs goal, days left, set counts, credited sets vs four-week average, and movement patterns. This is far more specific than the sibling get_* tools and lets an agent distinguish 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?

The description clearly establishes the scope (one Monday-Sunday week) and details the argument resolution rules (client timezone > timezone arg > UTC), which is genuine usage context. It stops short of explicitly naming when to prefer this over siblings like get_schedule or get_training_maxes, so it lacks exclusions, but the context is clear.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral detail beyond them: cardinality per lookup mode, folder propagation on name matches, and the empty-array result when nothing matches.

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

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

Three dense sentences, front-loaded with what is returned, then input mode semantics, then the empty-result case. No redundant restatement of the name or 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 and rich annotations, the description only needs to add what structured fields cannot: lookup precedence, result multiplicity, and the no-match case. All three are covered.

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 baseline is 3, but the description adds a precedence rule the schema does not encode: when both id and name are supplied, the id wins if it matches. That is genuine semantic value beyond the field descriptions.

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

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

States a specific verb and resource ('Get the full structured detail of a workout template') and enumerates the contents (names, sets, loads, rest modes, supersets, RPE, percentages), which distinguishes it from get_workout_templates 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?

Gives clear selection guidance between the two input modes ('Takes workout_id or exact workout_name; when both are given, the id is used if it matches'), plus the multi-result implication of a name lookup. It stops short of naming a sibling alternative for listing/searching, so not 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 cover read-only, idempotent, safe behavior. Description adds useful context: returns at most limit, default/max limits, truncation via total_count, and optional folder filtering. Goes beyond structured fields without contradiction.

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 fields, efficiently states limits and filtering. Slightly verbose but every sentence adds information; no wasted words.

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

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

Covers the tool's function, output fields (though output schema exists, so less critical), pagination/truncation behavior, and exclusion of details. Given annotations already handle safety, this is nearly complete; missing only explicit alternative tool guidance.

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

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

Schema coverage is 100%, so baseline is 3. Description repeats limit defaults and folder_name optionality, adding little beyond the schema. No extra syntax or format details.

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?

Clear verb (List) and resource (workout templates) with explicit scope: high-level summary fields. Distinguishes from get_workout_detail by stating it excludes individual exercises and sets, though it doesn't name the sibling directly.

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?

Implies usage for getting a summary list, but doesn't explicitly say when to use this vs get_workout_detail or search. The exclusion note provides some context but no clear when-to-use or alternative routing.

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 cover the safety profile (idempotentHint=true, destructiveHint=false, openWorldHint=false), and the description adds genuinely new behavioral facts: the entry propagates to the Garmin calendar and watch when linked, and duplicates result in no addition but a report of the existing entry. These cross-system side effects go well beyond what annotations declare.

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 action and side effects, then a compact Args block. The Args block partly duplicates the schema descriptions, but the date-range and case-insensitivity details earn their place, so waste is minimal.

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 the description fully covers the mutation's effects, the idempotent duplicate branch, and the constrained parameter ranges. Nothing an agent needs to invoke 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 100%, so the baseline is 3, but the description adds meaning the schema lacks: the date window (today through 30 days ahead) and that workout_name matching is case insensitive. The folder parameter is largely restated from the schema, which keeps this from 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?

States a specific verb and resource ('Schedule a saved workout template on one calendar date') with clear scope, and the duplicate-handling sentence distinguishes it from get_schedule and unschedule_workout siblings. An agent can tell what this does and what it does not do without inspecting 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?

Gives a clear usage condition and describes the no-op branch when the workout is already scheduled by any source. It stops short of explicitly naming alternative tools (e.g., unschedule_workout or get_schedule) or the inverse operation, so it is strong context without full when/when-not routing.

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 idempotentHint=true, covering the safety profile. The description adds useful return-format context ('Returns display name, muscles, and equipment, best matches first, max 20 results'), but this is arguably also covered by the output schema which exists. It does not discuss pagination behavior or how 'best matches' ranking works.

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-loads the core purpose, then adds return info, then parameter descriptions. Reasonably efficient, though the parameter section duplicates the schema and the catalog-membership note could be tighter.

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 annotations (read-only, idempotent) and an output schema, the description covers what an agent needs to select and call the tool correctly. The catalog-membership constraint is valuable context for a workout-building workflow. Minor gap around result ranking or pagination semantics, but overall complete for a search 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%, so all three parameters are already documented in the schema including enum values. The description repeats the parameter purposes without adding syntax, format, or interaction details beyond what the schema provides. Baseline 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?

States a specific verb and resource ('Search the exercise catalog') plus the facets it searches on (name, muscle group, equipment). This distinguishes it from siblings like validate_exercise_names and get_exercise_history, which serve different purposes.

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 clarifies implicit usage context with 'Every exercise in a workout must come from this catalog or the user's custom exercises,' which explains when this tool is relevant (constructing workouts). However, it does not explicitly name an alternative or state when NOT to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds that results are passages with titles and source URLs, but that return-format detail is largely duplicated by the existing 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?

Two tight sentences, purpose front-loaded before the return description, with no filler. Slight demerit because the return-format sentence restates what the output schema already conveys.

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

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

For a two-parameter read-only search with a full output schema and clear annotations, the description supplies enough to invoke correctly. The only missing piece is the explicit boundary with get_help_article, which would make selection unambiguous.

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% — both query and limit are documented in the schema, including the 1–8 cap. The description's phrase 'for instructions, feature explanations, and troubleshooting' hints at query phrasing but adds no syntax, format, or default-value detail beyond what the schema already gives.

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?

Clear verb+resource: 'Search LiftTrack's Help Center articles and FAQs', with the covered content types spelled out (instructions, feature explanations, troubleshooting). It does not, however, distinguish itself from the sibling get_help_article, so an agent must infer the search-vs-fetch split on its own.

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 only implied: the mention of instructions/features/troubleshooting suggests when the tool is useful, but there is no explicit when-to-use statement and no routing to the obvious alternative get_help_article for retrieving a full article by 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 declare destructiveHint and idempotentHint, but the description adds genuinely valuable context beyond them: updating an existing max recalculates the weight of every workout using percentage-of-training-max. That silent side effect is exactly the kind of disclosure an agent needs before mutating.

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 action and definition, then the recalculation caveat, then Args. Efficient, though the Args block duplicates schema descriptions and costs a little space without adding much.

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 and annotations covering the safety profile, the description supplies the one missing piece — the cascading recalculation on update — making the definition complete enough to invoke 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 both parameters are already documented in the schema; the description's Args section largely restates exercise_name and training_max. No additional syntax, format, or constraint detail is added beyond the units note already in 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 a specific verb (set) and resource (training max) and then defines what a training max actually is — the estimated 1RM used for percentage-based loads. This distinguishes it clearly from the read-only sibling get_training_maxes.

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 notes it creates-or-updates (upsert semantics), which is useful implied usage, but it never says when to prefer this over inspecting existing values via get_training_maxes or what prerequisites exist. Usage is inferable rather than 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 destructiveHint=true, idempotentHint=true, readOnlyHint=false, but the description goes further: it explains the external side effect on the user's Garmin calendar, that the template is not modified, that past occurrences are retained, and that a same-named workout may persist with the reason surfaced in still_scheduled_by.

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 removal scope and its main failure mode are front-loaded in the first two sentences, and every following sentence (Garmin side effect, still_scheduled_by, template preservation, arg constraints) carries distinct information with 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 destructive, idempotent mutation with an output schema, the description covers side effects, refusal conditions, retention behavior, and return-field semantics, leaving nothing an agent needs in order 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 100%, so the schema documents all three parameters; the description still adds the 'today or later' validation constraint on date and clarifies name matching is case-insensitive, which the schema does not state. Only mildly exceeds the 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?

States a specific verb+resource (remove a scheduled workout occurrence from one calendar date) plus the scope boundary that separates it from delete_workout: the template itself is untouched. An agent can distinguish it from schedule_workout/delete_workout purely from the text.

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 when-it-works/when-it-fails: only single-date scheduled occurrences can be removed, weekly-routine or program occurrences are refused and must be changed in the app, and the workout_folder_name parameter exists specifically to disambiguate duplicates. Past dates are excluded as training record.

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 declare destructive/idempotent, but the description adds the concrete destructive semantics: 'exercises replaces the entire exercise list' and exercises absent are removed, while omission preserves the list. It also discloses non-obvious side effects — progression links preserved only for exercises keeping their name, folder membership never changes, and notes surface on the watch step description.

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 mutation model and the rename-only shortcut, and every paragraph carries operational content. It is somewhat dense and could compress the exercise-field enumeration, which the schema already documents.

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, 4-parameter mutation tool with nested exercise payloads, the description covers replacement semantics, rename-only path, disambiguation, preserved progression links, and side effects, while deferring field constraints to the schema and return values to the output 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: workout_name must be the exact current name, workout_folder_name is identity-only disambiguation that never moves folders, and exercises is a full-replacement operation rather than a merge.

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 sentence states a specific verb and resource ('Change an existing workout template') and immediately scopes what can be changed (rename via name, full replacement via exercises). An agent can distinguish this from create_workout and delete_workout 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?

It gives clear conditional guidance: omitted fields keep current values, workout_folder_name is only needed for duplicate names, and a rename-only request contains workout_name plus name and omits exercises. It does not name a sibling tool as an alternative, so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavior: case-insensitive exact matching against a catalog plus the user's custom exercises, and suggestion generation (up to 3 close matches) for invalid entries. It does not mention the 50-name cap, which is minor.

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

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

Three tight sentences: what it checks, the input constraint, and the return contract, in that order. Nothing redundant and no preamble.

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 documentation is not required, yet the description still names the key fields (all_valid, invalid names, suggestions). Combined with annotations covering the safety profile and a fully documented single parameter, 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 100% with a single well-documented parameter, so the baseline is 3. The description earns above baseline by clarifying that the strings must be exact display names and that matching is case-insensitive, which the schema description ('Exercise display names to validate') 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?

States a specific verb (validate/check) and resource (exercise names) with explicit scope: existence in the catalog or the user's custom exercises. This cleanly separates it from siblings like search_exercises or get_exercise_history without opening their 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?

Implied usage is clear (pre-flight validation before referencing exercise names), and it notes names must be exact display names. However, it never states when to prefer this over search_exercises, nor any prerequisite such as needing names in hand first, so usage is inferred rather than directed.

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