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

Beyond the annotations (write operation, not idempotent), the description warns that nutrient IDs in extra_nutrients are not validated and must not duplicate macro IDs, and clarifies that nutrient amounts are for the full serving. This materially reduces the chance of misuse, although it does not discuss auth or failure behavior.

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

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

The description is front-loaded with the core purpose and serving-size rule, then uses a tidy Args block to document all 12 parameters. No sentences are wasted; the extra_nutrients caveat is long but necessary.

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 12-parameter creation tool with no parameter descriptions in the schema, the description covers every arg, the intended follow-up workflow, the source for nutrient IDs, and a key correctness warning. The output schema exists, so return-value details need not be repeated.

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

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

Since the schema has 0% description coverage, the Args section carries the full burden and does so completely: every parameter is listed with units, defaults, and the special extra_nutrients keying semantics. It adds meaning well beyond the bare schema titles.

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

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

The description opens with a specific action and resource: 'Create a custom food in Cronometer with specified nutrition.' It clearly centers on creating a reusable food object, distinct from logging entries or recipes, and reinforces the purpose by explaining the follow-up with add_food_entry.

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 a clear workflow clue—'After creation, use the returned food_id with add_food_entry to log it'—but it does not explicitly state when to prefer this tool over sibling alternatives like add_recipe, import_recipe, or search_foods. Usage context is implied by the name and first line rather than spelled out.

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 (mutation) and openWorldHint=true. The description adds behavioral context by explaining parameter sources (food_id from search_foods, etc.) and effect (adds entry to diary), going 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 well-structured with an Args section and clear sentences. It could be slightly more concise (e.g., default values could be omitted from text since schema shows them), but it remains effective.

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

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

Given the tool has 6 parameters, 3 required, and an output schema (present but not shown), the description covers all parameters, workflow, and usage context comprehensively. It is complete for a mutation tool with these complexities.

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

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

With 0% schema description coverage, the description fully compensates by explaining the meaning and source of each parameter (e.g., food_id from search_foods, date format YYYY-MM-DD, diary_group enum values). This adds significant 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 'Add a food entry to the Cronometer diary', uses a specific verb (add) and resource (food entry), and distinguishes from sibling tools like search_foods (for finding) and get_food_details (for confirming).

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 instructs to use search_foods and get_food_details before calling this tool, providing clear context. It lacks explicit when-not-to-use statements, but the workflow guidance is sufficient.

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

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

The description adds behavioral context beyond annotations by explaining that nutrient profiles are derived from ingredients, that grams always drive nutrition math, and that measure_id only affects the UI unit. It also clarifies that serving_grams defaults to the full batch weight. No contradiction with annotations 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 efficient and well-organized: purpose first, then differentiation, then usage flow, then parameter details. Every sentence adds value, with no redundant filler or restating of schema titles.

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 5-parameter creation tool with no schema descriptions, the description provides complete guidance on inputs, defaults, dependencies on other tools, and downstream usage. Nothing critical is missing for an 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?

Despite the schema having 0% description coverage, the description defines every parameter with meaningful semantics, including the ingredient object shape, the optional measure_id behavior, and default values for serving_name and serving_grams. This fully compensates for the sparse 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 creates a recipe in Cronometer from existing foods by ID, contrasting it with add_custom_food. It identifies the resource, the action, and the key distinguishing behavior (deriving the full nutrient profile from referenced ingredients).

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

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

The description explicitly tells the agent to use search_foods to find food IDs and to use the returned food_id with add_food_entry after creation. It also explicitly distinguishes this tool from add_custom_food, making the when-to-use decision unambiguous.

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

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

The description explicitly states 'Additive -- does not remove existing entries on the destination date,' which adds meaningful behavioral context beyond the annotations. The annotations already indicate non-destructive behavior, but the description clarifies the exact merge semantics and what side effects will not occur.

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

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

The description is compact and front-loaded with the primary purpose, followed by the key additive behavior and a concise parameter explanation. Every sentence conveys essential information without repetition or filler.

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

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

For a tool with one optional parameter, a clear source/destination model, an additive safety note, and an output schema, the description is complete. An agent has enough information to invoke the tool correctly without additional missing context.

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

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

