Coach MCP

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

Annotations only state readOnlyHint=false and destructiveHint=false; the description adds crucial behavioral detail: that creating a metric fixes its unit, that unit must be omitted on subsequent entries, and that recorded_at should be local time without UTC offset. This goes beyond the annotations and clarifies side effects of creation.

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 two paragraphs, but every sentence adds value: the first defines the core action and creation behavior, the second covers key reuse and parameter rules. It is slightly longer than strictly necessary, but there is no filler or repetition, so it earns its length.

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

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

For a tool with an output schema (which likely describes return values), the description covers all call-time decisions: key selection, unit handling, and timestamp formatting. It doesn't explain what the response contains, but the output schema covers that. The only minor gap is that it doesn't explicitly warn that a misformatted key could fail, but the instruction to reuse keys exactly implies that.

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 carries the full semantic burden for parameters. It explains key format (lowercase a-z, 0-9, _), the unit creation rule, and the recorded_at timezone convention. Every parameter that could be ambiguous is addressed, making the description essential and effective.

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 the exact action (log one entry) and resource (custom metric), and explicitly notes that the first entry for a new key creates it with its unit. This clearly distinguishes it from sibling tools like list_custom_metrics or delete_custom_metric_entry, leaving no ambiguity about its role.

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

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

The description gives explicit rules for when to include or omit unit and recorded_at, and instructs the agent to reuse keys exactly as returned by list_custom_metrics. While it doesn't explicitly contrast with alternatives, the constraints on parameters make the intended usage unambiguous.

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

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

The destructiveHint annotation already signals mutation, and the description reinforces it with 'Permanently delete.' It adds the single-entry scope but does not elaborate on side effects, permissions, or irreversibility beyond what the annotation already implies.

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

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

Two concise sentences, with the action and consequence front-loaded. The example and ID source add useful context without wasted words.

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

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

For a one-parameter delete tool with a clear annotation, an output schema, and a simple resource, the description fully covers what the tool does and how to obtain the required ID. 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 coverage is 0%, so the description must compensate. It does so by telling the agent exactly where entry_id values come from: 'Entry ids come from get_custom_metrics.' This is the key semantic needed for the single required 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 states a specific verb and resource: 'Permanently delete one custom metric entry.' It also clarifies the intended corrective use case with 'e.g. a typo,' and the resource is distinct 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 provides clear context for when to use the tool: deleting a specific custom metric entry, often to fix mistakes. It does not explicitly name alternatives or when-not-to-use conditions, but for a focused single-purpose tool this is adequate.

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 indicate destructive=true and readOnly=false, and the description adds valuable context: the Garmin copy is also removed. This discloses an important side effect beyond the basic deletion, and it does not contradict the annotations.

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

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

The description is a single sentence with no wasted words, front-loaded with the action and condition. It delivers the essential information efficiently.

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 delete operation with one parameter and an output schema (which covers return values), the description covers the core behavior and a notable side effect. It doesn't specify error behavior for completed workouts, but that is not necessary for a correct 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?

The only parameter, workout_id, is a UUID and is self-explanatory from its name. Schema coverage is 0%, so the description carries the burden, but it does not add meaning beyond the schema's type/format. Given the simplicity of the parameter, a 3 is appropriate.

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

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

The description states the specific action (delete/skip), the resource (workout), and a critical condition (uncompleted). It also discloses a side effect (Garmin copy removal). This clearly distinguishes it from siblings like mark_workout_completed or move_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 explicitly restricts usage to uncompleted workouts, giving an agent a clear criterion for when to call it. It does not name the alternative for completed workouts, but the constraint is strong enough to guide selection.

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

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

Annotations already mark the tool as read-only and non-destructive, so the description need not restate that. It adds meaningful behavior: free accounts can open only their latest 3 activities, and the response includes lap details. No contradiction with annotations.

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

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

Two short sentences with no filler. The core purpose is front-loaded, and the free-account restriction earns its place as an important behavioral note.

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

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

For a single-parameter read tool with an output schema and safe annotations, the description is largely sufficient. It names the return content (lap details) and the key access restriction. Error cases and pagination are not discussed, but they are not essential for selecting or invoking this tool.

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

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

There is only one required parameter, activity_id, whose meaning is self-evident from the tool name and schema title. However, the description does not elaborate on it, and with 0% schema description coverage it adds no explicit parameter-level detail. Low parameter complexity prevents a lower 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?

