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

This is the key disclosure the annotations can't convey: the call returns a preview and writes nothing unless apply=true, and apply is only set after user approval — a critical two-phase mutation contract for a non-readonly tool. Gaps remain on failure behavior (unknown exercise or day) and on what the preview contains.

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 parts: a one-sentence purpose with placement rule, then a concrete example, then the preview/apply contract. Front-loaded, zero filler, and the example does real work by showing day/exercise/sets/reps simultaneously.

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

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

For a 7-parameter mutation tool with no output schema and no parameter descriptions, the description covers the essential contract (placement, preview gate, example) and the annotations carry the safety profile. The unexplained `plan` parameter and missing error/conflict guidance (e.g., exercise already present) are the remaining gaps.

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 all meaning, and it does for most parameters: `after` placement semantics, day/exercise values via the worked example, sets/reps, and apply's preview-vs-save meaning. The `plan` parameter (default "") is never mentioned, so the agent can't tell whether it targets a specific plan or the current one.

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

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

The description uses a specific verb and resource: 'Add one exercise to a day of the training plan', and adds placement scope ('at the end or right after the exercise named in `after`'). Its add-only semantics contrast implicitly with swap_plan_exercise and remove_plan_exercise, though no sibling is named explicitly.

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

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

Clear operating context: add a single exercise, choose placement either at the end or after a named exercise, and only save after the user approved the preview. It doesn't explicitly route to siblings (swap_plan_exercise / remove_plan_exercise) for modification or deletion cases, so the boundary is inferred 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 cover read-only, idempotent, open-world and non-destructive behavior, so the bar is lower. The description adds useful non-annotation detail: results are ordered most-recently-done first, and the default result set is limited to exercises the user has performed, including frequency and recency of last performance.

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 lines with no filler, and the core search semantics are front-loaded before the default-behavior caveat. Slightly hurt by the trailing line break and the informal bullet-like second sentence, but size is appropriate.

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 correctly notes the caller gets frequency and last-performed data. However, it omits what an empty query plus only_used=false returns and any result-count or pagination limits — meaningful gaps for a search tool with three undocumented parameters.

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

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

Schema coverage is 0%, so the description has to carry parameter meaning. It does map loosely onto all three ('by name' for query, 'muscle or group' for muscle, 'by default only exercises the user has done' for only_used), but it never states that only_used=false returns the full exercise catalog, nor how name and muscle filters combine, nor expected value formats for muscle.

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 exercises by name and/or muscle group, with examples of muscle values. That clearly separates it from most siblings, though it does not explicitly distinguish itself from get_exercise_history, another exercise-oriented tool in the 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?

The description conveys the default context ('by default only exercises the user has done') but never says when to prefer this over get_exercise_history or what changes if only_used is turned off. Usage is implied by the query semantics 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?

The annotations already confirm that this is a safe, read-only operation, so the description does not add much rich behavioral context. It mainly reinforces the scope of the data being handled.

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

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

The definition is concise, but it suffers from structural vagueness by combining the functional definition with the usage policy into a single sentence, slightly diluting its impact.

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

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

The description is severely lacking in specifying output semantics. Since it is a 'document' getter, the agent needs to know if the return value is raw text, a specific JSON structure, or a stream. Without this, the tool is highly incomplete for effective invocation.

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

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

With 0% schema description coverage, the description provides no extra meaning beyond the required 'doc_id'. Since the input schema is minimal, the baseline score of 3 is appropriate.

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

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

The tool's purpose is clear (retrieving a single document by ID), but the differentiation from siblings is weak. Instead of stating its specific domain, it relies on negative exclusion ('for anything the other tools don't cover'), which is not a strong functional 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?

