Daash

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

Annotations only give the basic profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), but the description adds substantive behavior: validation happens before anything is created so a failed call leaves no half plan, nothing is stored outside Garmin, and workout names get the plan code appended after a middle dot. These are the exact details an agent needs to reason about failure modes and side effects.

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 atomicity guarantee, then a structured Args block that is easy to scan. It is on the long side and includes some polish detail (the card bands weeks by phase, the middle-dot naming rule), but nearly every sentence provides decision-relevant information.

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

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

For a six-parameter, nested-array write tool with no schema descriptions, the description supplies everything missing: parameter semantics, constraints, atomicity, storage location, and the result ('a new block drawn as an interactive plan card'). The output schema covers return shape, so nothing essential is absent.

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

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

Schema coverage is 0%, so the description carries the full burden and does so thoroughly: every parameter is explained, including defaults (running, 25 m pool, label derived from goal) and the shape of each session object with its date range (today to 30 weeks out) and nested steps/phase fields. The milestones structure is spelled out with an example.

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 with scope: 'Create a whole training block at once' where each session becomes a structured workout scheduled on the Garmin calendar. The 'whole block at once' framing distinguishes it cleanly from the single-item sibling create_workout without needing to name it.

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?

Clearly conveys the batch context (all sessions validated first, days without a session are rest days, at most 150 sessions) so an agent knows when this tool fits. It never explicitly says to use create_workout for one-off sessions or how this relates to schedule_workout, so the alternative routing is left implicit.

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 safety (readOnlyHint false, destructiveHint false, openWorldHint false), so the bar is lower. The description still adds real value beyond them: the non-editing guarantee and the ambiguity-abort behavior, which is a non-obvious transactional trait. It omits whether the creation is atomic across multiple exercise blocks beyond the name-match 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?

Front-loaded with purpose and the key constraint before any parameter detail. The example is lengthy but earns its place because the exercises array is untyped in the schema; the prose itself has 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 write tool with an output schema available, the description covers everything needed to call it correctly: purpose, non-editing guarantee, every parameter including the undocumented nested structure, and the ambiguity failure path.

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

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

