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

No annotations exist, so the description carries the full burden. It does disclose real behavior beyond the signature — that each exercise becomes its own block and that the call returns ids consumed downstream — but it says nothing about ordering, duplicate/invalid exercise handling, or side effects on an already-populated session.

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 with no filler, and the core action plus its block-per-exercise behavior is front-loaded. The second sentence is a slightly telegraphic fragment but still earns its place by flagging the downstream dependency.

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

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

An output schema exists, so return values need not be described, and the description correctly points at consumers of those ids. It remains incomplete on the workout_id semantics and on how the tool relates to add_to_block, both of which an agent needs to choose correctly among 29 siblings.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It clarifies that exercise_ids are 'library' exercises and that the result feeds set_prescription/update_block, but never explains that workout_id is the personal session identifier, leaving the primary key ambiguous.

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 ('Append library exercises to a personal session') and adds a distinguishing structural detail: each exercise goes into its own block. That implicitly separates it from add_to_block, but the sibling is never named, so the split still requires inference.

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 the phrasing 'append to a personal session', and the mention of set_prescription/update_block hints at a workflow sequence. There is no explicit when-to-use vs add_to_block, no prerequisites, and no statement about what to do if the exercise already exists.

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

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

With no annotations at all, the description carries the full burden, and it does disclose one non-obvious behavioral fact: the block is mutated into a superset, and prescriptions must be set separately. It says nothing about permissions/auth, duplicate-exercise handling, or whether the append is idempotent, which matter for a write operation with zero 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?

Two short sentences with the primary action front-loaded and the follow-up instruction second; nothing is padded. The trailing "turning it into a superset" phrasing is slightly ambiguous about whether that is automatic behavior or a semantic label, costing a point.

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, but the tool is a 4-parameter mutation with no annotations and 0% schema coverage. The description leaves the identity/role of program_workout_id and team_id and the ordering constraints between block and workout entirely undocumented, which is not enough for an agent to call it confidently.

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% across 4 parameters, so the description must compensate and it largely does not. It hints that exercise_ids are library exercise identifiers and that block_id must be existing, but program_workout_id and the optional team_id are never mentioned, leaving their roles and required relationships unexplained.

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 ("Append library exercises to an existing block") plus the resulting state change ("turning it into a superset"). It does not distinguish itself from the sibling add_exercises, so an agent cannot tell from the description alone which of the two is the right append tool.

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

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

Explicitly describes the required follow-up step: targets must be set afterward with set_prescription, naming the sibling to call. That is real workflow guidance. It stops short of a 5 because it never states when to prefer this over add_exercises or what preconditions (e.g. block must already exist in the given workout) apply.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses what is copied versus not copied (blocks, supersets, sets/reps/weights, cues, notes; logged results excluded) and explains the personal-session logging nuance, but it omits permissions, target-date conflict/overwrite behavior, and the actual response shape.

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

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

The first sentence front-loads the core action, and later sentences add copy-specific behavior rather than filler. It is slightly verbose but every sentence contributes useful context.

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

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

This is a mutation tool with no annotations, no output schema, and 0% parameter coverage. The description covers copy semantics but leaves out target overwrite/merge behavior, optional parameters, authorization needs, and return-value details, so important invocation context is missing.

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

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

Schema description coverage is 0% for four parameters. The description only implicitly maps 'session's plan' to program_workout_id and 'another date' to to_date; optional title and team_id are never explained, nor are formats or constraints.

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 gives a specific verb, resource, and target: 'Copy a session's plan to another date.' It clearly implies duplication rather than creation, but never names siblings like move_workout or create_session, so sibling differentiation is left implicit.

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 provides some applicable context: coach sessions work if visible, and logged personal sessions copy values typed during logging. However, it does not explicitly say when to use copy_workout instead of move_workout, create_session, or create_workout, nor does it state exclusions.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It discloses that the session is 'empty' and 'personal', but says nothing about permissions, side effects, whether duplicate sessions can exist on the same date, or what the response 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?

The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for the stated content, though that content is sparse.

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 mutation tool with three parameters, no annotations, no output schema, and 0% schema description coverage, the description is too thin. It leaves the meanings of title and instruction unexplained and provides no behavioral context beyond the date format.

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 should compensate for all three parameters. It documents the required date parameter with a useful format ('YYYY-MM-DD') but completely omits the optional title and instruction 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 description states a specific verb and resource ('Create ... session') and adds meaningful scope details: it is an empty, personal session on a date. It does not explicitly distinguish this from sibling tools like create_workout or update_session, so it falls short of a 5.

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

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

