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

Beyond the readOnlyHint annotation, the description discloses that overrides are not saved, that the window uses the athlete's calendar day versus the coach's parameters, that outputFile writes results to a local file instead of returning them inline, and gives an unusually detailed caveat about the limitations of removedOccurrenceCount. This goes well beyond what annotations provide.

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

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

The description is long but dense, and its structure is logical: purpose first, then defaults, overrides, return fields, and the outputFile option. The verbatim caveat sentence is heavy, but it earns its place given that no output schema exists to communicate the subtle meaning of removedOccurrenceCount.

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 fully equips an agent to invoke the tool correctly: all five parameters are explained, defaults are specified, side effects are stated, and the return payload is enumerated in detail, including a nuanced interpretive caveat. There is no output schema, so this rich description is necessary and sufficient.

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 schema description coverage at 0%, the description carries the full burden for parameter meaning. It explains the role of from/to, windowWeeks, toleranceDays, and outputFile, including defaults and override behavior. Every parameter in the schema is accounted for with meaningful, non-tautological semantics.

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

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

The description opens by explicitly framing the tool as answering 'how well does the athlete keep to the plan' over a chosen window and tolerance, which is a clear verb-plus-resource statement. It is distinct from common sibling tools like get_stats or get_progress, though it does not name any sibling or draw an explicit 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 description gives clear context for how the tool behaves by default: the window ends today, spans back windowWeeks, and uses the coach's persisted parameters unless overridden. It does not explicitly say when to prefer this tool over siblings, but the semantics are specific enough that an agent can infer appropriate use.

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, so the agent knows this is a safe read operation. The description adds context about the tool being a prerequisite for set_coach_parameters and that it returns defaults, ranges, and current values in one call. However, it doesn't describe the return format or whether the seven parameters are always present, which would add further behavioral 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?

Two sentences with no wasted words. The core purpose is front-loaded, and the usage guidance is concise and actionable.

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

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

For a zero-parameter read-only tool, the description is nearly complete. It states what is returned, when to call it, and why. The only minor gap is not describing the exact output structure, but with no output schema and a simple read operation, the description carries enough weight for an agent 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?

The tool has zero parameters, so the schema is trivially complete. The description adds meaning by explaining what the tool returns (defaults, allowed ranges, current values) and its role as a precursor to set_coach_parameters. With 0 params, baseline 4 is appropriate.

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

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

The description clearly states the tool reports seven training-state tuning parameters with their default values, allowed ranges, and current values in one call. It uses a specific verb ('Report') and resource ('seven training-state tuning parameters'), and distinguishes itself from the sibling set_coach_parameters by explicitly positioning itself as the read counterpart.

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 explicitly instructs to call this BEFORE set_coach_parameters and explains why: it is the right first step to learn what can be set and what it currently is, rather than discovering ranges by trial and error. This provides clear when-to-use guidance and names the alternative tool.

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

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

Annotations already declare readOnlyHint: true, so the read-only nature is covered. The description adds the fallback behavior for localized names and the structure of muscleGroups[].key, which goes beyond annotations. No contradictions; it enriches behavioral 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?

Two concise sentences with no filler. The first sentence front-loads the primary purpose and content; the second adds actionable parameter and cross-tool usage. Every word earns its place.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description covers the purpose, parameter behavior, and integration hint with get_stats. Nothing essential is missing for an agent 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?

The schema has zero description coverage for the only parameter 'lang'. The description fully explains its purpose and effect: adding a localizedName field with fallback to nameEn. This is essential information that the schema does not provide, so the description compensates completely.

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

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

The description clearly states the tool returns the full exercise catalog with muscle groups, equipment, and optional localized names. It is specific about the resource and content, but it does not explicitly differentiate from sibling tools like get_stats or list_templates. However, the purpose is unambiguous given the context.

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

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

The description provides concrete usage guidance: it explains how to use the optional 'lang' parameter to add localized names and fallback behavior, and it suggests pairing muscleGroups[].key with get_stats for aggregates. It does not explicitly state when not to use the tool, but it offers actionable usage context.

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

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