Schema coverage is 0%, and the description fully compensates: it names all three parameters, spells out the nested exercise object's fields with defaults (sets 3, reps 10, rest_seconds 90), documents the optional weight_kg, and provides a concrete example the schema's untyped array cannot convey.

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 and location ('Create a new strength workout in the user's Garmin workout library') and explicitly separates itself from editing via 'It never edits an existing one'. It does not, however, distinguish itself from the sibling create_workout, which an agent must choose between.

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

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

Gives clear usage context: creation-only, and a stated failure mode (ambiguous catalogue name → candidates returned, nothing created). It implies rather than states the alternative for modifying an existing workout (update_workout), and says nothing about the generic create_workout sibling.

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 with concrete behavioral rules: pace targets narrower than 5 s/km get widened, a single power value becomes a ±5% range, a repeat cannot nest another repeat, swim steps are whole pool lengths, a swim pace target renders as a note rather than an alert, and a durationless rest waits for the lap button. These are data-normalization side effects that the agent cannot get from readOnlyHint/destructiveHint.

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 and every paragraph covers a distinct parameter concern; the long step section is justified by a 0%-documented nested schema. Minor tension remains: 'exactly one of duration_seconds, distance_meters or until_lap' versus the later allowance that a rest with no duration simply waits for the lap button.

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

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

A complex 5-parameter creation tool with an untyped nested payload, fully specified down to interval normalization rules and swim-specific behavior. An output schema exists, so return values need not be described, and the annotations already cover the safety profile.

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

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

Schema coverage is 0% and steps is an opaque untyped object array, so the description carries the full load — and does: it defines the step 'type' vocabulary, the exactly-one-of duration/distance/until_lap rule, the repeat shape, the three target families with formats and ranges, sport defaults, and pool_length_meters values. A complete worked example of a 5x1km session removes ambiguity.

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

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

States a specific verb and resource ('Create a new structured workout in the user's Garmin workout library') and immediately scopes it against the update sibling with 'It never edits an existing one.' The sport list (running, cycling, swimming, walking, hiking) further separates it from create_strength_workout, which covers strength training.

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?

'A workout reaches the watch once it is scheduled on a date' hints at the schedule_workout follow-up, but no sibling is named and no explicit when-not guidance is given. The read-only/creation boundary is inferable, but an agent must open list_workouts, create_strength_workout, and schedule_workout to work out the routing itself.

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 destructiveHint=true and readOnlyHint=false, but the description adds the critical behavior the annotations cannot express: the deletion is permanent, and the first call is a safe no-op that returns the workout's name as a confirmation token. That two-phase safety protocol is exactly the kind of context an agent would otherwise get wrong and delete something accidentally.

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 permanent-deletion warning and the two-call protocol are front-loaded ahead of the arg list, which is the right ordering for a destructive tool. The short 'Args:' block is slightly redundant with the prose but earns its place given 0% schema coverage.

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

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

For a destructive two-parameter tool with an output schema (so return values need no explanation), the description covers everything an agent needs: irreversibility, the confirmation handshake, the activity-vs-workout boundary, and both parameter meanings. Nothing essential is missing.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it delivers: workout_id is the workout's id, and confirm is the exact name returned by the first call. It also explains why confirm's empty default matters — an omitted confirm means nothing is deleted — which the schema's `default: ""` alone never conveys.

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 states a specific verb (delete), resource (workout), and scope (the user's Garmin workout library, permanently). It immediately distinguishes itself from activity deletion with 'Recorded activities can't be deleted here', so an agent can tell it apart from the get_activities/get_activity_details family 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?

It gives a clear when-not ('Recorded activities can't be deleted here') and explains the precondition for a real deletion (a second call with the exact name). It stops short of naming an alternative tool for recorded activity removal, which would have made routing fully explicit.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior — matching normalizes hyphens and spacing, so 'pull up' and 'pull-up' both match — which is not derivable from the schema or 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-loaded with the core purpose, followed by the one non-obvious matching rule, then a compact Args block. Every sentence adds information an agent cannot get from structured fields; no filler.

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

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

With only two parameters, an output schema covering return values, and annotations covering the safety profile, the description is nearly sufficient. Minor omissions (case sensitivity, behavior on empty or unmatched query) are not enough to cause a failed call.

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

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

Schema coverage is 0%, so the description must carry the parameters, and it does: 'query' is defined as part of an exercise name with two examples, and 'limit' as the number of matches with its default of 25. It stops short of stating case sensitivity or an upper bound on limit, leaving a small gap.

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

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

States a specific verb and resource ('Search Garmin's strength exercise catalogue by name') with the exact domain narrowed to strength exercises. No sibling tool in the list overlaps with this lookup role, so an agent can place it immediately without comparing schemas.

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 context of use is clear: resolve an exercise name into catalogue entries (presumably before create_strength_workout). It does not state exclusions or an explicit 'use this when' clause, but no real alternative exists among the siblings, so the risk of misrouting is low.

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, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral detail beyond that: the default page size of 10, the 1-50 cap, and the rule that end_date falls back to today when start_date is supplied — all directly useful for shaping a 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 return shape, then a compact Args block with one line per parameter; nothing is redundant. The swim-detail sentence is slightly granular but still earns its place by signalling the field-level variation in results.

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 enumerated, yet the description still flags the notable swim-specific fields (pool length, SWOLF, stroke rate). Combined with complete parameter semantics and annotation-covered safety, an agent has everything needed to invoke this correctly.

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

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

Schema description coverage is 0%, so the description carries the full burden and does: it gives limit's bounds and default, start_date's YYYY-MM-DD format and role as range start, and end_date's conditional default. That is meaning the bare schema (types and nulls only) does not provide.

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 concrete resource and scope: recent runs/rides/swims with distance, duration, pace and HR zones, which clearly separates it from the singular get_activity_details. It stops short of explicitly naming that sibling or stating the listing boundary, so differentiation is by implication rather than statement.

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

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

Usage is only implied through the date-range parameters; nothing says when to call this versus get_activity_details or get_daily_summary, nor what happens with no arguments. The caller can infer the list-vs-detail split, but the description doesn't guide it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds useful content about what data is included for runs, rides, and swims, but it does not add operational details like permissions, rate limits, or error behavior. Because an output schema exists, much of the return-content disclosure is already covered structurally.

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

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

The description is front-loaded with the core purpose and then efficiently itemizes the data available by activity type. It is somewhat detailed for a read-only single-record tool, but the structure is clear and every section is relevant.

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 one required parameter, a read-only annotation profile, and an output schema, the description is largely complete about what the tool returns. The main gap is the lack of parameter format guidance and explicit usage guidance versus get_activities.

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 needs to compensate for the single parameter. It only says 'activity_id: The activity's id,' which restates the parameter name and does not clarify the anyOf integer-or-string type, expected format, or examples.

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

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

The description states a specific resource and scope: one activity in detail, with lap/split data plus type-specific metrics for runs, rides, and swims. The singular, detailed framing distinguishes it clearly from the sibling list tool get_activities without needing to name it.

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 activity in detail' implies it should be used when detailed data for a single activity is needed, but it gives no explicit when/when-not guidance or direct alternative. It does not tell the agent to use get_activities for listing versus this tool for detail.

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 readOnlyHint=true and non-destructive, so safety is covered. The description adds meaningful context beyond that: it discloses the two distinct facts returned (connection state and write capability) and the security-relevant guarantee that a token is never returned. Only the exact field shape/pagination-style behavior is absent, which the output schema 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?

A single front-loaded sentence with no filler; every clause (connection state, write permission, no token) carries information an agent needs.

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

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

For a zero-parameter, read-only status probe with a full output schema, the description supplies everything an agent needs to decide to call it and what it can rely on, including the no-token guarantee. 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly adds no parameter chatter.

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 precisely what the tool reports: whether Daash is connected to the user's Garmin account via the official API, and whether write access to workouts is granted. No sibling tool covers connection state, so differentiation is implicit and unambiguous. It phrases the purpose as a set of returned facts rather than a verb, which is slightly indirect but still clear.

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

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

There is no explicit 'call this before scheduling a workout' or any when/when-not guidance. The context (a write-permission flag) implies it is a prerequisite check for create_workout/schedule_workout, but the agent must infer that. No alternatives are named, though none exist among the 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 cover the read-only, non-destructive, closed-world profile, and the description adds real behavioral context beyond that: hard sessions are redacted to just "hard", per-member data is only as fresh as their last plan view ('updated_on'), and the response carries group_message and a conditional page_url. It also discloses the not-in-a-crew behavior.

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

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

The output structure is front-loaded and the args block is separated cleanly at the end. It is denser than strictly necessary (the 'card' framing and group-chat sentence could be trimmed), 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?

Given an output schema exists, the description needn't enumerate return fields, yet it still covers the notable ones (group_message, page_url) and edge cases (no crew, hard-session redaction, stale per-member data). Only the absence of sibling routing keeps it short of 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?

With 0% schema description coverage, the description must carry the lone parameter, and it does: week_of accepts any date in the week and defaults to this week, or on a Sunday to the week ahead. The null-vs-string shape is explained sufficiently for correct invocation.

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

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

The description concretely states the resource and scope: the user's crew week drawn as a card, with friends' runs, the club run, matching run days, and the group_message/page_url payload. It is clearly distinct in content from siblings like get_plan or get_daily_summary, though it never names those siblings to route the agent 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 only implied — the agent can infer this is the tool for 'what is my crew doing this week,' and there are hints about the non-crew case ('Says so when the user isn't in a crew'). But there is no explicit when-to-use/when-not or reference to alternatives such as get_plan for the user's own schedule.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful behavioral detail about the summary's contents, including Body Battery charge/drain contributors and longest stressful spells. It does not disclose data freshness or timezone, but against existing annotations this is still a solid contribution.

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

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

The description front-loads the summary contents in one sentence, then uses a compact Args block for the only parameter. Every phrase contributes to knowing what the tool returns or how to set the date.

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

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

For a single optional date parameter with an output schema, the description gives enough: it defines the summary's included data and explains all accepted date forms. Annotations cover safety, and the output schema carries return structure.

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

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

Schema coverage is 0% and the date parameter has no schema description. The description fully compensates by specifying YYYY-MM-DD, 'today', 'yesterday', offset syntax like '-3', and the default to today.

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 concrete resource and scope — one day's health summary — and enumerates the included metrics (steps, calories, resting heart rate, Body Battery, stress). It does not explicitly contrast with siblings like get_readiness, get_sleep_data, or get_activities, so it is clear but lacks sibling differentiation.

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

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

No sentence states when to choose this summary over get_readiness, get_sleep_data, or get_activities, nor any exclusions such as dates without data. The only implied use is a daily overview, which is insufficient 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?

Annotations only declare it as a safe read; the description goes well beyond that by defining the completion rule (within a day either side of the date, or any day that week when started from the workout on the watch), the strength-session rule, the fallback to recent running/riding when nothing is scheduled, and the enumerated plan-state outcomes. These are non-obvious semantics an agent could not derive from the annotations or schema.

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

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

Purpose and card contents are front-loaded, and every clause carries real information about semantics or fallback behavior. It is dense but slightly sprawling, with the state enumeration and completion rules packed into one long block rather than separated.

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 an output schema existing, the description supplies the interpretive layer that matters: what 'done' means, when the fallback view appears, and what the plan-state field is telling you. Combined with the parameter default explanation, an agent has everything needed to call and interpret this tool correctly.

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

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

Schema coverage is 0%, so the description carries the full burden and does so: it explains that label is a plan code Daash created, gives a concrete example ('HM'), and defines the null/default behavior. The only gap is that it does not say how an agent discovers valid codes.

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

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

The description states a specific resource and shape: 'the user's training plan week by week, drawn as an interactive plan card,' and enumerates what the card shows (done/missed/moved/ahead sessions, next session with steps and paces). It even covers the empty-schedule fallback and the plan-state summary. It does not explicitly contrast with siblings like get_progress or list_workouts, 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?

Usage guidance exists only at the parameter level: 'Omit it for the plan running now, or the calendar around this week,' which tells the agent the default case. There is no statement of when to prefer this tool over get_progress, get_workout, or list_workouts, so the agent must infer the boundary itself.

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 non-destructive, so the safety profile is covered. The description adds real behavioral value: the matching rule (activity within a day either side, roughly matching duration), the plain-English reason per session, the rendering format, and the explicit caveat that effort is not judged.

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 outcome and matching logic, then a compact args section. Slightly longer than strictly necessary, but every sentence conveys operationally useful information.

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

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

An output schema exists so return values need not be described, and the description still explains the card format and the per-session reason field. The matching criteria and the non-judgment of effort complete the picture for an agent deciding whether this answers a progress question.

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 parameter, and it does: 'weeks' is defined as how many weeks back including the current one, with the 1-12 bound stated. Only the default value (6) is left to the schema, which is acceptable.

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: it reports which planned sessions were completed, week by week, as a plan card. It clearly differs from get_plan (structure) by focusing on completion/adherence, though it never names get_plan explicitly to reinforce the distinction.

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 adherence-reporting framing, but there is no explicit when-to-use / when-not guidance and no mention of siblings like get_plan or get_activities that an agent might otherwise choose for similar questions.

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, non-destructive, closed-world), and the description adds real substance beyond that: the discrete verdict vocabulary, the baseline warm-up thresholds, and the important caveat that this is Daash's own computation rather than Garmin's official readiness score. It stops short of stating behavior for missing/partial data or future dates beyond the not_enough_data verdict.

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 the metric list are front-loaded, and the caveats follow in a logical order; the Args block is compact. The opening sentence is dense and run-on (five clauses plus parentheticals), which slightly slows parsing but contains 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 single-optional-parameter read tool with an output schema, this covers everything an agent needs: what data feeds the check, what the verdict values mean, when the verdict is unavailable, and that the score is derived rather than sourced from Garmin. Return-value detail is correctly 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 description coverage is 0%, so the description carries the full burden and does it well: explicit YYYY-MM-DD format, the 'today'/'yesterday' keywords, the '-1' offset form, and the default to today. That is more than the bare string|null schema could ever convey.

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 resource ('a recovery check for a day') and enumerates exactly what it aggregates: last night's sleep, overnight HRV, resting heart rate, Body Battery and last week's training. The four possible verdicts (ready_for_hard, fine_with_care, go_easy, not_enough_data) make it unmistakable that this is the readiness tool and not get_sleep_data or get_daily_summary.

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?

Implies a daily-recovery use case and gives data-sufficiency conditions ('no call until a week of nights gives an HRV baseline; an early one until about three weeks'), which is useful. It never names or excludes a sibling though, so an agent must infer on its own whether to reach for get_daily_summary or get_sleep_data 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 establish that this is a read-only, non-destructive, closed-world operation. The description adds useful context that the data is compared against the user's usual, but it does not disclose other behavioral details such as permissions or rate limits; the output schema covers return structure.

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

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

The description is front-loaded with the tool's purpose and then supplies only the necessary parameter semantics. There is no redundant or wasted text.

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

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

For a simple one-parameter read-only tool with annotations and an output schema, the description provides everything needed to invoke it correctly. The data returned and date semantics are both covered.

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 fully compensates by defining the single date parameter: it is the date the user woke up on, accepts YYYY-MM-DD, relative terms like 'today' and 'yesterday', offsets like '-3', and defaults to today.

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

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

The description clearly identifies the resource and the specific data returned: one night's sleep stages, sleep score, breathing rate, and SpO2. It does not explicitly distinguish this tool from related siblings such as get_daily_summary or get_readiness, so it falls short of a 5.

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

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

The description explains what the tool returns but gives no explicit guidance on when to use it rather than related tools like get_daily_summary or get_readiness. There are no exclusions, prerequisites, or alternative-selection cues.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the shape of the returned data, including how repeats are nested (8 x [1 km, 60 s recovery]), which tells the agent what to expect from parsing. It does not mention behavior for missing/invalid ids, but with annotations carrying safety that is a minor gap.

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

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

Two short sentences plus a one-line arg note. The repeats example is the most information-dense part and is placed where it matters, with no filler.

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

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

An output schema exists, so return values need not be explained in prose. The description covers what is returned conceptually and its one parameter, leaving only edge-case behavior (unknown workout_id) 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%, but there is exactly one required integer parameter, and the description documents it as 'The workout's id,' which is sufficient for an agent to populate it. No format or source guidance (e.g., where ids come from) is added beyond the schema.

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

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

Names a specific resource — the steps of one saved or scheduled workout — and describes what each step contains (distance or time and target), which clearly separates it from list_workouts or get_plan. The retrieval verb is only implied by the phrasing, but the scope is unambiguous.

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

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

Usage is implied: fetch the detail of a single workout once you have its id, versus listing workouts or reading a plan. The description never states when to prefer this over get_plan or list_workouts, nor what happens if the workout is scheduled versus saved.

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

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

Annotations only cover safety profile (non-readOnly, non-destructive, closed world); the description adds substantial context beyond that: the exact privacy contract (members see chosen name, usual times, and easy/long run day and distance for two weeks; hard sessions show only as 'hard'; nothing else from Garmin is shared). It also discloses the invite-code format and the default crew name, which an agent would otherwise have no way to know.

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 purpose then privacy scope, followed by an itemized Args block that stays close to one line per parameter with no filler. The inline enumeration of six usual_times values makes the block dense, 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?

For a 10-parameter, conditionally-branched mutation tool, the description covers the mode switch, per-parameter semantics, defaults, and the privacy consequences of the call. An output schema exists, so return values need not be explained here.

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

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

Schema description coverage is 0% across 10 parameters, so the description must carry the full load and does: every parameter is explained, including the enumerated values for usual_times, the match semantics ('Runs on the same day are matched by these'), and the format hints for club_run_day ('fri') and club_run_time ('HH:MM') and club_run_km (km).

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 ('Join ... or start') and resource (a Daash crew), and immediately defines the data-sharing scope, which distinguishes it cleanly from get_crew, update_crew and leave_crew. An agent can tell what this does without opening the schema.

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

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

The description makes the join-vs-create branch explicit: supply 'code' to join a friend's crew, or set start_new_crew=True to create one, and it labels the crew/club_run_* params as 'when starting'. It stops short of naming sibling alternatives (get_crew, leave_crew) or stating preconditions such as already being in a crew, so it is clear context without full routing.

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

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

Annotations already flag destructiveHint=true, but the description goes well beyond them: it names what is deleted (what the crew kept of the user's runs), how fast the effect is (crew stops seeing runs at once), the cascading case (last member deletes the crew), and the no-op guard on confirm. That is exactly the extra context a mutation tool 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?

Consequences are front-loaded in the first two sentences with zero fluff. The trailing 'Args: confirm: True to leave' largely repeats the earlier 'Nothing happens unless confirm is true', so one small redundancy keeps it off a 5.

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

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

For a single-parameter destructive mutation with an output schema and destructiveHint annotation, the description covers effects, timing, cascade, and the confirm gate, which is enough to call it safely. It never explicitly says the deletion is irreversible, which is the one gap worth adding.

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 single parameter, and it does: confirm is described as the leave switch and its false/no-op behavior is spelled out, which implies the default false. It could have restated the default explicitly rather than leaving it to inference, keeping this from 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 (leave the user's Daash crew) and immediately names the distinguishing effects: runs stop being shared and the last member deletes the crew. That separates it cleanly from join_crew, get_crew, and update_crew without opening a schema.

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

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

The context for calling it (a user wanting out of a crew) is unambiguous, and it warns that nothing happens unless confirm is true. It does not explicitly route to siblings such as join_crew or update_crew, nor state exclusions, so it falls short of a 5.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds that the results come from the user's saved library (a scoped, local read), but says nothing about ordering, pagination beyond the limit cap, or whether an empty library is a normal result.

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

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

Two short sentences with no filler; the resource statement comes first and the parameter note second. The 'Args:' fragment is slightly awkward for a prose description but costs little.

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. For a one-parameter read tool this is close to sufficient, but the absence of any routing guidance among ten-plus siblings and of ordering/pagination behavior leaves real gaps.

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

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

Schema description coverage is 0%, so the description carries the parameter burden and does so: it gives the range (1-100) and the default (20) for limit, which the bare integer schema does not. Only the behavior at out-of-range values is unspecified.

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

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

The description identifies the resource (the user's Garmin workout library) but never uses a verb like 'list' or 'retrieve', leaving the operation implicit. The plural 'workouts' and 'library' weakly distinguish it from the singular sibling get_workout, but that differentiation is by inference, not statement.

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

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

There is no statement of when to call this versus get_workout, get_plan, or the create/update_workout siblings. An agent must infer that this is the enumeration entry point from the name alone.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds genuine value beyond them: the removal is partial (only today onward), the operation is two-phase with a safe preview, and library entries are affected alongside the calendar. It doesn't say whether the deletion is reversible or how the preview is reported, which keeps it below the top mark.

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

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

Three short sentences front-load the effect and the safety protocol before the compact Args block. Every sentence carries distinct information; no restatement of the title or name.

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

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

A destructive, two-step mutation with two undocumented params and an output schema present. The description covers scope, the dry-run protocol, and both parameters, leaving only return-value formatting to the output schema as intended.

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 does: label is the plan code with a concrete example ('HM'), and confirm is the same plan code re-supplied on the second call. This is exactly the semantic the schema lacks, including the otherwise opaque empty-string default.

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 ('take the rest of a plan off the user's Garmin calendar and out of the workout library') and scopes it to future sessions only, which distinguishes it from delete_workout and unschedule_workout in the sibling list. An agent can tell what gets removed 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?

Specifies the exact call sequence: the first call is a dry run that removes nothing and reports what would go, and a second call with confirm set to the plan code actually removes. It also states the boundary condition (past sessions stay). Nothing about when/how to invoke is left to inference.

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

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

Annotations already declare a non-destructive, non-open-world write, and the description adds the crucial behavioral detail that this action is what pushes the workout to the watch. It does not disclose what happens if a workout is already scheduled on that date, which is a meaningful gap for a scheduling mutation.

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

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

Two tight sentences with the purpose and the key side effect front-loaded, followed by precisely the parameter information an agent needs. No filler.

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

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

For a two-parameter mutation with annotations and an output schema, this is nearly complete: purpose, side effect, and both parameters are covered. The missing piece is collision behavior when a date already holds a scheduled workout.

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

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

Schema coverage is 0%, so the description carries the full burden and does well: it defines workout_id and gives concrete accepted formats for date (YYYY-MM-DD, 'today', 'tomorrow', '+3'). It leaves the integer-or-string flexibility of workout_id unaddressed, but the essentials are covered.

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 ('Put a saved workout on a date in the user's Garmin calendar') and immediately explains the effect ('what sends it to the watch'), making it unmistakably distinct from unschedule_workout and other siblings.

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

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

It conveys the context in which to use the tool (placing a saved workout onto the calendar) but never names an alternative or states exclusions, such as when to unschedule or update instead. The usage is implied rather than explicitly routed.

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

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

Beyond the destructiveHint annotation, the description discloses exactly what is removed (the calendar entry) and what remains (the workout library). It also explains the ambiguity behavior when multiple workouts exist on the same day. This is strong behavioral context for a mutation tool.

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

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

The description is front-loaded with the core action, then behavior, edge case, and parameter explanations. Every sentence adds useful information, and the Args section is compact and organized.

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 has an output schema, so the description need not explain return values. For a two-parameter mutation tool, it covers the essential behavior, edge case, and parameter semantics needed to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does for the key semantics: date accepts YYYY-MM-DD, 'today', 'tomorrow', or offsets like '+3', and schedule_id targets one specific calendar entry with precedence over date. It does not clarify the meaning of the schema defaults (empty string and 0) or the accepted integer/string forms of schedule_id, leaving a small gap.

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

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

The description states a specific verb and resource: taking a workout off a day in the Garmin calendar. It also distinguishes the operation from deleting the workout entirely by explaining that the workout stays in the library and can be rescheduled. This is clear enough for an agent to distinguish it from sibling tools like delete_workout.

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

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

The description gives clear usage context: remove a calendar entry via date, or target one entry with schedule_id, which takes precedence. It also explains the multi-workout edge case where entries are listed and nothing is removed. It does not explicitly name alternatives such as delete_workout for permanent deletion, but the context is otherwise clear.

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 only destructive=true/openWorld=true; the description adds the authorization model, partial-update semantics ("Only what is passed changes"), the confirm=true gate for enabling/replacing the link, and that replacing the link invalidates the old one. It also discloses exactly what is exposed publicly when the page link is on, which is the key privacy consequence of a destructive flag here.

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 purpose and authorization before the field list, and no sentence is filler. It is long, but the length is justified by 11 undocumented parameters; the only mild redundancy is restating parameter names in prose.

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?

Because an output schema exists, return values need not be described; what remains — permissions, partial update behavior, confirmation gating, format conventions and the public-visibility side effect — is all covered. Nothing an agent needs to call this 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% across 11 parameters, so the description carries the full burden and does: every parameter is explained with intent and format ("HH:MM", 'e.g. "fri" or "none" to drop it', group_link values on/new/off). It also states cross-parameter rules, notably that confirm is required specifically for group_link on/new.

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 ("Change the user's details in their Daash crew, or the crew's settings") and immediately enumerates the mutable fields and who may change them. An agent can distinguish this from get_crew, join_crew, leave_crew and update_workout without opening any schema.

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

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

Gives clear conditions for use via permission tiers (anyone may edit own name/times/attendance; the founder may rename, change club run, remove a member, toggle the page link). It does not name siblings explicitly, so an agent must infer that leaving a crew belongs to leave_crew and that remove_member is an admin action against another person.

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 destructiveHint=true, and the description earns that by spelling out exactly what is destroyed: 'New steps replace the whole old list, and the result carries the steps that were replaced.' It also discloses non-obvious side effects the annotations cannot convey — id retention, scheduled dates persisting, and the watch receiving the new version at its next sync.

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 behavioral summary is front-loaded in one dense sentence, and per-parameter notes follow a consistent pattern. The repeated 'Omit to keep the current one' phrasing across four args is slightly redundant but keeps each arg self-contained.

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 and annotations cover the safety profile, so the description needn't explain the response shape — though it helpfully notes the replaced steps come back. The one real gap is 'steps: ... in the same shape as when creating a workout': the schema types steps only as an untyped object array (additionalProperties: true), so the agent must open create_workout to learn the step structure.

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%, but the Args block documents all six parameters, including the omit-to-keep defaulting behavior for null fields and the sport-only-with-steps dependency. 'Workout_id' being required is implicit but 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 opening sentence gives a specific verb and resource ('Change an existing workout in place') plus the exact fields it can touch, which cleanly separates it from create_workout, delete_workout and get_workout. 'It keeps its id' further distinguishes in-place mutation from delete-and-recreate.

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 'Omit to keep' convention is explained and constrains each optional field, and 'sport: Only with steps, and only to change the sport' states a real coupling rule an agent could otherwise get wrong. What's missing is explicit routing to siblings such as schedule_workout/unschedule_workout for changing scheduled dates.

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