Although schema description coverage is 0%, the description fully documents the only parameter: date as YYYY-MM-DD with a default of today. It also clarifies that date is the destination date, which adds meaning beyond the raw schema definition.

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 'Copy' and the resource 'all diary entries from the previous day' to a specified destination date. This is a specific, unambiguous operation that distinguishes copy_day from the provided siblings, none of which describe copying diary entries.

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

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

The intended use is implied by the core statement 'Copy all diary entries from the previous day to the given date.' However, the description does not explicitly discuss when to prefer this tool over alternatives or mention any exclusions, so usage guidance is only implicit rather than clearly framed.

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 destructiveHint=true, but the description adds crucial side effects: the food disappears from search and Custom Foods list, diary entries remain intact, and get_food_details can still retrieve it by ID. This goes beyond the annotations to explain the 'retiring' semantics, which is valuable for the agent.

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 succinct, with the core action stated first, then a clear bullet-like explanation of side effects and constraints, followed by an Args section. Every sentence adds value.

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

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

Given the output schema exists and annotations cover safety, the description provides sufficient context: it explains the retirement model, what happens to diary entries, and what cannot be deleted. It lacks explicit idempotency mention but that's in annotations, and error handling is likely in output schema.

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

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

The schema only defines food_id as an integer, with no description. The description adds that it's the ID of the custom food to delete, clarifying it's not a recipe or database food ID. This is minimal but necessary given the 0% 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 it deletes a custom food (one you created) by retiring it, distinguishing it from removing diary entries or editing foods. It also explicitly excludes database foods and recipes, which differentiates it from other tools like update_custom_food and remove_food_entry.

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 specifies that only custom foods can be deleted, not database foods or recipes, implying alternative tools for those. It also explains the retirement behavior (disappears from search, diary entries kept), which helps the agent decide when to use this tool. It doesn't name alternative tools explicitly, but the constraints are clear.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral detail beyond annotations, including the exact return format ('a list of {day, value} points') and default date ranges (start defaults to 30 days ago, end to today). This enhances the agent's understanding of what to expect 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?

The description is well-structured and appropriately sized: it front-loads the purpose and return format, then provides a useful cross-reference to list_biometrics, followed by a concise parameter list. Every sentence carries meaningful information without redundancy.

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

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

Given the tool has an output schema and rich annotations (readOnly, openWorld, idempotent, non-destructive), the description covers all necessary aspects: purpose, return shape, parameter semantics, defaults, and a prerequisite reference. No critical information is missing for an agent to invoke this correctly.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining every parameter: metric_id is a numeric ID from list_biometrics, unit_id is a numeric unit ID with a clarifying example, and start_date/end_date have format specifications and defaults. This provides meaning far beyond the bare schema properties.

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 begins with a specific verb ('Get') and resource ('a biometric time series such as weight or body fat from Cronometer'), making the tool's purpose immediately clear. It further distinguishes itself from sibling tools like add_biometric, edit_biometric, and remove_biometric by describing a read operation that returns data.

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

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

The description explicitly tells the agent to 'Use list_biometrics to find metric_id and unit_id', which is a clear prerequisite and points to the correct sibling for obtaining required parameters. While it doesn't explicitly enumerate exclusions or alternative retrieval tools, the context is sufficient to understand when this tool is appropriate.

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, idempotentHint, and destructiveHint, covering safety. The description adds substantial behavioral context: it explains that nutrients only appear if tracked in Cronometer, that values are null if a macro isn't tracked, that defaults resolve at call time in the account timezone, and that multiple days return a list of day objects. These are behavioral details not derivable from the schema or annotations. It does not contradict any annotation.

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

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

The description is long but every sentence earns its place. It is front-loaded with the core purpose, then structured with clear sections for the response shape and arguments. The 'Args' section is neatly separated, and examples are given inline. There is no fluff or repetition; it is dense yet scannable.

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

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

For a read-only tool with an output schema (present but not detailed here), the description covers everything an agent needs to call it correctly: input formats, defaults, behavior for multiple days, the tracked-nutrient caveat, and the exact response structure. It even notes how to surface additional nutrients (set a target). No essential information is missing.

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

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