The description implies the tool is used to create an empty session but gives no guidance on when to use it versus create_workout or update_session. There are no exclusions, prerequisites, or alternative-routing instructions.

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

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

With zero annotations, the description carries the full load and does disclose non-obvious behavior: exercises are placed in the given order, items sharing a `superset` label are collapsed into one block, and a failed step triggers rollback of the half-built session. That atomicity guarantee is genuinely valuable and not derivable from the schema. It omits what the call returns (e.g. a new session id needed for follow-up tools) and any duplicate-date or permission semantics.

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, then three short sentences that each add a distinct rule (ordering, superset grouping, rollback). No filler and no repetition of schema content.

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 mutation tool with no annotations and no output schema, the description covers construction semantics and failure behavior well, but leaves open the return value, the date format, and whether an existing session on that date conflicts. An agent could call it correctly but would be guessing about the response and about downstream id handling.

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?

Top-level schema description coverage is 0% (date, title, exercises, and instruction are undocumented), though nested $defs do describe superset, block_title, and exercise_id. The description compensates partially by explaining superset grouping and characterizing exercise fields as 'prescription and cue', but it says nothing about the expected `date` format or what `title` means in context.

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 — creating a complete workout in one call, with exercises placed into ordered blocks — which is concrete enough for an agent to understand the operation. However, the wording 'personal session' collides with the sibling tool create_session, and the description never clarifies the difference, leaving a real disambiguation risk.

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

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

The phrase 'in one call' implicitly contrasts this with the incremental path (create_session + add_exercises + set_prescription), which is useful signal. But there is no explicit when-to-use/when-not guidance and no mention of prerequisites such as needing existing exercise ids from search_exercises.

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

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

No annotations are provided, so the description carries the full behavioral burden for a destructive operation. It says 'delete' but does not disclose whether deletion is permanent, whether associated exercises or blocks are also removed, what permissions are required, or what the response 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?

The description is a single front-loaded sentence with no filler. It is appropriately concise, even though it omits important details that belong under other dimensions.

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 mutation tool with no annotations, no output schema, and an undocumented parameter, this description is insufficient. It should at minimum clarify the ID's meaning and the consequences of deletion.

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

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

The schema has one required parameter with 0% description coverage, and the description does not mention program_workout_id at all. It is unclear whether this ID refers to a session, a workout, or a program workout, or where an agent should obtain 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?

The description states a specific verb and resource: deleting a session from the calendar. This distinguishes it from create_session and update_session, though it does not explicitly name or contrast 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 explicit guidance on when to use delete_session versus update_session or other removal-related siblings. The purpose implies deletion, but the description provides no conditions, prerequisites, or 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?

No annotations are provided, so the description carries the burden; the verb 'get' and 'entry' strongly signal a read-only lookup, and it discloses the returned facets (notes, video, tracked params). It says nothing about behavior on a missing/invalid id, id format, or response shape, which is the minimum-viable-but-incomplete level.

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

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

One compact sentence, front-loaded with the resource and followed by a colon-delimited list of return contents; nothing is wasted. It is terse to the point of being fragmentary, but the structure is efficient.

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 and no annotations, the description partially compensates by listing return contents and by the 'library' qualifier that distinguishes it from set-level siblings. It still leaves the id semantics and error behavior unaddressed for a tool whose only input is that 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 parameter exercise_id has no description, so the description should compensate — but it never mentions the id or its format. 'For one exercise' only weakly implies a single exercise identifier, leaving ambiguity with the set-level id used by get_set_exercise.

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 concrete resource and scope: 'Full library entry for one exercise,' and enumerates what the entry contains (technique notes, video, tracked params). The word 'library' implicitly separates it from get_set_exercise and get_exercise_stats, 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?

There is no when-to-use guidance, no condition selecting this over search_exercises (find an id) or get_exercise_stats (performance data). The agent must infer usage purely from the title and name.

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

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

