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

Annotations indicate this is a non-read-only, non-idempotent mutation, but the description does not elaborate on side effects, concurrency control (despite expected_hash parameter), or what constitutes a 'managed library plan'.

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 good front-loading, but it is too brief for a tool with many parameters. Every word is earned, but it sacrifices utility.

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 11 parameters, 0% schema coverage, and an output schema not mentioned, the description is insufficient. Sibling tools indicate a lifecycle for plans, but no context on draft vs. scheduled state is provided.

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%, yet the description provides no explanation for any of the 11 parameters. Critical parameters like expected_hash, day, target, and others are left undocumented.

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

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

The description clearly states the action (Add), the resource (structured workout), and the target (managed library plan). It distinguishes from sibling tools like update_draft_workout or create_draft_plan.

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 guidance on when to use this tool versus alternatives. No mention of prerequisites (e.g., plan must exist and be in draft state) or scenarios where it should not be used.

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 (readOnlyHint=false, destructiveHint=false) indicate a mutation that is not destructive, but the description adds little beyond that. It states 'preserve a version' but does not explain the cloning process, such as whether the original plan remains unchanged, what happens to existing versions, or the role of the required expected_hash parameter. The output schema exists but is not described.

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

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

The description is a single sentence of 10 words, which is concise and front-loaded with the core action. However, this brevity comes at the cost of missing essential parameter and behavioral details, making it somewhat under-specified. It earns its place but is not optimally informative.

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 4 parameters with 0% schema coverage, a complex operation requiring hash confirmation, and an output schema that is not described, the description is far from complete. It does not explain the purpose of each parameter, the cloning semantics, or the return value, leaving an AI agent with significant ambiguity about how 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?

Schema description coverage is 0%, so the description must compensate, but it fails to define any parameter. It does not explain plan_id (the plan to clone), version_label (the label for the clone), expected_hash (likely a concurrency check), or confirmed (perhaps to confirm the action). The tool name implies version_label is the new label, but no details are given.

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 verb 'clone' and the resource 'managed draft plan', with the specific purpose 'to preserve a version before editing'. This distinguishes it from sibling tools like rename_draft_plan or create_draft_plan, as no other tool performs cloning. However, it could be more explicit about what cloning entails (e.g., creating a copy with a new version label).

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 minimal usage guidance: it only implies the tool should be used 'before editing' a draft plan. It does not specify when to use this tool versus alternatives like rename_draft_plan or schedule_draft_plan, nor does it mention prerequisites or when not to use it.

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

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

Annotations already indicate the tool is not read-only, not idempotent, and not destructive. The description adds the constraint that it does not apply to the calendar and states it’s a 'private managed library' plan, but no further behavioral details like side effects or permissions.

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, very concise but at the expense of parameter semantics and usage guidance. It is front-loaded with the action but lacks necessary detail.

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 the presence of an output schema (not shown) and sibling tools, the description does not cover parameter details, usage context, or the meaning of 'private managed library'. For a tool with 4 parameters, this is insufficient.

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 tool description does not explain any of the 4 parameters (name, confirmed, description, activity_types). The agent must infer from names alone, which is insufficient 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 clearly states the action ('Create') and the resource ('private managed library PLAN'). It differentiates from scheduling siblings by explicitly saying 'never apply it to the calendar'.

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 a clear negative directive ('never apply it to the calendar') but does not give positive guidance on when to use this tool, nor does it mention alternatives like schedule_draft_plan for applying. No prerequisites or context 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?

The readOnlyHint annotation already indicates idempotency. Description adds that the tool reads from the athlete profile specifically, providing additional behavioral context beyond the annotation.

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, complete sentence with no wasted words. Front-loaded with purpose.

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 zero parameters, a read-only annotation, and an output schema fulfilling return details, the description fully contextualizes the tool's functionality.

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?

No parameters exist, so description needs no parameter details. Schema coverage is 100%, baseline score of 4 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?

Describes specific verb 'Read' and resource 'health and body-composition fields from the athlete profile'. Distinguishes from sibling tools like get_personal_context by emphasizing 'profile only'.

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?

Context is clear: for reading profile health data. Does not explicitly state when not to use, but the description is sufficient given siblings like get_personal_context for other contexts.

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 readOnlyHint=true. The description adds that the tool rejects plans outside the draft namespace and returns both plan and workouts, providing context beyond read-only 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 description is a single sentence that efficiently conveys the main purpose and constraint. It is front-loaded and without unnecessary words, though it could be slightly more structured.

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 and minimal parameters. The description covers the return content and namespace restriction, which is sufficient for a simple get operation. No missing critical details.

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 description does not mention the single parameter plan_id or provide any additional meaning beyond the input schema. With 0% schema description coverage, the description fails to compensate by explaining the parameter's role or format.

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

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

