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

Annotations already flag destructive/non-idempotent/openWorld, but the description adds real operational context: rechecks of owner, gym, date, content and hosted role permission before at most one DELETE, a post-delete read of the own calendar/detail, and the caveat that absence does not prove permanence. The no-auto-retry rule and confirmation gate are exactly the behavioral details an agent needs for an irreversible write.

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 inputs, and every sentence carries an operational rule or guardrail. It is dense and jargon-heavy ("RM effects") and could split the recheck chain into cleaner clauses, but there is 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, non-idempotent, open-world mutation, the definition covers the full lifecycle: precondition reference, pre-delete recheck, single execution, post-delete verification, and uncertainty handling. Return values need not be explained because an output schema exists, so nothing material is missing.

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

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

With 0% schema description coverage, the description must carry parameter meaning, and it does for three of four: actionReference (must be a fresh prepare_activity_deletion reference), sourceActivityId (the target entry), and confirmed (set only after separate confirmation). gymId is only obliquely implied via "recheck ... gym", so one parameter remains under-explained.

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 entry") plus the identifying inputs ("fresh prepare_activity_deletion reference and its sourceActivityId"). This clearly separates it from prepare_activity_deletion and the other prepare_/execute_ sibling pairs, so an agent can pick 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?

Explicitly requires a fresh prepare_activity_deletion reference, requires separate account-holder confirmation before calling with confirmed: true, and forbids automatic retry of an uncertain write. It also excludes a plausible-but-wrong trigger ("Booking and publication preference switches do not affect this action"), giving both when and 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?

Annotations only say non-read-only, open-world, non-idempotent, non-destructive; the description adds permission rechecks, single-POST/no-automatic-retry behavior, and detailed confirmation policy including writeConfirmationRequired. It also notes that cancellation and deletion always require confirmation, which is useful policy 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?

Front-loads the action and then packs in behavior and confirmation rules with no obvious filler. It is still long and dense for one tool, so it is effective but not maximally concise.

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

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

Output schema and annotations cover return values and safety, and the description gives rich behavioral guidance. However, with 0% schema description coverage, missing explanations for two parameters leaves the agent without enough parameter context for a complex write action.

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

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

The schema has four parameters with 0% description coverage. The description explains `confirmed` semantics and implies `actionReference` comes from the prepared preview, but it never explains `gymId` or `acknowledgePossibleDuplicate`, leaving key parameter meanings missing.

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

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

Names a specific verb ('Publish') and resource ('exact fresh activity preview'), and frames it as execution after a prepared preview. This distinguishes it from prepare_activity_publication and query/preview siblings.

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

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

Gives explicit execution gates: recheck source, preferences, and role; perform at most one POST; never retry an uncertain result. It clearly states that query or preview-only requests do not authorize execution and spells out the true/false confirmation branches.

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?

Far beyond what annotations declare: it discloses the internal sequence (recheck reservation, at most one standard request, reconcile with fresh reads), the non-idempotent late-credit-loss outcome that returns a new pending reference, and an explicit anti-retry policy. Annotations already flag destructive/non-idempotent, and the description adds the operational detail that makes those hints 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?

Five short sentences, front-loaded with the action and its caveats, and each carries distinct operational content (sequence, retry policy, confirmation gate, scope exclusion). Dense but no filler; the ordering could be slightly tighter with the confirmation gate placed earlier.

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, open-world, non-idempotent mutation with an output schema (so returns need no explanation), the description covers the confirmation gate, the retry prohibition, the pending-warning state, and what the action does not affect. Nothing an agent needs to call it safely 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 0%, so the description must compensate, and it does partially: it pins 'confirmed: true' and implies actionReference is the token from the prepare step ('exact prepared booking'). It says nothing about gymId's role or the 64-hex reference format, leaving one of three parameters unexplained.

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

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

The opening sentence gives a specific verb and resource with a tight scope constraint ('one exact prepared booking'), which tells an agent this is the execution half of a prepare/execute pair rather than a general cancellation tool. It does not explicitly name the sibling execute_late_booking_cancellation or the prepare_booking_cancellation prerequisite, so sibling differentiation is inferred rather than stated.

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

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