The definition provides explicit usage guidance by instructing the agent to prioritize other specific tools first. It clearly suggests this tool is a fallback mechanism for non-standard or unique document retrieval.

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), so the bar is lower. The description still adds genuine behavior beyond them: results are ordered newest first, the payload includes a summary plus per-workout rows with specific metrics, and include_sets=true expands to every set including warm-ups. It does not disclose what happens on an ambiguous partial-name match (error vs. best guess) or how limit truncation behaves.

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 return shape, then the parameter notes, then the include_sets flag. Every sentence carries information. The first sentence is dense with metric names but not padded.

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 read-only history tool with no output schema and 5 fully undocumented params needs the description to cover date filtering and result-count limits, and it doesn't — the default limit of 100 and the empty-string date defaults are left for the agent to guess at. It is adequate for the shape of the response, thin on how to scope the query.

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 load. It meaningfully explains `exercise` (name/id/partial matching) and `include_sets` (warm-ups included), which are the two non-obvious parameters. But `limit`, `start_date` and `end_date` get no syntax or behavior treatment — notably the date format and whether an empty date means all-time — so the compensation is only partial.

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

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

States the specific resource (one exercise's history over time) and precisely describes the return shape: a summary plus one row per workout, newest first, with top set, e1RM, working sets and volume. An agent can distinguish it from get_sessions (all sessions) and get_progress. The retrieval verb itself is only implied by the name, but the resource and output are 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?

It gives real guidance on *how* to address the exercise (name, partial name if unambiguous, or id), which is usable context. It never states when to prefer this over siblings like get_progress, find_exercises or get_sessions, nor any prerequisite (e.g. resolve an ambiguous name first). Usage is implied rather than spelled out.

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, open-world behavior, so the safety profile is covered. The description adds genuinely new behavioral detail: the result set is ordered oldest first and includes dates alongside values, which matters for how an agent interprets the output. It says nothing about pagination or result size limits, keeping it below 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?

A single well-formed sentence: resource first, representative fields in parentheses, then the ordering guarantee. Nothing is redundant or padded.

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

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

With an output schema present, return-value detail is not required, and the description supplies the two things the schema cannot: what the resource is and the ordering of results. A brief note on volume or whether all history is returned would round it out, but nothing essential 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 there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies an unfiltered full retrieval rather than hinting at options that don't exist.

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

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

The description names a specific resource (recorded body measurements) and enumerates representative fields (bodyweight, body fat, waist), so an agent can tell it apart from get_progress or get_exercise_history on subject matter. It stops short of explicitly contrasting 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?

Usage is only implied: the wording ('Recorded ... with dates') signals a read of historical measurement records, but there is no statement of when to pick this over get_progress or get_exercise_history, and no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the default scope is the current plan only, which is useful behavioral context. Beyond that it does not disclose ordering, whether history/archived plans are included, or anything an agent couldn't infer from the schema and 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 short lines, zero filler, with the content summary first and the scoping behavior second. Every clause carries information not present in the structured fields.

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 read-only, single-optional-parameter tool with an output schema needs little prose, and the definition covers what the data represents and the default filter. The remaining gap is the unresolved overlap with get_weekly_training, which an agent would have to resolve by guessing.

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, and it does: it states the default (current plan only) and the effect of active_only=false (return all plans), which is exactly the meaning of the single boolean. It stops short of clarifying what 'current plan' means if multiple plans are marked active.

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

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

The description names the resource (training plans) and the shape of what comes back: per-day exercises with muscle groups plus weekly set/rep/RIR targets. That is specific enough to distinguish it from get_sessions, get_progress, and the plan-mutation siblings. It does not, however, explain how it differs from get_weekly_training, which sounds like it could return overlapping data.

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

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

The second sentence is really a parameter explanation ('active_only=false returns all plans') rather than a when-to-use rule. There is no statement of when an agent should reach for this instead of get_weekly_training or get_exercise_history, and no prerequisites or exclusions are given. Usage is implied by the data description rather than spelled out.

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 the read-only/idempotent annotations by disclosing the exact metrics computed per exercise (sessions, working sets per week, e1RM start/end, best e1RM, % change, last date) and the smoothing methodology (median of first and last 3 sessions). It also explains the fallback for unweighted exercises (top-set reps) and the sort order (muscle group), which an agent could not infer from annotations or 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 the core question and default window, then detail. The middle sentence is dense and wraps awkwardly with mid-sentence line breaks, but essentially every clause (metric list, smoothing rule, unweighted fallback, sort order, filter values) carries real 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?

Since an output schema and read-only annotations exist, the description needn't repeat return shapes or safety; instead it usefully documents computation logic that a schema cannot express. The only notable omission is date parameter formatting, which an agent would need to call correctly with non-default dates.

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 0% schema description coverage, the description carries the burden and largely succeeds: it explains min_sessions as a minimum session count, muscle as a filter accepting either a muscle or a group, and start_date/end_date as the range with a 6-month default. It does not specify the expected date string format, leaving one meaningful gap.

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

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

The opening line 'Which exercises are improving or stalled' states a specific analytical question this tool answers, clearly distinct from siblings like get_exercise_history (raw per-exercise history) or get_weekly_training (weekly rollups). It stops short of naming or contrasting those siblings explicitly, so an agent must infer the distinction.

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 operational context: default window is the last 6 months, a min_sessions threshold gates which exercises appear, and filtering works by muscle or coarse group (chest, back, shoulders, arms, legs, core). It does not say when NOT to use it or point to the sibling that returns raw history instead.

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, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description contributes only the scope of what is returned (all sets with their metrics), and says nothing about failure behavior for an invalid session_id. Given the annotation coverage, a 3 is appropriate.

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 compact sentence that front-loads the core concept ('One workout with every set') and then enumerates fields with zero filler. It is a fragment rather than a full sentence, but nothing is wasted.

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 output schema, the description does carry the burden of describing return values, and it does so adequately by listing the per-set fields. However, it leaves the required input parameter entirely unexplained, which is a meaningful gap for a tool the agent must call with an ID.

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 single required parameter session_id has no description in either the schema or the description. The description does not state the ID format or where to obtain a valid session_id, so it fails to compensate for the coverage gap.

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

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

The phrase 'One workout with every set' plus the enumerated fields (weight, unit, reps, RIR, duration, notes, targets) makes clear this retrieves a single session with set-level detail. The singular 'One workout' implicitly distinguishes it from the sibling get_sessions, though it never names that alternative 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?

There is no statement of when to use this tool versus get_sessions or get_exercise_history, and no mention that it requires a session_id obtained elsewhere. The agent must infer the retrieval context from the noun phrase 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 readOnly/idempotent/non-destructive, and the description adds genuine context beyond them: a 5-minute cache with a refresh=true override, newest-first ordering, and clarifying that 'mobility' entries are not counted as training. It omits pagination/limit behavior and what happens when the date range is empty.

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 in one line, then uses a tight second block for field contents and a third for edge cases (skipped, mobility) and operational traits (dates, cache). Dense but every sentence carries information an agent can act on.

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

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

An output schema exists, yet the description still usefully orients the agent to the shape of each workout summary. With four optional params and no required ones, the definition is nearly complete; only the meaning/effect of 'limit' is left unexplained.

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 load and does: refresh is explained as a cache reload, start_date/end_date are given a concrete YYYY-MM-DD format and inclusive semantics. Only 'limit' (default 20) is left entirely undocumented, a minor gap against three well-covered parameters.

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

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

The opening line names a specific resource (performed workouts/sessions) and its form (compact summaries, newest first), which lets an agent distinguish it from the single-record sibling get_session. It stops short of naming a sibling explicitly, so the differentiation is inferred from 'summaries'.

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?

Implicit usage: fetch a list of past workouts, optionally bounded by start_date/end_date, with a caching caveat and a refresh escape hatch. There is no explicit guidance on when to prefer this over get_session, get_weekly_training, or get_exercise_history, so the agent must infer the boundary.

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 safety (readOnly, idempotent, non-destructive), and the description adds meaningful aggregation semantics: fractional working sets counted 1 for the target muscle and 0.5 for main secondary muscles, frequency as days trained, and the rule that workout-free weeks are dropped from the average unless skip_empty_weeks=false. These are non-obvious behavioral traits not derivable from 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 purpose, then a scoped paragraph on per-week output, then the average and empty-week caveat, then filtering. Every sentence conveys distinct information an agent needs; nothing is redundant.

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

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

No output schema exists, and the description compensates by describing the returned fields and the `average_per_week` payload. The only real gap is date-parameter format and edge behavior for the start/end window.

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 all four parameters. It explains `muscle` well (example plus group enumeration) and fully defines `skip_empty_weeks`, but start_date and end_date are only implied by the 8-week default — no format, inclusivity, or empty-string meaning is given, so two of four parameters remain under-specified.

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 (weekly training load) and enumerates exactly what a week row contains: workouts, minutes, working sets, per-muscle fractional sets and frequency. It does not name a sibling such as get_progress or get_sessions to disambiguate, 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?

Gives concrete operating context: default window is the last 8 weeks, and filtering is by `muscle` or a listed group. However, there is no statement of when to prefer this over get_progress, get_sessions, or get_exercise_history, leaving tool selection to inference.

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

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

Adds real context beyond the annotations: it discloses that historical workouts retain the exercise ('Past workouts with it stay in the history') and that the write is gated behind a preview/apply confirmation gate, which tempers the destructiveHint=false and idempotentHint=false flags. It does not describe what the preview contains or what happens on a failed match of day/exercise.

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 statement of the operation, then a concrete example, then the critical preview/apply caveat. Every sentence carries information and nothing is repeated from 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 4-parameter mutation with full annotation coverage and no output schema, the description supplies the essential missing pieces: the persistence guarantee, the preview-then-apply workflow, and a worked example. The only residual gap is the ambiguous `plan` default, which is minor.

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. The example clarifies the meaning and format of day and exercise, and the apply gate is explained. But the `plan` parameter, with an empty-string default that presumably means 'the active plan', is entirely undocumented in both schema and description.

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

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

States a specific verb+resource+scope: 'Take one exercise off a day of the training plan.' An agent can distinguish this from add_plan_exercise and swap_plan_exercise by the verb alone, though the description never names those siblings explicitly.

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

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

Clearly spells out the two-step usage pattern: it returns a preview, and nothing is persisted unless apply=true, and only after user approval. Missing an explicit statement about when to prefer this over swap_plan_exercise (remove+add in one step) for exercises that need replacing.

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?

Given annotations only declare the generic write/openWorld profile, the description adds the crucial safety detail that nothing is persisted unless apply=true and that approval must precede it. It does not state what happens when sets or reps are omitted (leave-unchanged vs clear) or how failures for unknown exercises/days are reported.

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?

Short, front-loaded with the core action, then example, then the preview/apply rule — no filler sentences. Formatting is slightly awkward but every sentence earns its place.

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

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

No output schema, so the description must convey return behavior; it does say a preview is returned, which is the key fact. But a six-parameter mutation tool with zero schema descriptions still leaves `plan` and null-semantics for sets/reps unexplained.

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 0% schema description coverage, the description must carry all parameter meaning; it explains day, exercise, sets, reps, and apply well. The `plan` parameter is never mentioned, and the 'and/or' phrasing leaves ambiguous whether passing null for sets or reps clears or preserves the existing target.

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 (change) and specific targets (sets and/or reps) scoped to one exercise in the training plan, which separates it from the add/swap/remove_plan_exercise siblings. It does not explicitly name those siblings, so the differentiation is inferable rather than stated.

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

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

Provides a concrete example and clarifies the `day` format (name or number), plus a clear two-step workflow: call to get a preview, then re-call with apply=true only after user approval. No explicit when-not-to-use or named alternative tool, however.

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 it's a non-readonly, open-world, non-idempotent, non-destructive mutation. The description adds critical context beyond that: it returns a preview and saves nothing unless apply=true, and only after user approval. This two-phase safety behavior is exactly the kind of context annotations can't 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 core behavior is front-loaded in the first sentence, followed by a compact example and a single-sentence save-semantics note. Zero wasted text.

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

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

For a 7-param mutation tool with no output schema, the preview/apply contract is well covered. The main gap is the unexplained 'plan' parameter, but the critical behavioral and safety information an agent needs is present.

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 0% schema coverage, the description carries the burden. It explains apply (preview vs save) and sets/reps (override behavior) well, but leaves day, plan, exercise, and new_exercise to inference from their names, and the 'plan' parameter is entirely unaddressed.

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 ('Replace') and resource ('one exercise on a day of the training plan with another') with the target-preservation behavior included. It is clearly distinguishable from siblings like add_plan_exercise and remove_plan_exercise, and the example makes the operation concrete.

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?

Explains the when: sets/reps override targets otherwise preserved, and lays out the preview-then-apply workflow with the condition that apply=true only follows user approval. It doesn't explicitly rule out add/remove siblings but the replacement semantics make the boundary clear.

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