No annotations are provided, so the description carries the full burden and discloses essentially nothing behavioral: no confirmation that it is read-only, no indication of what happens when the exercise has no history, no auth requirements, and no sense of the result shape (one record? per-set entries?). The 'get' prefix implies a safe read but that is inference, not disclosure.

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

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

It is a single sentence fragment with no padding, which is efficient. However, being a bare noun phrase rather than a front-loaded statement of action and scope means it is under-specified rather than genuinely concise.

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 annotations, no output schema, and an undocumented optional date parameter, the description should do considerably more. It tells the agent roughly what comes back but nothing about how to call it correctly when on_date is supplied.

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 both parameters are undocumented in structured form. The phrase 'for an exercise' weakly implies exercise_id, but the optional on_date is entirely unexplained — its format, timezone, and whether it shifts the 'last performance' window or filters all three stats are unknowable from the definition.

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 fragment names the returned data ('last performance, personal record and working max') and the scoping resource ('for an exercise'), so the content is identifiable. But it has no verb and never distinguishes itself from siblings get_personal_records and get_working_max, which appear to return overlapping data, leaving an agent unsure whether this tool aggregates them or duplicates them.

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 versus get_personal_records or get_working_max, no mention of prerequisites (does the exercise need logged history?), and no exclusions. Usage is only inferable from the tool name.

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

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

With no annotations, the description carries the full behavioral burden: it implies a read but never says so explicitly, and gives no information about scope (all-time vs. recent), whether a record includes the date or session that set it, or what happens when no records exist. "By rep count" is the only hint at result shape.

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

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

One short, front-loaded sentence with zero filler. It is efficient, though the terseness borders on under-specification rather than true concision.

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 annotations and no output schema, so the description is the only source of behavioral and result-shape information — and it supplies almost none beyond the topic. For a stats-style lookup competing with several similar siblings, this is thin.

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

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

Schema coverage is 0% for the single required parameter, so the description must compensate. It only implies that exercise_id identifies "an exercise" — it does not say whether this is a library exercise ID (as used by get_exercise/search_exercises) or a session-scoped one, nor the ID format.

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 verb and resource ("Personal records") scoped "for an exercise by rep count", which is concrete enough to know what comes back. However, it does not differentiate from nearby siblings such as get_exercise_stats or get_working_max, which plausibly return overlapping strength 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?

There is no statement of when to use this versus get_exercise_stats, get_working_max, or get_workout_history. The agent must guess from names alone which of several strength-related reads to pick.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about read-only semantics, authentication requirements, or whether the coach-team list can be empty. It only describes returned content, not 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?

It is a single short clause with no padding, but it is a sentence fragment rather than a front-loaded action statement, and its brevity comes at the cost of specification rather than from tight editing.

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 and no annotations, the description partially compensates by enumerating the returned fields. However, it omits who the profile belongs to, the read-only nature, and any auth/permission context, leaving gaps an agent would need to discover by calling.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly implies the target is implicit (the authenticated athlete) rather than passed in.

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's returned fields (athlete id, name, coach teams), which tells the agent this is a profile read, but it never uses a verb and never states explicitly that it returns the calling athlete's own profile. Sibling tools are all workout/session oriented, so confusion is unlikely, but the purpose is inferred 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?

There is no guidance on when to call this versus other getters (get_workout, get_exercise_stats, get_personal_records), and no mention of prerequisites such as being authenticated as an athlete. The agent must guess the trigger condition.

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

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

With no annotations, the description carries the full burden, yet it discloses nothing beyond the implied read. It doesn't define the recency window, the ordering, how many circuits are returned, or whether results are scoped to the authenticated athlete.

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

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

A single front-loaded sentence with no filler, which is appropriately sized for a no-argument tool. It is terse to the point of being under-specified, but nothing in it 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 parameters, no output schema, and no annotations, the description is the only source of behavioral detail and it supplies almost none. An agent still cannot tell what the response looks like or what 'recent' means.

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; the baseline of 4 applies. The description does not need to compensate for any schema gap here.

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

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

The description names the resource (circuits) and the qualifier (used recently), so an agent can infer it returns recently used circuits. However, it never differentiates from the sibling search_circuits and leaves 'recently' undefined, so the purpose is only loosely bounded.

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 rather than search_circuits or get_recent_exercises. The agent must guess whether this is a shortcut for recent activity or a full search.

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

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

