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

Beyond the annotations, the description discloses that writes happen immediately with no separate approval step, that free accounts are capped at 3 memories and Pro at 50, that updates by id are allowed even at the cap, and that there is no delete/bulk capability. This meaningfully extends what the annotations alone communicate.

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 longer than typical, but each paragraph earns its place: purpose, do-not-duplicate workflow, exclusions for structured health data, and write/cap behavior. The core action is front-loaded before broader guardrails.

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 a 3-parameter tool with full schema coverage, an output schema, and meaningful annotations, the description closes the important gaps: when to update vs add, what content belongs, what caps apply, and why duplicate structured records should be avoided. No critical dimension appears missing.

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

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

The schema already covers all three parameters at 100%, but the description adds real semantics: it clarifies that content must be a compact durable fact/preference, illustrates valid content with examples, and explains the relationship between memory_id and operation update in the list-first workflow.

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

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

The description opens with a specific verb and resource: 'Add a new Personal Context memory, or update an existing one by id.' It also distinguishes itself from nearby tools in the sibling list by explaining that memories are durable circumstances/preferences and that structured health data belongs in other dedicated 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?

It gives explicit, actionable guidance: use list_personal_context first, pass the existing id with operation update instead of duplicating, and avoid storing metrics/trackable health data here because dedicated tools exist for those. This is strong when-versus-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?

The annotations already disclose destructiveHint=true and idempotentHint=true, so the description does not need to restate those. It adds useful framing with 'previously declared' and real user scenarios, but it does not reveal additional behavioral traits such as what happens when no rest day exists or whether the action is reversible.

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 compact and front-loaded: it states the action first, then gives usage examples, then supplies a clear inference instruction. Every sentence earns its place, and the structured 'INFER — do not ask' line is easy for an agent to parse.

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?

This is a single-optional-parameter tool with an output schema present and annotations covering mutability, destructiveness, and idempotence. The description covers what the tool does, when to use it, and how to handle the parameter, so an agent has everything 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 coverage is 100%, so the schema already documents the date parameter, its format, and default. The description adds meaningful semantic guidance beyond the schema by instructing the agent to infer the date from the user's reference rather than asking, which directly affects invocation behavior.

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

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

The description opens with a specific verb and resource: 'Remove a previously declared rest day.' This clearly differentiates the tool from sibling tools like log_rest_day and list_rest_days, since it targets undoing a prior declaration rather than creating or listing 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 gives explicit when-to-use guidance: when the user changes their mind or wants to undo a mistaken declaration. It does not explicitly name alternatives or state when not to use it, but the 'previously declared' qualifier and the examples make the intended context 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 already indicate readOnlyHint=false and destructiveHint=false, and the description aligns with a creating/writing operation. It additionally discloses behavioral details: the tool loads current goals itself, refuses to stack duplicate goals, reports what a standard target changed from, and supports acknowledged warnings. Minor gap: no explicit statement about persistence or side effects beyond creation, but annotations cover the general write nature.

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 organized into three focused paragraphs and avoids unnecessary filler. It is slightly repetitive with the 'See UNIT INPUTS' references and the phrase 'Required on create / Set at create, not editable later', but these repetitions serve clarity in a large parameter surface and do not harm usability.

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 large number of parameters (29) and the existence of an output schema, the description does not need to explain every field individually; the schema handles that. It does provide important contextual guidance on unit conversion, duplicate prevention, and when to omit list_goals. A small gap is that it references 'canonical Goals definitions' without embedding them, but this is acceptable given the schema already enumerates valid goal_type values.

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 100% and each parameter includes targeted descriptions referencing relevant goal types. The description also gives important cross-cutting semantics for unit fields (input_weight_unit/input_distance_unit) and clarifies required-on-create versus not-editable-later fields. This goes well 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 tool's purpose: 'Create a new Wellness Project goal or standard target' and specifies when to call it directly. It names the primary action (create) and the resource (goal), leaving no ambiguity about what the tool does.

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 explicit usage guidance: call directly when establishing a goal, no prerequisite schema discovery or list_goals call is needed. It also warns against calling list_goals first and explains the tool's built-in duplicate guard, which is actionable and relevant.

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 idempotentHint=true, so the destructive nature is covered. The description adds valuable behavioral detail: exactly one of id or date is required, date resolution matches only the period start date or any date within it, and an ambiguous match causes an error that returns candidate IDs to retry with. This goes 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?

The description is compact and front-loaded with the core purpose, followed by usage constraints and selector details. Every sentence earns its place, with no filler or repetition of schema content.

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 2-parameter destructive tool with annotations and an output schema, the description is complete. It covers what the tool does, when to use it, when not to use it, how to select the target, and how ambiguity is handled. 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 100%, so the schema already documents both parameters. However, the description adds important semantics: 'Exactly one required' clarifies the optional-looking schema, and it explains how date resolves and what happens on ambiguous matches. This meaningfully aids correct invocation beyond the schema alone.

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

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

The description states a specific verb and resource: delete a period record. It explicitly distinguishes itself from update_cycle, telling the agent it must not use this tool to 'fix' a record. This makes it easy to tell apart from the sibling update_cycle tool.

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?

Provides explicit when-to-use guidance: only when the user explicitly asks to remove a specific record. It also gives a clear exclusion and alternative: do not delete to fix a record; use update_cycle instead. The selector instructions further clarify how to invoke it correctly.

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 destructive, but the description adds meaningful behavioral context: deletion is permanent, severity history is also removed, and ambiguous injury matches cause an error returning candidate IDs. This goes well beyond the structured hints and clearly sets expectations for 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 compact and front-loaded: effect first, side effect second, then selector rules. Each sentence earns its place and no information is repeated from the schema or annotations. The use of an em-dash separator and explicit rule statements makes it easy to parse.

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

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

Given the output schema exists and annotations cover safety, the description supplies everything else needed: selection strategy, disambiguation behavior, requiredness despite no schema-required params, and destructive consequences. The tool is fully usable based on this description alone.

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

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

Schema coverage is 100%, so the baseline is met. The description adds value by explaining the mutual exclusivity between id and injury, the exact-one-required contract, the role of date as a narrowing filter, and the error behavior on ambiguous matches — all beyond the schema's individual property descriptions.

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: 'Permanently delete an injury entry.' The scope is precise, and naming the cascading removal of severity history distinguishes this from update_injury and log_injury. An agent can tell exactly what this tool does and what side effects come with 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?

Provides clear operational guidance: how to choose between id and injury, when to use date to narrow, and that exactly one selector is required. It does not explicitly discuss alternatives like update_injury for non-destructive changes, but the selector guidance is detailed enough for practical use.

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

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

The description goes well beyond the annotations by disclosing that date-scoped deletes are irreversible, can remove many rows at once, and require user confirmation. It also includes the strong guardrail 'Never guess a selector.' These behaviors are not inferable from readOnlyHint=false or destructiveHint=true alone, so the description adds substantial value.

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 well-structured with a bolded selector heading and bullet-like separators. Every sentence serves a purpose: defining the action, stating when to use it, warning about irreversibility, and explaining parameter combinations. The length is appropriate for the destructive and ambiguous nature of the operation.

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 destructive nature and four optional parameters with complex interactions, the description fully covers what an agent needs: when to use it, how to choose selectors, what is irreversible, and when to confirm with the user. The output schema exists, so return-value documentation is not required. No critical context 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?

