anatome

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

Beyond the annotations (readOnlyHint false, destructiveHint false, openWorldHint true), the description adds 'Not medical advice' and the confirmation requirement, signaling a cautious, user-confirmed generation behavior. It doesn't elaborate on persistence or side effects, but this is adequate given the annotation support.

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

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

The description is a single, front-loaded sentence that states the purpose first and packs essential cautions and requirements into minimal words. There is no redundancy or fluff.

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 6 parameters, a nested health object, no output schema, and important caveats (confirmation, medical disclaimer), yet the description stays at a high level. It doesn't describe what the meal plan draft includes, optionality of 'health,' or how 'days' and other parameters shape the output. This leaves the agent without enough context to invoke the tool confidently.

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

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

With 0% schema description coverage, the description must compensate but only mentions 'health constraints' and 'confirm:true.' It leaves 'days,' 'goal,' 'diet_type,' and 'daily_calories' unexplained, and the schema offers only types, not meanings. This under-explains a 6-parameter tool with a nested object.

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 starts with 'Draft a meal plan,' using a specific verb and resource that clearly distinguishes it from sibling tools like ai_parse_meal or ai_workout_plan. The added caveat 'Not medical advice' clarifies scope without muddling the core 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 gives explicit operational guidance: 'confirm:true required' and 'Pass health constraints so the draft can honour them.' It does not name alternatives or exclusion criteria, but the tool's name and purpose are self-evident compared to siblings, so the guidance is 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?

The description adds output context ('grams + macros') beyond the annotations, which is helpful. But it does not address the readOnlyHint=false flag or clarify whether the AI call has side effects. The openWorldHint is already in annotations, so the description provides only marginal additional behavioral 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 a single sentence, front-loaded with the verb, and clearly states input and output. Every word adds value 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?

There is no output schema, so the description should explain the return structure more fully. It mentions 'structured items with grams + macros' but does not provide an example output or clarify the role of locale, leaving some ambiguity for a tool with only two parameters.

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

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

With 0% schema description coverage, the description needs to compensate. It implicitly describes the 'text' parameter with an example ('2 eggs and toast with butter') but completely omits the optional 'locale' parameter, leaving half the parameters undocumented.

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

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

The description clearly states the tool parses free-text meal descriptions into structured items with grams and macros. The specific verb 'Parse' and resource definition distinguish it from siblings like ai_photo_macros (photo input) and ai_meal_plan (meal planning).

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 implicitly communicates when to use the tool: when you have free-text meal description to convert. However, it does not explicitly name alternatives or exclusion scenarios, such as not for photo-based parsing or structured logging.

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 the budget cap (free tier 1/mo) and the vision model distinction, which are not in annotations. However, it doesn't disclose potential side effects or output format, but annotations partially cover safety.

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 short sentences, front-loaded with the core purpose, then input constraints and budget info. 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 moderately complex tool with no output schema, the description explains what it returns (foods + macros) but lacks details on return format or side effects. Given the clear input schema and annotations, it's adequate but not exhaustive.

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 fully documents both parameters with mutual exclusivity descriptions; the description merely restates the oneOf constraint without adding new semantic 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 clearly states the tool analyzes a meal image and estimates foods and macros, with a specific verb (analyze) and resource (meal image). It distinguishes from sibling ai_parse_meal by explicitly specifying image input and vision model.

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 clear context for when to use (meal image analysis) and instructs to pass exactly one of image_url or image_base64, but it does not explicitly name alternatives or exclusions relative to siblings.

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

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

Annotations already indicate a non-read-only, non-idempotent mutation tool. The description adds that a confirm flag must be true, a critical behavioral prerequisite, and emphasizes that health constraints influence the draft. It stops short of describing side effects or output, but adds meaningful operational context beyond 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 extremely compact: two sentences front-load the verb and resource. The second sentence packs three critical details (non-medical disclaimer, confirm requirement, health constraints) without wasted words.

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

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

The tool has a nested health object, no output schema, and five parameters, yet the description only covers the health and confirm aspects. It does not describe the expected return value, how the other parameters influence the plan, or any side effects beyond drafting. Given the moderate complexity, this is adequate but has clear gaps.

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

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

With 0% schema description coverage, the description must compensate. It clarifies that 'confirm' must be true and that the 'health' object should be populated with constraints. However, it does not explain the purpose of 'days_per_week', 'goal', or 'experience', leaving them under-specified.

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 'Draft a workout plan' with a specific verb and resource, clearly distinguishing it from siblings like ai_meal_plan or get_workouts. It communicates a generative/creative action rather than logging or retrieving.

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 usage requirements: 'confirm:true required' and 'Pass health constraints so the draft can honour them.' It also adds a medical disclaimer. However, it does not explicitly contrast with alternative tools or state when not to use it.

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

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

Beyond the annotations' destructiveHint=true, the description discloses the soft-delete behavior and 30-day recovery window, as well as the required X-App-User-Id header, giving the agent essential behavioral context.

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

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

The entire description is a single sentence that packs the action, the soft-delete behavior, the recovery window, and the required header—no wasted words.

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

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

With a simple one-parameter schema, an output schema present, and annotations already marking destructiveness, the description provides sufficient context: what is deleted, how (soft), and the recovery window. It also notes the necessary authentication, making it complete for 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?

The schema has one parameter (meal_id) with zero description coverage; the phrase 'by id' minimally links meal_id to the meal's identifier, but the description doesn't explicitly explain the parameter's format or semantics, leaving a gap.

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

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