The description clearly states the tool reads a managed plan and its workouts, specifically for draft plans. The verb 'Read' and resource 'managed plan and its workouts' are precise, and the constraint 'reject plans outside the draft namespace' distinguishes it from other plan retrieval tools.

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 for draft plans only but does not explicitly say when to use this tool versus alternatives like list_draft_plans or get_training_context. No when-not or alternative guidance is 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 indicate read-only behavior (readOnlyHint: true). The description reinforces that and specifies the data types (power, pace, heart-rate). However, no additional behavioral traits (e.g., permissions, rate limits) are disclosed, which is adequate given 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, well-formed sentence with no extraneous words. It efficiently conveys the core action and constraints (read-only, specific data). Perfectly sized for a simple tool.

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

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

Given the tool has an output schema (documenting return values) and annotations, the description covers the essential action. However, it lacks explanation of the 'curves' parameter and how the tool integrates with typical workflows. Adequate but incomplete for optimal agent understanding.

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 explain parameters. It mentions curve types but does not describe the 'sport' (required) or 'curves' (default: '42d') parameters. This leaves the agent without meaningful guidance for parameter values.

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 ('Read') and the resource ('power, pace, and heart-rate duration curves'), with a specific scope ('curves'). It distinguishes from sibling tools which focus on drafting plans and personal context, making the purpose 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?

The description implies usage for read-only access via 'without modifying data,' but no explicit guidance on when to choose this tool over alternatives like get_athlete_profile or get_training_context. It provides minimal context for 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 include readOnlyHint=true, indicating a safe read operation. The description adds the purpose but does not describe the output or detailed behavior beyond that, which is acceptable given the annotation coverage.

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, direct sentence that conveys the tool's purpose and usage without unnecessary words. It is perfectly concise.

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

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

For a zero-parameter read-only tool with annotations and likely an output schema, this description provides sufficient context for an agent to understand when and why to use 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 no parameters, and schema coverage is 100%. The description adds no parameter details, but that is expected for a zero-parameter tool, meeting the baseline of 4.

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 'Read' and identifies the resource as 'durable athlete preferences and constraints', clearly distinguishing it from sibling tools like 'get_training_context' or 'get_athlete_profile'.

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 explicitly states 'before planning or editing', providing clear when-to-use guidance. No explicit exclusions or alternatives are given, but the context is clear enough.

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's 'Read' aligns with the readOnlyHint annotation, but no additional behavioral details (e.g., error handling, performance) are disclosed beyond the annotation. The inclusive ISO date range is noted, but this is more about parameters than 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 description is a single, concise sentence that front-loads the verb and key resources. Every word serves a purpose, with no redundancy 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?

Given the tool's simplicity (two required string params, read-only, output schema exists), the description adequately covers the core functionality. It could mention that it returns combined data, but the existing output schema mitigates this 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?

With 0% schema description coverage, the description compensates by specifying 'inclusive ISO date range', providing format context that the schema (only types and titles) lacks. It clarifies that the parameters are ISO dates and that the range is inclusive, adding meaning beyond the raw schema.

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

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

The description clearly states the verb 'Read' and the resources 'activities, wellness and calendar events', distinguishing it from sibling tools like get_athlete_profile or get_personal_context. The scope 'inclusive ISO date range' adds specificity.

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 use for retrieving a holistic training context over a date range, but does not explicitly state when to use this tool versus alternatives like get_personal_context or set_personal_fact. No exclusions or comparative guidance are given.

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

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

Annotations declare readOnlyHint=true. Description adds value by specifying the scope and that content hashes are included. No contradictions.

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 focused sentence, no redundancy. Front-loaded with key 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 zero-parameter list tool with output schema, description sufficiently covers purpose, scope, and return data.

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?

No parameters. Schema coverage 100%. Description not needed for parameter semantics. Baseline 4.

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?

Description clearly states verb (List), resource (plans managed by this server), and output characteristic (content hashes). Distinguishes from siblings like get_draft_plan.

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 usage scope ('managed by this server'), but does not explicitly state when not to use or provide alternatives. Clear enough given sibling context.

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 this is not read-only and not destructive, but the description adds no behavioral details beyond the renaming action. The mention of 'short display prefix' is unclear in terms of effect or 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?