Although schema coverage is 100%, the description enriches the parameters by explaining the selector hierarchy: id deletes one row, date deletes the whole draw, and date+marker resolves to one row with error behavior if multiple markers match. It also clarifies that panel_name narrows date-based selectors and that marker is ignored when id is present—none of which the schema alone conveys as clearly.

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 'Permanently delete one or more lab results,' which is a specific verb and resource. It also clarifies the exact use case ('when the user explicitly asks to remove or delete a logged lab result') and distinguishes itself from siblings by focusing on deletion rather than update or logging.

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 states when to use the tool and provides detailed selection guidelines among id, date, and date+marker. It does not explicitly name alternatives like update_lab_result for non-destructive corrections, but the context is clear enough that an agent should not confuse this with other lab-related tools.

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

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

Despite strong annotations (destructiveHint=true, readOnlyHint=false), the description adds important behavioral detail: irreversibility, cascade deletion of linked hydration events, and the exact error behavior when a match is not exactly one meal. It also clarifies that nothing is deleted on ambiguity, which is critical safety context 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?

The description is longer than average, but every sentence earns its place. It is front-loaded with purpose, then organized into clearly capped sections (FIND THE MEAL, HYDRATION) with no filler or repetition.

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, irreversible operation, the description covers all critical aspects: how to identify the exact meal, what happens on ambiguity, retry guidance, and cascade effects. An output schema exists, so return-value documentation is not the description's responsibility. 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 100%, but the description adds substantial selection logic: id is an alternative to date+name, name is a case-insensitive substring used only for disambiguation, and date defaults to today. This gives the agent the decision rules needed to choose the right parameter combination, going well beyond the schema descriptions.

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

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

The description opens with a specific verb and resource: 'Permanently delete a meal entry.' It also states the exact triggering condition ('when the user explicitly asks to remove or delete a logged meal'), which clearly distinguishes it from related meal tools like update_meal and log_meal.

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 when-to-use guidance, including the user-intent trigger. It also provides a detailed decision procedure for locating the meal (id vs. date+name, name only when multiple meals exist) and an explicit exclusion: do not issue a separate hydration delete. This fully routes the agent away from incorrect usage.

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 signal destructiveness and idempotency, and the description adds irreversibility, ambiguity-handling guidance, and the error behavior with candidate IDs. The description and annotations align, and the additional context meaningfully exceeds what annotations alone 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?

The description is front-loaded with the most important facts (permanence, irreversibility, ambiguity handling) followed by a compact selector block. Every sentence adds operational value and 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?

Given the tool's destructive nature and the non-obvious selector logic, the description fully equips an agent to call it correctly: it covers user clarification, parameter selection, ambiguity resolution, and error recovery. The output schema and annotations cover remaining details, so nothing material is missing.

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

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

Schema coverage is 100%, but the description adds crucial cross-parameter semantics: the selector relationship between id and session_date, the optional narrowing role of session_category, that session_category is ignored when id is given, and the exactly-one-required constraint. This goes well beyond the baseline schema descriptions.

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 ('Permanently delete') and a specific resource ('a recovery session log entry'), clearly distinguishing it from sibling delete/update/log tools. The title annotation adds a parallel label, and the resource is unambiguous against the large set of sibling 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?

Explicitly instructs the agent on when to ask the user for clarification, how to resolve the target session using either id or session_date, and what to do if multiple sessions match. It also clearly states that exactly one of id or session_date is required, which is not reflected in the schema's required parameters.

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 destructive and idempotent, and the description adds meaningful behavior beyond that: it will error with candidate IDs when multiple runs match, distance matching is approximate within 0.25 mi, and unit conversion is handled internally so the agent must never convert values itself. This gives the agent important operational expectations not encoded elsewhere.

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 appropriately sized and every sentence contributes useful information, but the main purpose ('Delete a run') is not front-loaded; the tool starts with a unit-inputs caveat instead. The selector and ambiguity guidance are well organized afterward, so the structure is good but not maximally focused.

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 all necessary invocation context: when to use it, confirmation behavior, how to choose between id and date, approximate matching, unit handling, and the error outcome when multiple runs match. An output schema exists, so not detailing return values is acceptable; nothing an agent needs to call this tool correctly is missing.

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

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

While schema coverage is 100%, the description adds critical semantic rules not present in the schema: exactly one of id or date is required, distance_mi is ignored when id is given, distance matching is approximate, and input_distance_unit only applies when the user supplied km. These constraints materially change how the parameters should be used and are essential 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 opens the second paragraph with 'Delete a run. Use when the user wants to remove a run entry,' which names a specific verb and resource and clearly distinguishes this tool from run-logging or run-listing siblings like log_run, list_runs, and show_runs. The title and name reinforce the action, and the description adds unambiguous purpose.

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 states when to use the tool ('when the user wants to remove a run entry') and instructs the agent to ask for confirmation if intent is ambiguous. It also provides selection guidance for resolving the target run, but it does not explicitly mention when-not-to-use or compare against sibling deletion tools, so it stops just short of full exclusion guidance.

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

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

The description reinforces the destructive nature ('Permanently delete') and adds transparency about the idempotent behavior (error with candidate IDs on ambiguous date). It goes beyond the annotations by detailing the exact failure mode and retry guidance.

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 compact yet complete, comprising two sentences and a selector note. Every word contributes to usage clarity, with no redundant or vague statements.

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, the description covers all necessary context: target, selector, exclusivity, and error handling. The lack of output schema details is acceptable since a delete confirmation is standard and does not hinder 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?

