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

Annotations already declare destructive, openWorld, and non-idempotent, and the description adds real operational context: reservation recheck, at most one standard request, reconciliation with fresh reads, and a pending late-credit-loss warning with a new reference that must not be retried. This is exactly the behavior an agent needs before an irreversible call.

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

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

Front-loaded with the core action, then prerequisites and failure handling, with no filler sentences. Some phrasing is opaque jargon ("standard request", "fresh reads", "publication preference switches") that costs a little clarity.

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 destructive action with an output schema, the description covers preconditions, the confirmation gate, retry policy, and the pending-warning outcome. Only the actionReference provenance and the choice among cancellation siblings remain unstated.

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

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

Schema coverage is 0%, so the description must carry the load. It explains the meaning of confirmed: true (separate account-holder confirmation gate) but says nothing about actionReference beyond "exact prepared booking", leaving the 64-hex reference format and provenance to the schema pattern 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?

"Cancel one exact prepared booking" gives a specific verb and resource and implies the prepare-then-execute split that distinguishes it from prepare_booking_cancellation and execute_late_booking_cancellation. An agent can tell this is the terminal cancellation step for a single previously prepared booking.

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?

States clear preconditions: show the exact full preview, obtain separate account-holder confirmation, and pass confirmed: true; also warns not to retry automatically after a late-credit-loss warning. The only gap is that the sibling alternatives (prepare_booking_cancellation, execute_late_booking_cancellation) are not named as the paths for other cases.

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

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

Annotations cover only readOnly/openWorld/idempotent/destructive, so the description carries the rest and does: at most one write per reference, recheck target and eligibility, reconcile with fresh reads, and treat an uncertain result as requiring manual inspection rather than a retry. The two-branch confirmation protocol (confirmed: true vs omitting confirmed) is behavioral detail no annotation could express.

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 operation and precondition, then the confirmation policy branch. Dense but every clause is load-bearing except the slight redundancy between "obtain separate account-holder confirmation" and "do not ask for another confirmation."

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

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

An output schema exists, so return values need no prose. For a non-idempotent open-world write, the description supplies the missing pieces: single-write discipline, pre-write revalidation, post-write reconciliation, and the escalation path for ambiguous outcomes.

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 for both parameters: actionReference must be fresh from prepare_booking_creation, and confirmed is conditional on the resolved writeConfirmationPolicy. The only gap is that the 64-character hex pattern of actionReference and any staleness/expiry limit are left to the schema regex.

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 ("Create exactly one booking") plus a hard precondition ("from a fresh prepare_booking_creation reference"), which cleanly separates it from the prepare_* sibling that produces that reference. An agent can identify the operation and its input provenance 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: use prepare_booking_creation first, then this; read writeConfirmationRequired from preparation and the bookingCreation setting from account context to decide whether to include confirmed. It also names the exclusion — "a query or preview-only request never authorizes execution" — which is exactly the when-not guidance most definitions omit.

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

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

Goes well beyond the annotations: at most one write, no retries, a reread after the save, and a full status vocabulary (confirmed, rejected, uncertain, stale) with the exact stale triggers (account, gym, or confirmed time zone changed; nothing sent). The no-retry statement is meaningful reinforcement of idempotentHint=false and destructiveHint=false without contradicting either.

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 the confirmation gate, then the retry and status behavior. The final status clause is a long semicolon-and-parenthetical run-on, which costs a little readability, 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?

For a non-idempotent write with an output schema, the description covers everything the agent must decide: whether to call at all, that it must not retry, and how to interpret each outcome. Return-value detail is appropriately left to the output schema.

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

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

Schema coverage is 50%: 'confirmed' is self-documented, but 'actionReference' has only a hex pattern and no prose. The description compensates by tying the reference to a specific preview from prepare_exercise_result and to the confirmation gate, though it does not say how the reference is obtained or how long it stays valid.

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 ('Save the exact strength result') and anchors it to the sibling that produces the input ('previewed by prepare_exercise_result'), so an agent can distinguish it from the prepare and deletion siblings 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?