No annotations are provided, so the description carries the full behavioral burden and it does not deliver: no mention of the recency window, ordering, deduplication, result limits, or whether it is scoped to the authenticated athlete. For a read tool with zero annotation coverage, this leaves the agent guessing at output shape and scope.

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

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

A single short sentence with no filler, and the key qualifier ('recently') is front-loaded. It is efficient but so terse that it borders on under-specification rather than disciplined 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?

Low complexity and no parameters lower the bar, but with no output schema and no annotations, the description is the only source of truth and it leaves 'recently' undefined and the return contents unstated. An agent cannot predict what it will get back.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for no-param tools applies. No parameter-level information is expected or missing.

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 the resource (exercises) and a scope qualifier (used recently by the athlete), which hints at a read of recent activity. However, it doesn't say how 'recent' is defined or how this differs from sibling tools like search_exercises or get_workout_history, so an agent cannot cleanly separate it from those alternatives.

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

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

There is no guidance on when to call this versus search_exercises, get_exercise, or get_workout_history. The agent must infer that this is the 'what did I just do' lookup rather than an explicit routing instruction.

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

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

No annotations are provided, so the description bears the full behavioral burden, but it only implies a read operation without confirming read-only safety, permissions, or whether the two required IDs must belong to the same session. Team scoping via team_id and any error behavior are also undisclosed.

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 single sentence is front-loaded and contains no filler, but it is under-specified rather than appropriately concise for a tool with three parameters and no 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 no annotations, no output schema, and 0% parameter description coverage, the description is too thin for the tool's complexity. It does not explain required ID relationships, team scoping, or what prescribed versus logged values mean in the response.

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

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

Schema description coverage is 0%, so the description must compensate for three undocumented parameters. It only vaguely gestures at 'one exercise of a session' and 'per-set' values, leaving the roles of program_workout_id, workout_set_exercise_id, and especially team_id unexplained.

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

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

The description identifies the returned content as 'per-set prescribed and logged values' scoped to 'one exercise of a session,' which gives some sense of the resource. However, it is a noun fragment with no verb, so it never explicitly says it retrieves data, and it does not distinguish itself from siblings like get_workout or get_exercise.

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

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

There is no guidance on when to call this tool versus get_workout, get_exercise, or get_workout_history. The agent must infer usage entirely from the name and the vague scope phrase.

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

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

No annotations are provided, so the description carries the full burden, yet it says nothing about read-only behavior, permissions, calculation method, recency of the value, or the response shape. An agent cannot tell whether this is a cheap cached read or an expensive computation.

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 a single short fragment with no wasted words, but its brevity is under-specification rather than economy; there is nothing to structure or prioritize.

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 annotations, no output schema, and an undocumented required parameter, the description does not come close to supplying what an agent needs to call this correctly or interpret the result.

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

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

Schema coverage is 0% and the only parameter, exercise_id, has no description. The phrase 'for an exercise' weakly implies that the integer identifies the exercise, but nothing explains the ID's source or format, nor what happens with an invalid ID.

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 'Current working max for an exercise' essentially restates the tool name get_working_max with one clarifying noun. It identifies the resource but gives no verb, no sense of what 'working max' means computationally, and no distinction from siblings like get_personal_records or get_exercise_stats.

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

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

There is no guidance on when to use this tool versus get_personal_records, get_exercise_stats, or get_exercise, all of which could plausibly surface similar numbers. Neither conditions nor exclusions are 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?

With no annotations at all, the description carries the full behavioral burden. It does disclose one useful trait — team scoping is resolved automatically — but says nothing about read-only semantics, behavior when the id is missing or inaccessible, permissions, or size/volume of the returned payload for a deeply nested session object.

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

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

Two short sentences with no filler, and the content overview comes first. The opening noun fragment ('One session: ...') is terse to the point of being cryptic, 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?

The absence of an output schema means the description must convey return shape, and it does list the main sections of a session. But for a deeply nested read tool with no annotations, it omits error behavior, whether the nesting is fully populated, and any indication of payload size.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It meaningfully clarifies team_id (optional, auto-resolved, safe to omit) but says nothing about program_workout_id beyond its name, leaving the single required parameter's source and format unexplained.

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

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