Strong guidance: 'Always show the exact full preview and obtain separate account-holder confirmation before execution with confirmed: true' defines a precondition and the required call shape, and 'do not retry automatically' plus the pending late-credit-loss warning state when not to act. It stops short of naming the specific alternative sibling tools for the late-cancellation path.

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 write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds real value beyond that: exactly one write, reconciliation with fresh reads, and a stop-and-inspect rule for uncertain outcomes. However, it does not disclose the failure surface (what a rejected/partial write looks like), retry behavior, or whether a retry re-consumes the actionReference, which are the highest-risk unknowns for a non-idempotent write.

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 one-shot constraint, then the confirmation policy — the ordering matches decision order. It is dense but nearly every sentence carries a rule; the confirmation-policy block runs long and could be tightened, since part of it restates the same conditional twice.

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 confirmation gate, single-write constraint, and uncertain-result handling are all specified, and an output schema exists so return values need not be described. The remaining gap is gymId's role and the behavior on a stale or already-consumed actionReference, neither of which is addressed anywhere in the structured fields.

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 does well on two of three parameters: it explains that actionReference must be a fresh prepare_booking_creation reference and spells out when to set confirmed:true versus omit it entirely. But gymId is never mentioned in the description and the schema gives it only a pattern, so its purpose and scoping effect remain undocumented.

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

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

States a specific verb+resource with an explicit cardinality constraint: "Create exactly one booking from a fresh prepare_booking_creation reference." It also names the sibling that produces the input (prepare_booking_creation), so an agent can distinguish it from the prepare/execute pairs for cancellation, publication, and deletion.

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 routing rules: read writeConfirmationRequired from preparation, require separate account-holder confirmation with confirmed:true when true, omit confirmed when false, and never treat a query or preview-only request as authorization. It also names the alternative path (manual inspection) when the result is uncertain, so when-to-use and when-not-to-use are both covered.

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 destructiveHint, non-idempotent and openWorld, so the safety profile is covered; the description adds genuinely non-redundant behavior: one-shot semantics, mandatory account-holder confirmation via confirmedCreditLoss, reconciliation through fresh reads, and that no refund or balance is verified. The lone gap is that 'No refund or balance is verified' is ambiguous about what the response actually reports.

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

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

Every clause carries rules, but it is a dense run-on chain and the operative purpose is buried behind the precondition phrase 'After a fresh standard cancellation reports pending-credit-loss'. Front-loading the action itself before the gating condition would improve 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?

An output schema exists, so return shapes need not be spelled out, and the write-safety story is well covered. What remains unresolved is the core ambiguity of whether this single call both surfaces the credit-loss information and performs the cancellation, plus any mention of gymId, leaving the agent to guess at the call's actual effect.

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

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

Schema description coverage is 0%, so the description must carry the load. It does explain confirmedCreditLoss: true as the confirmation gate and hints that actionReference must be the new late reference (not a stale one), but gymId is never mentioned and the 64-hex reference format is left entirely to the pattern.

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 name plus the opening clause make clear this is a late-cancellation write that only fires after a standard cancellation reports a pending credit loss, which distinguishes it from execute_booking_cancellation and the prepare_* siblings. However, the description never plainly states 'cancels the booking and forfeits credit' — the agent must infer the action from phrases like 'the exact still-booked target' and 'possible credit loss', which blurs whether the call previews or commits.

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?

Preconditions and routing are explicit: only after a fresh standard cancellation reports pending-credit-loss, use only the new late reference, recheck the same reservation, send at most one late request. It also states that both preference switches leave the requirement in force, closing off an obvious shortcut an agent might otherwise try.

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, openWorld, non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: search coverage is 'limited,' candidates 'do not prove personal records,' and 'no member selector is accepted.' These are useful scoping caveats rather than restated hints.

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

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

Four compact sentences, front-loaded with the search action and followed by the ambiguity rule and limits. Slightly jargon-heavy ('read for this account,' 'member selector') 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?

An output schema exists, so return shape need not be explained. The description covers the resolution flow, the ambiguity fallback, and coverage limits — enough for an agent to call this correctly, though the gymId scoping semantics remain 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 description coverage is 0% across three parameters, so the description must compensate. It clarifies 'name' as the search key and 'exerciseId' as an ID selected from returned candidates, but says nothing about how gymId scopes the search (only the oblique 'no member selector' line). Partial coverage justifies a mid score.

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

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

States a specific verb and resource: 'Search bounded exercise candidates by name,' which an agent can distinguish from get_exercise_1rm and get_exercise_rm_progression (those read results, this resolves candidates). The tie to 1RM is only implied by the tool name, not the description, so the intent is slightly opaque.

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

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