Explicit precondition (only after the account holder explicitly confirmed it) plus an explicit negative case: for an 'uncertain' status, ask the account holder to check their activity instead of saving again. That is a named alternative action and a when-not-to-retry 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?

Annotations already flag destructive/non-idempotent/openWorld, but the description goes further: it discloses the internal sequence (recheck calendar, one request, no retries, reread calendar) and enumerates the three terminal statuses including the stale case where nothing is sent. That is exactly the context an agent needs before an irreversible call.

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

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

Three tight sentences: action first, precondition second, execution/outcome semantics last. No restated name or title, no filler.

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

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

For a destructive one-shot tool with an output schema present, the description covers sequencing, safety gate, retry policy and status meanings, so it is close to complete. The remaining gap is the lifecycle of actionReference (validity window, reuse across calls), which the description leaves 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?

The schema documents 'confirmed' but leaves 'actionReference' bare (50% coverage); the description compensates by tying that reference to the preview produced by prepare_exercise_result_deletion and by emphasizing the explicit-confirmation gate. It does not say whether the reference expires or must be used unmodified, so it falls short of full compensation.

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 ('Delete the exact own activity') and pins it to the preceding sibling 'prepare_exercise_result_deletion', so an agent can distinguish it from prepare_exercise_result_deletion or execute_exercise_result 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 an explicit precondition ('only after the account holder explicitly confirmed it') and an explicit routing rule (the activity must be the one previewed by the prepare sibling). It also states the call-once policy ('sends at most one deletion request, never retries'), which tells the agent when not to re-invoke.

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 flag destructive, non-idempotent and open-world, and the description adds real context beyond them: the possibility of credit loss, the requirement for separate account-holder confirmation, the one-request ceiling, and the instruction to reconcile with fresh reads rather than retry uncertain writes. It also discloses a limitation absent from annotations – that no refund or balance is verified.

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 precondition and the confirmation requirement come first, which is the right ordering for a guarded destructive tool. The prose is telegraphic and some clauses are comma-spliced, but no sentence is filler given how tightly each constraint matters for a mutation that can lose credit.

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 open-world destructive tool with an output schema and annotation coverage, the description supplies preconditions, retry policy, reconciliation guidance and explicit verification gaps, which is close to complete. The remaining gap is that it never plainly states the outcome action (that the booking is actually cancelled late) or what the caller should do if the confirmation is declined.

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

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

Schema description coverage is 0%, so the description must carry the load and largely does: it explains that actionReference must be the new late reference (not a reused one) obtained from the freshly rechecked reservation, and that confirmedCreditLoss: true represents a separate account-holder confirmation rather than a default. It does not explain the 64-hex format, though the schema pattern already conveys that.

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 makes the tool's role identifiable: it is the escalation step that surfaces the concrete still-booked target plus potential credit loss and collects an explicit confirmedCreditLoss consent before proceeding. It is less crisp than a plain 'cancel X late' statement because the actual operation is only implied through protocol steps, and it never names the sibling execute_booking_cancellation it extends.

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?

Use conditions are explicit and narrow: only after a fresh standard cancellation reports pending-credit-loss, only with the new late reference, at most one late request, no automatic retry on an uncertain write. What is missing is a direct pointer to the alternative path (e.g. plain execute_booking_cancellation) for the case where the precondition is not met.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real context on top: search coverage is limited and candidates do not prove personal records. It also discloses the account scoping constraint (no member selector). It stops short of describing result ordering or how many candidates are returned.

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

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