The description enumerates the payload of a single session (title, notes, blocks, exercises with prescription, results and video), which implies retrieval. However, it is written as a noun fragment with no verb and never distinguishes this tool from look-alike siblings such as get_workout_history or get_set_exercise, so the agent must infer that this fetches one full workout by id.

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

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

The only guidance is about a parameter ('team_id is optional; the right team is found automatically'), not about when to choose this tool over alternatives. There is no when-to-use, when-not-to-use, or named alternative, even though the sibling list contains several overlapping read tools.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about permissions, whether the data is paginated or ordered, or whether an empty thread returns an error. For a read tool without safety hints, that leaves the agent guessing about response shape and access 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?

The single short clause is front-loaded and free of padding, which is good, but at this length it becomes under-specification rather than conciseness. There is room to add one sentence of usage or parameter context without bloat.

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 annotations, no output schema, and zero schema description coverage, the description is the only source of behavioral and parameter information, and it supplies neither. An agent cannot determine the return format, ordering, or the meaning of team_id from this definition.

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

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

Schema description coverage is 0% and the description names neither parameter. It never explains that program_workout_id identifies the session or clarifies the role of the optional team_id, so the agent must rely entirely on bare parameter names.

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 'Comment thread of a session (coach and athlete messages)' identifies the resource returned and hints at the content, but no verb clarifies whether it fetches, creates, or deletes comments. It is distinguishable from most siblings because no other tool mentions comments, yet the intended action must be inferred from the name alone.

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

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

There is no statement of when to call this tool versus alternatives, nor any prerequisites or context about the workout/session lifecycle. The agent receives no guidance on situations that require the comment thread instead of, for example, get_workout or get_workout_surveys.

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

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

No annotations exist, so the description carries the full load and does so reasonably: it discloses order (oldest first), inclusive date boundaries, the default window, future-date behavior for planned blocks, and that rows carry ids for chaining. It omits whether results are capped or paginated, which matters for a history query, but the core behavioral profile is present.

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?

Four dense sentences, zero filler, front-loaded with the core operation. Even the trailing line about ids is actionable because it tells the agent how to chain to sibling tools.

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 explanation, and the read-only nature is self-evident. Still missing is how the date parameters interact with days_back and whether results are bounded — gaps an agent would hit on a first call.

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 compensate, and it does partially: it fixes the YYYY-MM-DD format, inclusivity, and the days_back default meaning. It does not explain precedence when start_date/end_date are supplied alongside days_back, or whether one date alone is valid — the key ambiguity for a 3-param 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?

States a specific verb+resource: sessions scheduled between two dates, returned oldest first. It is clearly distinct from the singular get_workout and from get_recent_exercises, though it never names a sibling explicitly. An agent knows exactly what data comes back.

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?

Offers useful context — 'defaults to the last days_back days' and 'future dates work too, which is how to review a planned block' — and hints that returned ids feed other tools. However, it never names an alternative tool or states when to use get_workout instead of get_workout_history; usage is implied rather than prescribed.

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

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

With no annotations, the description carries the full behavioral burden, yet it discloses none of it: no read-only confirmation, no statement of what the leaderboard ranks (volume, reps, completion), no ordering, no pagination or team-scoping behavior. Only the word "team" hints at scope.

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

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

It is short and front-loaded with zero filler, but it is a sentence fragment that omits the essentials rather than being genuinely concise. Brevity here is under-specification, not efficiency.

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 single untyped-in-practice parameter, no annotations, and no output schema mean the description is the only source of meaning, and it supplies almost none. An agent cannot determine what the response contains or how to interpret the ranking.

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

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

Schema description coverage is 0% for the single required parameter program_workout_id, and the description does not compensate — it speaks of a "session" while the parameter is a program workout ID, leaving the mapping between the two terms unclear.

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?

"Team leaderboard for a session" restates the tool name with two added nouns ("team", "session") but names no verb and no resource relationship beyond the title. It does not say whether this retrieves rankings, scores, or points, so an agent still can't tell precisely what comes back.

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

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

There is no guidance on when to call this versus siblings such as get_workout, get_workout_history, or get_personal_records. No prerequisites, no exclusions, no alternatives are mentioned.

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

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

With no annotations, the description carries the full burden; it does disclose the response scale (1 worst to 5 best), which is genuine behavioral context an agent could not infer from structured fields. However, it says nothing about missing surveys, behavior for unknown/invalid workout IDs, or whether results are ordered or one-per-workout, which matter for a batch-read tool.

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

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