The description implies the workflow — resolve a name to a candidate, and if ambiguous, supply 'an explicit source exercise ID from these candidates' — which is genuine routing guidance. However, it never names a sibling tool or states when to skip this step, so the agent must infer the handoff to get_exercise_1rm.

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/openWorld/idempotent/non-destructive, and the description adds real context beyond them: an authentication step is required, a defaulting rule applies when no gym is chosen, an explicit Europe/Madrid timezone assumption is made, and gym names from the source are flagged as untrusted external content (a prompt-injection warning). That trust-boundary disclosure is unusually valuable, though error/failure behavior is not described.

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 clauses, purpose front-loaded, no filler. The timezone sentence is slightly compressed to the point of ambiguity ('user-confirmed' vs 'explicitly assumed') but still 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?

With an output schema present, the description needn't describe return values, and it covers the key call-time concerns: auth, gym selection/defaulting, timezone fallback, and untrusted content. Only failure modes for an invalid or inaccessible gymId are left 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 gymId parameter (only a regex pattern), so the description must carry the meaning — and it does, explaining that gymId overrides the default gym selection for this query only. It does not explain the identifier format or what happens with an inaccessible/unknown gym id.

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

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

States a concrete verb+resource chain: authenticate the configured account, discover accessible gyms, and resolve which gym/timezone the query runs against. That is clearly a bootstrap/context-resolution tool, distinguishable from the sibling read tools like get_class_sessions. It stops short of naming itself as the prerequisite step for the other tools, which keeps it from a 5.

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

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

The description explains the selection rule (only gym, or configured default, with gymId overriding) which implies when the parameter matters, but it never says when to call this tool versus the siblings or that it must precede other calls. Usage is inferable 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?

Even though readOnlyHint, openWorldHint, idempotentHint, and destructiveHint already cover the safety profile, the description adds substantial behavioral context: the reported gym zone may be assumed, history availability is not exhaustive, labels never establish attendance, and source names are untrusted. This meaningfully goes beyond the annotations.

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

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

Each of the four sentences carries a distinct, necessary piece of information: action/ordering, zone assumption, availability limitation, and source trust caveat. It is dense but free of filler, and the core purpose is front-loaded.

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

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

The description covers ordering, limitations, and trust semantics, and an output schema exists so return values do not need explanation. However, it does not state what happens when the optional gymId is omitted, and it never explicitly ties the 'reported gym zone' to the gymId parameter, leaving a small but real gap.

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

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

Schema description coverage is 0%, and the description never names or explains gymId. The phrase 'reported gym zone' only indirectly relates to the input, so the agent gets little help beyond the schema's field name and pattern. With only one optional parameter, a direct link between the behavior and gymId was needed.

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 ('Read') and a specific resource ('the account holder's available historical booking view'), with ordering ('newest first') and scope ('at a verified gym'). The 'historical' framing also clearly separates it from sibling tools like get_upcoming_bookings.

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

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

The description implies the tool is for historical booking views and provides useful context about verified gyms and the reported gym zone, but it never names alternatives or states when not to use this tool. Selection logic is left to inference rather than explicit 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?

The description goes well beyond the readOnly/idempotent/destructive annotations by detailing the IANA time zone assumption, the precise meaning of occupancy ('occupied places, not attendance or booking eligibility'), the untrusted nature of source names, and the all-or-nothing failure behavior ('All days must succeed; errors return no schedule'). This is rich, non-annotation 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?

Six sentences, each carrying a distinct fact, and the purpose is front-loaded. There is no filler or repetition; everything 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?

The output schema exists, so return values need no explanation. The description covers all essential behavioral and semantic aspects for a 5-parameter read-only tool: date range, time zone, filter semantics, occupancy definition, trust boundary, and error behavior. An agent has enough 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?

With schema description coverage at 0%, the description compensates meaningfully: it explains the inclusive interval for startDate/endDate, the exact-match className filter, and the HH:mm format for startTime. The gymId parameter is only indirectly referenced via 'verified gym,' leaving some ambiguity, but the most important parameters are semantically clarified.

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 statement, 'Query an inclusive interval of gym-local calendar dates,' which clearly identifies the tool's function and sets it apart from sibling tools about bookings, account context, and personal activity. The scope (gym, dates, sessions) is concrete and instantly distinguishes it from alternatives.

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

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

No explicit guidance is given on when to use this tool versus the sibling tools. There is no mention of alternatives, preconditions, or exclusions. The functionality is described, but the agent must infer when this is the appropriate choice.

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, openWorld), and the description adds genuinely new behavior: the account ID is derived internally, units require corroborating history text, and source names are untrusted. These caveats go well beyond the structured fields and warn the agent about data interpretation pitfalls.

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 read action is front-loaded, but the middle sentences are dense and cryptic ('the chart field named lbs alone is not a unit', 'limited exercise-detail coverage') without context, which dilutes rather than sharpens the message.

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 adds auth derivation, unit-handling, return-context, and trust caveats. Coverage is solid for a two-param read tool, though the cryptic unit and coverage phrasing leaves some ambiguity.

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 parameter meaning. It does semantically identify both params ('one known source exercise ID' for exerciseId, 'an accessible gym' for gymId), but adds no format, range, or ID-sourcing detail beyond that conceptual mapping.

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 ('Read') and resource ('latest dated 1RM for one known source exercise ID'), which is concrete enough to distinguish from find_exercise_1rm and get_exercise_rm_progression. It stops short of naming those siblings, so the differentiation is inferable rather than explicit.

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

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