Four short sentences, front-loaded with the search action and the resolution rule. The phrasing is dense and slightly jargon-heavy ('is read for this account'), 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 an output schema present, return-value details are rightly omitted, and the description covers the two things an agent actually needs: the resolution workflow and the caveat that a match does not imply a personal record. Only the candidate-list shape and pagination limits 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 carry the load, and it does: 'name' is the search key, and 'exerciseId' is defined as an explicit source exercise ID that must come from the candidate set. It does not mention the length bound on name or that exerciseId must be a positive integer, but the meaning of both parameters is clear.

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 — 'Search bounded exercise candidates by name' — plus the resolution rule (exact/sole candidate is read, ambiguity needs an explicit ID). It is clearly distinct in behavior from get_exercise_1rm, though it never names that sibling to sharpen the contrast.

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 selection conditions: an exact or sole plausible candidate is resolved automatically, while ambiguity forces the caller to pass an exerciseId drawn from the returned candidates. It also excludes a whole class of input ('No member selector is accepted'), but does not explicitly say to call get_exercise_1rm afterwards or name any 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 cover read-only, idempotent, non-destructive and open-world, and the description goes well beyond them: it documents the GYM_REQUIRED error path, the fallback rule (the only gym if none chosen), the explicit Europe/Madrid time-zone assumption versus a user-confirmed zone, and a trust-boundary warning that gym names are untrusted external content. These are exactly the behavioral traits an agent needs to react correctly to the result and to the failure case.

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 primary function is front-loaded, but the middle sentence is a long run-on that enumerates defaults sub-fields (workout class, participant filter, weekly booking plan structure, weekday multiplicity) already documented by the output schema. That enumeration dilutes the high-value sentences about GYM_REQUIRED, the time-zone assumption and the untrusted source names.

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 zero parameters, rich annotations and an output schema, the description covers everything an agent needs: what the call does, its failure mode, its fallback rules, an explicit default assumption, and a data-trust caveat. Nothing material is left to inference for a context-gathering tool of this simplicity.

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 full schema coverage, so there is nothing parameter-wise for the description to compensate for; baseline 4 applies. The description instead characterizes the returned shape (gym, defaults with class, participant filter, weekly plan entries, friend count), which is useful orientation even though an output schema exists.

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

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

The first sentence names a specific verb and resource: authenticate the configured account and report its gym, plus the account's defaults. It is clearly distinct from every sibling (all booking/exercise operations), though the description never explicitly says so or names an alternative. The added detail about the GYM_REQUIRED condition sharpens what the tool returns.

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 rather than stated: this is evidently the bootstrap/context call, but the description never says 'call this first' or 'use this before prepare_booking_creation to resolve the gym'. The one genuine usage signal is the GYM_REQUIRED failure mode, which tells the agent when the call cannot resolve a gym and what the account holder must do on the settings page.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, yet the description adds substantive context beyond them: history is partial and not an exhaustive interval, reservation/late-cancellation labels do not prove attendance, and source names must be treated as untrusted content (a prompt-injection warning). The gym-zone caveat ("may be assumed") also discloses an implicit-context dependency. Some phrasings, such as "source flags remain explicit," are too terse to be fully actionable.

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 adds a distinct caveat rather than repeating itself. It is dense but not padded. Minor cost: several compressed jargon phrases ("source flags remain explicit") force the reader to decode intent.

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

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

With an output schema present, return values need no explanation, and the description does well on trust and data-quality caveats. What is missing is the relationship to sibling tools and an explanation of how the gym context is established given the empty input schema. For a zero-argument read in a crowded booking toolset, those gaps matter.

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

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

The tool takes zero parameters, which normally sets a baseline of 4. However, the description repeatedly references a "verified gym" and a "reported gym zone" without explaining where that input comes from when no parameters exist, leaving an unresolved question about how the call is scoped. That ambiguity in an otherwise parameterless tool pulls the score down.

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

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

The opening sentence names a specific verb and resource ("Read the account holder's available historical booking view") and adds a scope detail ("at a verified gym, newest first"). It is clearly distinct from get_upcoming_bookings by the word "historical," though the sibling is never named. The phrasing "available historical booking view" is slightly abstract — it does not say whether it returns bookings, classes booked, or attendance records.

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

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

No when-to-use or when-not-to-use guidance is given, and no alternative is named despite a large sibling set (get_upcoming_bookings, get_personal_activity). The notes about limited history and non-exhaustive intervals are coverage caveats, not routing guidance. An agent must infer from the word "historical" alone when to prefer this over the other booking tools.

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

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

