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 the mode-dependent behavior (list vs. detail/structure return), but says nothing about pagination, result volume, permissions, or read-only nature. Adequate but with clear gaps for an unannotated 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 compact sentences, front-loaded with the resource and followed by the parameter-driven branching. No wasted words.

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

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

Complete enough for a 2-param, no-output-schema read tool: it explains both modes and both parameters. Only return-format/pagination detail is missing, which is minor here.

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 explains both parameters' roles: `query` filters the list, and `program_id` switches the tool into a detail-fetching mode. This adds meaningful semantics the bare schema lacks.

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

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

States a specific resource ('Speediance's official multi-week programs') and a clear dual-mode behavior. The agent can distinguish it from workout/exercise siblings, though it never names an alternative directly.

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

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

Explicitly tells the agent when each mode applies: omit program_id to list, supply it to fetch a specific program's details. Clear context, but offers no guidance on when to reach for this versus sibling listing tools like list_my_workouts.

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 present the description carries the full burden, and it delivers real behavioral context: it reveals the connected:false outcome, that a message should be relayed to the user, and the silent token-renewal case. It stops short of describing the full return payload (e.g. success shape, any expiry or identity fields), but what it covers is the operationally important part.

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

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

Three short sentences, front-loaded with the primary directive (call first) followed by the failure protocol and the one edge case. Every sentence earns its place; nothing is padding.

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

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

For a zero-parameter, no-annotations, no-output-schema tool the description covers purpose, ordering, failure handling, and the token-renewal edge case. The only gap is that return-field details (beyond the connected flag and message) must be inferred, which is minor given how simple the operation is.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly implies a no-argument ping and does not fabricate inputs.

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: verify the Speediance login is live. It is immediately distinguishable from every sibling (workouts, programs, preferences, facts) — none of which touch authentication. An agent knows exactly what this tool does without opening the schema.

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

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

Explicitly prescribes when to call it (FIRST in a session, before any other tool) and what to do with the result (stop if connected:false and relay the message). It also pre-empts a common false negative by clarifying that an expired token with a remembered password is renewed silently, so the agent won't misreport a failure.

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 does not disclose authentication requirements, behavior when no earlier session exists, error behavior for invalid IDs, or whether the result is scoped to shared movements only. The per-movement delta output is mentioned, but the operational behavior is largely unspecified.

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

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

Two tight sentences, front-loaded with the tool's purpose and output dimensions, followed by the one non-obvious parameter behavior. No filler.

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

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

For a two-parameter, no-annotation, no-output-schema tool, the description explains the special meaning of previous_training_id=0 but leaves gaps around training_id semantics, missing previous session behavior, and per-movement scoping edge cases. Adequate but not complete.

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 partially does: it explains that previous_training_id=0 means the most recent earlier session sharing a movement. But it does not explain the primary training_id parameter, nor what happens when previous_training_id is absent from the input or references a session with no shared movements. This offsets the baseline.

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: compare a session with an earlier one, per movement. It immediately names the output dimensions (top weight, total reps, volume deltas), which distinguishes it from siblings like get_session_detail or get_training_stats. It is clear, though it does not explicitly name a contrasting sibling 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?

Usage is implied: this tool is for comparing two sessions, and previous_training_id=0 selects the most recent earlier matching session. However, there is no explicit when-to-use vs alternatives guidance, no mention of whether sessions must share movements, and no exclusion of related tools such as get_session_detail or get_training_stats.

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 delivers: it discloses read-back verification, the meaning of verified:false, and that the reply carries hardConstraints and legacyUnreviewed facts requiring re-check. It omits permission/auth requirements and reversibility, but the post-save behavior disclosure is unusually rich.

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 one-line purpose, then dense, purposeful detail on structure and post-conditions. Every clause adds information; the embedded JSON snippets and ⊘ symbol make it slightly cramped, 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?

For a tool with no annotations and no output schema, the description supplies the create contract, verification semantics, and key return fields. It is largely self-sufficient; only auth/permission context is missing, which is minor here.

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, and it does so thoroughly for `exercises`: object shape, set formats by movement kind (reps/timed/Vita), optional side/rest fields, and weight units. Only `name` is left unexplained, which is trivially inferable, keeping this just short of exemplary.

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: 'Create a custom workout template.' This clearly distinguishes it from read/list siblings, but it does not explicitly differentiate itself from update_workout or schedule_workout, leaving the create-vs-schedule boundary 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?

Provides some in-flight guidance ('Never program a ⊘avoided movement unless asked by name', verify before declaring done), but gives no explicit when-to-use/when-not guidance versus siblings like update_workout or schedule_workout. Usage context is implied rather than stated.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the irreversible/destructive nature and the preference for `code` over numeric id, but says nothing about required permissions, whether scheduled instances are also removed, or whether any confirmation step exists.

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, both front-loaded: the action first, then the irreversibility and usage guardrail. No filler or restated metadata.

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

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

For a one-parameter destructive tool with no annotations and no output schema, the description covers the essentials: what is deleted, in what formats, and that it cannot be undone. Side effects on scheduled sessions remain unstated, but nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 0% for the single required `template_id`, so the description must compensate — and it does, explaining that the argument is a `code` string (preferred) or a numeric id, which maps directly onto the schema's anyOf string/integer and adds a preference ordering the schema lacks.

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

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

States a specific verb and resource ('Permanently delete a custom template') plus the two accepted identifier forms, which cleanly separates it from siblings like get_workout, update_workout, and unschedule_workout. Minor friction: the description says 'template' while the tool name and parameter say 'workout', leaving a slight ambiguity about the target object.

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?

Includes the guardrail 'only when the user asked for it', which is real when-to-use guidance, but it never names an alternative (e.g. unschedule_workout if the user wants to remove a scheduled session without deleting the template). Usage context is implied rather than explicitly routed.

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 does well: it discloses soft-delete semantics (still visible via list_facts(include_archived=true)), the effect on default reads (leaves every default read), and a side effect (legacy facts are marked reviewed). It never says explicitly whether the action is reversible/restorable or what the response returns, so it falls just short of 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?

Front-loaded with the core action, followed by visibility behavior and the alternative in order of importance. Three tight sentences with no filler; size is appropriate.

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

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

For a single-parameter mutation tool with no annotations and no output schema, the description covers what the action does, where the id comes from, downstream visibility, and the relevant alternative. Only reversibility and error behavior are unaddressed.

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

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

Schema coverage is 0%, so the description must compensate; it adds real meaning by telling the agent the `id` originates from get_preferences `facts` or list_facts. It does not state the id format or behavior on an invalid/unknown id, leaving a small gap.

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

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

States a clear verb and resource ('Archive a fact') and immediately scopes it as one that 'no longer applies', which distinguishes it from the sibling remember_fact. An agent can tell what this does without opening the schema.

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

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

Explicitly routes the agent: 'For a fact that changed, prefer remember_fact(..., supersedes=[id])', and names where ids come from (get_preferences `facts` or list_facts). Both the alternative and the selecting condition are given, not inferred.

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 behavioral burden, and it does substantial work: it explains that legacyUnreviewed facts may still bind until curated, that injury facts there should be treated as hard constraints, that conflicts must be surfaced rather than resolved silently, and that otherActivities must count toward load. It says nothing about freshness/caching, read-only nature, or error behavior, so not fully complete.

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: the first clause states the tool's role, then the payload is enumerated, then the handling directives follow. It is dense and the parenthetical enumeration with symbols (★preferred / ⊘avoided) is heavy, but each sentence conveys actionable information rather than filler.

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

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

With no output schema and no annotations, the description has to explain the return shape itself, and it does so concretely across all payload groups. For a read-only snapshot tool of this complexity it is close to sufficient; the unresolved gap is the undocumented 'days' parameter and lack of any note on payload size or truncation.

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 is one parameter, 'days' (default 14), with 0% schema description coverage, and the description never mentions it — 'recent sessions' gestures at a time window but does not tie it to the parameter or state what changing it does. The most invokable knob on the tool is left entirely undefined.

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 scope statement ('Everything needed before planning') and then enumerates the exact payload: profile fields, coaching memory grouped as constraints/preferences/goals/observations/conflicts, preferred/avoided exercises, owned equipment, recent sessions, and phone-imported otherActivities. An agent can tell this is the aggregate pre-planning fetch rather than a narrow getter like get_preferences or list_facts. It never states the verb explicitly, but the resource and breadth are unambiguous.

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

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

It gives clear when-to-use context ('before planning'/'before building any workout') and prescriptive handling rules: check memory.facts.constraints.hard and respect it, raise memory.facts.conflicts with the user rather than choosing, and curate legacyUnreviewed facts promptly. It stops short of naming alternatives, so it never says when a narrower sibling (get_preferences, list_facts, get_training_stats) is the better call instead.

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

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

With no annotations, the description carries the full burden and does so richly: it discloses the merge of completed custom-template sessions from the history feed (tagged source:"history"), the meaning of isReservation:true, that otherActivities are not gym sessions but count toward weekly load, and the data-completeness caveat that Speediance only holds what the phone synced. These are non-obvious behavioral traits an agent could not infer from structured fields.

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

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

The purpose is front-loaded in the first sentence and each subsequent sentence conveys distinct, load-bearing information about merge behavior, reservations, and otherActivities. It is dense and slightly run-on, but no sentence is filler.

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

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

With no output schema and no annotations, the description still describes the return shape (each day carries trainingPlanList, per-day otherActivities, source tags) and the caveats that matter for interpretation. For a single-parameter read tool this is complete enough to call and interpret correctly.

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

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

Schema coverage is 0%, so the description must compensate, and it supplies the format for the single parameter (`month` = 'YYYY-MM'). That is the key semantic an agent needs for the one required arg, though it adds nothing about timezone or range handling.

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

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

The opening clause states a specific resource and scope ('what's scheduled and trained in a month') and the description immediately differentiates the tool from get_session_detail by explaining what the calendar feed does and does not include. An agent can tell this apart from siblings like list_my_workouts or get_training_stats without opening a schema.

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

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

The description gives clear context for what the calendar covers and routes the agent onward ('pass their trainingId to get_session_detail'), which is an explicit alternative. It does not, however, frame when to prefer this tool over list_my_workouts or get_training_stats, so it stops short of full when/when-not 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?

With no annotations and no output schema, the description carries the full behavioral burden, and it does disclose the return payload (muscles, equipment, laterality, form description/cues, media). It says nothing about failure behavior for a bad group_id, permission needs, or freshness/caching, so the disclosure is partial.

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 front-loaded sentence with the payload stated first and no filler. The em-dash aside about unilateral exercises is slightly tangential but does add domain value rather than padding.

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

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

For a 1-param read tool with no annotations and no output schema, the description adequately covers what comes back but leaves the required parameter and the call-vs-alternative decision unexplained. It is minimally viable rather than complete.

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

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

Schema coverage is 0% and the single parameter 'group_id' is undocumented both in the schema and in the description. The description never mentions group_id, leaving the agent to guess whether it identifies an exercise, a muscle group, or a superset — a real ambiguity for a tool whose only argument is required.

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 resource ('one movement's details') and enumerates the return fields, so an agent can tell it apart from list_exercises or get_exercise_history in broad terms. It never explicitly names an alternative, though, so differentiation is inferred from the field list 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 when-to-use guidance and no mention of the sibling tools it sits among (list_exercises for browsing, get_exercise_history for logs). The parenthetical about unilateral mattering 'when building workouts' hints at a use case but gives no selection rule.

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 does well: it discloses sort order (oldest -> newest), per-day aggregation ('one entry per training DAY, same-day sessions combined'), returned fields (topWeight, volume, minWeight on ranged days), and the failure mode ({needsPick:true, matches:[...]} with nothing fetched). It omits any limit/pagination behavior and permission requirements, keeping 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?

Compact and front-loaded with the core scope, and the 'how is my bench press going?' framing earns its place by making selection intuitive. The phrasing is dashed and run-on, so structure is good but not exemplary.

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 tool with no annotations, no output schema, and 0% parameter description coverage, the description covers the return shape only partially (some fields, plus the ambiguous-match case) and leaves limit semantics and the full entry structure undefined. Adequate for a read-only history lookup, but not complete.

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 explains the exercise/groupId pair usefully (fuzzy name matching plus grouped exercise IDs), but the third parameter, limit, is never mentioned — and since entries are per-day, 'limit' is ambiguous between days and entries, which is exactly the kind of semantics the schema fails to supply.

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 precise verb+resource+scope: full chronological history for ONE movement ('EVERY time the user has done ONE movement, oldest -> newest'), which separates it from aggregate siblings like get_training_stats or get_strength_profile. It does not name any sibling tool explicitly, so it stays at 4 rather than 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?

Gives practical invocation guidance — pass the exercise name 'as the user says it' or a groupId — and specifies the disambiguation path (if several match, ask the user). However, it never states when to prefer this over compare_sessions, get_exercise, or get_strength_profile, so usage context is only implied.

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 load, and it does disclose meaningful behavior: the return granularity (second-by-second), the downsampling cap (at most 600 points), and the degraded-run case (available:false when no watch recorded). It omits auth/rate-limit considerations, but for a read-only getter those are minor.

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

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

Two tight sentences with the core content front-loaded; the payload list and the edge case are packed in without filler. Slightly comma-dense 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?

For a single-parameter read tool with no annotations and no output schema, the description covers the return shape and the empty case well, which is the main gap left by the absent output schema. It is incomplete on the input parameter and on when to prefer this over session-level 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, yet it never names or explains training_id. The phrase 'for a watch-paired session' only loosely implies a session identifier and adds no format, validity, or lookup detail beyond the self-explanatory parameter name.

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: it retrieves second-by-second heart rate for a watch-paired session, and enumerates the exact payload (average, max, min, series). This is far more than a restated name. It does not explicitly differentiate from nearby siblings like get_session_detail or get_training_stats, which keeps it out of the top band.

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

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

Usage is only implied: the phrase 'for a watch-paired session' and 'available:false when no watch recorded it' signal the precondition under which the tool is meaningful. There is no explicit when-to-use versus alternatives nor any routing to a sibling. Minimum-viable implied 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?

With no annotations, the description carries the full burden and discharges it well: it explains the volume-spreading method, that attributed totals exceed actual load, that they are 'shares of attention, not a decomposition of load,' and that timed/level work is deliberately routed to unweightedExercises rather than counted as zero. It does not state read-only status or auth requirements, but the method and edge-case disclosure are unusually rich.

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 answer to 'what does this return,' then methodological detail and caveats. Dense but each sentence adds real semantic value (ratios, unweighted work, notTrained interpretation); it is on the longer side but not padded.

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

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

No output schema exists, so the description must explain return values — and it does, defining pushPull/upperLower ratios, unweightedExercises, and notTrained. The notable omission is the `days` parameter, and read-only/auth behavior is left implicit.

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 is one parameter (`days`, default 30) with 0% schema description coverage, and the description never names or explains it — only alluding obliquely to 'recent training' and 'in the window.' Units, default, and the effect of changing the window are left entirely unspecified, so the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource — 'Which muscles the recent training actually loaded, and how balanced it was' — which is concrete and distinctive. It does not name or differentiate from plausible siblings like get_strength_profile or get_training_stats, so an agent must infer the boundary itself.

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 through the health/balance framing ('read it next to `unweightedExercises` before concluding a muscle was neglected'), but there is no explicit when-to-use, when-not-to-use, or named alternative among siblings. The reader must guess how this differs from get_training_stats or get_strength_profile.

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 behavioral burden and does so well: it warns that unusable_equipment must never be used in planning, defines ★preferred vs ⊘avoided notation, and specifies that legacy injury facts should be treated as hard constraints until curated. It does not cover pagination or freshness of the data, but the interpretation guidance is substantial.

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 front-loaded with the identifying phrase 'The coaching memory:' and every clause conveys distinct content about the returned structure. It is a single dense run-on enumeration rather than grouped prose, which slightly hurts scannability, but no sentence 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?

There is no output schema, so the description must describe return values itself — and it does so exhaustively, enumerating each fact group (constraints, preferences, goals, observations, conflicts, legacy buckets). Nothing an agent needs in order to interpret the response is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. Schema description coverage is 100% and the empty arguments object leaves no semantic 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?

The description names the resource ('the coaching memory') and enumerates exactly what it holds (goal, training days, session length, load anchors, equipment, preferred/avoided exercises, curated facts). It is clear what data the tool returns, though it never uses an explicit retrieval verb, and it does not distinguish itself from siblings like list_facts or set_preferences.

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 concrete workflow guidance: 'Check facts.constraints.hard before building any workout; resolve any conflicts with the user,' and instructs curating legacyToReview promptly. It does not name alternative tools or state when not to call it, so it stops short of full when/when-not routing.

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

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

With no annotations, the description carries the full burden and does substantial work: it explains the resolvedType:false sentinel, the account-scoped resolution via history, the conditional cardio/rowing blocks, and that weights are already in displayUnit. It omits auth expectations and any pagination/size limits, but the return-shape disclosure is well beyond the schema.

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

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

Core purpose is front-loaded in the first line, followed by the advisory-parameter caveat and conditional return types. It is dense with detail but each sentence adds real information, with no filler.

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

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

With no output schema and no annotations, the description does the heavy lifting by describing the returned per-exercise fields and conditional cardio/rowing additions. Remaining gaps — training_id semantics and ownership/auth constraints — are minor for a single-session read.

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 defines `type` as optional and advisory and explains the history-resolution behavior. That covers `type` well, but `training_id` is only implicitly described (the id that must be in your history) and gets no explicit naming or 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?

States a specific verb and resource — the per-exercise log (sets, reps, weight per movement) for ONE completed session — which cleanly distinguishes it from siblings like compare_sessions and get_workout. An agent can tell what it retrieves without opening the schema.

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

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

It scopes usage to 'ONE completed session' and clarifies that only sessions the account owns can be read, implying the actor's own history. However, it never names an alternative or states when to prefer this over get_workout or compare_sessions, so routing guidance is only implied.

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 safety/behavior burden, and it does disclose meaningful traits: the Epley formula, that it scans only the 10 most recent weighted sessions, and that it reports a trend across a window. That is useful limitation context, but it omits auth/permission needs and how the internal 10-session cap interacts with the caller-supplied window.

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 dense, front-loaded sentences with no filler; the output content leads and the scan limitation follows. Minor cost is the fragment-style opening, but it 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?

For a tool with no output schema or annotations and two fully undocumented parameters, the description does a decent job of describing what comes back but leaves the parameter meanings and the window/scan-cap relationship underspecified.

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 both params, so the description must compensate. It hints at a time window ('recently', 'across the window') and a session cap, but never defines what days or limit control, and the stated '10 most recent sessions' does not map cleanly onto limit's default of 15.

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 computation: per movement, estimated 1RM via Epley from the best set, that set, and the top-weight trend. It is clearly a strength-trending read, distinguishable from generic siblings like get_training_stats or get_exercise_history, though it never names them explicitly.

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

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

There is no when-to-use guidance and no alternatives named. The agent is left to infer from context whether this beats get_training_stats, get_muscle_balance, or get_exercise_history for a strength question.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the date format (YYYY-MM-DD) and that both bounds are inclusive, plus the exact metric set returned, but it never explicitly confirms this is a read-only aggregation or how large ranges are handled.

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

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

A single front-loaded sentence that begins with the verb and immediately scopes the date range, then lists outputs. Efficient and waste-free, though the metric enumeration is slightly long.

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 and no output schema, the description does the important work of naming the returned aggregate fields (sessions, minutes, calories, volume, energy) and the date semantics. It is nearly complete for a simple two-param aggregation tool; only the read-only nature is left implicit.

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, and it does: it fixes the format as YYYY-MM-DD and clarifies that the interval is inclusive. That resolves the main ambiguity an agent would have about start/end, though it doesn't say which bound drives the window if reversed.

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 (totals) and resource (training metrics) and enumerates the exact outputs, so an agent can distinguish it from detail-oriented siblings like get_session_detail or get_athlete_snapshot. It stops short of naming a sibling it must not be confused with, so it is clear but not fully differentiated.

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 questions like 'how was my week?'" implies an aggregate-over-a-range use case, which is genuine guidance. However, it never states when to prefer this over overlapping siblings such as get_athlete_snapshot or compare_sessions, so usage is only implied.

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 provided, the description carries the full burden of behavioral disclosure. It does add valuable return-structure context (exercises in order, each set's reps/seconds, weight, Vita level, side, rest, and displayUnit) which partially compensates for the missing output schema. However, it does not state whether the operation is read-only, whether it requires authentication, or whether it has any side effects, leaving significant behavioral gaps.

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 concise sentence that front-loads the return structure and includes a useful unit clarification. Every clause earns its place, with 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 simple single-parameter getter with no output schema, the description adequately outlines the return data but leaves key gaps: the meaning of the required 'code' parameter is unexplained, and no usage context or safety profile is given. It is enough to infer the basic operation but not complete enough to call confidently without opening the schema.

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

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

The input schema has a single required 'code' parameter with 0% description coverage. The description does not explain what 'code' represents, its format, or how it is used. The mention of 'a template's full prescription' loosely implies that the code identifies a template, but it does not compensate meaningfully for the schema's lack of parameter documentation.

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 identifies the resource and return contents: a template's full prescription with exercises, sets, reps, weight, Vita level, side, and rest. However, it lacks an explicit action verb like 'get' or 'retrieve', and it does not distinguish this tool from siblings such as list_my_workouts or get_session_detail. An agent can infer the purpose from the name plus the detailed return description, but the description alone is not fully self-contained.

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 no when-to-use guidance, no conditions for selecting this tool over alternatives, and no prerequisites. Sibling tools like list_my_workouts and get_session_detail are not mentioned, leaving the agent to infer usage from the name alone.

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

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

With no annotations, the description carries the burden well: it discloses the 200-item limit, in-order processing, deduplication against earlier accepted items, return fields, and that dry_run writes nothing while returning an identical report. It does not enumerate the referenced 'single-write rules' or mention permissions/rate limits, so it is strong but not fully self-contained.

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 efficiently front-loaded: bulk-save purpose first, then item shape, then batch rules, then return shape and dry-run recommendation. Every sentence supplies operational 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?

No output schema or annotations exist, so the description must cover behavior, parameters, and returns. It does: it defines batch limits, item fields, dedupe/order behavior, the full return shape, and dry_run semantics, which is complete enough for an agent to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate and does: it lists the fields for each fact item (text, kind, category, severity, scope, supersedes, expires_days, source) and explains dry_run's behavior and reporting. This adds substantial meaning beyond the generic array/object and boolean schema.

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

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

States a specific verb and resource: 'Bulk-save facts (up to 200)'. It also distinguishes the tool from sibling remember_fact by describing bulk items with the same fields and by noting batch ordering and deduplication behavior.

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 use case ('curate the legacy facts') and an explicit dry-run workflow: use dry_run=true first, show the user, then run it for real. It implies single writes should use remember_fact by contrasting bulk-save with per-item single-write rules, though it does not state that alternative explicitly.

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 does disclose meaningful behavior: results are deduplicated by name and each entry carries `owned` and `usable` flags. It omits auth requirements and pagination/refresh behavior, so it falls short of full disclosure for an unannotated 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: the catalog contents and dedup rule come first, then the actionable follow-up. Every clause earns its place with no filler.

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

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

There is no output schema, so the description must convey return shape, and it does cover dedup plus the owned/usable flags. It is slightly thin on the full field set of each catalog entry, but it is adequate for a zero-argument list tool.

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

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

The tool takes zero parameters (empty schema), so the baseline is 4; there is nothing for the description to clarify beyond that and it does not misrepresent any inputs.

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

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

States a specific resource (Speediance's accessory catalog) with concrete examples (bars, handles, rope, benches, AeroRow) and clarifies the deduplication key. This clearly distinguishes it from sibling list tools such as list_exercises or list_my_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?

The description gives a clear workflow: look up accessories here, then persist ownership via set_preferences(owned_equipment=[names]). It names the complementary tool explicitly, but offers no when-not-to-use guidance or conditions under which the catalog should be skipped.

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 delivers: first call downloads the library (~30 s), subsequent calls use a 24-hour cache, movements tied to unusable_equipment are ALWAYS hidden, avoided movements are hidden unless include_avoided=true, and preferred movements sort first. These are non-obvious behaviors an agent cannot infer from the schema.

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

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

Front-loads the purpose, then groups filters, then the visibility rules, ending with the latency/cache note. Dense but every clause carries information; only mild compression from the bullet-ish symbol notation is lost.

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 no-annotation, no-output-schema tool with 8 params, the description supplies the key behavioral and filtering semantics an agent needs. The residual gap is `limit` semantics and no hint about the shape of returned exercise entries, which is minor for a search tool.

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

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

Schema coverage is 0%, so the description must compensate, and it does for six of eight parameters: query (name words), muscle (with examples), category (library tab), kind (with the 'reps'/'timed'/'level' values), owned_only (with how to set it), and include_avoided. It leaves `limit` and the exact meaning of `equipment` unaddressed, so it is strong but not complete.

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 ('Search the Speedience exercise library') and enumerates the exact filter dimensions, so an agent can immediately distinguish it from get_exercise (single-lookup) and browse_programs. The scope is unambiguous.

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

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

Gives clear usage context via the filter semantics and the two set_preferences cross-references (owned_equipment, unusable_equipment), implying when results will be filtered. It stops short of explicitly stating when to prefer this over get_exercise or browse_programs, so no exclusions are named.

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

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

With no annotations the description carries the full burden and does well: it discloses ordering, the default scope, and precisely what include_archived surfaces (superseded, forgotten, expired, legacy). It does not mention return format beyond the field list or any auth/limit behavior, but for a read-only lister that is minor.

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

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

Two dense sentences that front-load the ordering and scope before the filter details. Every clause carries information, though the second sentence packs three separate concerns tightly.

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 3-param read tool with no annotations and no output schema, the description supplies the default behavior, the archival expansion, the filter domains and the returned fields (status, supersedes chain, source, legacy flag). Little an agent needs 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 must compensate, and it fully enumerates the values for kind (constraint | preference | observation | goal) and category (injury | equipment | schedule | body | nutrition | note) plus the semantics of include_archived. This is exactly the missing information the schema lacks.

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

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

States a specific verb and resource ('audit surface for the curated facts') plus the ordering ('oldest first'). It is clearly distinct from the mutation siblings remember_fact, forget_fact and import_facts, so an agent can place it without opening the schema.

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

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

Gives a clear default ('active facts only') and the condition that selects the other mode ('include_archived=true returns the full history'). It also states the two filtering dimensions. It stops short of explicitly naming when-not or naming sibling alternatives, so it is clear context rather than full routing guidance.

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

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

With no annotations, the description must carry the full behavioral burden. It discloses scope (user-owned, custom templates) and the existence of a `code` identifier, but says nothing about ordering, pagination, result count, or whether scheduled/historical workouts are included, which is a notable gap for an unannotated 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 compact sentences with no filler; the resource is front-loaded and the follow-up usage note is placed after. The first sentence is a fragment lacking a verb, but that does not hurt density or readability significantly.

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

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

No output schema exists, so the description ideally should sketch the returned template shape (fields beyond `code`). It identifies the resource and one key field but leaves the rest of the return structure and any ordering/pagination behavior unspecified, which is only partially adequate for a no-schema list tool.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description adds a small amount of value by naming the `code` field an agent will consume from the results, which aids downstream parameter usage even though nothing is being 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 (the user's saved custom workout templates), which is a specific, distinguishable resource from siblings like list_exercises or browse_programs. It is phrased as a noun fragment rather than an explicit verb+resource, and does not directly contrast with get_workout, but the implication of a listing operation is clear from the name and content.

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

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

It gives real downstream guidance — pair a template's `code` with get_workout, update_workout, delete_workout, or schedule_workout — which is useful chaining context. However, it never states when to call this tool versus alternatives (e.g., before scheduling, to discover codes), leaving the invocation trigger implied.

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 well: it discloses that an ambiguous name marks nothing and returns candidates, that avoided moves are never programmed unless requested by name, and that the reason note is surfaced to the user in the web app. Auth/error behavior is unstated, but the key side effects and failure mode are covered.

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

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

The core behavior, identification strategy, and trigger condition are front-loaded in the first three sentences, with the optional reason note trailing appropriately. The inline ★/⊘ glyphs add density without much cost, but the passage is otherwise waste-free.

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

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

For a 4-parameter mutation tool with no annotations and no output schema, the description supplies the missing pieces: state values, id/name resolution, ambiguity outcome, and downstream effect on programming. Nothing critical for correct invocation is obviously absent, though it never states the return shape or error behavior.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: it defines the legal `mark` values (preferred/avoided/none), explains `name` as the fallback when no id exists plus its ambiguity behavior, and clarifies `reason` as an optional short note shown to the user. `group_id` is named but not further characterized.

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 (mark) and resource (a movement), and enumerates the exact states it can set: 'preferred', 'avoided', or clear ('none'). It is clearly distinguishable from siblings like set_preferences or remember_fact, which operate on global settings and facts rather than per-exercise markers.

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

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

It gives an explicit triggering condition: 'Use when the user makes a LASTING per-exercise preference clear (it always hurts / they love it)', which sharply separates it from transient reactions. It also explains the id-vs-name routing path. It stops short of naming alternatives (e.g. remember_fact, set_preferences) or stating when NOT to use it.

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

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

No annotations, so the description carries the behavioral burden and does well: it discloses the 600-char cap with no truncation, the silent-no-save dedup behavior with saved=false, in-write archival of superseded facts, and expiry for temporary facts. Remaining gaps are the response payload shape and any auth/permission requirements, which are not stated.

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

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

Front-loaded with the core action and cap, then structured parameter-by-parameter with no filler sentences. It is dense and long, but nearly every clause carries required semantic content given the zero schema coverage.

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

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

For an 8-parameter, no-annotation, no-output-schema tool this is close to complete: it covers every parameter's meaning plus dedup, archival, and expiry behavior. The only shortfall is that the success response contents beyond saved=false and the returned near-match are left implicit.

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 and it does: it enumerates kind values (constraint/preference/goal/observation) with the severity rule, category values (injury/equipment/schedule/body/nutrition/note), and defines scope, supersedes, expires_days, and source with its default. All 8 parameters are given meaning beyond their bare titles.

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 ('save ONE durable training fact') and defines the exact kinds/categories the fact can take. It also distinguishes itself from the sibling set_preferences by declaring what it must not store (bodyweight/load numbers), so an agent can route correctly.

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

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

Gives explicit when-to-use (durable facts), when-not (bodyweight/unit and load numbers, route to set_preferences), and a correction path via supersedes rather than adding a second version. The dedup fallback ('re-send with supersedes=[its id]') tells the agent exactly what to do on the near-match branch.

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 full burden, and it does disclose the meaningful dual behavior that add=false removes the entry. It omits other behavioral traits an agent needs for a calendar mutation: what happens if the workout is already scheduled, permission/auth requirements, 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?

One sentence, front-loaded with the primary action and the key parameter facts; every clause earns its place with no filler.

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

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

For a 3-parameter mutation with no annotations and no output schema, it covers the parameters adequately but leaves out the relationship to unschedule_workout, conflict behavior, and error/permission context that an agent would need to choose and call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it explains that `code` comes from list_my_workouts, that `date` is YYYY-MM-DD, and that `add=false` removes rather than adds. Only mild gaps remain (no note on default value or accepted code formats beyond the sibling reference).

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 verb+resource ('put a saved template on a day') with the required identifier source and date format, which is well beyond a tautology. It does not distinguish itself from the sibling unschedule_workout, and the add=false removal path actually overlaps with that sibling, leaving ambiguity about which tool owns removal.

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 tells the agent where the `code` comes from (list_my_workouts), which is genuine usage context. However it gives no explicit when-to-use vs. alternatives, and does not resolve the overlap with the dedicated unschedule_workout 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 no annotations, the description carries the full load and largely delivers: it discloses merge semantics for load_anchors (other anchors kept), removal via null/0, replacement semantics for owned_equipment, and the downstream effect that unusable_equipment hides movements. What it omits is auth/permission needs and the merge/replace behavior for the remaining fields (goal, training_days, session_minutes).

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 general update semantics before per-field detail, and dense with no filler. It is long but every sentence conveys a distinct rule; a semicolon-separated field-per-clause layout keeps it scannable.

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% schema coverage, the description does well on semantics and downstream effects but leaves three parameters and any return/permission behavior unstated. It is adequate but not fully complete for a 6-param mutator.

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 richly documents 3 of 6 parameters (load_anchors, owned_equipment, unusable_equipment) including value format (group_id -> weight in displayUnit). However goal, training_days, and session_minutes remain undocumented in both schema and description, leaving half the surface 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+resource ("Update structured preferences") and immediately scopes it with "only the fields given change". It also names and rules out the sibling remember_fact, so an agent can distinguish this from the free-text path without opening either schema.

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

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

Gives clear routing: free-text facts belong in remember_fact, and equipment names should come from list_accessories. It lacks an explicit overall when-to-use trigger (e.g. vs get_preferences), but the alternative-tool guidance is unusually concrete.

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 does useful work: it discloses the estimation method (Epley), the data source (most recent best set), an explicit fallback (saved load anchor), and that the result reports its basis. It omits whether the tool mutates state or requires permissions, but 'suggest' plus the fallback chain give solid 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 tight sentences, front-loaded with the core function and followed by the estimation source and fallback. No filler and the key computation detail arrives before the supporting logic.

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 computation tool with no output schema and no annotations, the description explains what drives the result and that it reports its basis, which is enough to call it correctly. It falls short only on the un-described scoping parameters (`exercise`, `groupId`) and any output format hint.

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 explains `rir` as 'reps in reserve' and ties `reps` to the output, adding real meaning for two of four parameters. However `groupId` and `exercise` (the scoping parameters) are entirely undocumented in both schema and description, leaving a significant gap.

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

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

States a specific verb (suggest) and resource (working weight) and even names the inputs (`reps`, `rir`) that determine the result. It is clearly distinguishable from read-oriented siblings like get_strength_profile or get_exercise_history because it computes a value rather than retrieving stored data.

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

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

The scenario is implied (choosing a working weight for a set), but the description never states when to use this versus alternatives such as get_strength_profile or get_exercise_history, nor any prerequisites (e.g., requires prior logged sets). Usage is inferable but unstated.

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 it discloses almost nothing: no statement of whether the operation is idempotent, what happens if nothing is scheduled on that date, whether prior data is lost, or what permissions are required. For a mutation tool this is a substantial gap.

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

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

A single tight sentence with the action front-loaded and the format hint appended; nothing is wasted. It is arguably too terse for the mutation it performs, but as structure it 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?

For a two-required-parameter mutation tool with no annotations, no output schema, and zero schema description coverage, the description leaves the agent without enough to call it confidently — notably the meaning of 'code' and the effect on any existing schedule entry.

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 both parameters. It does clarify the date format (YYYY-MM-DD), which adds real value, but 'code' is never explained at all, leaving half the required inputs 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?

The verb phrase 'take a scheduled template off a day' identifies the resource (a scheduled workout template) and the action (removal from a calendar day), which is enough to separate it from schedule_workout. However, the informal wording and the unexplained relationship between 'template' and the 'code' parameter make the exact object being modified less clear than a named entity would.

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 unschedule versus deleting a workout (delete_workout) or editing it (update_workout), and no mention of prerequisites such as needing an existing scheduled entry. The inverse sibling schedule_workout is never referenced, so the agent must infer the pairing.

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 it does well: it discloses in-place mutation, that omitted fields are left unchanged, that exercises replaces the entire list, that changes are verified by read-back, and what the response carries (hardConstraints, legacyUnreviewed). It omits any statement about permissions/authorization or irreversibility of the overwrite.

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 semantics (in-place edit, no new slot) and every sentence adds operational value; four sentences is defensible for a mutation with this much semantics. It is dense, with parentheticals doing additional work, but not padded.

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

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

For a 3-parameter mutation with no annotations and no output schema, the description covers mutation semantics, replacement behavior, verification, and even the response payload's notable fields. Remaining gaps are authorization requirements and error/failure modes, which are secondary 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?

Schema coverage is 0%, yet the description compensates: template_id is explained as code (preferred) or numeric id, exercises is documented as a full-list replacement whose element format matches create_workout, and name falls under the "omitted fields keep their current value" rule. Nested exercise-object shape is only pointed at via another tool rather than described.

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 ("Edit a template in place") and immediately distinguishes the operation from creation with "an edit never uses a new slot." It also names the resource key precisely (template_id as code or numeric id), so an agent can tell it apart from create_workout/delete_workout without opening any schema.

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

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

Gives real workflow guidance: "start from get_workout" before supplying exercises, and the read-back + re-check instruction tells the agent how to verify completion. It never explicitly states when *not* to use it (e.g., scheduled vs template edits, or when to prefer create_workout), so it stops short of full when/when-not routing.

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