Schema coverage is 0% (no descriptions in the input schema), so the description carries the full burden. It thoroughly explains both parameters: date (format, examples, defaults, resolution timezone) and days (range, inclusive behavior, and how days=3 with a date excludes today). This goes far beyond the schema's default values and titles, giving the agent precise semantics.

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

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

The description opens with a clear verb+resource: 'Get consumed macro and micronutrient totals for one or more days.' It names the specific output (summary and nutrients) and distinguishes itself from siblings like get_food_log (which returns per-entry logs) and get_nutrition_scores (which likely returns scores). The purpose is unambiguous.

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

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

The description provides clear guidance on parameter usage ('Prefer relative inputs over dates calculated from conversation history') and explains how days and date interact. However, it does not explicitly state when to use this tool versus alternatives like get_food_log or get_nutrition_scores. It implies its scope (daily totals) but never names a sibling or gives an exclusion condition. Thus it falls short of a 5 but is well above vague.

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, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds valuable behavior beyond annotations: returned fields (status, timestamps, duration) and default date behavior (30 days ago to today), which helps the agent understand what a call will produce.

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

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

The description is compact and front-loaded: the core purpose appears first, then return contents, then parameter details. Every sentence contributes useful information without redundancy or filler.

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

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

With only two optional parameters, rich annotations, and an output schema present, the description covers the essential call context: what is fetched, the default range, and the date format. Minor details like timezone handling or status enumeration are not specified, but these are not critical given the output schema and the simple read-only nature of the 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?

The input schema only shows nullable string parameters with null defaults and 0% description coverage. The description compensates by documenting start_date and end_date as YYYY-MM-DD with explicit defaults, giving the agent the format and semantics needed to invoke the tool correctly.

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

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

The description opens with a specific verb and resource: 'Get fasting history from Cronometer.' It then clarifies exactly what is returned—'fasts within the date range including status, timestamps, and duration'—which distinguishes it from related siblings like get_fasting_stats, add_fast, or delete_fast.

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 a fasting history within a date range is needed, and the date-range context is clear. However, it does not explicitly mention alternatives or when not to use this tool, leaving the agent to infer the boundary against siblings like get_fasting_stats.

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 operation as read-only, idempotent, and non-destructive, so the description does not need to restate safety. The description adds meaningful behavioral context by specifying that the tool returns computed aggregates rather than raw entry data, which is not captured by 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 extremely concise: one clear purpose sentence followed by a line enumerating return values. It is front-loaded with the core action and adds no filler or redundant information.

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

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

For a zero-parameter, read-only aggregated stats tool with rich annotations and an output schema, the description covers the essential information. It clearly states what the tool does and what it returns, and there are no hidden inputs or side effects an agent would need to know about.

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 schema description coverage is 100%, so there is no parameter semantics burden on the description. The baseline of 4 applies because with no parameters, nothing additional is needed.

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 that the tool retrieves 'aggregate fasting statistics' and enumerates the exact computed metrics returned: total fasting hours, longest fast, average fast duration, and completed fast count. This distinguishes it from the sibling get_fasting_history, which implies raw history rather than summary metrics.

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

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

The word 'aggregate' and the list of summary metrics imply this tool is for overview statistics rather than detailed history, but the description does not explicitly mention when to prefer it over get_fasting_history or other fasting-related tools. No alternatives or exclusion criteria are named.

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 readOnlyHint, idempotentHint, and non-destructive behavior, so the description carries a lighter burden. It adds context about the full nutrient profile and measure_ids, but it does not describe further behavioral traits such as error cases or data availability. 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 compact, front-loaded with the primary purpose, and every sentence earns its place. The Args section adds provenance for the only parameter without excessive 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 the single parameter, rich annotations, and presence of an output schema, the description is sufficiently complete. It also explains the important workflow relationship with search_foods and add_food_entry, which would otherwise be ambiguous.

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 food_id. It does so by specifying 'Food ID from search_foods results,' which gives the agent the essential source and provenance of the parameter beyond the bare integer type.

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

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

The description states a specific verb and resource: 'Get detailed food information including nutrition and serving sizes.' It adds the key deliverable, 'full nutrient profile and available measure_ids,' and implicitly distinguishes itself from search_foods by being the follow-up detail lookup.

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

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