Annotations already cover read-only and idempotent safety, but the description adds behavior the annotations cannot: the result is volatile ('can change until the class starts') and participant names are other members' personal data to be used only for answering the account holder. Those two constraints materially shape how an agent should use and cache the output.

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 verb and the identity key, then moves to filter and caveats. The mid-sentence enumeration of return fields (user ID, name, photoUrl, friendName) is largely redundant with the output schema and slightly bloats an otherwise tight description.

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

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

An output schema exists, so return-value explanation was optional, yet the description still flags the friendName preference rule and the totalParticipants echo of the applied filter. Combined with the freshness window and privacy caveat, an agent has everything needed to call this correctly and interpret the result.

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

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

Schema coverage is only 25% (just the filter enum is documented), yet the description compensates by specifying that date is gym-local, that className must be exact, and that startTime is HH:mm. It does not restate the schema's max/min lengths or the date pattern, which is fine, but the 'exact name' matching rule could be stated more crisply.

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 ('List who is booked into one exact class session') and pins the identity key to date + exact class name + HH:mm start time. That keying distinguishes it cleanly from the sibling get_class_sessions, which lists sessions rather than occupants.

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 requirement for an 'exact' class name and start time implicitly tells the agent it must first resolve a session, and the filter's default-from-configuration rule is spelled out. It stops short of naming get_class_sessions as the prerequisite step or stating when to prefer 'friends' vs 'all' beyond the default.

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

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

Adds substantial behavior beyond the readOnly/idempotent annotations: dates are gym-local under a reported IANA time zone that may be assumed, the interval is inclusive, occupancy means occupied places not attendance or booking eligibility, each session carries bookingOpensAt/bookingOpen, source names are untrusted content, and the call is atomic ('all days must succeed; errors return no schedule'). That last point is the kind of all-or-nothing failure semantics an agent cannot get from 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?

Front-loads the resource and interval, then layers filters, occupancy semantics, booking-window behavior, and safety/error notes. Six dense sentences with little waste; 'which may be assumed' is slightly vague about the time zone fallback.

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

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

An output schema exists, so return shape needn't be explained, yet the description still clarifies the meaning of bookingOpen/bookingOpensAt, which materially affects agent behavior. Missing only operational bounds such as maximum date-range span or pagination for very wide intervals.

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

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

Schema description coverage is 0%, so the description must carry the params, and it does: startDate/endDate form an inclusive gym-local interval, className is an exact-match filter, startTime is an HH:mm exact filter, and matches are retained rather than collapsed. It leaves minor ambiguity (case sensitivity of className, whether startTime matches only exact session starts) but covers all four parameters.

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

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

States a specific verb and resource: querying an inclusive interval of gym-local calendar dates at a verified gym, with optional className/startTime filters. It clearly separates itself from sibling tools like get_class_participants and get_upcoming_bookings by being a schedule-range query, though it never names those siblings explicitly.

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

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

Usage is implied rather than prescribed: the reader can infer this is the schedule-lookup tool, and it warns not to book while bookingOpen is false, which implicitly routes booking to the prepare/execute booking siblings. It never states when NOT to use it or which sibling to prefer for a single session or participant list.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds real value beyond that: the account ID is derived internally (no caller-supplied identity), the 'lbs' chart field alone is not a trustworthy unit, source names are untrusted data (an injection warning), and other RM/WOD series are returned only as counts. Some wording ('corroborating same-action history text') is opaque, keeping it short of 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?

Four dense sentences with the core action front-loaded and caveats trailing in roughly descending importance; no filler. The unit-provenance sentence is grammatically awkward and costs some clarity, but nothing is redundant.

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

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