Both parameters (id and date) are fully described in the schema and the description, including the semantics of date ('any day within the entry's period') and the exclusivity requirement. High schema coverage combined with clear prose makes parameter usage unambiguous.

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 ('Permanently delete') and the target ('a wellbeing entry'), with no ambiguity. It effectively distinguishes this from sibling tools like update or log by specifying deletion and the selector mechanism.

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

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

Explicitly explains when to use the tool by providing a selector rule: pass id or date, exactly one required. It also describes the error condition when the date matches multiple entries, giving clear guidance for resolution.

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 annotation destructiveHint=true is reinforced by the description's use of 'Permanently delete' and 'irreversible.' The description also explains the idempotent behavior (if no unique match, nothing is deleted and an error is returned), which aligns with idempotentHint=true. No contradictions exist between the description and 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 well-structured with clear sections: the primary purpose, FIND THE SESSION, and SAVED WORKOUTS. It avoids redundancy and each sentence adds necessary information. The use of bold labels and concise bullets (though not bullets) makes it easy to parse. Despite being lengthy, it is efficiently organized and not verbose.

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 fully covers the decision tree for selecting parameters: session_id vs session_date+name, defaults, the saved_workout_id alternative, and the error case (no unique match). It also states the destructive and irreversible nature, leaving no ambiguity for an agent. Given the moderate complexity (4 params, 0 required, with defaults and alternatives), the description is 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?

All four parameters are fully described in the schema, and the description adds valuable context beyond the schema. For example, session_id is described as an 'Alternative to session_date + name,' session_date includes format and default, name explains substring/case-insensitivity and when it applies, and saved_workout_id clarifies its distinct purpose. The description references the FIND THE SESSION section for cross-guidance, making semantics clear.

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

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

The description clearly states the verb and resource: 'Permanently delete a workout session and all its exercises and sets.' It also explicitly says 'Use when the user wants to remove a logged workout entirely,' providing unambiguous intent. The distinction between completed workout history and reusable saved workouts is also clarified.

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 usage guidance: it instructs when to use the tool and how to select the correct target. It explains the two identification paths (session_id vs session_date + name), the default for session_date, and the alternative for saved_workout_id. It also states the error behavior when no unique match exists, so the agent knows when to retry or use a different parameter.

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, idempotentHint=true, and destructiveHint=false, so the description's job is behavioral context beyond safety — and it delivers: the guide is 'intentionally limited to stable, customer-facing help,' navigation must be grounded only in explicitly named paths ('Do not infer, invent, or autocomplete nearby navigation'), and pricing must be reproduced verbatim with an exact CTA block appended in the in-app coach. These operational constraints shape how the agent should consume the result and cannot be inferred from 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?

Front-loaded with purpose in the first sentence, then flows from usage scope to exclusions to navigation grounding to operational pricing rules to examples — a logical structure. It is long, but every section carries operational weight; the only drag is the dense single-sentence exclusion list, which could be broken up for easier parsing.

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

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

For a 1-parameter lookup tool with an output schema present, the description covers everything needed for correct invocation: purpose, scope boundaries, grounding constraints, exact pricing reproduction behavior, and worked examples. Combined with annotations covering the read-only/idempotent profile, 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?

Schema description coverage is 100%, so each of the 12 enum values is already thoroughly documented, giving a baseline of 3. The description adds genuine value above that via natural-language example mappings ('where do I see my PRs?' -> pages_training) and by clarifying that cost/Free/Pro/Founding Member/3-analysis questions route to topic=pricing — a routing detail not present in the schema enum description.

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: 'Look up general customer help for the Wellness Project app.' Then narrows scope to 'broad questions about where a feature lives, how to use it, what a visible feature does, common troubleshooting steps, or pricing,' which clearly distinguishes it from the data-centric sibling tools like log_meal, update_workout, and get_exercise_history.

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

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

Gives explicit scoping with 'Use this only for...' followed by a precise list of question types, plus negative guidance listing what must not be added or inferred (implementation details, policy, privacy claims, billing mechanics, etc.). It also provides concrete example-to-topic mappings and detailed conditional rules for the pricing topic, telling the agent exactly which message to reproduce and when.

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 annotations already declare readOnlyHint: true, idempotentHint: true, and destructiveHint: false, with no contradiction in the description. The description adds useful behavioral context beyond the annotations, such as that exercise_name 'resolves to canonical, or says so if never logged' and that 'Banded and unbanded PRs are shown side-by-side when both exist.' This extra detail about resolution and output formatting earns a score above the baseline of 3.

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 well-structured with distinct sections (overview, USE FOR, NOT, INFER) and uses bullet-like lines for readability. However, some information is repeated (e.g., the opening paragraph already mentions all-time PR and recent performance, and the USE FOR section restates these examples). This slight redundancy keeps it from a perfect score, but it remains clear and reasonably 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?

The description is thorough for the tool's complexity. It details the output contents (est. 1RM PR, exact set, date, weight, reps, RPE, banded vs unbanded, superset siblings, notes, rep-range bests, recent sessions, delta), explains the optional parameters' effects, and covers edge cases like 'never logged.' Given that no output schema is shown, this descriptive completeness is essential and well-executed.

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 100% (all three parameters are described). The description adds semantic nuance that improves parameter understanding: since_date 'narrows only the Recent block; the PR is always all-time,' recent_limit is 'default 10, capped at 50,' and exercise_name is 'free-text — the tool resolves to canonical.' This additional guidance justifies a score above the baseline of 3.

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's purpose: 'Look up everything the user has done for ONE exercise: all-time PR plus recent performance, across many sessions.' It uses a specific verb ('look up'), a specific resource (exercise history), and a clear scope (one exercise). It also distinguishes the tool from siblings like get_workout and list_workouts by mentioning 'NOT for a full session' and 'or a date-window list regardless of exercise.'

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 lists use cases under 'USE FOR:' (PR lookups, recent-activity questions, trend questions) and non-use cases under 'NOT for' (full session, date-window list), naming the appropriate sibling tools (get_workout, list_workouts). It also provides operational guidance under 'INFER — do not ask:' for each parameter, making 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?

Annotations already signal read-only and idempotent behavior, and the description goes far beyond them by disclosing a non-obvious accuracy quirk: a wrong or missing equipment tag on a dumbbell exercise 'silently halves or doubles its NSI score.' It also explains when equipment is shown per exercise vs per set and what 'missing' means, which is highly useful behavioral detail not present in 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 long but densely informative, with clear section headers (NSI, EQUIPMENT, REQUIRED WORKFLOW, SAVED WORKOUTS) that make scanning easy. Every sentence adds operational knowledge; there is no filler or repetition of schema definitions.

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 tool has complex behavior (nested NSI scoring at session/exercise/set grains, equipment-tag sensitivity, two distinct input modes). The description covers all of these, plus the required lookup workflow and a correctness caveat. Together with the annotations and schema, an agent has everything needed to invoke the tool correctly and interpret its unusual scoring behavior.

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 100%, so the baseline is 3. The description adds value beyond the schema: it explains that session_id comes from list_workouts and is required, clarifies saved_workout_id returns a 'reusable prescription instead of a completed workout session,' and warns against combining saved_workout_id with session_id/session_date. These semantic clarifications exceed the schema's basic field descriptions.

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

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

The description opens with a specific verb and resource: 'Retrieve full detail of a workout session' and enumerates the exact contents (exercises, sets, reps, weights, superset groupings, heart points, notes, NSI scoring). It clearly differentiates from siblings like list_workouts (list vs full detail) and show_workout (which may focus on summary/display), and also explains the separate saved_workout_id mode.

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

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

Explicitly states when to use: 'Use for detailed questions about a past workout, reviewing training before recommendations, confirming what was logged, or comparing a session to population strength standards.' It also mandates the preceding workflow step ('call list_workouts first to find the session ID — never guess it') and gives a clear exclusion/alternative for saved workouts ('Do not combine it with session_id/session_date').

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 read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that: it is a search over public content, returns specific fields, and prescribes how results should be linked inline. This is more than the annotations alone provide, though it does not cover edge cases like empty results or error 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 compact and well organized: purpose first, usage constraint second, return format and link handling last. Every sentence adds useful information, 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?

This is a simple, optional-parameter read tool with a rich schema, output schema, and full annotations. The description covers when to use it, what it returns, and how to format links, so an agent has everything needed to select and 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 100%, so all three parameters are already documented with types and descriptions. The tool description adds no new parameter semantics beyond the general search framing, which matches the baseline for fully covered schemas.

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 and resource: searching the public Crew Blog at /blog for advisor-authored posts. It clearly identifies what the tool returns and the /blog/<slug> link format, making its purpose unambiguous and distinguishable from the many list/show 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 gives explicit when-to-use guidance: only when the user explicitly asks about the blog or what an advisor has written. It also provides a clear when-not-to-use instruction: don't volunteer posts in normal conversation. No sibling tool covers this same domain, so naming an alternative is unnecessary.

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 annotations (readOnlyHint, idempotentHint, destructiveHint false), the description adds behavioral context: it states BMI in the output is derived from the user's canonical height and that day's resolved weight, and instructs the agent not to recompute it. It also explains default parameter behavior (infer 30 days ago to today). These details help the agent understand side effects and derived data, exceeding annotation-only transparency.

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 and well-structured. It covers purpose, usage conditions, range constraints, and behavioral notes without unnecessary verbosity. Each sentence serves a distinct purpose: identifying the resource, stating when to use, noting the 31-day limit, and explaining parameter inference. No fluff or redundant 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?

Given an output schema exists, the description need not explain return values. It fully covers input parameters, defaults, usage context, range limits, and derived data behavior. The description provides all necessary information for an agent to invoke the tool correctly in various scenarios, making it contextually 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?

The schema descriptions for start_date and end_date specify format (YYYY-MM-DD) and defaults ('30 days ago', 'today'). The description reinforces these defaults and adds the 'INFER — do not ask' guidance, making the parameter semantics fully clear. Schema coverage is 100%, and no enums exist, so the description effectively complements 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?

The description clearly states the tool lists body composition entries within a date range. It specifies the resource ('body composition entries') and scope ('date range'), and the context signals show sibling tools include similar list tools, enabling an agent to distinguish this from list_workouts, list_meals, etc. The verb 'list' and explicit resource make 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 explicitly states when to use the tool ('when the user asks about their weight history, body fat trend, or any body metrics over time'). It also provides guidance for handling longer periods by making multiple calls with sequential date ranges, and instructs the agent to infer default parameters rather than asking the user. This gives clear, actionable usage instructions.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it clarifies date-range scoping, explains the relationship to update/delete operations, and instructs the agent to infer defaults rather than ask the user.

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 compact and front-loaded with the core purpose. The sibling differentiation, usage condition, and default-inference instruction each earn their place without redundant filler. It is structured for quick scanning by an agent.

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 list tool with two optional parameters, full schema coverage, a safe read-only annotation profile, and an output schema, the description provides everything needed to invoke it correctly. It also covers the relevant edge case of ambiguous update/delete matches, making it contextually complete.

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

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

Schema description coverage is 100%, with both start_date and end_date already documented including format and defaults. The description mostly repeats these defaults in the INFER block. It adds the 'do not ask' operational instruction, but that is not new parameter semantic meaning beyond what the schema already provides.

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: 'List the user's logged period records within a date range.' It also explicitly differentiates this tool from update_cycle and delete_cycle, so an agent can tell exactly what list_cycle is for relative to its 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 gives explicit when-to-use guidance: use it when the user asks about cycle history, or to get an id after an ambiguous update/delete match. It also explicitly says the tool is no longer required before update_cycle/delete_cycle because those resolve records by date, which prevents unnecessary calls.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful context by revealing the grouping behavior and explaining that canonical names support exercise tracking and NSI score calculation, which goes beyond the annotations.

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

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

Three concise sentences with no filler: output definition, when to call it, and why it matters. The most actionable guidance is front-loaded, and every sentence earns its place.

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

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

For a zero-parameter read-only listing tool with an output schema present, the description is complete. It explains the return content, the grouping, the practical invocation timing, and the downstream benefit, leaving no obvious gap for an agent to call it correctly.

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

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

The tool has zero parameters, so there is no parameter semantics burden on the description. The baseline is 4, and the description appropriately focuses on the return value and usage context rather than inventing parameter details.

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 ('Returns'), a precise resource ('all canonical exercise names from the exercise library'), and an organizing detail ('grouped by muscle group'). It clearly distinguishes this tool from sibling list_* tools by focusing on the canonical exercise library rather than logs, meals, or 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 explicitly says to call this before log_workout or update_workout to match user-described exercise names to canonical ones. This provides clear contextual guidance, though it does not explicitly discuss when not to use it or name alternatives as exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds meaningful behavioral context beyond that: it explains that include_capabilities=true appends a 'full catalog' that is 'large', informing the agent of an output-size tradeoff. It also clarifies that write tools resolve current goals themselves, preventing unnecessary calls. Minor gaps remain (e.g., pagination or exact response shape), but the output schema exists to cover 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 three sentences, each earning its place: the first states purpose and output, the second gives usage triggers, and the third covers negative usage and the parameter caveat. It is front-loaded with the core purpose and 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-only tool with a full output schema and comprehensive annotations, the description covers everything an agent needs: when to use, what it returns, when to pass the parameter, and when not to use it. No critical context 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 100%, so the baseline is 3. The description adds value beyond the schema by tying include_capabilities to a specific user intent ('what kinds of goals Wellness Project supports') and explicitly warning that the appended catalog is 'large'. This helps the agent decide when to set the flag, which is more actionable than the schema's generic phrasing.

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 ('Analyze or show the user's current and past goals'), names the resource ('user's goals'), and enumerates the exact return categories: active/paused formal goals, completed/historical formal goals, and current standard targets. It also implicitly distinguishes itself from sibling write tools by noting it should not be used to fetch an ID for create_goal or update_goal.

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

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

Explicit usage conditions are provided: use when the user asks about their goals or wants a review/analysis. The description also gives a clear when-not-to-use rule ('Do not call this tool merely to obtain an ID before create_goal or update_goal') and a precise condition for setting include_capabilities. This fully routes an agent to the correct tool and parameter choice.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description only needs to add extra context. It adds meaningful behavioral details: maximum range of 31 days, defaulting to the last 7 days, and the Settings prerequisite. This goes beyond the annotations without contradicting them.

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 cover purpose, usage trigger, prerequisite, range, and defaults with no filler. The most important scoping information is front-loaded in the first sentence.

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 two-parameter list tool with an output schema, the description is complete: it states what is returned, when to use it, the prerequisite, the allowed range, and the default behavior. Nothing needed for correct invocation or selection is missing.

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

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

Schema coverage is 100%, so the schema already describes both parameters and their defaults. The description adds value by stating the maximum range (31 days) and the default window (last 7 days), which helps an agent validate input without opening 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?

The description uses a specific verb ('Review') with a clear resource ('hydration events and stored effective hydration totals'), and the hydration domain distinguishes it from the many list_* siblings. It states exactly what the tool returns without relying on the title.

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 says 'Use when the user explicitly asks about hydration history or fluid intake' and adds a prerequisite ('Hydration tracking must already be enabled in Settings'). It does not name an alternative tool, but no direct hydration-list sibling exists, so the guidance 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds valuable behavioral context beyond the schema: the default filter combines Active and Monitoring, the meaning of 'all' versus 'Resolved', and an explicit instruction to infer rather than ask.

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 well-structured with a clear usage section and a compact INFER block. The only minor flaw is slight redundancy between the sentence 'Defaults to active and monitoring injuries' and the INFER line restating the same default, but the overall size is appropriate and front-loaded.

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

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

For a simple read-only list tool with one optional parameter, an existing output schema, and strong annotations, the description covers everything an agent needs: what it returns, when to use it, how to handle the status filter, and how it relates to sibling mutation tools. No important operational gap remains.

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

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

Schema coverage is 100% and the schema already documents the status filter, so the baseline is 3. The description adds extra semantic value by specifying the default behavior, the exact meaning of each enum option, and an INFER directive that helps the agent invoke the tool without unnecessary clarification.

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 and resource ('List injuries from the injury log') and clearly distinguishes the tool's purpose from update_injury and delete_injury by explaining that those can resolve injuries without a prior lookup. It also enumerates concrete use cases: reviewing the log, answering history/rehab questions, and retrieving an id after ambiguous matches.

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 says when to use this tool (review, answer history/rehab questions, get an id after ambiguous matches) and when it is not required (before update_injury/delete_injury). It also gives direct guidance on the status filter values, making the decision boundary 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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds useful behavioral context: it returns canonical library data, includes aliases for matching, and supports canonicalization. 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?

Three sentences with no filler. The primary return value is front-loaded, the output fields are enumerated compactly, and the usage directive follows naturally. Every sentence earns its place.

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

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

The tool has no parameters, has an output schema, and is fully annotated as read-only and idempotent. The description adds the only missing context: what the data represents, what fields are returned, and how it should be used in the logging workflow. Nothing essential is left out.

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 parameter burden for the description to carry. The description instead clarifies the semantic meaning of the returned canonical marker set, which is more valuable here. Baseline 4 is appropriate for a no-parameter tool.

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 ('Returns'), a specific resource ('LOINC-coded markers in the reference library'), and enumerates the returned fields. It clearly distinguishes itself from list_lab_results, which is about logged lab results rather than the reference marker library.

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 tells the agent to call this BEFORE log_lab_results, gives the matching purpose, references the analogous list_exercises pattern, and explains why it matters ('prevents name drift and ensures trending works'). This is strong when-to-use guidance with a concrete alternative pattern.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond those annotations: the tool returns IDs, defaults start_date to 365 days ago, end_date to today, and clarifies that update/delete can resolve results independently. It does not describe every output detail, but an output schema exists, so this is not a major 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 well-structured and front-loaded with the core purpose. Each subsequent sentence adds distinct value: sibling relationship, use cases, filtering, and inference defaults. There is no filler or repetition of schema fields, and the formatting makes the INFER instructions easy to parse.

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 low complexity (0 required parameters, 4 optional well-documented parameters, no nested objects, and an output schema), the description covers all important context. It explains when the tool is needed, when it is not needed, what IDs are for, and how defaults should be inferred. Nothing essential is missing for correct selection and invocation.

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 100%, with each parameter already documented with format, defaults, and optionality. The description adds value by instructing the agent to 'INFER — do not ask' the defaults and by explaining why start_date defaults to 365 days ago ('labs are infrequent'). This goes beyond the schema and gives practical guidance for parameter selection.

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: 'List lab/biomarker results within a date range, including each result's ID.' It clearly distinguishes itself from related siblings like list_lab_markers, update_lab_result, and delete_lab_result by focusing on historical review and ID retrieval. No ambiguity remains about what the tool does.

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 states when to use the tool: to review lab history, answer trend questions, or get an ID after ambiguous update/delete matches. It also explicitly says this tool is 'no longer required' before update_lab_result or delete_lab_result, giving clear exclusion criteria. The INFER defaults further guide autonomous invocation without asking the user.

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 it read-only and idempotent, lowering the bar. The description adds useful behavioral context beyond the annotations, such as timezone resolution for dates, the 31-day maximum range, and the recommendation to make multiple calls for longer periods. This enhances transparency without contradicting 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 long but well-structured, with clear sections for usage, ranges, and inference rules. While it repeats some schema information, the added guidance on when to call and how to handle date ranges is valuable and not redundant. The organization makes it easy to parse.

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 when to use the tool, what it returns (meals with fields), limitations (max range, multi-call strategy), and parameter handling. Given that an output schema exists, an agent has all necessary information to decide when and how to call this tool successfully.

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 covers 100% of parameters with detailed descriptions (format, optionality, meaning), establishing a baseline of 3. The main description adds extra semantic context, particularly the inference rules for date and end_date (e.g., "this week" maps to Monday through today), which helps agents interpret parameter values correctly.

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's function: 'List all meals logged for a date or date range, including each meal's ID, date, type, food description, and macros.' It also distinguishes itself from sibling tools by noting that update_meal and delete_meal can resolve meals without this tool, making the purpose and scope 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?

Explicit usage scenarios are provided: 'use it to answer "what did I eat today/this week/yesterday?", review what has been logged, or get an id after an ambiguous update_meal/delete_meal match.' It also gives practical guidance on date ranges and multi-call handling, and clarifies that it is not required before update/delete operations.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by specifying that only 'active' memories are returned and by describing the type of content stored, which helps the agent set expectations 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?

The description is concise and front-loaded: it states the core action and resource first, gives illustrative examples, then provides usage context. Every sentence adds value and there is no redundancy beyond the harmless 'Read-only' confirmation.

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

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

For a parameterless read-only tool with an output schema and annotations covering safety, the description fully covers purpose, scope, content type, and when to invoke it. Nothing essential is missing for an agent to select and call 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?

The tool has zero parameters and the schema is trivially complete at 100% coverage. With no parameters to document, the description's focus on the returned content and usage context is appropriate. The baseline for zero-parameter tools is 4, and the description earns it.

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

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

The description names a specific verb ('List'), a specific resource ('the user's active Personal Context memories'), and includes concrete examples. It clearly distinguishes this tool from the sibling add_or_update_personal_context and from other list tools by focusing on durable remembered preferences and circumstances.

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 when to use: when the user asks what has been remembered about them, or before proposing a new memory to check for existing coverage. This gives clear practical guidance and implicitly routes the agent to add_or_update_personal_context when no existing memory covers the subject.

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 annotations already declare readOnlyHint, destructiveHint, and idempotentHint, and the description does not contradict them. It adds meaningful behavioral context such as the 90-day maximum range, the need for sequential calls to cover longer periods, and the 'INFER — do not ask' directive, which helps the agent behave correctly. It does not explicitly mention output format or error behavior, but with an output schema present that is less critical.

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 lengthy but well-organized: it starts with the primary purpose, then contrasts with a sibling, and finally gives usage and inference rules. While it could be trimmed, the added detail on multi-call traversal and inference rules is necessary for correct usage, so the structure is appropriate.

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 complexity (multiple optional parameters, inference rules, range limitations, and a sibling that is easily confused), the description covers all necessary context: it identifies when to use it, how to handle date ranges, how to distinguish from list_recovery_strategies, and how to handle long histories. No critical information is missing for an agent to use 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?

The input schema provides descriptions for all four parameters, and the description enriches them further: it explains default values for start_date/end_date, that omitting category returns all categories, and the limit's default/maximum. This goes beyond the schema and gives the agent full understanding of each parameter's meaning and usage.

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 'List', the resource 'logged recovery sessions', and the scope 'within a date range, each with its ID'. It also explicitly contrasts with the sibling tool list_recovery_strategies to remove ambiguity, so an agent immediately knows what this tool does and how it differs.

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 explicit usage scenarios ('answer what recovery sessions have I logged', audit/spot-check, get an id after ambiguous match) and gives concrete inference rules for parameters (default date range, category omission). It also tells the agent when to make multiple calls for longer histories, making the usage guidance highly actionable.

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 readOnly/idempotent/non-destructive behavior. The description builds on that by explaining the INFER behavior ('do not ask'), the default filter, and what fields are returned. This adds useful operational context 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?

The description is compact and front-loaded: purpose first, use cases second, then a clearly marked INFER block with parameter guidance, and finally a one-line return convention. Every sentence carries 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 single-parameter, read-only list tool with annotations and an output schema, the description covers usage, filter semantics, inference behavior, and return fields. Nothing an agent needs to invoke it correctly is missing.

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

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

Although schema coverage is 100%, the description adds meaning not present in the schema: 'use 'all' for history; use 'historical' for ended strategies only.' This disambiguates the enum values and gives the agent a rule for inferring the parameter without asking.

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 begins with a specific verb and resource: 'List the user's recovery and mindfulness strategies.' It also gives concrete use cases ('user asks about recovery practices, mindfulness routines, or you need strategy IDs before logging a session'), which distinguishes it from related siblings like manage_recovery_strategy or list_recovery_sessions.

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

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

It explicitly states when to use the tool: when the user asks about recovery practices, mindfulness routines, or needs strategy IDs before logging a session. It does not explicitly name alternatives or say when not to use it, so it earns a 4 rather than 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by stating the INFER rule: default start_date to 30 days ago and end_date to today without asking the user.

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 compact and front-loaded: purpose first, then usage conditions, then inference rules. No filler or redundant phrasing; every sentence contributes.

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 list tool with two optional, fully documented parameters, an output schema, and annotations covering safety, the description provides everything an agent needs: purpose, when to use, inference behavior, and range semantics. Nothing critical 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 100%, so the schema already documents both parameters and their defaults. The description adds meaningful guidance beyond the schema by instructing the agent to infer defaults rather than ask, which changes invocation behavior.

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 ('List') and resource ('dates a user has marked as rest days within a range'), clearly distinguishing it from sibling tools like log_rest_day and cancel_rest_day. The accompanying examples reinforce the exact purpose.

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

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

Explicitly says 'Use when the user asks about their rest pattern' and gives two concrete example queries. It doesn't name alternatives or state exclusions, but the context is clear enough for an agent to route to this tool correctly.

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, idempotent, and non-destructive behavior; the description adds transparency about the output structure (compact summary then individual runs) and that metrics are computed together, with 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?

The description is organized with the primary purpose first, then output details, then usage guidance; each sentence adds value, including the list of computed metrics and the note about longer spans.

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

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

Given the output schema exists, the description provides all necessary context for an agent to decide when and how to use this tool, including return structure and limitations, with no missing guidance.

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?

Both parameters are fully described with format and defaults in the schema, and the description adds crucial semantics about the maximum range (92 days) and default window (7 days ago 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 states the tool lists runs within a date range, specifies the resource and scope, and differentiates it by being the preferred single read for computed metrics, contrasting with piecing together data from multiple calls.

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 positions this tool as the preferred single read for specific metrics, implies alternatives by stating 'rather than pieced together from several calls', and gives usage guidance for longer spans by advising multiple consecutive calls.

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 annotations already provide readOnlyHint and destructiveHint, and the description adds transparency about the returned data fields (duration, score, stage breakdown) and the nature of the entries. There is no contradiction; the description supplements the annotation adequately.

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 yet information-dense, covering purpose, scope, parameters, defaults, limits, and exclusions in a clear, structured format without superfluous wording.

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?

All necessary details for correct usage are present: the data returned, the date range constraints, the default behavior, and the exclusion of naps. Given the tool's simplicity, the description is fully complete and leaves no 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?

Both parameters are explained with format and default values in the description, adding guidance on the 31-day limit and the inference of defaults, which goes beyond the schema's basic descriptions. This is particularly valuable given the schema only lists field names and descriptions.

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 verb 'List' clearly specifies the action, the resource 'sleep log entries' is unambiguous, and the scope (date range) is defined. It also implicitly differentiates from logging a new sleep entry via the sibling tool 'log_sleep'.

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 states the maximum range of 31 days and instructs to make multiple calls for longer periods. It also clarifies the default values for start_date and end_date, and notes that daytime naps are excluded, providing clear when-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds useful behavioral context: default filtering behavior, how to request history, and the full list of returned fields. This goes beyond annotations without contradicting them.

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 well-structured and front-loaded with the core purpose, followed by concise parameter inference guidance and a clear list of return fields. Every sentence adds value, and the use of labeled sections ('INFER — do not ask') makes it easy for an agent to parse. Nothing feels redundant or wasted.

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

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

For a read-only list tool with two optional enum parameters and an output schema, the description is complete. It covers when to use the tool, what each parameter means, how to handle ambiguous matches, and what fields are returned. There is no missing information an agent would need to invoke 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?

Although the input schema covers both parameters 100%, the description adds significant extra meaning. It defines the inference rules, explains the default 'active' filter, clarifies when to use 'all' vs 'historical', and specifies that omitting category returns both types. This is exactly the kind of parameter guidance that helps an agent choose values correctly without asking the user.

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

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

The description opens with a specific verb and resource: 'List the user's medications and supplements.' It clearly distinguishes itself from the sibling manage_supplement by explaining that list_supplements is for reviewing what the user takes, not for managing individual items. This lets an agent immediately know what the tool does and how it differs from related 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 explicitly states when to use the tool: when the user asks what medications/supplements they're taking, asks to review their stack, or needs an id after an ambiguous manage_supplement match. It also explains that manage_supplement can resolve items on its own, so list_supplements is not a required prerequisite. This is strong, actionable 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?

The description discloses important behaviors beyond the read-only annotation: it explains how Zone Minutes are calculated, how calories burned may be estimated and labeled, and how TDEE is derived or why it might be missing. It also states the tool will infer defaults without asking, which is transparent.

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 verbose and somewhat repetitive: the same list of metrics appears in both the opening sentence and the 'Use when' clause. While the extra paragraphs on Zone Minutes and calories are informative, they could be condensed, and the overall length makes it harder to scan quickly.

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 all necessary context: what data is returned, operational limits (31-day range), default handling, and special labeling for estimates. It does not describe the output schema, but that's not required for a list operation. It is complete but slightly over-explained.

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 already provides 100% coverage with clear descriptions and defaults for both parameters. The description reinforces the default behavior (INFER) but does not add new details beyond what the schema already states, though it does clarify the date format implicitly through 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?

The description clearly states the tool lists daily wearable data across multiple specific metrics (steps, HRV, calories, etc.), with a verb and resource. It distinguishes itself from sibling list tools like list_workouts and list_body_metrics by explicitly naming the wearable data categories.

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 includes a direct 'Use when' clause listing user queries (step count, heart rate, HRV trends, etc.) and provides operational guidance such as the 31-day maximum range and instruction to make multiple calls for longer periods. This leaves no ambiguity about when to invoke this tool.

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

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

Annotations already mark it as read-only, idempotent, and non-destructive; the description adds further transparency by explaining that the tool is not a prerequisite for update/delete operations and that it returns ids useful for resolving ambiguous matches. No contradictions 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?

Every sentence contributes: the main purpose, the relationship to update/delete, the 31-day limit, and the parameter defaults. No redundant or filler content; the structure flows logically from what the tool does to how to use it.

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 two optional parameters and the presence of an output schema (mentioned in context), the description provides sufficient context for an agent to call the tool correctly. It covers parameter defaults, usage scenarios, and operational limits, so no missing information would cause incorrect invocation.

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 fully describes both parameters with types and defaults, and the description reinforces their behavior ('INFER — do not ask' with default values), clarifying that the agent should infer these rather than prompt the user. This adds semantic value beyond the schema's basic metadata.

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?

Clearly states the action ('List wellbeing log entries') and the resource, with explicit scope ('within a date range'). It distinguishes itself from sibling tools by noting that update_wellbeing and delete_wellbeing can resolve entries on their own, making list_wellbeing specific to trend queries and id retrieval after ambiguous matches.

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?

Provides explicit when-to-use guidance: for trends over time or getting an id after an ambiguous match, and explicitly states it is not required before update/delete. Also gives operational constraints (maximum 31 days per call) and default parameter values, leaving no ambiguity.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description reveals important runtime behaviors: default date range, 90-day maximum range, the need to chain calls for older periods, and the effect of the saved_workouts flag. This adds meaningful 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?

The description is slightly long but well-organized with labeled sections (SAVED WORKOUTS, INFER) and each sentence adds value. It front-loads the core function and usage examples before diving into edge cases, though a bit of trimming could improve 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 three optional parameters and the tool's role in a broad ecosystem, the description covers all necessary aspects: default dates, range limitations, chaining strategy, saved workout mode, and the output fields. Users have enough context to call it correctly without referencing external docs.

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 descriptions cover all three parameters, but the tool description enriches them further by specifying defaults (start_date = 7 days ago, end_date = today), the meaning of saved_workouts, and instructions to widen the range up to 90 days. This goes well beyond the schema's basic descriptions.

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's function: listing workout sessions with specific attributes (ID, date, focus, location, NSI rating). It also gives concrete usage examples and distinguishes between completed workouts and saved workouts, making its 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?

It provides explicit guidance on when to use it: before get_workout to find a session ID, for answering trend questions, and how to handle older data via chaining. It also clarifies the saved_workouts flag to switch modes, which helps select the right tool among 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?

The description adds substantial behavioral context beyond the annotations: one row per day, calling twice on the same date is an upsert, all fields except date are optional, and the tool converts units once before storage. These are critical runtime behaviors an agent needs to know and are not present in 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 long but justified given 23 parameters and complex unit/derivation rules. It is logically sectioned, though not perfectly front-loaded: the purpose statement appears only after an initial dense unit-input paragraph.

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 high-complexity tool, the description covers purpose, usage, units, inference rules, upsert behavior, and exclusions like BMI. An output schema exists, so return-value details are not necessary. The minor input_distance_unit inaccuracy prevents a perfect score.

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

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

Schema coverage is 100%, but the description greatly enhances parameter meaning by explaining unit-input conventions, derived-field formulas, percentage ranges, and the distinction between muscle mass and lean mass. It loses a point because it references input_distance_unit, which does not exist in this tool's schema, creating potential confusion.

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's function: 'Log or update body composition metrics for a given date.' It names the exact resource and action, and differentiates itself from sibling read/list tools by explicitly describing when the user shares a body composition reading.

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 strong when-to-use guidance: weight, body fat percentage, or other composition readings from manual entry, smart scale apps, or photos. It also provides important when-not behavior, such as never asking for BMI. However, it does not explicitly name alternative tools like log_wearable or list_body_metrics for exclusions.

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

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

Beyond the annotations, the description discloses meaningful behavior: it can reopen a period that was marked ended, it infers started_on and ended_on instead of asking, and it requires a consent/tracking check before logging. No statement contradicts the provided 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 well-structured with a clear top-line definition, a bulleted list of cases, a prerequisite warning, and an inference section. Every sentence carries information an agent needs; nothing is filler or 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?

The description covers edge cases, prerequisites, inference rules, and forbidden usage. An output schema exists, so the description does not need to explain return values. For a tool that logs cycle data with inference and consent requirements, this is 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?

While the schema already documents both parameters at 100% coverage, the description adds crucial semantics: started_on defaults to today for current-period statements, ended_on should be omitted unless explicitly stated, and both dates can be inferred from context. This goes well beyond the schema's basic format descriptions.

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

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

The description opens with a specific verb and resource, 'Log a period to the user's cycle log', and then enumerates the distinct real-world utterances it handles. This makes the tool's scope unmistakable and clearly separates it from siblings like list_cycle, update_cycle, and delete_cycle.

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 applicability through concrete examples, a prerequisite check for cycle tracking, and an explicit exclusion: 'Do NOT use this tool to log future dates.' It does not explicitly route users to update_cycle for modifications, but for a logging action the guidance is strong and actionable.

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 substantial behavioral context beyond the annotations: injuries are date ranges that stay open until end_date is set, many fields should be inferred rather than asked, and only body_part warrants a clarifying question. The annotations correctly indicate a write operation with readOnlyHint=false, so there is no 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?

The description is well-structured and front-loaded: purpose, trigger conditions, domain model, then a scannable INFER list. Every sentence earns its place, and there is no redundancy with the schema descriptions.

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 9-parameter create tool, the description covers when to call, what to infer, what to ask, and the date-range semantics. Since an output schema exists and schema coverage is 100%, no critical information is missing for an agent to invoke 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 100%, so the baseline is 3. The description adds meaningful extra value with numeric severity anchors (minor twinge=2-3, moderate pain=5-6, severe/acute=8-9), an example for affected_movements, and a clear policy to ask only when body_part is unclear. This is above baseline but not maximal because the schema already carries much of the parameter information.

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: 'Log a new injury or aggravation.' It also lists concrete user signals like 'getting hurt, feeling pain, straining something' that trigger this tool. The word 'new' distinguishes it from sibling tools like update_injury and delete_injury.

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 says when to use the tool: when the user mentions getting hurt, feeling pain, straining, or describes an injury. It doesn't explicitly state when not to use it, such as 'if the injury already exists, use update_injury instead,' 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?

Even though annotations mark this as readOnly=false, the description adds substantial behavioral context: the required list_lab_markers workflow, the infer-not-ask policy for date/panel_name/flag/reference ranges/lab_name, and the requirement to submit all markers from one visit in a single call. 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?

The description is long but densely informative and well organized with clear sections (glucose routing, workflow, inference policy). It front-loads the purpose and gives the most critical routing distinction early. Minor redundancy exists between the workflow section and schema field descriptions, but every sentence earns its place.

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

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

For a lab-logging tool with nested result items and several inferable fields, this description is complete: it covers when to use it, how to prepare parameters, how to disambiguate from related tools, what to infer, and how to batch submissions. The output schema exists, so return-value details do not need to be repeated.

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

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

Schema coverage is 100%, so the schema already documents each field well. The description adds extra parameter-level guidance: use canonical marker_name and loinc_code for matches, omit loinc_code when no match exists, infer defaults for several fields, and batch all markers from a visit into one results array.

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: "Log one or more blood test or biomarker results." It also distinguishes from log_wearable by explicitly routing glucose measurements to that sibling, so an agent can tell them apart.

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 says when to use this tool (lab/blood-draw results from a PDF, paper report, or photo) and when not to use it (finger-stick, CGM, home meter, wearable glucose belongs in log_wearable). It also defines a required workflow with list_lab_markers and tells the agent what to do if results are mentioned but not shared.

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 show readOnlyHint=false and no other safety hints, so the description carries the behavioral burden. It fully discloses important behaviors: never overwriting known stored macros with fresh estimates, requiring confirmation before force=true, handling duplicate errors by prompting the user, and letting the server decide whether hydration tracking is enabled.

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 long, but its complexity warrants it: 11 parameters, macro resolution rules, duplicate handling, and hydration all need explanation. It is well-organized with clear section headers and fronts the core purpose before diving into edge cases, though a more compact phrasing would slightly improve 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 tool's complexity, the description is remarkably complete. It covers inference rules, macro sourcing, required fields, fasting, duplicates, and hydration, leaving no major decision ambiguous. An output schema exists, so the absence of explicit return-value details is not a 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?

Despite 100% schema coverage, the description adds substantial meaning beyond the schema: date inference rules, canonical meal_type time mapping, when recipe_name supplies macros, how fluids and alcohol_g interact, and the explicit rule to never call without all four macros populated. This goes far beyond what the input schema alone 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 description opens with a specific verb and resource: 'Log a meal to the user's food diary,' and expands with concrete trigger conditions ('mentions eating, describes a meal, or asks to log food'). It covers special cases like fasting and drinks without blurring the core purpose, and it is clearly distinguishable from siblings like update_meal and list_meals.

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 detailed when-to-use guidance: direct meal logging, repeats, saved recipes, brand names, fasting days, and drinks/hydration. It explicitly names alternatives such as list_meals for repeats and update_meal for correcting duplicates, and it states this is the single write path for drinks, clearly routing behavior away from other tools.

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

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

Beyond the annotations, it details real behavior: infer date/category/strategy_name instead of asking, omit duration_minutes for skipped sessions, include quality only when the user rates it, and map 'skipped/missed/didn't do' to skipped=true. These rules tell the agent exactly how the tool expects the call to be constructed.

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 organized into a two-sentence purpose, a compact INFER bullet list, and a short workflow callout. There is no filler, and the highest-value guidance is front-loaded.

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

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

For an 8-parameter write operation, it covers all major decision points: defaults, inference rules, skipped handling, strategy linking, and the standalone fallback. Optional fields like notes are already documented in the schema, and an output schema exists, so the description does not need to explain return values.

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 already 100%, but the description adds inference semantics that the schema cannot express: category comes from the practice name, strategy_name comes from the linked strategy or user phrasing, and duration is omitted when skipped. This materially improves an agent's ability to fill the parameters correctly.

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 action and resource: 'Log a completed or skipped recovery/mindfulness session,' and lists representative practices. It also carves out 'one-off standalone sessions not linked to a recurring strategy,' which separates this tool from strategy-management siblings and gives the agent a clear scope.

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 trigger is explicit ('Use when the user says they did or skipped...') and the preferred workflow names list_recovery_strategies and a standalone fallback, so the agent knows when to invoke it. It never states a when-not or names a sibling tool as the alternative, leaving some exclusion logic 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?

The description conflicts with the annotation by declaring the operation idempotent while the annotation sets idempotentHint to false. This contradiction undermines transparency. Additionally, it does disclose side effects like suppressing workout-prompt nudges, but the contradiction is a major issue.

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 moderately long but well-structured with clear paragraphs and a bullet point for inference rules. There is minor repetition, but it remains concise and easy to parse.

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 when to use, how to infer the date, the effect on workout nudges, idempotency, and the alternative cancellation tool. It provides all necessary context for 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?

The schema already documents the 'date' parameter with format and default, but the description adds crucial inference rules for parsing user references like 'today' and 'yesterday,' going 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?

The description clearly states the tool's purpose with the verb 'Mark' and the resource 'date as an intentional rest day.' It also provides usage examples, making the action 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?

It explicitly specifies when to use the tool ('Use when the user says they took a rest day...') and directs users to the sibling tool 'cancel_rest_day' for removal, leaving no ambiguity about when to choose this tool.

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

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

With only weak annotations (all hints false), the description carries the behavioral burden and delivers richly: it discloses that the tool converts units itself ('The tool converts once before storage, so this overrides any wording that asks you to do the arithmetic'), that logging 'writes the completed run and returns a card marker for in-app editing', and imposes anti-fabrication constraints ('Never invent sensor data or splits', 'do NOT call it easy merely because it was a run'). These go well beyond what readOnlyHint=false and idempotentHint=false convey. 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?

The description is long (~250 words) but earns its length given 19 parameters and two operational modes. It is well-organized with labeled sections (UNIT INPUTS, intent, RUN TYPE, DETAIL) and front-loads the most critical instruction (unit handling) before anything else. Minor deduction: some redundancy with schema descriptions — the run_type and splits/segments 'never invent' constraints appear both in the schema and the description.

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

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

For a tool with 19 parameters, two intents, and five enums, the description covers the decision-critical ground: unit conversion policy, the log-vs-plan distinction with required fields, run-type classification guardrails, and data-fidelity constraints. An output schema exists, so return values need not be described. Minor gaps: no explicit guidance on ambiguous cases (e.g., a run that might be both a plan and a log) and some per-field sourcing rules are left to the schema — but nothing an agent needs to call it correctly is missing.

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

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

Though schema coverage is high (89%), the description adds critical cross-parameter semantics the schema only references: the UNIT INPUTS paragraph explains the pairing rule ('when they gave kg / km / cm set input_weight_unit / input_distance_unit / input_length_unit in that same object. Omit the companion when the number is already lb / mi / in'). It also adds intent-specific required fields for log (date, distance_mi, duration_sec) that the schema does not state, and clarifies run_type classification guardrails. This far exceeds the baseline 3 for high schema 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 states a specific verb and resource: 'Create an editable running card. Use for a completed run OR a future run plan.' It further distinguishes two intents — log (the run happened) vs plan (the run has NOT happened) — which sets it apart from nearby siblings like log_workout, log_wearable, and log_rest_day. An agent can clearly identify this as the run-specific card creator 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 gives explicit 'when' guidance: use for a completed run OR a future run plan, with a hard rule that a future run must never go into completed history. It also clarifies defaults (log is default) and mode-specific required fields. However, it does not explicitly name alternatives or exclusions (e.g., 'use log_wearable for synced wearable data' or 'use update_workout to modify'), so routing between siblings is left partly 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?

The description surfaces behaviors not visible from annotations: repeated calls on the same date upsert rather than duplicate, entries are always tagged manual, and wearable-provider sources are reserved for auto-sync. It also discloses the proactive questioning behavior. These details match the write-oriented annotations and add real operational transparency.

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 organized into labeled sections, each earning its place: core purpose, proactive collection, inference rule, subset/upsert behavior, and manual tagging. There is no redundant or filler content, and critical scoping information is front-loaded.

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

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

For a 9-parameter write tool with many optional fields, the description answers the key operational questions: when to call it, what to ask if data is missing, how to compute date, whether partial data is allowed, what happens on duplicate calls, and how entries are tagged. An output schema also exists, so the description does not need to explain return values.

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

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

Schema coverage is 100%, so the schema already defines each parameter. The description adds valuable semantics by clarifying that date refers to the wake date (night ending on that date), defaults to today, allows any subset of fields, and that a second call on the same date updates the existing row. This goes beyond the schema's per-field descriptions.

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

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

The description opens with a specific verb-resource pair, 'Log a sleep entry', and lists the exact data types accepted (duration, score, stage breakdown, bedtime, wake time) and the sources (Fitbit, Oura, Whoop, Apple Health, manual recall). It clearly distinguishes this write tool from read siblings like list_sleep and show_sleep_detail, and separates manual entry from wearable auto-sync behavior.

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

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

'Use when the user shares sleep data...' gives an explicit triggering condition. Proactive data collection instructions specify what to ask when the user wants to log but has no numbers, and the 'INFER — do not ask' section prevents unnecessary clarification. It does not explicitly name sibling alternatives for when to use something else, but the manual-vs-auto-sync note provides a meaningful exclusion rule.

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

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

Annotations already signal mutation (readOnlyHint=false). The description adds meaningful behavior beyond that: it documents inference defaults (date=today, taken=true), the requirement that exactly one selector be provided, and the error behavior when supplement_name matches multiple items. This is valuable context for invocation.

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 compact and well-organized. Purpose, usage condition, inference rules, and selector requirements are each given their own section with no redundant or filler content. Every sentence adds operational 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?

Given the moderate complexity, the 100% schema coverage, the presence of an output schema, and annotations covering mutation safety, the description is complete. It covers prerequisites, defaults, selector resolution, and failure behavior, so an agent can invoke it correctly without guessing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds important semantics beyond the schema: the exact-one-required relationship between supplement_id and supplement_name, the inference rules, and the multiple-match error behavior. This compensates well for the schema's lack of required-parameter enforcement.

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: 'Mark a medication or supplement as taken or not taken for a specific date.' This clearly distinguishes it from sibling tools like list_supplements or manage_supplement, and the action 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?

It explicitly says when to use the tool: 'Use when the user says they took (or missed) a medication or supplement on a particular day.' It also notes the daily tracking mode prerequisite. It does not explicitly name alternatives or state when not to use it, but the guidance is clear enough 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?

The description is highly transparent (additive step semantics, replacement behavior, no-op success), but it explicitly claims 'IDEMPOTENT' while the annotation idempotentHint is false. This is a direct annotation contradiction, so per rubric the score must be 1 despite the otherwise rich detail.

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 long but well structured, with front-loaded purpose and uppercase section headers (VITALS, STEPS, ALL OTHER FIELDS, INFER, IDEMPOTENT). Some enumeration of vitals duplicates the schema, creating mild redundancy, but the operational rules justify most of the 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 17-parameter tool with an output schema and 100% schema coverage, the description covers all critical behaviors: defaulting to today, step additive semantics, replacement scope, no-op idempotent success, and lab-result routing. Only minor gaps exist, such as explicit behavior for omitting all fields, but nothing required for correct invocation is missing.

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

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

Schema coverage is 100%, but the description adds substantial extra meaning: step_count is additive and requires explicit confirmation, vitals replace existing manual values, systolic requires diastolic to accompany, and glucose routing depends on source. These are the exact semantic constraints the schema does not fully capture.

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 a specific verb and resource: logging daily wearable/manual health metrics across many vitals. It explicitly distinguishes where lab glucose values belong (log_lab_results instead), which separates it from that sibling without opening 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?

Provides explicit when-to-use and when-not-to-use guidance: manual step_count only for device-missed steps, never for sync issues; lab-derived glucose belongs in log_lab_results; all other fields replace existing manual values. This is model-level routing guidance.

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