The phrase 'one known source exercise ID' implies a precondition (you must already have an ID), and 'at an accessible gym' hints at scope, but there is no explicit when-to-use/when-not guidance and no pointer to the sibling tools that would be chosen instead.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description earns credit for going beyond that: it explains that source-marked new RM events are labeled separately, that optional WOD entries are kept distinct, and that the view is limited to the own account rather than complete history. That is meaningful output-shaping context an agent could not infer 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?

Three compact sentences, front-loaded with the verb and resource, then the labeling behavior, then the scope limitation. Dense but each sentence carries information; minor jargon ('source-marked') slightly slows parsing.

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 need not be described, and the description supplies the scope limitation, labeling semantics, and WOD handling an agent needs to interpret results. Only gymId's role remains unexplained, which is a small residual gap.

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

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

Schema description coverage is 0% across three parameters, so the description must compensate. It addresses exerciseId ('known source exercise ID') and indirectly includeWod via the WOD-context sentence, but gymId is never explained in either place, leaving a real 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 description gives a specific verb (Read) and resource (separate 1/3/5/10RM series) keyed to a source exercise ID, which clearly separates it from get_published_workouts and the booking tools. It stops short of naming get_exercise_1rm/find_exercise_1rm as siblings, 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?

'Known source exercise ID' implies the ID must be obtained elsewhere, and the closing sentence excludes it from being a full lifetime history, which is a scope caveat. However, no explicit when-to-use/when-not or alternative tool (e.g. get_exercise_1rm) is named, leaving usage 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 already cover read-only, idempotent and non-destructive semantics, but the description adds non-obvious behavior beyond them: timezone assumptions ('reported gym zone, which may be assumed'), explicit coverage reporting, and the critical caveat that partial results never establish session count or verified attendance. It also flags source content as untrusted data, a security-relevant disclosure no structured field carries.

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 scope, then layered with return and caveat information in a tight block. It is dense and slightly run-on, but each sentence adds a distinct constraint or caveat rather than restating structured data.

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 the description need not detail return values, yet it still supplies the important interpretation rules (source encodings, completed-date coverage, partial-result limits). The only real gap is the undocumented gymId parameter in an otherwise complete picture.

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

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

Schema description coverage is 0%, so the description must carry the load. It clarifies the startDate/endDate pair by defining the permitted span and the gym-local calendar interpretation, but gymId is never mentioned and no format or default guidance is given for it.

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

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

States a specific verb and resource ('Retrieve personal activity') plus the scope constraint of 1–31 gym-local calendar dates. It does not name or contrast any sibling such as get_booking_history or get_published_workouts, so differentiation is left to inference.

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

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