The description states a specific action ('Get') and resource ('one activity with lap details'), making the singular retrieval scope unambiguous. It naturally distinguishes itself from sibling tools like list_recent_activities, which lists activities rather than returning one.

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 this tool is for retrieving a single activity's details, but it does not explicitly say when to use it over alternatives or mention sibling tools. The free-account limitation is a constraint, not a usage directive.

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, so safety is covered. The description adds ordering (oldest first), timezone handling (local times), a summary, and constraints on days (max 365) and end_date format (YYYY-MM-DD). These are valuable 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?

Two sentences with no filler. The primary purpose is stated first, followed by the time-window constraint. Every word adds value.

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 is present, so return format is covered externally. The description covers the input constraints (days range, date format, default) and key behavioral traits (order, local times, summary). It does not mention pagination or error handling, but these are unlikely to be needed given the output schema and scope. Overall, complete for typical usage.

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

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

Schema description coverage is 0%, so the description must compensate. It explains days (max 365) and end_date (format and default), but does not describe the 'key' parameter beyond implying it identifies the metric. The required parameter lacks explicit semantics, leaving some 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 ('Get') and resource ('one custom metric's entries'), with behavioral details (oldest first, local times) and a summary. The contrast with list_custom_metrics is clear: this returns entries for a single metric, not a list of metrics.

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 it clear that this retrieves entries for one metric, but does not explicitly contrast with sibling tools like list_custom_metrics or mention when to prefer this tool. No exclusions or alternatives are named, so guidance is implied rather than 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 and destructiveHint=false. The description goes slightly beyond the annotation by enumerating the exact data categories the profile contains (body measurements, HR zones, health conditions, injuries), which is useful behavioral context for what the agent can expect. The bar is lower due to annotations, and this description adds relevant scope context without contradiction.

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, efficient sentence that front-loads the verb and resource, then enumerates the result categories in a compact list. Every word earns its place; there is no filler or redundancy.

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 parameterless read-only tool with a full output schema and clear annotations, the description is fully complete. An agent needs nothing more to decide when to call it and what to expect from it.

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

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

There are zero parameters, so there is no input schema to disambiguate. The description fully compensates by telling the agent exactly what data will be returned, making it clear there is nothing else needed to invoke the tool. With 0 params, the baseline for this dimension is 4, and the description exceeds it by specifying the result content.

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

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

The description uses a specific verb ('Get') and identifies a distinct resource ('the user's profile') with a concrete list of what it contains: body measurements, HR zones, health conditions and injuries. This clearly differentiates it from siblings like get_activity or get_schedule, and from the write-oriented update_profile, without needing to open 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 conveys a clear context: it is a read-only retrieval of profile information. It does not explicitly state when to prefer this over siblings such as list_custom_metrics or report_injury, but given zero parameters the tool is unambiguous in its scope. There is no exclusion guidance, so I cannot rate above a 3.

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 convey read-only and non-destructive behavior, so the bar is lower. The description adds the non-obvious default time window rule, which is useful, but it does not disclose how include_completed affects results or how explicit dates behave.

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, front-loaded with the action and resource, with no filler. Every phrase adds meaning.

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 read-only tool with three optional, self-describing parameters and an existing output schema, the description covers the main behavior and default range. The main gap is the unstated semantics of include_completed, but the schema title and default mitigate the 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 needed to compensate, but it only clarifies that absent dates default to the next 14 days. It never explains include_completed or the expected date format, leaving the agent to rely on property titles and defaults.

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

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

The description names a clear verb and resource: 'Get scheduled workouts and calendar events.' This distinguishes the tool from siblings like get_activity, list_daily_metrics, and get_custom_metrics, and the parenthetical examples clarify what counts as a calendar event.

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 by stating the default behavior ('Defaults to the next 14 days'), which tells an agent when a plain call is appropriate. It does not explicitly name alternatives or exclusions, but the purpose is specific enough that overlap with siblings is minimal.

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 indicate readOnlyHint=true and destructiveHint=false, so the description's job is light. The description adds that it returns training blocks and weekly targets, which gives some context about the nature of the data. It doesn't mention any other behavioral aspects like auth or rate limits, but given the read-only nature and zero parameters, this is minimal 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?

The description is a single concise sentence that is front-loaded with the main purpose ('Get the season plan') and elaborates with specific content. No unnecessary words. Perfectly sized for a tool with no parameters.

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

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

Given the tool has no parameters, an output schema exists, and annotations cover safety, the description is complete enough. It explains what the tool returns (training blocks and weekly targets). The only minor gap is that it doesn't describe how this differs from get_schedule, but for a no-parameter read-only tool, that's acceptable.

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

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

The tool has zero parameters, so the description does not need to clarify parameter meaning. The schema coverage is 100%, but with no parameters, the description is sufficient. The description adds value by specifying the content (training blocks and weekly targets), which sets expectations for the output.

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

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

The description clearly states the tool retrieves the season plan consisting of training blocks and weekly targets. It distinguishes it from sibling tools like get_schedule or get_activity by specifying 'season plan' as the resource, though it doesn't explicitly differentiate from those 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?

The description implies usage: when you need the season plan (training blocks and weekly targets), use this tool. However, it doesn't explicitly mention when not to use it or compare with alternatives like get_schedule, which might be used for similar scheduling information. There is no exclusion or alternative guidance.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds useful context about the data being self-reported series with units, but it does not disclose any additional behavioral details such as ordering, pagination, or scope beyond the user's metrics.

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 names the operation and immediately clarifies the resource with helpful examples and the unit concept. Every element earns its place; there is no repetition or filler.

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

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

For a parameterless read-only report with an output schema and safety annotations, the description gives enough to know what the tool returns. It is slightly incomplete only in the sense that it never addresses the near-twin sibling get_custom_metrics, which is a selection rather than invocation 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?

The tool accepts zero parameters, so the baseline is 4 and there is nothing for the description to clarify beyond the general scope. The empty schema and 100% schema coverage mean parameters cannot be a 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 clearly states the operation (list) and the resource (the user's custom metrics), and it adds a concrete sense of what those metrics are (self-reported series like pushups or weight history, each with unit). It does not explicitly differentiate from the similarly named sibling get_custom_metrics, so it loses the top point.

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

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

There is no guidance on when to use this tool versus its siblings, particularly get_custom_metrics or list_daily_metrics. The context is implied by the name and short description, but no exclusions or alternative routing are provided.

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, so the read-only nature is covered. The description adds valuable behavioral context beyond annotations: results are ordered newest first and free accounts are limited to 3 days of data. This helps the agent set expectations and avoids surprises.

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

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

Two compact sentences: the first states the action, scope, examples, and ordering; the second adds a key constraint (free account limit). There is no redundancy or filler. The information is front-loaded in order of importance.

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 what the tool lists, ordering, and a free-tier limit, and the output schema handles return values. However, the only parameter (days) is left unexplained, which is a clear gap for an agent trying to invoke it correctly. Given that there is only one parameter, this omission is more noticeable, so completeness is only adequate.

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 one optional parameter 'days' with default 14 and zero description coverage. The tool description does not explain what 'days' means—whether it's the number of days to return, a look-back window, or something else. Since the description is the only place to explain this parameter, its omission is a significant gap, leaving the agent to guess its semantics.

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

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

The description clearly states the action (list), the resource (user's latest daily metrics), and provides concrete examples (sleep, HRV, stress) along with ordering (newest first). This distinguishes it from sibling tools like list_custom_metrics, which target custom metrics, and get_activity, which is about a single activity.

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

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

The description gives clear context for when to use the tool: when the user needs their daily health metrics. It does not explicitly contrast with alternatives or state exclusions, but the examples and focus on 'daily metrics' make the use case obvious. No misleading guidance is present.

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

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

Annotations already mark this as read-only and non-destructive; the description adds the ordering guarantee and the free-account visibility limit, which are meaningful behavioral details beyond the structured annotations.

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

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

Two short sentences, both informative; the core operation is front-loaded and the free-account caveat is delivered without waste.

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 low-complexity read-only tool with an output schema and defaulted optional parameters, the description covers the essential behavior. It is slightly incomplete only in not clarifying pagination behavior of limit/offset, but the schema defaults mitigate that 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 does not explain how limit or offset behave, nor does it indicate a maximum or default beyond the account-level 'latest 3' fact. The parameter names are conventional but the description adds no semantic value for them.

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 ('List') and resource ('the user's activities'), and adds ordering ('newest first'). This clearly distinguishes it from singular get_activity and from metric-listing siblings in the toolset.

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 intended use is implied by the name and first clause, and the free-account limit is a useful context caveat. However, it never names alternatives or says when another listing tool would be more appropriate, so routing guidance 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 communicate that the tool is non-read-only and non-destructive. The description adds that this is a manual completion path rather than something derived from a recording, but it does not disclose status changes, idempotency, or undo 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?

Single sentence with no filler. The action is front-loaded and every word contributes to meaning.

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

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

The tool is simple, has one required parameter, and an output schema exists, so the description covers the main call scenario. It is missing only a small note on effects or preconditions, such as whether the workout must exist or be scheduled.

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 provides no parameter-specific explanation; workout_id is only inferable from the tool name, field title, and uuid format. The single-parameter design mitigates the harm, but the description itself adds no semantic value for this dimension.

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

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

The description uses a clear action ('Mark ... as done') and a specific resource ('a workout') plus a scope condition ('when the user did it without a recording'). This distinguishes it from sibling tools like delete_workout and move_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?

It gives an explicit trigger condition: use when a user completed a workout but no recording exists. It stops short of naming alternative tools or stating when not to use it, so it is clear context without full routing guidance.

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

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

Beyond the destructiveHint=true annotation, the description discloses a key side effect: workouts already on Garmin are removed first and are NOT re-sent, instructing the agent to tell the user to ask the coach to push it again. This is valuable behavioral context that annotations alone do not provide.

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

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

Two short, front-loaded sentences carry the core action and the critical caveat. Every sentence earns its place, with no redundant 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 mutation tool with an output schema and annotations already present, the description provides the essential extra context: the Garmin removal limitation and the required user-facing follow-up. Nothing critical is missing for an agent to invoke it correctly and communicate the outcome.

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 0% parameter description coverage, but the description compensates for the least obvious parameter: 'omit am_pm to keep its current AM/PM slot.' workout_id and new_date are self-explanatory from their names and formats, so the description adds meaning where it matters most.

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 ('Move an uncompleted workout to another date') and is clearly distinguishable from siblings like delete_workout or mark_workout_completed. The qualifier 'uncompleted' adds precision that prevents misuse.

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

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

The description gives clear context for the tool: moving uncompleted workouts to another date, and it explicitly excludes completed workouts by saying 'uncompleted.' It does not name sibling alternatives, but the use case is unambiguous enough that an agent can decide when to call 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 indicate readOnlyHint=false and destructiveHint=false, so the mutation behavior is already implied. The description adds modest value by stating that it 'Returns the full list' and noting the coaching adaptation effect. It does not disclose other behavioral traits such as update/delete behavior, permissions, or list specifics, but it does not contradict the annotations.

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

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

The description is two concise sentences with no filler. The core action is front-loaded, followed by the consequence and return behavior. Every sentence contributes useful information.

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

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

For a simple one-parameter recording tool with an output schema, the description is reasonably complete: it gives the action, the purpose, and the return behavior. It could be slightly clearer about what 'the full list' contains, but the overall context is sufficient for an agent to invoke the tool correctly.

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

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

The input schema has 0% description coverage and the single required parameter 'description' is generic. The tool description only indirectly indicates that the value should describe the injury or health condition, but it does not provide format expectations, examples, or additional context. With low schema coverage, the description does not sufficiently compensate for the missing parameter semantics.

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

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

The description clearly states a specific verb and resource: 'Record an injury or health condition.' It also explains the consequence ('the coach adapts training to it'), which distinguishes it from generic add/list tools like add_custom_metric. The purpose is unambiguous and easily differentiated from siblings.

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

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

The description implies when to use this tool: when an injury or health condition needs to be recorded. However, it does not explicitly contrast it with alternative tools such as add_custom_metric or any of the get/list tools, nor does it provide when-not-to-use guidance. The usage context is clear but not fully elaborated.

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 discloses that list fields replace the entire list, which is a behavioral trait beyond what annotations provide. Annotations already indicate destructiveHint=true, so the description adds the specific list replacement nuance. However, it doesn't mention other side effects like whether scalar fields are partially updated or if all fields must be provided, leaving some uncertainty.

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 concise, a single sentence, and front-loads the action and the critical list replacement note. It is not verbose, but for a tool with many fields, it might be too terse. The structure is efficient, but it sacrifices completeness.

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 a large schema and an output schema, but the description is minimal. It doesn't explain update semantics (e.g., partial vs. full update), return values, or error handling. The list replacement note is helpful but insufficient for a tool with this complexity. The agent would need to infer much from the schema, which is not fully covered by the description.

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 descriptions are comprehensive for each field, but the tool description adds only the list replacement behavior for list-type parameters (health_conditions, supplements). Since schema description coverage is 0%, the description carries some burden, but it doesn't explain individual parameter meanings. It adds value by clarifying list semantics, but not enough to fully compensate for the lack of coverage.

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

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

The description clearly states the action ('Update profile fields') with a specific resource, and it mentions a key behavioral nuance (list fields replace the whole list). It is specific enough to distinguish from read-only tools like get_profile, though it doesn't explicitly name alternatives. The purpose is clear but not exceptionally differentiated.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, conditions, or exclusions. The only usage hint is the list replacement behavior, which is about how the tool works, not when to use it. This is a significant gap for a mutation tool with many parameters.

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