An output schema exists, so return values need not be described, yet the description usefully flags what comes back (other RM and WOD counts, limited exercise-detail coverage). For a one-parameter read tool it covers preconditions, identity derivation, data-trust, and scope limits; only error/inaccessible-ID behavior is 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% for the single exerciseId parameter, so the description must carry the load. It does clarify that the ID must be a 'known source exercise ID' subject to gym accessibility, which is meaningful beyond the bare integer, but it gives no format, range, or example, and never says what happens when the ID is unknown or inaccessible.

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: read the account holder's latest dated 1RM for one known source exercise ID at an accessible gym. It implicitly distinguishes itself from find_exercise_1rm by requiring a 'known' source exercise ID, but never names that sibling or get_exercise_rm_progression, so the reader must infer the routing.

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 precondition 'one known source exercise ID' implies the ID must already be resolved (presumably via find_exercise_1rm) and that gym accessibility is checked, but no alternative is named and no when-not-to-use case is stated. Limitations such as 'no complete catalog or lifetime history is claimed' hint at scope boundaries without explicit 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?

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuine behavioral context beyond that: results are split into separate per-RM series, source-marked new RM events are labeled distinctly, optional WOD entries stay as separate context rather than merging, and the view is scoped to the caller's own account with incomplete history.

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 compact sentences with the resource and scope front-loaded, followed by output-shape caveats and a limitation disclaimer. No filler, though the phrase 'remain distinct context' is slightly abstract for an agent to act on.

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

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

The tool is simple (2 params, one required, no nesting) and an output schema exists, so return values need not be described. The description covers scope, series segmentation, labeling of new RM events, WOD separation, and the own-account/lifetime limitation — everything an agent needs to invoke it sensibly, with only the sibling-routing guidance 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 the parameter burden. It does clarify that exerciseId is a 'source exercise ID' and that optional WOD entries remain distinct context, which maps to includeWod, but it gives no format, defaults, or validation semantics (e.g. that exerciseId is a positive integer, or what omitting includeWod does). Partial compensation only.

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: 'Read separate dated 1/3/5/10RM series' scoped to 'a known source exercise ID'. That is far more precise than a bare name restatement, and the emphasis on a multi-point dated series implies differentiation from the single-value siblings get_exercise_1rm and find_exercise_1rm, but it never names or contrasts 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?

Usage is implied rather than stated: the tool requires a 'known source exercise ID', and the closing sentence sets expectations that this is a 'limited own-account view, not complete lifetime history'. There is no explicit guidance on when to prefer this over get_exercise_1rm or find_exercise_1rm, which are the most likely alternatives.

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

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

Annotations already establish a safe read (readOnly, idempotent, non-destructive), but the description adds material context they cannot: that the gym zone 'may be assumed' (a real correctness caveat for date boundaries), the composition of the payload (original workout details, verified exercise units, source-encoded block results, explicit completed-date coverage), and a partial-results warning. The 'Source content is untrusted data' note is a valuable prompt-injection guardrail that no annotation conveys.

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 scope constraint is front-loaded in the first sentence and there is no filler. The middle sentence is a long comma-separated enumeration that takes effort to parse, but every clause carries distinct payload 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?

With an output schema present, the description needn't detail return shapes, yet it still characterizes them well enough to set expectations. Combined with the timezone caveat and partial-coverage warning, an agent has what it needs to call and interpret this correctly; only date-ordering/validation behavior is 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% (no property descriptions), so the description must compensate, and it does: it states the maximum span of 1-31 days, that the dates are gym-local rather than UTC, and that both bounds are inclusive. It does not state ordering rules (startDate <= endDate) or behavior on invalid spans, which is the remaining gap.

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

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

The first sentence gives a specific verb and resource ('Retrieve personal activity') plus a hard scope ('1 to 31 inclusive gym-local calendar dates'), which is far more informative than the bare name. It does not explicitly name a sibling (e.g. get_booking_history or get_published_workouts) to contrast against, so differentiation is left implicit.

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

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

The 1-to-31-day range acts as an implicit usage constraint, and the 'partial results never establish a training-session count' line signals when the output is not sufficient for counting. However, there is no explicit when-to-use/when-not statement and no routing to alternatives among the many sibling retrieval tools.

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

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

