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

The annotations already indicate a safe, read-only, idempotent operation. The description adds meaningful behavioral context beyond that: results are computed from stored values as-is, and cooking losses are not modelled when raw ingredients are passed. This is exactly the kind of caveat that helps an agent reason about correctness.

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

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

Three sentences with no redundancy. The first sentence states the main purpose and input, the second the return structure, and the third an important limitation. All information is front-loaded and 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 read-only calculation tool with a fully described schema, the description covers the essentials: purpose, input format, output shape, and a key modelling limitation. Since there is no output schema, the explicit mention of returned totals, per-serving, and per-100g values is valuable. It could be slightly more explicit about how servings affect results, but overall it is complete.

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

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

All four parameters are fully described in the schema, so the baseline is 3. The description adds general context about food numbers and gram amounts but does not need to repeat parameter-level details. It does not meaningfully enhance the schema's 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 ('calculate'), names the resource ('nutrition of a recipe or meal'), and specifies the input type ('food numbers and gram amounts'). It also states the output forms (totals, per serving, per 100 g), which clearly separates it from food-search siblings.

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

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

The description gives clear context for when to use the tool: when calculating recipe/meal nutrition from food numbers and gram amounts. However, it does not explicitly contrast it with siblings such as get_food or compare_foods, so the guidance is clear but lacks explicit exclusions 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 establish read-only, idempotent, and open-world behavior. The description adds meaningful context not in the annotations: the comparison is per 100 g, uses a fixed nutrient set by default, and supports 2–6 foods. This is sufficient supplemental behavioral disclosure for 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 no redundancy. The primary action and constraints are front-loaded, and the default set is compactly listed. 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 read-only comparison tool with fully described parameters and a default nutrient set, the description covers the essential context an agent needs. No output schema exists, but the tool's return is straightforward, and no critical behavior like error handling or authentication is needed given the read-only annotations.

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?

Input schema covers all parameters with descriptions, so the bar is met by the schema itself. The description adds the default nutrient set and per-100 g basis, which enriches the 'nutrients' parameter's meaning, but it does not explain parameter syntax or relationships beyond what the schema already states.

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

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

The description clearly identifies the action (compare), the resource (foods), and the scope (2-6 foods, same nutrients per 100 g). It also lists the default nutrient set, which sets it apart from sibling tools like get_food and search_foods, whose purposes are singular retrieval or search.

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 the tool—when a side-by-side comparison of foods is desired—but it does not explicitly state when not to use it or point to alternatives like get_food for a single food's data. The usage guidance is present but not fully 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 declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral detail about the returned nutrition summary and optional sections, which goes beyond the annotations without contradicting them.

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

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

The description is a single informative sentence with the key action front-loaded. It lists necessary return fields without unnecessary elaboration or repetition of schema details.

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, but the description sufficiently explains the return content, including the nutrient list and optional included sections. Combined with the fully documented input schema and annotations, an agent has enough context to call the tool correctly.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description adds little about parameter semantics beyond mentioning optional sections, but it doesn't need to compensate for missing schema 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 states a specific action ('Get one food by number') and a precise resource, then enumerates the exact fields returned. This makes it easy to distinguish from siblings like search_foods, compare_foods, and calculate_recipe_nutrition.

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 makes the usage context clear: it is for retrieving a single food when a food number is already known, with optional extended sections. It does not explicitly name alternatives or exclusion conditions, but the 'one food by number' framing is enough to guide selection.

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

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

Annotations already cover read-only/idempotent safety. The description adds two behavioral details: the default return set ('all ~60 nutrients') and how unknown filter terms are handled ('listed in unmatched'). This gives an agent foresight into failure modes and response shape without repetition.

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, zero waste. Purpose is front-loaded, followed by default behavioral scope, then the edge case. Every word 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 single-food nutrient query, the description covers the main behavior, the scaling (per 100 g), default nutrient set, and the unmatched-field edge case. Since there is no output schema, a little more return-structure detail would help, but the essential context is present and adequate.

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

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

Schema description coverage is 100%, so the baseline is 3. The description only lightly references the nutrients filter and adds no syntax or code details beyond what the schema already provides. No extra semantic 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?

States a specific verb and resource: 'Get nutrient values per 100 g for one food.' The 'one food' scope differentiates it from compare_foods and calculate_recipe_nutrition, and the 'per 100 g' detail adds precision. An agent can tell it apart from siblings without opening schemas.

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

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

The description implies a clear use case (single food nutrient lookup) but never explicitly names alternatives or conditions for when to use those instead. No mention of search_foods as a prerequisite or compare_foods for multiple items. Usage is inferred, not directed.

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, so the safety profile is covered. The description adds meaningful behavioral details beyond annotations: exact multi-word matching ('All words must appear'), ranking, pagination, and next_cursor behavior. It does not detail the exact response shape, but for a search tool the description is sufficiently transparent.

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

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

Three tight sentences cover purpose, output, matching behavior, and pagination with no filler. The most important facts are front-loaded: what the tool searches and what it returns.

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 search tool with no output schemaanding, the description covers what it searches, how matching works, what it returns, and how pagination works. The remaining parameter details (limit, language, type) are fully covered by the schema, so nothing essential 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 100%, so the schema already documents all five parameters. The description adds value by clarifying query semantics ('All words in the query must appear in the name') and the pagination contract tied to cursor ('include next_cursor when more matches exist'). This goes beyond simply restating 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 names a specific verb ('Search'), resource ('Swedish Food Agency's food composition database'), and method ('by name'), and states the key output ('food numbers to use with the other tools'). This clearly distinguishes search_foods from sibling tools like get_food or get_nutrients, which operate on already-known foods.

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 primary use case: find food numbers first, then use them with the other tools. It also gives important search behavior ('All words in the query must appear in the name') and pagination semantics. It does not explicitly name alternatives or exclusions, but the 'use with the other tools' statement provides clear context.

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