The description gives the valid date-span window (1 to 31 inclusive) and notes the gym zone may be assumed, which implies usage context. However, it never says when this tool is preferable to siblings like get_booking_history or get_upcoming_bookings, and gives no exclusions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial context: load is computed only for today/future against the latest verified own-account 1RM per exact source exercise ID, original values and all variants are retained, and missing RM/unit/identity/read failures surface as per-exercise 'unavailable' status. It also flags that source content is untrusted, which is a valuable prompt-injection caution.

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 verb and selectors, then moves into behavioral detail with zero filler sentences. It is dense and somewhat telegraphic ('Missing RM, unit, identity or read failure has per-exercise unavailable status'), but every clause conveys actionable semantics.

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 shapes need not be explained, and the description covers the non-obvious parts: load-calculation scope, partial-failure modeling, past-date behavior, and trust warnings. The remaining gap is the role/optionality of `gymId` and what 'published alternatives' concretely contains.

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 burden; it does clarify that `date` is interpreted as gym-local and `className` must be an exact match. However, the optional `gymId` parameter is never mentioned at all, leaving its role and default behavior undocumented in both places.

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 workout alternatives') plus the key selectors (gym-local date, exact className). It is clearly a read of published class content rather than sessions or personal history, though it never names a sibling to contrast with and 'alternatives'/'labeled variants' remain domain jargon.

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

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

Usage is implied by the parameterization ('by gym-local date and exact className') and the today/future vs past distinction gives some context, but there is no explicit when-to-use or when-not-to-use guidance relative to siblings like get_class_sessions or get_personal_activity. The agent must infer the 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?

The description substantially enriches the annotations: it explains time-zone assumptions, state distinctions, that reservations do not establish attendance, that coverage has no verified date horizon, that source names are untrusted, and that failures return errors rather than empty views. These details go far beyond readOnlyHint and openWorldHint 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?

Each sentence earns its place: the action is front-loaded, and the following sentences cover time-zone handling, state semantics, coverage limits, trust boundaries, and error behavior. The description is dense but not bloated, and every clause addresses a decision or interpretation an agent would otherwise lack.

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

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

Given the output schema exists and the annotations already cover read-only, idempotent, and open-world behavior, the description completes the remaining picture: how to interpret states, what absence means, how time zones are handled, and what failure looks like. Nothing critical is missing for correct invocation and interpretation.

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?

Although schema description coverage is 0%, the description adds meaningful context for the single gymId parameter: the gym must be verified, and its reported time zone may be assumed. This is useful beyond the schema's pattern constraint, even though it does not explicitly name the parameter.

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

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

The description opens with a specific verb and resource: "Read the account holder’s upcoming booking view at a verified gym." The word "upcoming" clearly distinguishes this from siblings like get_booking_history and get_class_sessions, so an agent can infer its scope even 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?

The tool's intended use is clearly implied: use it to read the account holder's upcoming booking view, including distinguishing booked, waitlisted, and unknown states. It does not explicitly name alternatives or exclusion conditions, but the scope is precise enough that an agent can select it appropriately among the listed siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description goes well beyond them: no backup or undo, possible irreversible loss, unknown RM-history effects, and a current hosted role permission requirement. That is exactly the kind of consequence-level context an agent needs before surfacing a deletion preview.

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?

Dense but front-loaded: the read-only-preview framing and ownership scoping come first, then consequences, then the confirmation protocol. Most sentences earn their place, though the trailing 'Booking and publication preference switches do not affect this action' and the out-of-schema 'confirmed: true' reference add noise for a preview-only tool.

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 not be explained, and the description covers permission requirements, irreversibility, and the required confirmation handoff. The remaining gap is the optional-parameter behavior (what a date-only call covers) and the ambiguous 'confirmed: true' mention, which belongs to the execution step, not this one.

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 parameter meaning; it does so only partially, tying 'owner, gym, date' to the inputs and clarifying that 'arbitrary IDs do not select another account' (a real scoping constraint on sourceActivityId). It never explains what omitting the optional gymId or sourceActivityId means, and the 'confirmed: true' flag it references does not exist in this schema (additionalProperties: false), which muddies the parameter picture.

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 a read-only preview of one exact own calendar entry') and scopes it to the caller's own entry, which cleanly separates it from execute_activity_deletion and from prepare_activity_publication. An agent can identify the tool's job 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 frames the tool as a preparation step that 'never sends DELETE' and requires 'separate account-holder confirmation before execution with confirmed: true', and rules out booking/publication preference switches as irrelevant. It stops short of naming the sibling execute_activity_deletion as the follow-up call, so the routing 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?