It gives explicit usage context: 'Use this after search_foods' and explains that the output is 'needed for add_food_entry.' This clearly positions the tool in a workflow, though it does not explicitly list when-not-to-use 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?

Beyond the annotations (readOnlyHint, idempotentHint), the description reveals important behavioral details: entries are enriched with food name, source, measure, etc.; non-food entries carry their own name; per-entry nutrients are distinct from the day-level nutrition_summary; and it explains the energy_summary fields and the instruction to report remaining_kcal. This adds substantial context beyond the structured annotations.

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

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

The description is long but well-structured with clear sections for Args and return fields. It front-loads the primary purpose and usage guidance. While it could be trimmed slightly, every sentence adds necessary detail for correct use, and the organization makes it easy to scan. It is not excessively verbose for the tool's complexity.

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 (as indicated), the description doesn't need to enumerate every return field, but it does explain key structures (energy_summary, nutrition_summary) and the difference between per-entry and day-level data. Both parameters are thoroughly documented, and the behavior for single vs. multiple days is clarified. Nothing an agent needs to call this tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must fully compensate. It does: for 'date', it explains it is inclusive end date, supports YYYY-MM-DD, 'today', 'yesterday', or 'N days ago', and defaults to today in account timezone. For 'days', it explains range 1-31, includes the end date, and gives an explicit example (days=3 includes today). This is comprehensive and removes ambiguity.

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

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

The description states a clear verb and resource: 'Get diary entries for one day or the last N calendar days.' It also differentiates itself from get_daily_nutrition by explicitly naming the alternative and when to prefer it, ensuring the agent can select the correct tool without ambiguity.

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 guidance: 'Prefer relative inputs for relative questions... For calorie/nutrient totals without individual entries, prefer get_daily_nutrition(days=N).' It also clarifies the meaning of 'days' and how dates are resolved, which is essential for correct invocation.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful context by explaining that the result includes the per-day template mapping and all saved templates with their values, which clarifies what 'macro targets' means.

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 with no filler. The main purpose is front-loaded and the second sentence expands the meaning of 'weekly schedule and templates' without 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 zero-parameter schema, rich read-only annotations, and presence of an output schema, the description provides all essential context. It clearly states what the tool returns, making it complete enough for an agent to select and invoke 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?

There are zero parameters, so the input schema fully documents the calling contract. The description correctly implies no arguments are needed.

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

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

The description states a specific verb ('Get'), a clear resource ('current macro targets'), and the precise scope ('weekly schedule and templates'). It also distinguishes the tool from the ambiguous sibling 'get_targets' by naming the macro-specific contents returned.

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 indicates this is the tool to call when the agent needs the current weekly macro schedule or saved macro target templates. It does not explicitly name alternatives or exclusions, but with zero parameters and such specific return content, the usage context is obvious.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations, including date resolution semantics: 'Defaults to today in the account timezone, resolved at call time,' and guidance to prefer relative date inputs. This explains call-time behavior without contradicting the annotations.

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

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

The description is well-structured and front-loaded: a clear one-line purpose, then return contents, then usage guidance, then parameter details. The category list is long but directly informs what the agent will receive. No sentence is filler.

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

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

With only one optional parameter, a full explanation of that parameter, an output schema present, and annotations covering safety/idempotency, the description is complete for a correct call. The agent knows what data comes back, when to use it, and how to specify the date.

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

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

The input schema provides only the parameter name 'date' with no description, so schema coverage is 0%. The description fully compensates by specifying accepted formats ('YYYY-MM-DD, today, yesterday, or N days ago'), the default behavior, timezone handling, and a recommendation about relative inputs. This is exemplary parameter documentation.

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 first sentence names a specific verb and resource: 'Get nutrition scores with per-nutrient consumed amounts and category grades.' It enumerates the exact categories returned and labels itself 'the richest nutrition endpoint,' which differentiates it from siblings like get_food_log or get_macro_targets. An agent can immediately tell what this tool does.

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

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

The description explicitly states when to use the tool: 'use it when you need to know both how much of each nutrient was consumed AND how close each is to the target.' It does not name alternative tools or give when-not-to-use guidance, but the intended context is clear and actionable.

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

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

The description adds significant behavioral context beyond annotations: matching is fuzzy, returned matches should be reported for confirmation, unresolved lines are excluded under 'unmatched,' and the result saves to My Foods. It also clarifies that add_food_entry is needed to log it.

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

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