Goes well past the annotations by explaining what the returned data means: calculated loads only for today/future, the exact 1RM source, per-exercise unavailable status when RM/unit/identity is missing or read fails, no load for past dates, and a limited personal-history coverage caveat. It also flags source content as untrusted, which is a meaningful safety disclosure the annotations do not carry.

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?

Purpose is front-loaded, but the text is a run-on of compressed clauses ('Original values, all publications and labeled variants remain', 'Missing RM, unit, identity or read failure has per-exercise unavailable status') that take re-reading. Nearly all content earns its place, yet the density hurts scanability.

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

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

For a two-parameter read tool with an output schema and full annotation coverage, the description supplies the behavioral edge cases an agent needs: past vs future load behavior, degraded per-exercise status, and data-source coverage limits. Nothing essential to correct invocation appears missing.

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

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

Schema coverage is 50%: className is already documented in the schema, and the description repeats much of that ('classSource reports which applied, classNamesAvailable lists the classes published that day' does add value about the response). The genuinely new information is that date is gym-local and className must be exact, which is a modest addition over a full date-format schema.

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

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

The first clause names a specific verb and resource ('Retrieve published workout alternatives') and pins scope to 'gym-local date and exact className'. It is clearly distinguishable from get_published_workouts_range in spirit, but it never names that sibling, so the differentiation is left implicit.

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

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

Gives an explicit conditional rule for the optional parameter: 'omit className to use the class configured for the gym, and pass it only when the account holder names another class.' That is real when/when-not guidance. It stops short of stating when to prefer this tool over get_published_workouts_range.

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

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

Annotations already cover read-only, idempotent, non-destructive, open-world behavior, and the description adds real context beyond that: one list read per day, detail requests scoped to the requested class, per-day available/unavailable status, a classNamesInRange summary, and a trust warning that source content is untrusted. The only weak spot is the cryptic '%RM enrichment matches get_published_workouts for today and later' clause, which is not self-explanatory.

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 verb, resource and range, then the sibling comparison, then output and trust notes — a sensible escalation. It is dense but every sentence carries information; minor cost is jargon like '%RM enrichment' that assumes prior context.

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

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

With annotations, full schema coverage and an output schema already present, the description covers the remaining gaps an agent needs: when to prefer it, the 14-day bound, how each day is reported, the classNamesInRange helper, and the untrusted-source caveat.

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

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

Schema coverage is 100%, so the baseline is 3; the description lifts it modestly by framing what the date range is typically used for ('today, a given weekday, or this week') and by restating the omit-vs-pass rule for className in operational terms. It does not add format or validation detail beyond the schema, so it stays below the top mark.

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 ('Retrieve published workouts of one exact className') plus the exact scope ('every gym-local date in an inclusive range of up to 14 days'). It also names the sibling it supersedes (get_published_workouts), so an agent can distinguish it 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?

Explicitly routes the agent: 'Prefer this over repeated get_published_workouts calls' with the reason (one read per day, details only for the requested class). The className rule — omit for the gym-configured class, pass only when the account holder names a class — is a clear when-to-use condition.

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

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

Annotations already declare the safe-read profile (readOnly, idempotent, non-destructive), yet the description adds substantial context: time-zone assumptions, the booked/waitlisted/unknown state model, unbounded coverage horizon, untrusted external source names, and the guarantee that a failed lookup returns an error rather than an empty view. The error and trust disclosures are exactly the kind of behavioral detail an agent cannot get 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?

Six sentences, each carrying a distinct semantic payload (scope, time zone, states, coverage limits, trust, failure mode), with purpose front-loaded. The density is high but no sentence is redundant, though the phrasing is slightly compressed for readability.

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 tool with an output schema and full annotations, the description covers the remaining gaps an agent needs: what counts as a booking, the absence of a date horizon, content trust, and error semantics. Nothing required to call and interpret it correctly appears to be 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 has zero parameters, which sets the baseline at 4 per the rubric. Coverage is inherent in the schema, and the description's note that the gym time zone is reported (and possibly assumed) clarifies how the implicit context affects results without introducing phantom 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?