It adds real context the annotations do not carry: role permission required on the hosted service, a draft-without-reference fallback when EMOM rounds or achieved values are missing, duplicate notices, and the writeConfirmationPolicy split between bookingCreation and activityPublication. However, the closing paragraph instructs the caller to execute 'with confirmed: true' and to 'omit confirmed', yet no such parameter exists in this schema, so the execution semantics are muddled for a tool the annotations mark readOnlyHint=true.

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

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

The first sentence is front-loaded and the display/verification sentences are compact, but the trailing confirmation-policy block is near-boilerplate, references a parameter that does not exist here, and doubles the length without adding callable guidance for this specific tool.

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 spelled out, and the description still covers permission requirements, the draft fallback, duplicate notices and confirmation policy. The remaining gaps are gymId and comment, plus the unresolved 'confirmed' instruction that belongs to the execute sibling.

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 parameter meaning; it names source ID, activity date, difficulty variant and 'achieved results or actual loads' and clarifies that historical RM suggestions and prescribed rounds are not valid results. It never explains gymId or comment, and does not map 'audience' or 'WOD TV' to any actual parameter, leaving two of seven parameters undocumented anywhere.

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 gives a specific verb and resource: 'Prepare one own activity entry from a current verified gym workout.' The 'Prepare' framing plus the sibling names prepare/execute activity_publication make the two-stage intent inferable, though the description never names execute_activity_publication 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?

It tells the agent what inputs to supply and how to treat historical RM suggestions and prescribed rounds, but the when-to-use routing is only implied by the word 'Prepare'; no sentence says 'call this first, then call execute_activity_publication'. The confirmation-policy paragraph gives conditional instructions but points at a 'confirmed: true' step rather than at the sibling tool.

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

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

Annotations declare readOnlyHint=true, but the description earns its place by adding what annotations cannot: the fresh-schedule read, the absence of any POST during preparation, the credit-loss disclosure requirement including the 9NBC 90-minute rule, and the mandatory two-step confirmation. None of this contradicts the read-only, non-destructive hints.

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

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

The purpose and the no-POST scope are front-loaded, and nearly every sentence adds a distinct constraint. A few clauses are dense and slightly compressed ('9NBC 90-minute rule', 'in a user-confirmed gym IANA zone') but nothing is wasted.

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

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

With an output schema present, return values need no explanation, and the safety and confirmation sequence is fully covered. What is missing is operational detail on target matching and failure modes beyond 'receive no reference', which matters given the 0% parameter coverage.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate. It clarifies identification semantics (exact own booked class by class name and time window, not a reservation ID) and that gymId must be a user-confirmed IANA zone, but it does not describe the date/time formats or what the required className matching tolerates.

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 scopes it against siblings by noting preparation sends no POST and execution happens separately with confirmed: true. An agent can distinguish it from execute_booking_cancellation and prepare_booking_creation 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?

Explicit exclusions are given ('No reservation ID or family selector is accepted', 'Unsupported or ambiguous targets receive no reference') plus the precondition flow: show the full preview, obtain separate account-holder confirmation, then execute with confirmed: true. It also rules out irrelevant switches ('Booking and publication preference switches do not affect this action').

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 and destructiveHint=false, but the description adds substantial context: preparation performs no write, failed/ambiguous targets return no reference rather than raising, and the confirmation obligation is conditioned on the bookingCreation policy. No contradiction with the annotations; the idempotentHint=false is not troubled by anything said.

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 scoping and no-write constraint is front-loaded, and the density is mostly justified by the confirmation branching. The writeConfirmationPolicy sentences are dense with internal field names and take a second pass to parse, which costs some 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?

An output schema exists, so return values need not be described, and the confirmation workflow is fully documented. The one gap is the optional gymId parameter and whether the 'user-confirmed gym IANA zone' is supplied by the caller or read from account context.

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 whole burden. It adds real meaning for four of the five parameters (exact class name, date, start and end time must match the schedule), but leaves gymId unexplained, including whether it is derived from account context or must be supplied explicitly.

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: read the daily schedule and prepare exactly one class booking, explicitly excluding writes ('Preparation sends no write'). This cleanly separates it from execute_booking_creation and from the query siblings like get_class_sessions.

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 preconditions (user-confirmed gym IANA zone, exact class name/date/start/end) and explicit no-op cases (ambiguous, missing, already booked, waitlisted, unsupported targets receive no reference). It also spells out the confirmation branch via writeConfirmationRequired in writeConfirmationPolicy and states that a query or preview-only request never authorizes execution.

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