The only annotation is readOnlyHint=true, so the description carries limited safety burden; it adds meaningful behavioral details beyond that: newest-first ordering, result cap behavior via limit, and the outputFile side effect of returning only path/byte size/item count. This goes well beyond what the annotation alone conveys, without contradicting it.

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 dense and front-loaded, with each sentence contributing a distinct fact: return scope, ordering, when-to-use guidance, optional filter, limit cap, and outputFile behavior. It is longer than the minimum but every clause earns its place.

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

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

Given five parameters, no output schema, and a read-only annotation, the description covers the essential call requirements: required date range format, optional filter, limit behavior, ordering, and outputFile result reporting. It does not describe the shape of the inline session/set-log return, but the tool is still callable without that detail.

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, and it does: from/to are explained as a date range with YYYY-MM-DD format, exercise as an optional UUID filter, limit with default/maximum cap, and outputFile with its local-file writing behavior. Every parameter is given actionable meaning beyond its bare schema 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 description uses a specific verb ('Return') with a precise resource ('sessions and set-logs') scoped to a date range and optional exercise filter. It also differentiates itself from get_training_state by framing this as the targeted raw-detail lookup, so an agent can distinguish it from 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?

It explicitly says to call get_training_state first for the athlete's overall standing and to use this tool when underlying raw sessions and set-logs are needed. That is direct when-to-use guidance with a named alternative.

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

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

Annotations already mark the tool as read-only. The description adds meaningful behavioral details beyond that: cancelled occurrences are pre-filtered, completed occurrences are intentionally not excluded, and roots expose parsed series fields. This helps an agent interpret results correctly.

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 bit long but each sentence earns its place: core purpose, date constraints, cancellation/completion semantics, and structured fields. It is front-loaded with the main verb and resource, and the extra detail is necessary for correct use.

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

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

For a simple read-only tool with two parameters and no output schema, the description explains the return concept (occurrences and roots) and the key behavioral nuances. It does not enumerate exact occurrence fields, but the depth provided is appropriate for the tool's complexity.

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 explicitly states `from` and `to` are mandatory dates in YYYY-MM-DD format with a maximum span of 366 days, adding meaning beyond the raw schema pattern and required list.

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

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

The description clearly states the tool returns calendar occurrences and their planned-workout roots for a date window. It is specific about the resource and output, though it does not explicitly name sibling tools to differentiate; still, the resource ('planned workouts') is distinct from `get_history` or `get_adherence`.

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 gives concrete invocation constraints (mandatory `from`/`to`, max 366 days, cancelled excluded) and clarifies that completed occurrences are included. However, it never says when to use this tool versus alternatives like `get_history` or `get_training_state`, leaving the choice to inference.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds useful context (authenticated scope and returned fields) but does not detail behavior such as error cases, auth prerequisites, or response envelope. No contradiction with annotations.

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

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

A single, front-loaded sentence that states the action, target, and result fields with no filler. Every word earns its place.

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

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

Given the tool's simplicity, no output schema, and read-only annotation, the description is nearly complete: it names the resource and all returned fields. It could add a brief note on auth context or error behavior, but nothing critical is missing for correct 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?