The first sentence gives a specific verb and resource: "Read the account holder's upcoming booking view at a verified gym," which is concrete enough to distinguish this list tool from mutation siblings like prepare_booking_creation. It never names a sibling it is not, so the differentiation from get_booking_history or get_class_sessions must be inferred from the word "upcoming."

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 interpretation rules (absence of a booking cannot prove no booking on an arbitrary date, reservations do not establish attendance) that help an agent use the result correctly. However, it never states when to choose this tool over get_booking_history or get_class_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?

Annotations declare readOnlyHint=true and the description reinforces this with 'Preparation sends no POST,' then adds real value beyond the annotations: ambiguous targets yield no reference, credit-loss and cancellation-window (AIMHARDER_CANCELLATION_WINDOW_MINUTES) effects are surfaced, and confirmation is required before execution. The reference to 'confirmed: true' is slightly misleading since this tool's schema does not accept that field, but it does not contradict the read-only profile.

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

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

Front-loaded with the action and its key constraint, and every sentence carries operational content. The opening sentence is overloaded and reads awkwardly, 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 an output schema present, the description need not explain the preview payload, and annotations cover the safety profile, so the remaining burden is target identification and execution flow — both addressed. The unresolved 'confirmed: true' reference and the undocumented relationship between the four identifiers and the stated IANA zone keep it from being 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% and the four required parameters (date, className, startTime, endTime) receive no explanation at all. The description clarifies what is NOT accepted (no reservation ID, no family selector) but never explains how date/time strings are interpreted, how the 'user-confirmed gym IANA zone' relates to the missing timezone parameter, or how strictly className must match. With zero schema documentation, this leaves the caller guessing.

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 ('prepare cancellation of one exact own booked class') and immediately distinguishes itself from the execute sibling by declaring 'Preparation sends no POST.' An agent can separate prepare_booking_cancellation from execute_booking_cancellation 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?

Explicitly rules out identifier-based selection ('No reservation ID or family selector is accepted'), restricts scope to the caller's own bookings, requires a user-confirmed IANA zone, and defines the failure path for ambiguous targets. The only gap is that it never names execute_booking_cancellation as the follow-up tool, referencing 'execution with confirmed: true' obliquely 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?

Beyond the readOnlyHint and destructiveHint=false annotations, it discloses that the call sends no write, that ambiguous, missing, already-booked, waitlisted or unsupported targets yield no reference, and how the confirmation policy is surfaced via writeConfirmationRequired and writeConfirmationPolicy. It also describes the not-yet-open outcome and its gym-local timestamp, which no annotation covers.

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 and the no-write guarantee are front-loaded, and every sentence carries policy that affects behavior. The confirmation section is dense and could be tightened, but it prevents a costly double confirmation or an unauthorized execution.

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

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

An output schema exists, so return values such as the reference and bookingOpensAt need not be explained in prose. The description covers the no-write phase, the window gate and the confirmation gate, which are the hard parts. The only remaining gap is the unexplained gym IANA zone requirement, which has no matching input parameter.

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

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

With 0% schema description coverage, the schema documents none of the four parameters, so the description has to carry that burden. It adds the requirement that the class name, date and start and end time be exact, and that the gym IANA zone be user-confirmed, but it never gives the expected format of date or time, and the zone is not even a schema parameter, which leaves some ambiguity about where it comes from.

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 definition leads with a specific verb and resource: 'Read the current daily schedule and prepare one exact class booking.' It also separates itself from the write-side sibling by stating 'Preparation sends no write,' so an agent can distinguish prepare from execute 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?

It gives explicit use conditions: check writeConfirmationRequired, display the exact preview and get separate confirmation when true, omit confirmed when false, and never treat a query or preview-only request as authorization. It also tells the agent what to do when the booking window has not opened: report bookingOpensAt instead of retrying.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Sends no write,' removing any ambiguity about side effects. It adds behavior annotations cannot express: a hard prerequisite (user-confirmed gym time zone) and a mandatory confirmation workflow before the execute step, which is exactly the kind of procedural context an agent needs.

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 scoping, then the prerequisites and the confirmation gate — a sensible order with no filler. The field enumeration overlaps the schema slightly, which keeps it from being maximally tight, but every sentence carries actionable 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?