The description is front-loaded with the core purpose and every sentence contributes meaningful guidance: usage, alternatives, behavior, and parameter semantics. The Args section is clean and directly aligned with the schema properties.

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

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

For a two-parameter tool with an output schema, this description covers input format, optional parameters, matching behavior, persistence, and follow-up action. No important guidance is missing for correct 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%, but the description fully compensates. It explains that ingredients are newline-separated, gives a concrete example, and warns that bare names can produce surprising amounts. It also clarifies that name defaults to a server-generated value.

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

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

The description opens with a specific verb and resource: 'Create a recipe from a free-text ingredient list.' It distinguishes itself from add_recipe and search_foods, making its role among siblings immediately clear.

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

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

Explicitly states when to prefer this tool: 'Prefer this when the user describes ingredients in their own words.' It also names the alternative condition: 'Use add_recipe instead when you have exact food_ids and gram weights,' and even notes that search_foods is unnecessary first.

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 define the read-only, idempotent, non-destructive nature. The description adds valuable behavioral context by disclosing that it returns 'every metric type the account can record' and that results contain metric_id and unit_id fields, enabling a follow-up workflow with get_biometrics. No contradiction with annotations.

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

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

Three concise, information-dense sentences. The main purpose is front-loaded, followed by a clarifying example list and a practical usage pointer. No redundant words or repetition of schema/annotation 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 parameterless list tool with rich annotations and an output schema, the description fully covers what the tool returns, gives concrete examples, and explains the subsequent step (get_biometrics). 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?

There are zero parameters, so the description is not required to explain parameter meaning. The baseline for zero-parameter tools is 4, and the description goes slightly beyond by indicating how to use the result fields (metric_id, unit_id), which adds semantic value even though not parameter-specific.

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 ('List') with a clear resource ('the biometric metrics tracked in Cronometer'). It explicitly clarifies that this returns metric types (Weight, Body Fat, etc.), not actual measurements, which distinguishes it from get_biometrics (which retrieves actual biometric data). The purpose is unambiguous.

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

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

The description provides clear context that this is a metadata-listing tool and explicitly instructs the agent to 'Use the metric_id and a unit_id from the results with get_biometrics.' It implies when to use it as a precursor to get_biometrics, though it does not explicitly state cases where it should NOT be used (e.g., when actual biometric values are needed).

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 states the core mutation (marking a day complete or incomplete), which aligns with the annotations readOnlyHint=false and destructiveHint=false. It does not add richer behavioral context such as side effects on streaks or handling of non-existent days, but the annotations already provide idempotency and destructiveness safety, lowering the burden on the description.

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 crisp sentences followed by a structured Args block. The purpose is front-loaded, and there is no filler or redundant explanation. 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 simple two-parameter mutation, the description covers the operation and all parameter meanings. The output schema and annotations cover return values and safety characteristics. It stops short of a 5 by leaving edge-case behavior (e.g., what happens if the day does not exist) unmentioned, but this is a minor gap.

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

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

The schema provides only types and a default, with zero parameter descriptions. The description's Args block compensates fully by specifying the exact date format 'YYYY-MM-DD' and the boolean mapping 'True to mark complete, False for incomplete'. This gives an agent everything needed to set each parameter correctly.

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

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

The description states a specific verb ('mark') and resource ('diary day') with the two possible states 'complete or incomplete'. It is clearly distinguishable from all sibling tools, which deal with foods, biometrics, exercises, and fasting rather than diary completion status.

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

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

The description provides clear context for when to use the tool: whenever a diary day's completion status needs to be set. It does not explicitly name alternatives or exclusions, but no sibling tool appears to overlap this functionality, so explicit routing is unnecessary.

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

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

The annotations already carry the key behavioral hints: destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds the target ('Cronometer diary') and the 'one or more' batch capability, but it does not disclose potential side effects, failure semantics, or irreversibility beyond what 'Remove' and the destructve annotation imply.

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

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

The description is compact and front-loaded with the purpose, followed by a short prerequisite and an Args list. Every sentence contributes necessary information and there is no filler or unnecessary 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 two simple parameters, an output schema, and annotations covering destructive/idempotent behavior, the description is complete: it states what is removed, how to find valid IDs, and how to specify the date. No critical information needed to invoke the tool correctly is missing.

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

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