The tool has zero parameters, so the baseline is 4. The description compensates minimally by listing the fields that will be returned, which is more meaningful than an empty schema alone.

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 ('Return') and names the exact resource ('authenticated user's profile') followed by a concrete list of fields. It unambiguously distinguishes this from sibling getters like get_stats or get_template.

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 context is implied by 'authenticated user's profile' and the sibling tool names, but the description does not explicitly state when to choose this over alternatives or mention any exclusions. It is adequate but leaves inference to the agent.

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?

Annotation Contradiction: readOnlyHint=true indicates a read-only operation, but the description says `outputFile: true` will 'write the full point series to a local file.' That is a persistent side effect, so the description directly contradicts the annotation despite otherwise being rich about behavior.

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

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

The description is dense and front-loaded with the key `kind` branching, and each clause contributes useful semantics. The long nested sentences make it harder to scan, but there is little filler.

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

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

Given an empty input schema and no output schema, the description works hard to cover modes, metric selection, direction-label provenance, empty-result behavior, and file output. It is still not fully complete because the formal schema omits the described parameters and the 'local file' destination is underspecified, but as prose it is unusually thorough.

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 input schema exposes zero properties, yet the description fully defines `kind`, `exerciseId`, `templateId`, `points` (with range 3-30), and `outputFile`, including omission defaults. This is far more parameter meaning than the empty schema provides and meets the 0-param baseline with substantial added value.

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 pinpoints a specific resource and action: it returns two kinds of training progress series selected by `kind`, and it details what each mode returns. This clearly separates it from sibling tools like get_stats or get_history even without naming 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?

It provides explicit decision rules for choosing `exercise` vs `format`, for omitting `exerciseId` or `templateId` to broaden the result, and for overriding `points` or switching to `outputFile`. It does not explicitly tell the agent when not to use this tool in favor of a sibling, so it stops one point short.

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

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

Annotations already mark the operation as read-only. Beyond that, the description discloses exact behavioral details: e1RM uses the same Epley formula as the app, statistics are app-consistent, and `trend.points` contains the full per-session series in addition to the first-vs-last delta. This is meaningful disclosure beyond the annotation.

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 dense and front-loaded, leading with the core purpose before elaborating on modes and output specifics. Every clause earns its place and there is no filler or repetition of the title.

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 explains the output fields and the computational formula well, but the gap between the described `by` parameter and the empty input schema is significant: an agent cannot tell how to request exercise-specific or muscle-specific stats. There is also no output schema, so the description partially compensates by naming key fields, but the invocation mismatch remains unresolved.

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

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

There are zero parameters in the input schema, so the baseline is 4. The description adds useful conceptual meaning by explaining the `by` modes and what they return. However, it references a `by` argument that is absent from the input schema, which is a minor inconsistency in how an agent would actually invoke the tool.

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

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

The description opens with a specific verb ('Compute') and a specific resource ('training statistics'), then names concrete outputs (e1RM, volume, set/session counts, trend). It also distinguishes three modes of operation (`by: 'exercise'`, `by: 'muscle'`, `by: 'capabilities'`), making it easy to tell apart from siblings like get_progress or get_history.

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 gives clear conditional guidance on when each mode applies: a specific exercise, a muscle group, or a capabilities breakdown. It does not explicitly name alternative sibling tools or state when not to use this tool, but the usage context is unmistakable.

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

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

Beyond the readOnlyHint annotation, the description discloses failure behavior for unknown or non-owned ids and explains that a modified accept includes appliedPayload. This adds useful expectations about errors and return-shape nuances.

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 concise sentences, each carrying one distinct fact: what is returned, where the id comes from, and when an error occurs. There is no redundant wording or filler.

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

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

For a single-parameter, read-only tool, the description covers return contents, input provenance, and error cases. With readOnlyHint already covering side effects and the schema covering the id format, 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 schema only defines id as a UUID with 0% description coverage, so the description must compensate. It does so by specifying that the id must come from get_suggestions and must belong to the caller, which is the key semantic constraint for successful invocation.

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

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

States a specific verb ('Return ... in full') and a specific resource ('one of the coach's own proposals'), and clarifies scope by mentioning payload and appliedPayload. This clearly distinguishes it from sibling get_suggestions, which retrieves a list rather than a single item.

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 instructs the agent to pass an id from get_suggestions, establishing the prerequisite relationship with the list tool. It does not formally list exclusions or alternatives, but the retrieval-by-id context is clear enough for correct selection.

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

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

Beyond the readOnlyHint annotation, the description reveals ordering ('newest first'), payload absence, the returned field set, the `limit` clamping behavior (default 200, max 500), and the empty-array-not-error guarantee. These are concrete behavioral disclosures that meaningfully inform invocation.

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 dense but every sentence earns its place: first the returned row shape, then sibling routing, then parameter behavior, then the edge case. It front-loads the most decision-relevant 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?

Given two optional parameters, a meaningful sibling relationship, and no output schema, the description fully covers what an agent needs: returned fields, filtering, limits, the relationship to `get_suggestion`, and the empty-array behavior. 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?

Schema description coverage is 0%, so the description carries full responsibility for both parameters. It explains the `status` enum values in place and gives `limit` semantics (default 200, clamped to 1..500), adding meaning the generic integer schema lacks.

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

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

The description names a specific verb ('List') and resource ('the coach's own proposals'), and clearly distinguishes itself from `get_suggestion` by emphasizing summary rows vs full proposal. It also enumerates the fields returned, making the tool's scope unmistakable.

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

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

It explicitly instructs the agent to 'Call this first' and directs when to use `get_suggestion` instead ('only when you need the full proposal'). This gives direct routing guidance relative to the closest sibling tool.

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

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

The readOnlyHint annotation already signals no side effects. The description adds value by disclosing the join behavior and the error condition when the template is not found.

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 core action front-loaded and no filler. Every sentence adds useful 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?

For a single-parameter read tool with readOnlyHint set, this is nearly complete. It covers what is returned, how to obtain the ID, and the error case. It doesn't describe the full response structure, but the lack of an output schema makes that a minor gap.

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

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

Schema coverage is 0%, so the description carries the burden. It compensates by explaining that the parameter is a UUID from list_templates, giving the agent actionable semantic context beyond the raw schema type/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?

The description states a specific verb ('Return'), a precise resource ('one workout template'), and what is included ('blocks and template-exercises joined'). It is clearly differentiated from siblings like list_templates and get_planned_workouts.

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

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

It clearly tells the agent to pass the UUID obtained from list_templatesaine and states the not-found error behavior. It doesn't explicitly enumerate alternatives, but the source-of-ID guidance gives clear usage context for this single-parameter tool.

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

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

With readOnlyHint already present, the description adds meaningful behavior beyond the annotation: the tool computes results at query time, produces a deterministic narrative without a second model call, and binds calendar days to the athlete's timezone rather than the coach's. It also explains the semantics and limits of removedOccurrenceCount, which is valuable transparency.

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 dense but every clause earns its place: it front-loads the core purpose, enumerates the returned content areas, states exclusions, names alternatives, and clarifies timezone behavior. The length is justified because there is no output schema to carry the return-value details.

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 no output schema and zero parameters, the description is remarkably complete: it enumerates the main result categories, names the sibling tools for adjacent cases, specifies the read-only computed nature, and clarifies the timezone binding. An agent has everything needed to select and invoke this tool correctly.

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

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

The tool has zero parameters and an empty input schema, so there are no parameter semantics to document. The description still indirectly clarifies that the tool takes no arguments and needs no configuration, which is sufficient for this vacuous case.

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, specific purpose: it is the standard entry point for an athlete overview, computed at query time rather than raw history. It also distinguishes itself from siblings by naming exactly what it does not carry (point series, pair lists) and which sibling tools cover those cases.

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 gives explicit routing guidance: use get_progress for per-exercise/format progress series, get_adherence for full adherence pair/missed lists, and get_history for raw session history. This leaves no ambiguity about when to choose this tool over its siblings.

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

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

Annotations declare readOnlyHint=true, which covers safety. The description adds meaningful behavioral context: it filters out deleted templates and returns counts rather than full objects. It does not discuss pagination or ordering, but for a simple list that's a minor gap. No contradiction with annotations.

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

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

Two sentences, zero filler. The first sentence states the core behavior and output; the second routes to the alternative for more detail. The key information is front-loaded and every word earns its place.

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

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

For a zero-parameter list tool with readOnly annotation, the description fully covers what an agent needs: it states the filter (non-deleted), the output (block/exercise counts), and how to get more detail if needed. No output schema exists, but the description explains the return semantics sufficiently. 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?

There are no parameters, so the schema is trivially complete. The baseline for 0 params is 4. The description does not need to add parameter details because none exist; it adds value by describing what the returned data contains.

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

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

The description opens with a precise verb and resource: 'Return all non-deleted workout templates' and specifies what data is included (block and exercise counts). It clearly differentiates from get_template by stating the scope (all vs. specific) and the level of detail (counts vs. full detail). No ambiguity about what the tool does.

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

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

It explicitly tells the agent when to use the sibling instead: 'Use get_template to fetch a specific template's full detail.' This gives a clear condition for choosing between list_templates and get_template, and the sibling is named. While it doesn't list every alternative, it addresses the most relevant one for this resource.

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

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

Beyond the annotations, it discloses that a proposal is created rather than the exercise itself, that the proposal lands in a coach inbox, that duplicate names short-circuit to an existing UUID, and what is returned in that case. This is valuable behavioral depth.

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 core purpose front-loaded and the important duplicate/idempotency behavior stated in the second sentence. No fluff.

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 covers purpose, non-destructive behavior, and dedup behavior, but with no output schema it leaves the normal success return value unexplained and does not clarify how to fill the required fields. Adequate as a minimum-viable definition, but with real 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 description coverage is 0% and the description adds no parameter-level meaning. It only indirectly references 'name'; mode, usesWeight, and rationale are left to bare schema types and enums.

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

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

The description opens with a specific verb and resource: 'Propose a brand-new custom exercise for human review.' It explicitly contrasts with direct creation ('Never creates it directly') and names the exact delivery path, so an agent can distinguish it from sibling proposal tools.

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

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

It is clear this tool is for submitting a new exercise for coach review rather than for creating or modifying an existing catalog entry. It does not explicitly name alternatives or when-not conditions, but the context is unambiguous enough to route selection.

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

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

Beyond the annotations, the description adds valuable behavioral nuance: the tool never creates directly, routes to a coach inbox for accept/reject, and automatically resolves matching newExercises entries to catalog UUIDs to avoid duplicates. This materially changes how an agent should reason about consequences and idempotency.

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

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

Three sentences, front-loaded with the core purpose, followed by the two most important behavioral caveats. No filler, no repetition of schema constraints, and each 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?

For a complex, nested tool with no output schema, the description covers the critical context: review-based workflow, no direct creation, and duplicate-avoidance behavior. It does not explain how to structure exercise references (catalog vs new) or what response the agent should expect, but the schema and the proposal-flow description cover most operational needs.

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 of explaining parameters. It explains the purpose of blocks/exercises broadly and the special behavior of newExercises[] resolution, but it does not explain the source catalog/new exercise union, temp IDs, orderIndex semantics, or target fields. The parameter names and schema structure provide some self-evidence, but meaningful gaps remain.

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 ('propose'), a specific resource ('brand-new workout plan (blocks + exercises)'), and the delivery target ('coach inbox for accept/reject'). This clearly distinguishes it from sibling tools like propose_plan_update and propose_new_exercise by focusing on new plans routed for review.

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 gives clear use context: this is for proposing a new plan that will be reviewed by a human coach, not directly created. It does not explicitly name alternatives or state 'use propose_plan_update for existing plans', but 'brand-new' and the proposal flow make the primary use case unambiguous.

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

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

Beyond annotations, it discloses that the tool never mutates directly, rejects without a network call for a detailed list of named causes, and transports the proposal to a coach inbox. This gives an agent an accurate mental model of side effects and failure modes.

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 dense but organized: front-loaded purpose, then intent-by-intent semantics, then rejection and outcome behavior. Every sentence adds operational information, and the structure mirrors how an agent would parse it.

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

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

For a complex multi-intent tool with no output schema, this description is complete enough to invoke correctly: it covers accepted intents, parameterized identifiers, validation failures, and the post-acceptance destination. No critical operational aspect 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?

With no parameters in the input schema, the description must carry the full parameter burden, and it does: it names rootId, occurrenceDate, newDate, templateId, date, recurrenceRule, cutoffDate, and scope, and explains validity constraints for each intent. This far exceeds the baseline for zero-parameter tools.

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 action ('Propose a change to the calendar for human review') and enumerates four distinct intents, so an agent knows exactly what resource is affected and in which modes. It also distinguishes the operation from direct mutation, clarifying its role relative to siblings like propose_plan_update and propose_new_plan.

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

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

It gives clear context: use for calendar changes requiring human review, and explicitly sources IDs/dates from get_planned_workouts. It does not explicitly name excluded alternatives, but the 'never a raw envelope' and 'for human review' signals effectively scope when this tool is appropriate.

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 description goes well beyond the annotations by revealing non-obvious behavior: the call never mutates directly, proposals go to a coach inbox, format rows are recomputed from formatParams so ops[] diffs would be silently discarded, validation fast-fails without a network call, and catalog-matching new exercises are auto-resolved to UUIDs. No statement contradicts the annotations.

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

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

The description is dense but every sentence adds operational value: the main purpose is front-loaded, conditional usage is sequenced logically, and the consequences of misusing formatParams and ops[] are explained without repetition. The length is justified by the tool's complexity.

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

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

Given the complexity, the absence of an output schema, and minimal annotations, the description covers the essential selection, invocation, and behavior of the tool: parameter choice, mutation semantics, error fast-fails, and the human-review outcome. The only lightly covered required parameter is rationale, but its purpose is self-evident and the schema already marks it required.

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 schema description coverage at 0%, the description carries the parameter-meaning burden and does so thoroughly. It explains the central parameter choice (ops vs formatParams), the exact constraint that only one may be set, the meaning of newExercises[] resolution, and the need to reference get_template.workoutType to determine which parameter group applies.

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

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

The description opens with a specific verb and resource: 'Propose a structural change to an existing workout template for human review.' It immediately distinguishes the proposal role from direct mutation and clarifies the two operation modes (ops[] diff for CLASSIC templates, formatParams for format templates), which helps an agent select it correctly among the propose_* 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 guidance is explicit and conditional: use ops[] only against CLASSIC templates, use formatParams only against format templates, never pass ops[] to a format template, and set exactly one of ops/formatParams. It also tells the agent to check get_template's workoutType and describe failure modes such as fast-failing on a missing templateId or shape mismatch.

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 description adds meaningful behavioral context beyond the annotations: it rejects out-of-range values and invalid uncertainThreshold/matchThreshold combinations before any server change, and it returns the resulting overall state. Annotations already cover idempotency and non-destructiveness, so the added value is real but not exhaustive.

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 with no filler: purpose first, required precursor second, validation and return behavior third. Every sentence earns its place and the most important routing guidance is 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?

The description handles the call sequence, validation behavior, and return value well, but for a seven-parameter tool with no schema-level descriptions or output schema it leaves parameter semantics underspecified. The guidance to call get_coach_parameters first mitigates this only partially, since that call supplies ranges and current values, not necessarily parameter meanings.

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 and seven parameters, the description needed to compensate by explaining at least the key parameter meanings. It does not list or define the seven parameters, though it does mention the uncertainThreshold/matchThreshold relationship. The phrase 'training-state tuning parameters' is too generic to guide correct invocation.

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

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

The description opens with a specific verb and object: 'Set one or more of the seven training-state tuning parameters.' This clearly identifies the action and resource, and naturally distinguishes it from read-only siblings like get_coach_parameters and get_training_state.

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

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

The description explicitly instructs the agent to call get_coach_parameters first to learn defaults, ranges, and current values, which is clear usage guidance. It does not spell out when not to use this tool or name alternatives, but the prerequisite and intent are unambiguous.

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 idempotentHint=true and destructiveHint=false, but the description adds real behavioral context: the status is changed to withdrawn, the record is not deleted, audit history remains readable via get_suggestion, repeated withdrawal is a no-op, and error wording is intentionally uniform. This goes well beyond the structured hints.

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

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

Three dense sentences, each earning its place: the core purpose, the persistence behavior, and the failure semantics. Information is front-loaded and nothing is redundant with the schema or annotations.

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

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

Covers the critical operational details: state change, non-deletion, idempotence, readable audit record, and error conditions. The only minor gap is not describing the success return value, which is less important for a largely fire-and-forget mutation but would make the description fully self-contained given there is no output schema.

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

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

The schema declares only a required UUID 'id' with no description, so the description must compensate. It clarifies that the id identifies one of your own pending proposals and conveys the semantic failure modes, though it could have explicitly said 'supply the proposal/suggestion id' rather than leaving that inference to the agent.

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 action (retract), a specific resource (one of your own pending proposals), and a clear context (single named exception to the propose-only boundary). This sharply distinguishes the tool from the read-only get_* and proposal-creating propose_* 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?

Explicitly says when this tool is the right choice: to retract your own still-pending proposal, framing it as the sole exception to the propose-only rule. It also lists the concrete conditions that make a call invalid (unknown, not yours, no longer pending), giving an agent precise when-to/not-to guidance.

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