Two short sentences, front-loaded with what is returned, with no filler. The scale sentence earns its place because it is necessary to interpret the values.

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

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

For a single-parameter read with no output schema and no annotations, the description covers what the payload contains and how to read the numbers, which is the core need. It is still missing the input-side contract (list of workout IDs, error/omission behavior), which an agent needs to invoke it correctly.

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

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

Schema description coverage is 0% and the single parameter (saved_workout_ids) is completely undocumented in the schema. The description says answers are 'for saved workouts' but never states that the parameter is a list of integer IDs, whether an unmatched ID errors or is skipped, or whether results are keyed back to those IDs.

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 (readiness survey answers) and enumerates exactly which data points are returned (sleep, mood, energy, stress, soreness), so an agent knows what it gets. It does not explicitly distinguish itself from the sibling write path (submit_survey), leaving that differentiation implicit.

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

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

The phrase 'for saved workouts' hints at the input scope, but there is no statement of when to call this versus related siblings like get_workout, get_workout_history, or submit_survey. No preconditions, no exclusions, and no named 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?

With no annotations, the description carries the full burden and discloses the important non-obvious trait: the operation is really copy-then-delete, so the session is destroyed and recreated with new ids. It omits what the response returns (presumably the new id) and any permission/auth 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, front-loaded with the eligibility rule, followed by the mechanism that justifies the rule. No waste.

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

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

The key behavioral risk (identity change, destructive copy/delete) is covered, but for a mutation with no annotations, no output schema and 0% parameter coverage, the description leaves the return value and the `team_id` parameter 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 must compensate for all three parameters. It explains `to_date` and implies `program_workout_id` is the session being moved, but `team_id` is never mentioned and no formats are given for the date.

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

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

States a specific verb+resource ('Reschedule a personal session') and scopes it to sessions with no logged results, which separates it from update_session/delete_session. It never names those siblings explicitly, so differentiation is inferential 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?

Gives a clear eligibility precondition ('has no logged results yet'), which tells the agent when this tool applies and implicitly when it does not. It stops short of pointing at the alternative (update_session) for sessions that already have results.

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

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

No annotations are provided, so the description carries the full burden. It conveys the destructive cascade (all exercises are removed with the block) but says nothing about permissions, reversibility, whether the session must exist, or what happens to an emptied session.

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 that communicates the action and scope with no filler. It is efficient, though the brevity contributes to gaps covered in other dimensions.

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 an unannotated destructive mutation with no output schema, the description omits too much: return value, failure behavior for a missing block_id, permissions, and confirmation expectations. The cascade note is helpful but insufficient on its own.

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

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

Schema coverage is 0% and the description never mentions block_id, how to obtain it, or whether it is a session-scoped identifier. The parameter name is self-descriptive, but the description adds no meaning beyond the schema's type declaration.

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

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

The description names a specific verb and resource ('Remove a whole block') and clarifies scope with the parenthetical '(all its exercises) from a session', which distinguishes it from remove_exercise. It stops short of explicitly naming that sibling, so a 4 rather than a 5.

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

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

The parenthetical scope implies when this tool is appropriate (removing an entire block rather than a single exercise), but the description never states alternatives, prerequisites, or when not to use it. Usage is inferable but not 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?

With no annotations, the description carries the full behavioral burden and does disclose a meaningful side effect: an emptied block is also removed. However, it omits permissions/auth requirements, irreversibility, response behavior, and what happens to the remaining exercises in the session. This is useful partial transparency, not complete disclosure.

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

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

The definition is a single tight sentence with no filler. The core action is front-loaded, and the cascade caveat is included only because it materially affects behavior.

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 mutation tool with no annotations, no output schema, and zero schema description coverage, the description is too thin. It covers purpose and the empty-block cascade but leaves parameter meanings, authorization context, and return/error behavior unspecified.

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% across three parameters, so the schema provides bare names and types only. The description does not explain program_workout_id, workout_set_exercise_id, or team_id, nor how they relate to the session/exercise removal. It adds almost no parameter meaning beyond the schema.

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

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

The description states a specific verb and resource: removing one exercise from a session. It also clarifies the cascade scope, making it distinguishable from remove_block or delete_session by the exercise-level resource. It does not explicitly name alternatives, which keeps it from a 5.

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

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