Schema description coverage is 0%, but the description compensates fully by explaining both parameters: entry_ids is 'List of serving/entry IDs to remove,' and date is 'YYYY-MM-DD (defaults to today).' It adds format and default semantics that the input schema, which only declares 'string or null', does not provide.

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

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

The description opens with a specific action and resource: 'Remove one or more food entries from the Cronometer diary.' This clearly distinguishes it from sibling tools like edit_food_entry or add_food_entry by naming the removal operation and the target (diary entries).

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 prerequisite guidance: 'Use get_food_log to find entry IDs,' which tells the agent how to obtain the required parameter. However, it does not explicitly state when not to use this tool or compare it to alternatives such as edit_food_entry, so it lacks full exclusion guidance.

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

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

Annotations already establish the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds useful behavioral context beyond annotations: results contain food IDs, measure_ids, and source information, and matching is by name/keyword. There is no contradiction between the description and annotations.

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

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

Every sentence earns its place: purpose, return shape, downstream routing, then the parameter definition. The purpose is front-loaded in the first sentence, and the entire description is compact with zero 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?

For a low-complexity, single-parameter, read-only search tool with an output schema and rich annotations, the description is complete. It covers what the tool does, what results contain, how to chain results into add_food_entry or get_food_details, and what the query parameter means. Minor details like pagination or result limits are not critical at this level of simplicity.

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 fully compensate — and it does. The Args block defines query as a 'Food name or keyword' and supplies concrete examples ('eggs', 'chicken breast'), adding real meaning that the bare string parameter in the schema completely lacks.

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

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

The opening sentence, 'Search Cronometer's food database by name,' states a specific verb, resource, and scope in a single line. The follow-up about returning food IDs and source information, plus the routing to add_food_entry and get_food_details, distinguishes it from sibling listing and retrieval tools such as list_custom_foods and find_entries_by_food.

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 downstream workflow guidance: use the returned food_id and measure_id with add_food_entry, or pass food_id to get_food_details for full nutrition info. It implies the public-database scope and separates this tool from detail-fetching tools, but it never explicitly states when not to use it (e.g., for custom foods, use list_custom_foods), leaving a small 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?

Beyond annotations (readOnlyHint false, destructiveHint true, idempotentHint true), the description reveals key behaviors: the in-place partial update semantics, that existing diary entries adopt new values, that nutrients are per serving, and that changing serving_grams scales per-serving values while leaving per-100g values intact. It also states a limitation (recipes not editable). No contradictions with annotations; the description adds substantial 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 description is thorough but not bloated. It front-loads the main purpose and then logically proceeds to usage, behavior, and parameter definitions. The length is justified given the 13 parameters and the need to explain nuanced partial-update behavior. It could be slightly tighter, but every sentence adds value, so it earns a 4.

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 13 parameters, 0% schema coverage, and an output schema, the description covers all necessary aspects: what it does, how to use it, what happens on update, parameter meanings, and exclusions. The presence of an output schema means return values need not be described. Nothing essential is missing for an agent to call this tool correctly.

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

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

Schema description coverage is 0%, so the description must fully define parameters. It does: an 'Args:' block explains each parameter, including units (e.g., 'calories per serving (kcal)'), the meaning of serving_grams, and the extra_nutrients constraint ('must not reuse an ID the named args already cover'). This goes well beyond the bare property names, giving agents clear semantics for all 13 parameters.

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 precise verb-resource pair: 'Edit an existing custom food (one you created) in place.' It clearly distinguishes the tool from siblings by noting that recipes cannot be edited even though they show as source 'Custom,' and it directs the agent to search_foods/get_food_details to find the food_id. This leaves no ambiguity about what the tool does.

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

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

The description gives explicit usage guidance: it states the partial-update behavior ('Only the arguments you pass change'), specifies the exclusion ('Recipes cannot be edited with this tool'), and explains how to locate the food_id ('Find the food_id with search_foods (source "Custom") or get_food_details'). It also offers a specific scenario for changing serving weight without re-entering nutrition. These are concrete when-to-use and when-not-to-use instructions.

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