The description is concise (one sentence) but at the expense of completeness. It provides no structure or breakdown of the tool's functionality.

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 4 parameters (3 required) and no parameter documentation, the description is severely lacking. The presence of an output schema does not excuse missing explanations of inputs like 'expected_hash' and 'confirmed'.

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 fails to explain any of the four parameters (name, plan_id, confirmed, expected_hash). The agent has no clue what 'expected_hash' or 'confirmed' mean in this context.

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 (rename) and the object (one managed library plan). However, the phrase 'using the configured short display prefix' is ambiguous and might confuse agents unfamiliar with the system concept.

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 guidance is provided on when to use this tool versus siblings like create_draft_plan or clone_draft_plan. There is no mention of prerequisites or context that would help an agent decide to invoke 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 a non-read-only, non-idempotent, non-destructive operation, but the description adds no context about side effects, such as what happens if the date already has calendar events or if the plan can be rescheduled.

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 with no wasted words, but it is too brief to convey necessary details, resulting in under-specification.

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 5 parameters (including an expected_hash and conflict flag) and an output schema (not detailed), the description omits crucial context about parameter semantics, return values, and how this tool differs from siblings like get_draft_plan or clone_draft_plan.

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 any of the five parameters (plan_id, expected_hash, start_date, confirmed, allow_calendar_conflicts), failing to add meaning beyond the bare schema.

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

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

The description clearly states the tool applies a draft plan to the calendar on a specific future ISO date. This distinguishes it from siblings like unschedule_draft_plan (removes), rename_draft_plan, or add_workout_to_draft.

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 guidance on when to use or avoid this tool versus alternatives. Sibling tools like unschedule_draft_plan or update_draft_workout exist, but no criteria for selection 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 provide idempotentHint=true and destructiveHint=false; description adds 'non-secret' and 'replaced safely', which aligns but doesn't disclose auth needs or rate limits. Adequate for the annotation coverage.

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 14 words. No redundancy. Front-loaded with key action verb 'Remember'. Optimal conciseness.

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 3 required parameters, enum, output schema existence, and annotations, the description covers the core behavior but omits any mention of return format or potential errors. Adequate but not thorough.

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?

Description provides no explanation of the three parameters (section, key, value). With 0% schema coverage, the burden is on description to add meaning, which it fails to do effectively.

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 remembers a durable, non-secret athlete fact with safe replacement under the same section/key. It distinguishes from sibling read tools like get_personal_context.

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 use for storing non-secret facts and that calling with same section/key replaces. No explicit when-to-use or when-not-to-use compared to siblings like create_draft_plan or rename_draft_plan.

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 adds behavioral context beyond the destructiveHint annotation by specifying what is deleted (calendar copies) and what is preserved (library plan). However, it does not disclose behavior such as what happens if no calendar copy exists, potential cascading effects, or rate limits.

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 fluff, which is concise. However, given the lack of parameter descriptions and the complexity of the operation, the description is under-specified and fails to convey necessary 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?

Despite having an output schema, the description does not mention return values or side effects beyond deletion. With 4 parameters and no parameter descriptions, the description is incomplete for an agent to use 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?

No parameter descriptions are provided in the schema (0% coverage), and the tool description does not explain the meaning or purpose of any parameter (plan_id, expected_hash, start_date, confirmed). The agent receives no guidance on how to populate these fields.

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 ('Delete') and target ('calendar copies from one managed plan application'), clearly distinguishing this tool from siblings like schedule_draft_plan and create_draft_plan. It explicitly states the library plan is preserved.

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 removes calendar copies while keeping the library plan, but it does not explicitly state when to use it versus alternatives (e.g., full deletion) or provide any prerequisites or conditions.

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 this is not read-only, idempotent, or destructive. The description adds that it checks a hash before replacing, implying conditional behavior, but does not explain error handling (e.g., if hash mismatch) or what happens to the replaced workout. No output schema is provided to clarify return values.

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 that efficiently communicates the core action and a key requirement. However, it could be slightly more structured by listing the fields being replaced.

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 complexity (12 parameters, 7 required, no schema descriptions) and the existence of an output schema (not shown), the description is too sparse. It omits essential context like the need for the plan to be in a draft state, what the hash represents, and the expected return value.

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 should compensate, but it only mentions plan_id, expected_hash, and workout_id. It does not explain the meaning or usage of required parameters like name, description, activity_type, day, or optional ones like tags, time, indoor, target, confirmed.

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 ('replace'), the resource ('one workout on a managed plan'), and a key precondition ('after checking the plan hash'). This differentiates from siblings like add_workout_to_draft and rename_draft_plan.

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, such as add_workout_to_draft for adding new workouts. It does not mention prerequisites (e.g., the plan must be a draft) or conditions for use.

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