The description explains what the tool does but gives no guidance on when to use it versus remove_block, delete_session, or update_session. It lacks prerequisites, exclusions, or any when-not conditions.

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

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

With no annotations, the description carries the full disclosure burden. It does clarify the scope boundary against the app, but it does not say whether the call overwrites previously saved feedback, whether it is idempotent, whether athlete/team context is required, or what happens on failure — all material for a write tool.

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

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

Two tight sentences, with the affirmative scope stated first and the exclusion second. No filler, though the stray line break and the slightly awkward 'that is done in the TrainHeroic app' clause cost it a point.

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 5-parameter mutation tool with no annotations and no output schema, the description covers intent and scope but not the mechanics: two parameters are undocumented, the RPE/rating distinction is unaddressed, and the return behavior after saving is unstated.

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% across 5 parameters, so the description must compensate. It names three of them (notes, RPE, rating) but leaves team_id and the required program_workout_id completely unexplained, and — most importantly — never clarifies how RPE (integer 1-10) differs from rating (number 0-10), which is the one ambiguity an agent would most likely get wrong.

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

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

Uses a concrete verb ('Save') with a specific resource ('the athlete's session notes, RPE and rating'), and immediately bounds the scope by excluding per-set logging and session completion. It doesn't name any sibling tool, so the differentiation is by exclusion rather than by comparison, which keeps it just short of a 5.

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

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

The description says what this tool is NOT for ('does not log per-set results or mark the session completed; that is done in the TrainHeroic app'), which is a genuine exclusion. But it never states the positive trigger condition (e.g., 'after finishing a workout') or points to any sibling such as submit_survey or get_workout_surveys, so the agent must infer when to call 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?

The verb 'Find' implies a read-only search, and the description adds library scope and name-based matching. However, with no annotations, it does not disclose pagination behavior, empty-query behavior, or permission/rate-limit context.

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

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

A single front-loaded sentence with no wasted words. It clearly identifies the resource and search dimension.

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

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

The output schema reduces the need to explain return values, but the description is still incomplete for a two-parameter search tool with no annotations and 0% parameter coverage. It leaves key invocation details about query and limit undocumented.

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

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

Schema description coverage is 0%, so the description must compensate. It only implies that 'query' is a name search term and says nothing about the 'limit' parameter or its default of 20.

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: find circuits, clarified as predefined exercise groups in the library by name. It is clear enough to distinguish from get_recent_circuits and search_exercises, but it does not explicitly name siblings or exclusions.

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 when searching circuits by name, but it gives no explicit when-to-use guidance, prerequisites, or alternatives. Agents must infer that get_recent_circuits is for recent items rather than name search.

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

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

With no annotations, the description carries the burden well: it discloses a 24h cache with a refresh override and states the return fields (id, title, tracking scheme, video link). It does not cover auth requirements, rate limits, or what happens on no matches, which keeps it from a 5.

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

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

Two tight sentences: purpose and matching rule first, return shape and cache behavior second. No filler, nothing buried.

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 re-explained, and the description still summarizes them usefully. The remaining gap is the undocumented limit and with_video_only parameters, which an agent would need in order to call the tool precisely.

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 compensate. It does explain query semantics (all words must match) and the purpose of refresh, but limit and with_video_only are documented in neither the schema nor the description, leaving half the parameters opaque.

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 ("Find") and resource ("exercises in the TrainHeroic library") plus the matching rule ("all words must match"), which clearly separates it from get_exercise (single lookup) and get_recent_exercises (recent list). It stops short of naming those siblings explicitly, so differentiation is inferred from naming 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?

The description implies the use case (name-based lookup in the library) and mentions refresh=True for reloading the cache, but gives no explicit when-not guidance or pointers to alternatives like search_circuits, get_recent_exercises, or get_exercise. An agent can infer intent but must guess at boundaries.

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

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

With no annotations, the description carries behavioral disclosure well: it states partial-update semantics ('Targets and the set count you leave out keep their planned values'), ownership requirement, and validation against tracked targets. It omits error behavior or return format, but covers the critical mutation semantics.

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?

Every sentence earns its place: the core action is front-loaded, followed by the critical formatting rule, the partial-update behavior, and the validation pointer. No redundant or filler 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 12-parameter mutation with no annotations and no output schema, the description covers ownership, partial-update semantics, target formatting, and validation. It leaves some parameter meanings (e.g., `rpe`, `percent`, `team_id`) unexplained, but the core invocation risks are addressed.

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

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

Schema coverage is 0% and the description compensates significantly by explaining the scalar-vs-list format for target parameters, giving a concrete example, clarifying that omitted values persist, and specifying reps are whole numbers while cues belong in `instruction`. It does not explain `rpe`, `percent`, `meters`, `team_id`, or the two required IDs, leaving some gaps.

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: setting sets and per-set targets for one exercise of a session. It distinguishes itself from sibling tools like add_exercises and update_session by focusing on prescription targets, and an agent can identify its role 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?

Provides clear context: it operates on a session you own and only accepts targets the exercise tracks, pointing to `get_workout`'s `tracks` field. It does not explicitly name alternatives or when-not-to-use, but the ownership and validation constraints give sufficient 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a write (recording an answer) but never says whether re-submitting the same question overwrites a previous answer, whether the saved_workout_id must exist, or whether submissions are rate-limited or final.

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

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

One tight sentence that front-loads the action and folds the score scale into the same clause. Nothing is wasted and nothing is buried.

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 three-required-parameter mutation with no annotations and no output schema, the description says too little: not what happens on duplicate submission, not whether the score is retrievable later, not what a successful call returns. An agent could call it, but not confidently.

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

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

Schema description coverage is 0%, so the description must compensate for all three params. It adds the direction of the scale (1=worst, 5=best) beyond the bare min/max bounds, but leaves saved_workout_id and the meaning of 'question' (the enum values are only self-evident by name) undocumented.

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 ('answer/submit') and resource ('one readiness question for a saved workout') with the score scale, which is enough to separate it from read-side siblings like get_workout_surveys. It never explicitly names a sibling or contrast, so it stops short of full differentiation.

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

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

The phrase 'one readiness question' implies a one-call-per-question granularity, which is a usable usage hint. But there is no statement of when to use this versus save_workout_feedback or get_workout_surveys, and no preconditions (e.g., workout must already be saved).

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

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

No annotations are provided, so the description carries the full burden for a mutation tool. It does not disclose permissions, whether the update is partial or replaces existing values, how null values are treated, or what happens to required parent IDs. It only states the two fields that can change.

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

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

The description is a single, front-loaded sentence with no wasted words. The examples in parentheses add useful context without bloating the definition.

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 five parameters, zero schema descriptions, no annotations, and no output schema, the description is materially incomplete. It tells the agent what fields can change but omits required parent identifiers, mutation behavior, and return/response expectations.

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

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

Schema description coverage is 0%, so the description must compensate for all five parameters. It adds meaning only for 'title' (rename) and 'instruction', leaving 'program_workout_id', 'block_id', and 'team_id' undocumented, along with the effect of null/default values.

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 clear verb-resource pair: 'Rename a block and/or set its instruction.' It makes the resource ('block') and the updatable fields ('title', 'instruction') explicit. It does not explicitly distinguish this from siblings like update_session or set_prescription, so it falls short of a 5.

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

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

The description implies this is for modifying block metadata, but it gives no explicit guidance on when to use this tool versus alternatives such as update_session, set_prescription, or add_to_block. There are 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the useful partial-update trait, but does not explain permissions, failure behavior for missing sessions, or whether null values clear fields or leave them unchanged.

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

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

Two short sentences with zero waste. The mutation purpose and the partial-update rule are front-loaded.

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

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

For a mutation tool with no annotations, no output schema, and 0% parameter description coverage, the definition is too sparse. It leaves key details about workout_id, null handling, permissions, and failure modes unstated.

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

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

Schema description coverage is 0%, so the description must compensate. It obliquely maps 'rename' to title and 'notes' to instruction, but never explains the required workout_id, and the term 'notes' does not match the schema parameter name 'instruction,' creating ambiguity.

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 clear mutation verb and resource: rename a session and/or set its notes. It is distinguishable from create_session/delete_session, though it does not explicitly differentiate update_session from update_block or set_prescription.

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 implies partial update behavior with 'Omitted fields stay unchanged,' but gives no explicit guidance on when to use this tool versus alternatives such as update_block or create_session. There are no prerequisites or exclusions.

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