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

Annotations only declare readOnlyHint=true; the description adds real behavioral context beyond that: totals are lower bounds when an item lacks nutrient data, and the response flags which items were affected. It also discloses that household measures are only available for curated foods. Return shape details are left to the output schema.

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

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

Three sentences, front-loaded with the core action, then input modes, then the caveat about lower bounds and defaults. Dense but every sentence carries information; the parenthetical example is slightly bulky but earns its place by clarifying household measures.

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, the description doesn't need to explain return values, and it still covers the one caveat an agent must know (lower-bound totals) plus input prerequisites. Nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the per-field docs (grams as edible portion, quantity defaulting to 1, household_measure examples) already carry the detail. The description adds only the either/or rule between grams and household_measure and the default nutrient set, both of which are also stated in the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Sum nutrients over a list of TACO foods') and immediately pins the scope: it aggregates over food ids, not looks them up. That distinguishes it cleanly from search_food (which supplies the ids) and get_nutrients (single-food 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?

Routes the agent to the two prerequisite tools by name ('ids from search_food', 'see convert_household_measure'), which is exactly the context needed before calling. It stops short of explicit exclusions, e.g. when to use compare_foods or get_nutrients instead of summing a meal.

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, so the safety profile is covered. The description adds real behavioral value beyond that: the per-100 g comparison basis and the explicit caveat that missing data surfaces as null or {"trace":true} and must not be ranked as lower — a data-interpretation rule an agent would otherwise get wrong.

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

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

Two compact sentences with the scope, basis, and the null-handling caveat front-loaded. Every clause carries information; nothing is 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?

With an output schema present, the description needn't explain return structure, and it covers the essential inputs, basis, and null semantics. Minor gaps remain: it doesn't say how invalid or out-of-range food ids are handled, nor whether results come back ordered or paginated.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the default nutrient set and the min/max bounds. The description largely restates the 2–10 range and adds only the per-100 g comparison basis, so the baseline of 3 applies.

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

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

States a specific verb (compare), resource (TACO foods), arity (2 to 10), selection dimension (chosen nutrients) and normalization basis (per 100 g edible portion). This clearly separates it from siblings like get_nutrients (single food detail) and calc_meal (aggregation), and it points to search_food as the id source.

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 establishes the entry condition (ids from search_food) and implies when the nutrients parameter can be left out via the schema default. It does not explicitly say when to prefer this over get_nutrients or calc_meal, so routing against every sibling is left partly to inference.

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

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

Beyond the readOnlyHint annotation, the description discloses important behavioral constraints: only some foods are covered, the mapping is hand-curated, it never guesses, ambiguity returns candidates, and uncovered cases are reported. These are exactly the edge-case behaviors an agent needs to know before calling.

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 purpose and coverage constraints, then ends with the key parameter routing. It is compact and every sentence contributes useful 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?

Given the output schema, full parameter descriptions, and readOnly annotation, the description supplies the remaining critical context: source table, coverage limits, ambiguity handling, and uncovered-case behavior. Nothing essential for correct invocation appears to be missing.

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

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

Schema description coverage is 100%, so the schema already defines food_id, measure, quantity, and food_query in detail. The description reinforces that food_id comes from search_food and gives measure examples, but it adds little beyond the structured 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 description uses a specific verb and resource: converting Brazilian household measures of TACO foods to grams. It also names the underlying source (IBGE POF) and scope, so an agent can distinguish this from search_food, get_nutrients, and other siblings without opening the schema.

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

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

It clearly states when this tool is appropriate and what to do before calling it by pointing to search_food for food_id. It also sets expectations for uncovered foods and ambiguous measures. It stops short of explicitly naming alternatives to use instead of this tool, but the practical usage context 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?

Annotations only declare readOnlyHint; the description supplies the genuinely non-obvious behaviors: sparse coverage (26 foods) and that missing data yields available:false with a list of foods that do have it — explicitly 'not zero'. That prevents the agent from misreading absence as a zero value, which is the highest-risk failure mode here.

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, no filler: the payload definition and the unit basis come first, the coverage caveat second. Every clause carries information the agent needs before calling.

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, return shape needn't be described, and the safety profile is covered by readOnlyHint. Purpose, units, id provenance and the sparse-data failure mode are all stated, so nothing material 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 coverage is 100%, so the schema already documents food_id provenance, the grams basis and the nutrients enum. The description's 'per 100 g or scaled to grams' and 'one TACO food by id' merely restate the schema's own 'omit for the table basis of 100 g' semantics rather than adding new detail.

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?

Names a specific verb+resource ('Amino acid profile ... of one TACO food by id') and scopes it with units ('per 100 g or scaled to grams'). The enumerated examples (lysine, leucine, tryptophan) plus the 'TACO food by id' framing separate it cleanly from get_nutrients, get_fatty_acids and calc_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 gives a real applicability condition — only 26 foods carry this data — which tells the agent when the call will succeed. However, it never names an alternative path (e.g. get_nutrients for the general case) or says what to do after receiving available:false, so the routing decision is left 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?

Beyond readOnlyHint=true, it discloses the partial-coverage behavior (423/597), the critical distinction that missing data yields available:false rather than zeros, and the sentinel encodings Tr = {"trace":true} and null for missing. These are exactly the traps that would cause an agent to misreport a food as zero-fat.

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 dense sentences, front-loaded with what is returned, then the caveat, then the encoding conventions. No filler and nothing repeated from the schema.

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?

An output schema exists, yet the description still supplies the return-value semantics an agent needs (trace vs null vs available:false). Combined with the complete parameter schema and readOnly annotation, nothing required to call it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3; the description adds value by clarifying the 100 g default basis versus gram-scaled output and by naming the nutrient groups (saturated, mono/poly, omega-3/6, EPA, DHA, trans, individual acids) that map to the `nutrients` filter keys.

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

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

States a specific resource (fatty acid profile of one TACO food) with the exact nutrient classes covered and the unit basis. It is unmistakable against siblings like get_amino_acids or get_nutrients, which cover different nutrient domains.

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?

Clear context: one food, looked up by id, with an explicit caveat that only 423 of 597 foods have the profile and that others return available:false. It does not explicitly route the agent to an alternative tool for foods lacking data, but the coverage caveat is the decision-relevant 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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower, and the description adds real value on top: missing nutrients come back as null or {"trace":true} and never as 0. That distinction materially changes how an agent interprets results and is not in the schema or 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 dense sentence with the resource and identifier front-loaded, followed by two qualifying clauses. No wasted words, though the missing-data clause is compressed to the point of being terse.

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, return structure needn't be explained, and all three parameters are documented in the schema. The description covers scaling basis and null/trace semantics, leaving only minor gaps such as behavior on an invalid or unknown food_id.

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%, making 3 the baseline, but the description adds meaning beyond it by stating the default basis (100 g) and the scaling behavior for the grams parameter, plus the provenance of food_id. The nutrients array is left entirely to 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?

States a specific verb and resource ("Full composition of one TACO food by id") with clear scope: one food, full nutrient table. "Full composition" implicitly contrasts with the partial-output siblings get_fatty_acids and get_amino_acids, though it never names them.

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 parenthetical "(from search_food)" establishes the prerequisite lookup chain, which is genuine usage guidance. However, it gives no when-not-to-use condition and does not mention the sibling tools that return subsets of the same data.

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

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

Annotations declare readOnlyHint=true, so the safety profile is already covered, and the description is consistent with it (a pure health check). It adds value by naming the exact payload contents, though it doesn't say whether the echo parameter is optional or how the response is shaped — a small gap for a trivial tool.

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, purpose first, then return contents. No filler and nothing an agent must scroll past to find the point.

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?

An output schema exists, so the description needn't enumerate return values — and it briefly does anyway. For a zero-required-parameter health check with full schema coverage and readOnly annotations, this is nearly everything needed; only explicit triggering guidance is missing.

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

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

Schema description coverage is 100% for the single optional `echo` parameter, so the schema already explains it and the description adds nothing. Baseline 3 applies — the description neither compensates nor conflicts.

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

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

States a specific verb+resource ("Health check for the taco-br server") and specifies exactly what comes back (server name, version, data source citation). This is unmistakably distinct from every sibling, which are all food/nutrient query tools.

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

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

The description implies usage (a ping/liveness probe) but never says when an agent should call it — e.g. connectivity checks, version verification, or troubleshooting before a failed query. No alternatives or exclusion conditions are named, which is less critical here since no sibling competes for this purpose.

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 only declare readOnlyHint=true, and the description is consistent while adding real behavioral context: accent-insensitivity, typo tolerance, regional-name aliasing (aipim, macaxeira, mandioquinha), and the form of the returned identifiers. The dataset's known gaps are disclosed, though nothing is said about ordering or relevance 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?

Three sentences, front-loaded with the corpus and language, then retrieval behavior, then the handoff to get_nutrients. Every clause contributes information an agent needs.

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?

An output schema exists, so no return-value exposition is needed, and the description still identifies the key return artifact (ids) and the corpus's language and unit basis. Enough context is present for correct invocation and correct interpretation of results.

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

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

Schema coverage is 100%, so both query and limit are already documented in the schema. The description reinforces the Portuguese-name constraint and enumerates regional synonyms, but adds no syntax or format detail beyond what the schema states; baseline 3 applies.

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

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

States a specific verb and resource ('Find foods in the Brazilian TACO table') plus scope detail (597 items, per 100 g, Portuguese names) that separates it from get_nutrients and calc_meal. An agent knows exactly what corpus this searches and in what language.

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?

Names the downstream tool explicitly ('Returns ids to use with get_nutrients') and gives a coverage caveat ('Restaurant dishes and brands are mostly absent') that tells the agent when this lookup will fail. It stops short of naming an alternative to use instead when coverage is missing, so usage is clear but exclusions aren't fully routed.

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