An output schema exists, so return values needn't be described, yet the description still tells the agent to surface the exact preview including the current latest 1RM. Combined with the time-zone prerequisite and confirmation gate, an agent has everything needed to call this correctly in a two-step prepare/execute flow.

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 80%, so the baseline is 3; the description earns above that by tying exerciseId to its source (find_exercise_1rm) and restating the 'today or earlier' constraint on date in the context of a real workout record. It does not add unit or format nuance for sets/reps/load beyond what the schema already documents, so it stops short of a 5.

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

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

States a specific verb and resource — preview recording a strength result for one exercise — and enumerates the inputs (date, sets, reps, load in kg) plus the app semantics ('as the AimHarder app saves a PR'). It is clearly separable from the sibling execute_exercise_result, which the description names as the follow-on action.

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: use find_exercise_1rm to obtain the exercise ID, require a user-confirmed gym time zone, then show the preview and get explicit confirmation before calling execute_exercise_result. When-to-use and the alternative are both stated, 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Sends no write' rather than contradicting it. It also adds real behavioral context the annotations do not carry: the tool validates that the activity is on the account calendar for that date and gym and displays its exercises. It stops short of stating what happens when verification fails or how the preview is presented.

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

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

Three tight sentences, front-loaded with what the tool does, then the verification behavior, then the confirmation workflow. The workflow sentence is agent-directed rather than a description of the tool, but it earns its place for a two-step destructive flow.

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

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

An output schema exists, so return values need not be explained, and the description still tells the agent what the preview contains (the activity's exercises). For a read-only two-parameter preview gating a deletion, nothing an agent needs in order to call 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 coverage is 100%, so both parameters are already documented, and the description still adds meaning: the date is gym-local, and the ID must be the account holder's own activity sourced from two named tools. That provenance guidance is genuinely beyond the schema text.

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 — preview deleting one of the account holder's own activities (e.g. a saved PR) — keyed by gym-local date and activity ID. That phrasing separates it cleanly from execute_exercise_result_deletion and from the non-deletion siblings in the list.

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

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

Explicitly names where the activityId comes from (get_personal_activity or execute_exercise_result) and names the follow-up tool, execute_exercise_result_deletion, which must only run after the preview is shown and explicit confirmation is obtained. The when-to-use and the handoff to the alternative are both spelled out.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Sends no write.' Beyond that, it discloses the full status vocabulary each entry can return (ready, already-booked, waitlisted, not-yet-open with bookingOpensAt, missing, ambiguous, unsupported), the single-use nature of each actionReference, and the per-date not-planned reporting for empty days — behavior an agent cannot infer from annotations alone.

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?

Purpose and trigger condition are front-loaded, which is correct, and no sentence is filler. However, the middle section is a single dense run-on enumerating statuses and the second half bundles procedural instructions, so it is slightly heavier than ideal for scanning.

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?

Despite having an output schema, the description still explains the meaning of each return status, the actionReference handoff, and the two-step preview-then-execute workflow — everything an agent needs to drive a multi-day booking plan correctly.

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

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

Schema coverage is 100%, with both startDate and endDate fully documented including the 14-date cap. The description restates the 14-day limit and offers the 'book next week' example, but adds no new syntax or format guidance beyond the schema, so the baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource: 'Preview booking the account holder's planned classes', and immediately anchors it to a data source (AIMHARDER_BOOKING_PLAN). It also disambiguates from the sibling tools by noting that actual writes happen via execute_booking_creation and that confirmation rules mirror prepare_booking_creation.

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 states the exact triggering condition ('Use it when the account holder asks to book without naming exact classes'), which is the key differentiator from prepare_booking_creation. It also prescribes the follow-up flow ('Show the whole list, then execute each ready day separately with execute_booking_creation') and an explicit fallback ('Ask about the other days instead of choosing a different class').

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