The description uses a specific verb ('Delete') and resource ('a logged meal') with the identifier dimension ('by id'), clearly distinguishing it from sibling delete_workout or update_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 conveys clear context—when a logged meal should be removed—and adds the prerequisite requirement 'Requires X-App-User-Id.' However, it doesn't explicitly mention alternatives or when not to use it, so it stops short of the highest rating.

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

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

Beyond the destructiveHint annotation, the description adds crucial behavioral context: it is a soft delete with a 30-day recovery window and it cascades to sets. This provides the agent with important expectations about the operation's effects and reversibility, fully complementing 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?

A single, front-loaded sentence that immediately communicates the primary action and key details (sets, soft delete, recovery window). Every word earns its place; 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 simple one-parameter destructive tool with an output schema and annotations indicating non-read-only and destructive behavior, the description provides the essential additional context (cascade to sets, soft-delete recovery window). It is complete and appropriately scoped.

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

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

The schema has one parameter (workout_id) with no description, and the description covers 0% of it. The phrase 'by id' adds minimal meaning since the parameter name already implies the workout identifier. No additional format, semantics, or edge-case handling is disclosed, so the description fails to compensate for the low 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 clearly states the action ('Delete a logged workout and its sets') and the resource ('workout') by id. It distinguishes itself from sibling tools like delete_meal by specifying the scope (workout and its sets) and the soft-delete 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?

The description implies the use case: when you need to delete a logged workout with its sets. However, it does not explicitly state when not to use it (e.g., for deleting a single set via update_sets) or mention alternatives. Guidance is implied but not fully developed.

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 readOnly, idempotent, and closed-world behavior. The description adds valuable context about identity coming from the token and never caller-supplied, which is a security-related behavioral trait not covered by annotations. It also clarifies the return format as JSON and the full-copy semantics, enhancing transparency beyond the structured fields.

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

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

The description is two sentences, front-loaded with the primary purpose, and each clause earns its place. It includes necessary usage details without redundant filler.

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

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

Given the tool's simplicity (2 params, 100% schema coverage, no output schema), the description covers the key aspects: the export function, parameter modes, and auth source. Minor gaps include behavior when neither parameter is provided and whether both can be passed together, but overall it is sufficiently complete for an agent.

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% with descriptions for both parameters. The description adds meaning by explaining the relationship between `domains` and `confirm` as alternatives ('Pass `domains` ... or confirm:true'), which is not immediately clear from the schema alone. It also provides concrete examples ('meals,workouts').

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: 'Export the signed-in user's data as JSON.' The verb 'export' is specific, and the resource is defined as the user's data. It also distinguishes itself from sibling get_* tools by offering bulk export rather than individual record retrieval.

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 usage instructions by explaining the two modes ('Pass `domains` ... or confirm:true for a full copy'), but it does not explicitly state when to choose this tool over alternatives like get_meals or get_workouts. The context implies bulk export, but there is no direct comparison or exclusion of sibling 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?

Annotations already disclose readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the agent knows this is not a safe read-only operation. The description adds 'Returns SVG', which clarifies the output format, but does not disclose other behavioral traits such as permissions, side effects, or rate limits. Given annotations exist, this is adequate but not exceptional.

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

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

The description is a single sentence that is both concise and front-loaded. It immediately states the primary action and output, with no wasted words or redundant information. It earns its place by being succinct yet informative.

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

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

Despite the tool's moderate complexity, the description fails to cover essential usage context. It lacks parameter explanations, usage scenarios, and any distinction from sibling tools. The output schema exists, so the return format is partially covered, but the complete lack of parameter semantics and usage guidelines makes the description insufficient for an agent to invoke the tool correctly.

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

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

With 0% schema description coverage, the description must compensate by explaining parameters. It hints at 'arbitrary colors' which likely relate to the 'layers' parameter, but it does not explain what 'view', 'gender', or 'layers' should contain. This leaves the required 'layers' parameter ambiguous, offering minimal guidance.

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 ('Render an SVG diagram') and the resource ('of the human body with muscles highlighted in arbitrary colors'). This distinguishes it from sibling tools like list_muscles or get_muscle_recovery, which deal with data rather than visual generation. The explicit mention of 'Returns SVG' also clarifies the output type.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or alternative tools. Although 'Render' implies usage for creating images, there is no explicit context or comparison with siblings, making this a gap.

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, openWorldHint=false, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral details: ordering (most recent first), filtering options, and the requirement for an app user context. This goes beyond annotations, though it doesn't mention pagination or edge cases like empty results.

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

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

The description is two sentences, front-loaded with the action and resource. Every phrase adds value: examples, ordering, and filter capabilities. No redundant or filler 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?

Given the 4 optional parameters, presence of an output schema, and strong annotations, the description covers the core functionality, filter options, and context requirement. It does not need to explain return values due to output schema, and the missing details (e.g., limit behavior) are inferable from defaults. Slightly more edge-case info (e.g., pagination) would push it to 5.

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

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

Schema description coverage is 0%, so the description must compensate. It explains metric_type with examples and implies the meaning of from/to via 'date range', but does not explicitly describe the 'limit' parameter or date formats. This is helpful but incomplete for all parameters, leaving some interpretation to the agent.

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 it lists body metrics/measurements for the current user, with specific examples (weight, height, bicep, body fat). It distinguishes itself from sibling tools like log_body_metric (write operation) and get_progress (different resource). The verb 'List' plus resource 'body metrics' makes 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?

It provides clear context on when to use: retrieving the current app user's body metrics, with optional filtering by metric_type and date range. It also states a prerequisite: requires an app user context. However, it does not explicitly name alternatives or exclusion criteria, so it lacks explicit when-not-to-use guidance, but the context is strong.

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

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

Annotations already declare readOnly and idempotent hints, and the description adds the sorting behavior and user scope. However, it does not disclose behavior about date filtering or pagination beyond what the schema implies.

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

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

A single concise sentence with no filler, front-loading the action and resource.

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 the core return (cardio activities) and ordering, and an output schema exists. However, it lacks guidance on the optional parameters and does not address filtering or limit behavior, making it incomplete for a tool with 3 undocumented params.

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

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

Schema description coverage is 0% and the description does not mention any of the three parameters (limit, date_to, date_from). The parameter names are self-explanatory but the description provides no additional semantic value for them.

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

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

The description uses the specific verb 'List' and identifies the resource 'cardio activities' scoped to the current app user, with an ordering qualifier 'most recent first'. This clearly distinguishes it from sibling tools like get_workouts or get_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 implies usage when the user needs their cardio activity list, but it does not explicitly state when to use this tool versus alternatives like get_workouts or get_events. There are no exclusions or alternative recommendations.

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 explains key behaviors: returns deletes, uses a global seq counter where gaps are other accounts' events, and instructs to judge completeness from has_more not seq. This adds essential interpretation context.

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

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

Three sentences deliver purpose, return shape, usage, and critical caveats without wasted words. The information 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?

Given the tool's cursor-based pagination and the lack of an output schema, the description fully covers return values, pagination flow, and how to interpret gaps and completeness. It leaves no major usage questions unanswered.

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

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

The description adds significant meaning to the `since` parameter, explaining exactly how to use it as a cursor. With schema coverage at 67%, the description compensates for the unexplained `limit` parameter by emphasizing the cursor mechanism and has_more, though it doesn't detail entities or limit 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 clearly states the tool's function: it reports changes since a cursor, explicitly including deletes, which distinguishes it from list reads. The specific verb 'changed' and resource 'events' make the purpose unmistakable.

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 usage instructions: pass the last seq as `since` for subsequent calls, omit for first sync. It also explains when to prefer this over a list read (to see deletes), though it doesn't name a specific sibling alternative.

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 read-only and idempotent behavior, which the description doesn't need to repeat. The description adds the selection behavior by name, id, or random, including the 'random' retrieval mode which is a meaningful behavioral detail. It does not describe return format, but annotations lower the bar.

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

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

The description is a single, front-loaded sentence that communicates the core functionality without wasted words. It is perfectly sized.

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 fetch, the description covers the basic operation, but it omits important usage details such as parameter exclusivity, behavior when no parameters are provided, and what the response contains. Since there is no output schema, the description needs to give a bit more context, making it incomplete for an AI agent to invoke correctly in all scenarios.

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

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

With 0% schema description coverage, the description is the sole source of parameter meaning. It explains that name, id, and random are the lookup criteria for fetching an exercise, adding meaning beyond the raw parameter names. However, it leaves ambiguity about mutual exclusivity and the behavior when multiple parameters are provided, preventing a higher score.

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

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

The description uses the specific verb 'Fetch' with resource 'one exercise' and specifies three retrieval modes (name, id, random). This clearly distinguishes from search_exercises that would return multiple results. It is concise and unambiguous.

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

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

The description implies usage when retrieving a single exercise by identifier or randomly, but it does not explicitly state when not to use it or mention alternatives like search_exercises or resolve_exercise. With siblings present, the lack of explicit exclusion could lead to tool mis-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 adds scope information ('current app user's meals') and date-range filtering, but does not disclose additional behavioral details beyond what annotations (readOnlyHint, idempotentHint) already convey. It does not mention pagination, ordering, or default date behavior, though the annotations cover the safety profile.

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

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

The description is a single, concise sentence that gets straight to the point with no redundant phrasing. Every word contributes to understanding the tool's purpose.

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

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

For a simple list-retrieval tool with a readOnlyHint and an output schema, the description is adequate and complete enough for an agent to understand the tool's basic function. It could optionally mention that dates are inclusive or describe return structure, but the output schema covers returns, and annotations cover safety.

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

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

The input schema has no descriptions for date_to and date_from, and schema description coverage is 0%. The description only says 'for a date range' without explaining which parameter represents the start or end date, nor the date format expected. This leaves parameter semantics to be inferred from parameter names.

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 the current app user's meals within a date range. It uses a specific verb ('List') and resource ('meals'), distinguishing it from sibling tools like log_meal and update_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 provides clear context that this is for retrieving the current user's meals over a date range, implying when to use it. However, it does not explicitly mention alternatives or exclusions, such as when to use search_foods or ai_parse_meal instead.

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

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

The description goes beyond the readOnly and idempotent annotations by explaining that the tool recommends fresh muscles and how include_bodyweight=true affects recovery calculations. It does not contradict the annotations and adds useful behavioral context.

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

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

Two dense sentences cover purpose, use case, and parameter behavior with no filler. The most important information is front-loaded, making it easy to scan.

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 is present, the description does not need to explain return values. It covers what the tool does, when to use it, and how the optional parameter modifies behavior, making it complete for this read-only tool.

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

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

While the input schema already describes include_bodyweight, the description adds meaningful context: it explains why the parameter exists (to make recovery reflect real load) and implies it only applies to bodyweight exercises. This adds value beyond the schema's field 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?

The description clearly states the tool returns per-muscle 7-day recovery percentages and explicitly positions it as the 'what should I train today?' input, recommending fresh muscles. This distinguishes it from sibling tools like list_muscles and get_body_metrics by focusing on recovery-based training recommendations.

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

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

The phrase 'the what should I train today? input' provides clear context for when to use this tool. It does not explicitly exclude alternatives or name sibling tools, but the intended use case is 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 mark the tool as read-only and idempotent, and the description adds valuable context by noting the required X-App-User-Id header and the default date range of last 7 days. This 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?

The description is compact, front-loads the core data returned, then adds purpose and a requirement. Two sentences carry all necessary information without waste.

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

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

With an output schema present and annotations covering safety, the description covers the tool's purpose, default behavior, and a prerequisite. It is complete for an AI agent to select and 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?

The schema already fully describes both parameters (date_to and date_from) with 100% coverage. The description adds the default range concept but does not significantly elaborate on parameter formats or semantics beyond what the schema 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 clearly states the tool returns per-day calories, macros, fiber/sugar/sodium/alcohol, water, targets, and adherence percentages over a date range. This specific verb+resource+scope distinguishes it from sibling tools like get_water or get_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?

It provides clear context by labeling the tool as 'The how am I tracking today? tool', implying when to use it. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

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

The annotations already declare readOnlyHint and idempotentHint. The description adds valuable context beyond that: the requirement for an app user context and the specific fields included. This gives the agent a good sense of what the operation entails, though it doesn't discuss error cases or response format, which is acceptable given the simplicity.

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

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

The description is two sentences, front-loaded with the core purpose, and every word earns its place. The parenthetical field list is a compact, useful addition.

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 no output schema, the description lists the likely return fields (height, weight, goals, diet, sports) and the required context. This gives a complete picture for a zero-parameter read-only tool. No mention of pagination or errors is necessary here.

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

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

The tool has zero parameters, and the schema already reflects this (100% coverage). Per guidelines, the baseline for no parameters is 4. The description adds the relevant context about what the profile contains, which is sufficient.

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

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

The description uses a specific verb ('Get') and resource ('current app user's fitness profile') and enumerates the exact contents (height, weight, macro + water goals, diet, active sports). This clearly distinguishes it from sibling get_* tools like get_body_metrics or get_progress.

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

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

The description provides clear context by specifying this is for the current app user's profile and states a clear prerequisite: 'Requires an app user context.' It does not explicitly name alternatives or when-not-to-use scenarios, but the scope is clear enough for a simple getter.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the agent knows it's a safe read. The description adds meaningful behavioral detail beyond annotations: 'Only completed sets count' and metric-specific semantics (acute:chronic ratio thresholds, per-muscle freshness, correlate pairing). This goes beyond the structured safety hints 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 two sentences, front-loaded with the main purpose, and every clause earns its place. It packs essential details (metric selection, specific thresholds, and counting rule) without any fluff 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?

Given 14 parameters, several enums, and no output schema, the description effectively conveys the core selection mechanism and explains the most complex metrics. It doesn't cover all metrics, but the schema handles those parameter descriptions. The addition of the 'only completed sets' rule adds cross-cutting context. A little more guidance on date-range or grouping could improve it, but it's not necessary due to schema support.

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 86%, leaving a high baseline. The description adds value by explaining semantic nuances for several enum values of `metric` (training_load, muscle_recovery, correlate) and clarifies data scoping ('Only completed sets count'). This supplements the schema's brief parameter 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: 'Any progression metric for the current user — pick one in `metric`.' It identifies the resource (progression metrics) and the action (retrieve), and differentiates itself from siblings like get_muscle_recovery by covering all metrics in one tool. The scope is well-defined (current user) and the examples add specificity.

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

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

The description provides useful context on how metrics work (e.g., training_load thresholds, correlate requires two metrics) but does not explicitly state when to use this tool vs alternatives like get_muscle_recovery or get_body_metrics. Usage is implied rather than directly guided, so it lacks clear when-not-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 and idempotentHint, so the safety profile is covered. The description adds meaningful context about the response structure — days, slots, exercises, sets, reps, rest, supersets — and states that it is 'fully expanded,' which informs the agent about the scope and detail level beyond the annotations.

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

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

Two sentences, both informative. The first packs the essential semantics with specifics, and the second provides a memorable heuristic. No wasted words.

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

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

For a simple read-only tool with one param and no output schema, the description covers the core behavior and return contents sufficiently. It explains what 'fully expanded' entails and which data structures are included. Minor gaps like slug format/tips are acceptable given the simplicity, and the description is complete for the agent's decision-making.

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

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

The schema has one parameter 'slug' with only a type and no description (0% coverage). The description mentions 'by slug,' which confirms the parameter's role but adds no format, examples, or provenance guidance; it essentially restates the parameter name. This is minimal compensation for the lack of schema 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?

The description uses specific verb 'Fetch' with clear resource 'routine' and key identifier 'slug'. It distinguishes from siblings like list_routines by emphasizing 'single' and 'fully expanded', and positions itself as the 'give me a full program' 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?

The description implies when to use it: when you need a single routine's full program by slug, as opposed to listing routines or instantiating one. However, it does not explicitly name alternatives or state exclusions, so it has clear context but no direct 'use this instead of...' 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 and idempotentHint=true, covering the safety profile. The description adds valuable context by disclosing the required X-App-User-Id header and the scoping to the 'current app user', which are not visible in the structured annotations. No contradiction exists.

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

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

The description is two sentences and 19 words total. It front-loads the verb 'List' and includes only essential information: the resource, scope, and auth requirement. No unnecessary elaboration or filler.

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

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

For a simple read-only tool, the description provides the core purpose, scope, and auth requirement, and annotations cover safety. However, it lacks detail on parameter semantics and the response format (no output schema), leaving the agent to guess what the entries look like. This makes it adequate but not fully 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 0%, so the description must compensate for the bare parameters. It only mentions 'date range', which loosely suggests date_from/date_to are used for filtering, but it doesn't explain each parameter individually, their formats, or whether 'date' is a single date. This is insufficient to clarify the three undocumented params.

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 ('List') on a clear resource ('water intake entries') with scope ('current app user' and 'date range'). It distinguishes itself from sibling tools like log_water by clearly indicating a read operation. This is exactly what a purpose statement should provide.

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

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

The description implies usage by saying 'current app user' and 'water intake entries', suggesting you'd use it to retrieve water intake data. However, it provides no explicit guidance on when to prefer this over alternatives, nor does it state any exclusions. The X-App-User-Id requirement is a prerequisite, not a usage guideline.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description's addition of 'current app user's' and 'most recent first' provides useful scoping and ordering context. However, it does not disclose behaviors like pagination, limit caps, or date-range inclusivity, which would add further 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 a single, front-loaded sentence with no filler or redundant information. Every word contributes to the tool's core purpose and ordering behavior.

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

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

The tool is relatively simple, has an output schema, and the core behavior is adequately described. It might benefit from mentioning date-range filtering or typical use cases, but given the annotations, output schema, and straightforward nature, the description is complete enough 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?

The schema has 0% description coverage, and the description does not explain any of the three parameters (limit, date_from, date_to). While the overall listing purpose suggests their meaning, the description provides no explicit semantic value for these fields, forcing the agent to rely on parameter names 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 uses the specific verb 'List' with the resource 'workouts' and scopes it to 'current app user', making the operation unmistakable. It also indicates ordering with 'most recent first', which distinguishes it from single-item getters like get_exercise or write operations like log_workout.

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

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

The description clearly states what the tool does, but it does not explicitly discuss when to use it versus alternatives or include any exclusions. The usage is implied ('list workouts'), but there is no direct comparison to sibling tools such as list_routines or get_exercise, so it lacks explicit guidance.

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

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

Annotations already indicate readOnly=false, idempotent=false, destructive=false, so the description only needs to add extra behavioral context. It does add scope/auth guidance by saying 'signed-in user' and 'REST-only', but it does not disclose side effects such as whether existing planned workouts are overwritten, how cadence is applied, or whether the operation can fail due to conflicts.

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

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

Two short sentences, the first states the core action and the second provides a scope limitation. No redundant phrases, front-loaded with the main verb and object.

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 mutation tool with 4 parameters and no output schema, the description is too thin. It does not explain cadence behavior, idempotency semantics, what happens if the routine already has planned workouts, or any error conditions. The REST-only note helps but leaves major behavioral gaps.

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

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

Schema coverage is only 25% (start_date has format). The description mentions the routine and start_date ('signed-in user's routine', 'from start_date'), but does not explain cadence_days or idempotency_key, and does not map routine_id to the parameter. With low schema coverage, the description should compensate more than it does.

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 the specific verb 'Schedule' with clear resources: 'the signed-in user's routine' into 'planned workouts', starting from a date. It distinguishes the tool from siblings like get_routine and list_routines by indicating this is a write operation that creates planned workouts from a routine, and the REST-only note clarifies a related but unsupported path.

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 explicitly that coach assignment of another user is REST-only, which tells the agent when not to use this tool and provides the alternative (REST API). It also scopes usage to the signed-in user's routine and gives the start condition ('from start_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 declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and side-effect expectations. The description adds useful context beyond annotations by specifying the fixed count (23) and that it returns slugs with anatomical names, which clarifies the output shape. However, it does not describe pagination or ordering behavior, but that's minor for a simple enumeration.

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

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

The description is a single clear sentence that conveys all necessary information without any filler or repetition. It is optimally concise 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 parameterless tool with no output schema, the description fully specifies what the tool returns (a list of 23 slugs with anatomical names). There is no need for additional detail about return values or complex behavior—the tool is inherently simple and the description covers everything.

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 0 parameters, and the schema is trivially 100% covered. Baseline for 0 parameters is 4, and the description adds no parameter-specific semantics because there are none to describe. This is appropriate.

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

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

The description clearly states the action ('List'), the exact resource ('all 23 supported muscle slugs'), and the included detail ('with anatomical names'). It distinguishes itself from sibling tools by specifying the fixed count and scope, leaving no ambiguity about its function.

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

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

The description implies the tool is for retrieving the canonical list of muscle slugs when needed, but it does not explicitly state when to use it over alternatives or provide exclusions. Since this is a simple enumeration tool with no obvious sibling alternative, the usage context is implied rather than explicitly guided.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it is a safe read operation. The description adds the facts that the library is 'curated' and that the response is a 'minimal list', which provides useful behavioral context beyond the annotations. However, it does not elaborate on output structure or pagination, so the added transparency is moderate.

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

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

The description is two sentences totaling about 25 words. It opens with the verb 'Browse', immediately states the resource and key filters, then closes with the return characteristic. Every sentence earns its place with no redundant or filler 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 simple read-only list operation with no output schema, the description covers the core aspects: purpose, filter choices, and return minimality. It does not mention the 'limit' parameter or its default of 20, but this information is available in the input schema. Given the good annotations and relative simplicity of the tool, the description is sufficiently complete, though it could briefly note the limit 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?

With schema description coverage at 0%, the description carries the burden of parameter clarification. It names four of five filter parameters (goal, difficulty, split_type, days_per_week) and indicates they serve as filters, which adds context beyond the bare schema. However, it omits the 'limit' parameter and does not explain filter combinations or value meanings, relying on self-explanatory enums.

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 the specific verb 'Browse' to indicate the action of viewing the workout routine library, lists concrete filter dimensions (difficulty, goal, split_type, days_per_week), and notes the return type ('minimal list'). This clearly distinguishes it from siblings like get_routine or ai_workout_plan, which focus on a single routine or AI generation, respectively.

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

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

The description implies usage for browsing/filtering the curated library, but it does not explicitly state when to use this over alternatives such as get_routine for specific routines or ai_workout_plan for AI-generated plans. There is no mention of exclusions or when not to use, so the guidance remains implied rather than explicit.

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

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

Annotations already indicate a non-read-only write operation. The description adds the consequence that logging weight enables bodyweight-inclusive volume analytics, but it does not disclose other behavioral details such as idempotency behavior, despite the presence of an idempotency_key parameter. 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 concise and front-loaded with the action ('Log a body measurement'). The list of metric types is efficiently packed into a single sentence, and the note about weight analytics is a valuable addition without unnecessary fluff.

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 and annotations, the description covers the most critical parameter semantics (metric_type and unit) and provides a use-case for weight logging. Minor gaps remain for date format, value constraints, and idempotency handling, but these are partly addressed by the schema's basic type information.

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

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

With zero schema description coverage, the description compensates by enumerating all metric_type options with their corresponding units, which is essential for correct invocation. However, parameters like date, value, notes, and idempotency_key are not elaborated beyond their schema types, leaving some gaps.

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 'Log a body measurement' and enumerates the supported metric types with their units, making it distinct from sibling tools like log_meal and log_workout. It leaves no doubt about the resource and action.

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

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

The description implies use for recording body metrics and provides a specific benefit for logging weight, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. The domain is clear, but there is no direct 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 adds no behavioral context beyond what the annotations provide. It does not disclose what happens after logging (e.g., returns the created activity), any side effects, or validation behavior. The annotations already indicate it is a non-read-only, non-destructive operation, but the description contributes no further 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 brief and front-loaded: the first sentence states the purpose, and the second lists capabilities. It is appropriately sized, though the inclusion of 'power' is inaccurate and slightly undermines clarity.

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 9 parameters and no schema descriptions, this description is incomplete. It does not explain the date format, valid sport values, or required fields. The presence of an output schema means return values need not be described, but the parameter semantics are too sparse for reliable 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 0%, so the description must compensate, but it only mentions a few fields (duration, distance, HR, calories) and incorrectly includes 'power', which is not in the schema. It does not explain the required parameters (date, sport) or other optional fields like notes, title, or idempotency_key.

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 a cardio activity (run/bike/swim/etc.) for the current app user.' It uses a specific verb and resource, and the parenthetical examples distinguish it from strength workout logging tools like log_workout.

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

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

The description gives clear context by specifying the action (logging cardio) and scope (current app user), but it does not mention when to prefer this tool over alternatives or any exclusions. The distinction from log_workout is implicit through the term 'cardio'.

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 minimal behavioral context beyond the annotations. It scopes the operation to the current app user, but does not explain side effects, idempotency behavior, or what happens on duplicate entries. The mention of 'optional ingredients' is not supported by any schema parameter, which could mislead. However, it does not contradict the annotations.

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

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

The description is a single, succinct sentence that front-loads the main action and key details. Every word earns its place, and it is appropriately concise without padding.

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 8 parameters and an output schema, the description is incomplete for a logging tool. It does not explain parameter meanings, required fields, or constraints like date format or meal_type values. The output schema exists, so return values are covered, but the overall context for effective use is severely lacking.

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

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

With 0% schema description coverage, the description carries the parameter-documentation burden, but it only mentions 'calories' and 'macros' (which maps to protein/carbs/fats). It omits required parameters like date and name, and misunderstands the schema by referring to 'optional ingredients' when no ingredients field exists. This provides insufficient parameter clarity.

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 a specific verb ('Log') and resource ('a meal'), and distinguishes it from sibling tools like update_meal and delete_meal by indicating creation. It also specifies the key content (calories + macros + optional ingredients), 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?

No guidance is provided on when to use this tool versus alternatives such as ai_parse_meal or log_water. The description only states that it logs a meal for the current user, but lacks any when/when-not instructions or alternatives.

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 (write operation) and idempotentHint=false. The description adds that it logs for the current app user but does not disclose behavior like appending records or the role of idempotency_key. With annotations covering the safety profile, a mid-range score is appropriate.

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

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

The description is a single concise sentence that is front-loaded with the verb and resource. Every word earns its place with no 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?

This is a simple logging tool with an output schema and annotations providing safety hints. The description states the essential action and scope. It is complete enough for expected usage, though it could benefit from a note about idempotency or typical call patterns.

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

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

Schema description coverage is 0%, and the description provides minimal parameter meaning beyond the unit 'ml'. It does not explain the date format, the expected range or type of amount_ml, or the purpose of idempotency_key, leaving the agent to rely on param names only.

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 (Log), names the resource (water intake), specifies the unit (ml), and identifies the scope (current app user). It clearly distinguishes from sibling tools like get_water (read) and other log_* 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 provides clear context by indicating the action and scope, making it obvious when to use this tool. However, it does not explicitly mention alternatives or when not to use it, though this is less critical for a simple logging 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 annotations all false, the description must carry the behavioral disclosure burden. It adds a meaningful prerequisite (requires an app user context) and the verb 'log' implies an additive write, but it does not disclose idempotency behavior, potential side effects, or response structure. This is limited but not misleading.

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

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

The description is two short sentences with no filler. Each sentence adds a distinct point: what the tool does and a prerequisite. It is efficiently structured 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?

This is a fairly complex tool with 5 parameters, a nested sets array, and an idempotency_key, yet the description is very sparse. It fails to explain the structure of sets, the meaning of primary_sport, or the idempotency mechanism, making it incomplete for an agent to use correctly without additional inference.

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

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

Schema description coverage is 0%, so the description is the only source of parameter meaning. It mentions 'exercise sets' and that they can be strength or cardio unified, but ignores key parameters like date, title, primary_sport, and idempotency_key. This leaves most parameters unexplained.

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

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

The description clearly states the verb 'Log' and the resource 'workout', and specifies 'with exercise sets (strength or cardio unified)'. This distinguishes it from sibling tools like log_cardio and log_meal, and the requirement of an app user context adds further specificity.

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

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

The phrase 'strength or cardio unified' implies this tool is for logging complete workouts that may include both types of sets, which helps differentiate it from log_cardio. It also states a prerequisite (app user context), but does not explicitly mention alternatives or exclusions for cases like updating existing sets or standalone cardio logging.

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, idempotentHint, and openWorldHint, covering the safety profile. The description adds that the lookup is for food products via barcode but does not disclose behaviors like not-found handling or data source limitations. Since annotations handle primary safety traits, a mid-range score is appropriate.

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

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

The description is a single concise sentence that front-loads the action ('Lookup') and target ('food product'), with no wasted words 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 simple single-parameter nature and the presence of an output schema plus read-only annotations, the description is complete enough. It defines the input scope and purpose without needing to explain return values since the output schema covers that.

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

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

The schema provides no description for the 'barcode' parameter (0% coverage), so the description must compensate. It does so by specifying the barcode format as EAN/UPC, which gives the agent meaningful input expectations beyond the parameter name alone. This is valuable but lacks detail on exact format constraints.

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 a specific verb 'lookup' and a well-defined resource 'food product' plus a specific key type 'EAN/UPC barcode'. This distinguishes it from sibling tools like search_foods, which would search by text, making the purpose unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives such as search_foods. The description only states what it does, not the appropriate context for using it or when to prefer another 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 declare the tool as read-only and idempotent. The description adds meaningful behavioral context: identity comes from the token rather than a caller-supplied user id, and the response is a subset ('slice') with configurable domains. No contradiction with annotations.

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

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

Two concise sentences, each serving a distinct purpose: stating the function, default behavior, customization, and authentication. Front-loaded with the core action and free of 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?

The description adequately covers the essential aspects for a read-only tool with an output schema: purpose, default domains, customization via `domains`, and identity handling. Since an output schema exists, it does not need to describe return values or structure.

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

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

The description thoroughly explains the `domains` parameter, including accepted values and defaults, adding value beyond the schema. However, `workout_limit` is not mentioned at all, and the schema only provides a default with no purpose, leaving its meaning (likely limiting workout entries) implicit.

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 returns a slice of the signed-in user's training picture, explicitly listing default domains (workouts, nutrition) and optional domains (checkin, notes, profile). This distinguishes it from sibling getters that focus on individual domains, such as get_workouts or get_nutrition_daily.

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

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

The description implies usage for fetching a combined training context with configurable domains, and notes the authentication requirement (identity from token). However, it does not explicitly state when to prefer this over alternative single-domain tools, leaving the comparison implicit.

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

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

Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds useful context about the output structure ('primary/secondary muscle layers') and the rendering purpose, but it does not disclose behavior for unknown exercise names or edge cases. It provides moderate additional context without contradicting 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?

A single, front-loaded sentence that efficiently conveys the operation, input, and output. There is no redundancy or unnecessary detail; every word contributes to understanding the tool's purpose.

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

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

For a simple tool with one parameter and no output schema, the description provides enough to grasp the core purpose and expected output type. It leaves open questions about return structure and handling of unknown names, but given the openWorldHint and simple nature, it is largely 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 0%, so the description must compensate. The phrase 'exercise name' clarifies that the parameter is a name, not an ID, but no examples, format rules, or constraints are given. This is minimal added value 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 action ('resolve'), the resource (exercise name), and the output (primary/secondary muscle layers for rendering). This specificity distinguishes it from siblings like get_exercise, which retrieves full exercise data, and search_exercises, which finds exercises by criteria.

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

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

The phrase 'for rendering' implies when to use it, but there is no explicit comparison to alternatives or exclusions. It doesn't say 'use this instead of get_exercise' or clarify when not to use it, leaving the usage context somewhat implied rather than stated.

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

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

Discloses that results are lean, points to get_exercise for instructions/media, and explains pagination mechanics. This adds valuable behavioral context beyond the annotations (readOnly, openWorld, idempotent) that already indicate a safe, read-only operation.

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

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

Two sentences with high information density: purpose first, then row content, the pointer to get_exercise, and pagination. No filler words.

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

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

Given the output schema, annotations, and pagination, the description covers the key aspects: what rows contain, how to paginate, and how to get full details. The schema handles field descriptions, so 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?

The description gives meaning to muscle/equipment/level as filters and clarifies cursor for pagination. With schema description coverage at 29%, the description partially compensates, but it doesn't explain valid values for level/muscle/equipment or the exact behavior of q beyond 'by name.'

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 'Search 873 exercises by name with muscle/equipment/level filters,' specifying the exact verb, resource, count, and filter categories. This distinguishes it from sibling tools like get_exercise, which returns full details.

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 context: rows are lean 'enough to pick one; get_exercise returns instructions and media,' explicitly naming the alternative for full details. It also explains pagination with next_cursor/cursor. However, it doesn't explicitly state when not to use it (e.g., if you already have an exercise ID).

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, openWorldHint, and idempotentHint. The description adds value by disclosing data sources and the per-100g macro return format, which are not covered by annotations. It does not discuss pagination or locale behavior, but with annotations present, this is sufficient.

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

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

The description is a single, well-structured sentence that concisely states the purpose, data sources, and return format without extraneous words.

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

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

With a simple tool and an output schema present, the description covers the core function and return format but lacks usage guidance and parameter explanations. It is adequate for a straightforward search but leaves some gaps in context for the agent.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies the 'q' parameter as a name search but provides no semantics for 'locale' or 'page_size'. The names are self-explanatory to some degree, but the description does not explicitly explain them, leaving ambiguity for the agent.

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 'Search food products by name' with a specific verb and resource, and identifies data sources (Open Food Facts + USDA) and the return format (macros per 100g). This distinguishes it from sibling tools like search_exercises and lookup_barcode.

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

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

The description implies usage by name but does not explicitly state when to use this tool versus alternatives such as lookup_barcode for barcode queries. No exclusions or alternative recommendations are provided, leaving the agent to infer context from sibling names.

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 a required authentication header (X-App-User-Id) and explicitly states partial-update semantics ('Pass only the fields you want to change'). These go beyond the annotations, which only indicate non-readonly, non-idempotent, and non-destructive. It does not describe error behavior, but the annotations already cover safety aspects.

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

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

The description is two sentences long, front-loads the primary purpose, and contains no fluff. Every sentence adds value: one states the purpose and scope, the other gives usage guidance and an auth requirement.

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 14-parameter schema and minimal annotations, the description does not fully cover the tool. It omits the idempotency_key parameter, does not mention the output schema, and the 'portion' reference introduces ambiguity. However, the output schema exists, so missing return-value details are less critical.

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

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

With only 14% schema description coverage, the description must compensate by explaining the parameter list. It names broad categories ('macros, nutrients, portion, date or meal_type'), but 'portion' does not exist in the schema, and the exact nutrient mappings are left implicit. It does add the useful 'pass only fields to change' guidance, which clarifies optionality.

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 ('Correct') with a clear resource ('a previously logged meal') and lists the targeted fields ('name, macros, nutrients, portion, date or meal_type'). This clearly distinguishes it from sibling tools like log_meal (create) and delete_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?

It clearly states this is for correcting an existing meal and instructs users to pass only the fields to change. It does not explicitly mention alternatives like log_meal for creating, but 'previously logged' provides enough context to infer when this tool should be used.

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

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

The description adds behavioral nuance beyond annotations by explaining the separate selection/change behavior, enabling partial updates like relabeling a subset. It also mentions the delete option, consistent with destructiveHint=true, and clarifies that existing logged sets are modified rather than created.

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 concise sentences, front-loaded with the core purpose, and every sentence earns its place. It avoids fluff while covering purpose, usage, and the key distinction from log_workout.

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 fairly complete for an 8-parameter destructive tool, covering the main operations and the source of set IDs. It does not explicitly mention irreversibility of delete, but the destructiveHint annotation and the word 'delete' cover that. The presence of an output schema also reduces the need to describe 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?

With only 13% schema description coverage, the description compensates by explaining the key parameter set_ids (from log_workout) and mapping several fields to operations: relabel exercise, fix weight/reps/rpe, mark completed, add notes, delete. It does not detail every parameter, but it provides sufficient semantic context beyond the bare schema.

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

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

The description clearly states the tool corrects already-logged sets by set ID, with a specific verb ('Correct') and resource ('sets'). It lists the specific operations (relabel exercise, fix weight/reps/rpe, mark completed, add notes, delete) and distinguishes itself from log_workout for adding sets.

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 'Adding a set is log_workout, not this,' providing a clear when-not-to-use condition. It also gives context that set IDs come from log_workout, and explains that selection and change are separate, which guides partial updates.

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 idempotency and non-destructiveness. The description adds meaningful behavioral context beyond annotations by disclosing that timezone determines how daily totals, streaks, and adherence windows are bucketed (defaulting to UTC), and that weight serves as a fallback bodyweight for bodyweight-inclusive volume. This enriches the agent's understanding of side effects and dependencies.

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

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

The description is two concise sentences, front-loaded with the main purpose, followed by two high-value caveats. No filler words; every sentence adds necessary context.

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, the description is relatively brief. It covers the key behavioral nuances (timezone bucketing and weight fallback) but does not explain whether unspecified fields are left unchanged or reset, nor any validation constraints. The idempotent annotation helps, but a bit more detail on partial-update behavior would increase completeness.

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 only 35% (6 of 17 parameters). The description meaningfully explains only timezone and weight, leaving the other 11 parameters without semantic elaboration. Given the low coverage, the description should compensate far more to clarify parameter meanings and interactions.

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 clear verb and resource: 'Upsert the current app user's fitness profile.' This precisely states the action and distinguishes it from siblings like get_profile (read) and log_* (data logging) tools. The unique scope 'current app user' also disambiguates from any multi-user context.

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

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

The description provides clear operational guidance, most notably 'Set timezone first' and explains the consequences of timezone and weight semantics. It implies usage for profile updates but does not explicitly contrast with alternative tools such as get_profile, though the tool's unique resource makes exclusion implicitly obvious.

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