KABO Indian Nutrition Index

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

Annotations already cover read-only, idempotent, closed-world, non-destructive, so "Read-only" earns no credit. What does add value is the partial-failure contract: unmatched names land in not_found while the remaining foods are still compared, and an unsupported nutrient fails with an error naming valid ones. That is real behavior an agent must plan around; only the response shape (per-100 g headline plus "other rows") stays loosely specified.

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, correctly front-loaded with the core action followed by routing, safety, and error semantics. Minor waste: "Read-only" repeats annotations and the parenthetical nutrient list repeats the enum, though the parenthetical does aid scanning.

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

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

There is no output schema, so the description carries the burden of describing returns and does so (headline value per 100 g, other rows, source URL). Combined with the partial-match and invalid-nutrient behavior, an agent has everything needed to call this correctly and interpret the result.

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

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

Schema description coverage is 100%, and the description largely restates it: the nutrient list duplicates the enum, the 2-8 bound duplicates minItems/maxItems, and the not_found behavior for unknown names is already in the foods parameter description. Baseline 3 is correct because the schema, not the prose, carries parameter meaning.

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 ("Compare 2-8 Indian foods side by side on a single nutrient") with tight scope: 2-8 items, one nutrient, per-100 g basis. It also names the sibling it is not ("use lookup_food for one food in depth"), so an agent can choose between them without opening either 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?

Gives an explicit trigger ("which has more protein/iron/fibre") and an explicit alternative with its own condition (lookup_food for single-food depth). The when-not case is covered by naming the sibling rather than leaving it 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?

Annotations already declare readOnly/idempotent/non-destructive, so 'Read-only' is redundant. The description does add genuinely new context: prices are 'live' (fetched at call time, may fluctuate) and results are broken out 'for every pack size', which tells the agent what shape of answer to expect. It stops short of describing ordering or how many rows come back.

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

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

Three short sentences, front-loaded with the verb and compared fields, then the parameter mode, then the safety note. Nothing padded or ambiguous.

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 no output schema, the description usefully names the compared fields and the per-pack-size granularity, which is what an agent needs to decide whether to call it. Minor gaps remain around matching behavior for product names and result ordering.

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

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

Schema description coverage is 100% and already states 'Omit to compare all', so the description's 'Omit products to compare the whole range' repeats structured data. It adds no format hints (e.g. fuzzy vs. exact name matching) beyond what the schema provides; 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+resource ('Compare KABO products side by side') and enumerates the compared attributes (serving size, protein, calories, live price per serving, per pack size). It does not, however, differentiate itself from the sibling 'compare_foods', which an agent could easily confuse with this tool.

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

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

'Omit products to compare the whole range' gives clear guidance for the optional parameter's two modes. But there is no when-to-use vs. alternatives guidance — nothing says when to pick this over compare_foods or get_product when only one product is of interest.

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 covered. The description adds useful behavior beyond that: it discloses live price and stock, cart link or checkout profile, and explicitly says it never places orders.

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 dense but front-loaded sentence that leads with the core purpose and then enumerates return contents. Most clauses earn their place by describing what the agent will receive, though the sentence is long and semicolon-heavy.

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

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

There is no output schema, so the description carries the burden of explaining return values, and it does so thoroughly: nutrition, composition, dietary suitability, live price and stock, price per serving, and cart/checkout link. Combined with annotations covering safety and idempotency, an agent has enough context to call it correctly.

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

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

There is one parameter with 100% schema description coverage, and the schema already explains that it accepts a product name or handle with examples. The description adds no syntax or selection guidance beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: "Get one KABO product in full." It also scopes the result to a single product, which implicitly separates it from list_products and compare_products, and it names the exact fields 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 phrase "Get one KABO product in full" implies the tool is for detailed single-product lookup, but it does not explicitly state when to use this versus siblings such as list_products, compare_products, or lookup_food. No alternatives or exclusions 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the trailing 'Read-only, no side effects' is largely redundant. The description does add genuine behavioral context beyond the annotations: the data source ('from each product's own nutrition panel') and the intended two-step workflow with get_product.

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

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

Front-loaded with the resource and its payload, then the workflow, then the safety note, so the most important information comes first. Slightly wasteful because the final 'Read-only, no side effects' clause restates annotations and the parentheses around '(each flavour)' add little, but overall it is tight.

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, and the description compensates by naming the returned fields (protein, calories, fibre, vitamin count, rating, URL) and the per-flavour granularity. Combined with the zero-parameter schema and full annotation coverage, an agent has everything needed to call it and interpret the result.

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 takes no parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description does clarify the granularity of results (one entry per flavour), which is the only semantic detail that could otherwise be ambiguous.

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?

Specific verb plus resource ('List KABO's own nutrition shakes (each flavour)') and it enumerates exactly what each row carries: protein, calories, fibre, vitamin count, rating and URL. It is clearly distinguishable from get_product, which supplies price/stock/cart link instead.

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

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

Explicit sequencing is given: 'Use first to see what KABO sells; then call get_product for price, stock and a cart link.' This names the alternative and the condition that selects it, so no inference is required.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds genuinely new traits: the not-found fallback (found=false plus the list of available foods instead of an error) and that each value ships with a source article URL for citation. Both materially change how an agent handles a miss. It stops short of describing output shape beyond those fields.

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

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

Front-loaded with the action and resource, then coverage, then sibling routing, then the fallback behavior — a sensible order with no repeated content. It is a dense single paragraph, but nearly every clause carries a fact 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?

With no output schema present, the description still conveys return content (four nutrients, per-100g and per-serving values, source URLs) and the miss path (found=false with available foods). Combined with clean annotations and a fully documented 2-parameter schema, an agent has everything needed to call and interpret it.

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%, including the enum for nutrient and an example-laden description for food, so the schema already carries parameter meaning. The description adds only the per-100g vs per-katori framing, which is output-side rather than input-side nuance, so the 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?

Specific verb ('Get nutrition facts') plus a precisely scoped resource ('ONE Indian food'), with the nutrient set and per-100g/per-katori breakdown named. It also names the coverage corpus (60 foods, ICMR-NIN tables), so an agent can tell exactly what domain this serves.

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 routes the agent: 'Use compare_foods for several foods at once, search_guides for topics rather than single foods.' Both the when and the when-not are stated with named siblings, leaving nothing 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?

Annotations already cover read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds meaningful context beyond annotations: prices are approximate typical retail values rather than live quotes, and the ranking is predetermined so whole foods appear cheaper than all powders including KABO's.

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

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

Front-loaded with the core action, units, and ordering, followed by a usage example and an important price caveat. The KABO's clause is somewhat promotional and arguably expendable, but the description remains compact and readable.

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 one-parameter ranking tool with no output schema and full annotation coverage, the description provides the metric, source scope, ordering, inclusion list, and price caveat. A brief note on the return shape or budget filtering would make it fully self-contained.

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 single optional budget_inr parameter has 100% schema description coverage, including its ceiling semantics. The description adds no parameter-specific information, which is acceptable given the schema fully documents it.

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

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

States a specific verb and resource — rank protein sources by cost in rupees per 10 g of protein, cheapest first — and enumerates the included sources. This is clear enough to distinguish from lookup_food or compare_foods, but it never names or contrasts those siblings explicitly.

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

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

Gives one concrete usage context: answer 'cheapest way to get protein in India'. It does not say when not to use it, nor does it route the agent to compare_foods, lookup_food, or protein_target for related questions.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond annotations: it is a pure calculation, returns an error if weight_kg is missing or invalid, and includes a medical-advice disclaimer.

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 dense but front-loaded with the core purpose, then adds standards, range context, and caveats. It is appropriately sized for a calculator tool, though the long single sentence is packed with clauses.

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 no output schema, the description still explains what the tool returns: grams, ranges for training/weight loss/pregnancy/breastfeeding, per-meal threshold, age guide link, and error behavior. It also covers safety and medical limitations, leaving little an agent needs to infer.

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 three parameters. The description reinforces that the calculation comes from body weight and that age affects guidance, but it adds little semantic detail beyond what the schema provides.

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

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

The description states a specific verb and resource: calculate a person's daily protein target in grams from body weight. It also names the standards and outputs, making it clearly distinct from siblings like protein_cost, lookup_food, and compare_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?

It gives implied usage contexts (training, weight loss, pregnancy, older adults) and a clear medical caveat for kidney disease, but it does not explicitly state when to use this tool versus alternatives such as protein_cost or search_guides.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results are ranked by word overlap with the title, and an empty list means no guide matched, plus it states the return payload is titles and URLs to cite. It stops short of latency/rate-limit detail, but with full annotation coverage that is a minor omission.

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

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

Front-loaded with the core verb, corpus size and domain, then the return format, then the disambiguation, then the ranking semantics. The parenthetical topic list is the only dense passage, and it earns its place by telling the retriever what kinds of questions will match.

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?

No output schema exists, so the description correctly compensates by stating what comes back (titles and URLs to cite). Both parameters are fully covered by the schema, required/optional status is clear, and the corpus scope is bounded (kabo.co.in only), giving an agent everything needed to call it correctly.

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

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

Schema coverage is 100% with per-parameter descriptions and numeric bounds on limit, so the schema does the heavy lifting. The description still adds value by revealing that 'query' is interpreted as keywords matched against titles rather than semantic search, which shapes how an agent should phrase the query.

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 (keyword search) over a specific, quantified resource (1,308 Indian nutrition guides on kabo.co.in), lists the topical coverage, and states the return shape (titles and URLs to cite). It is unmistakably distinct from lookup_food and the product-comparison 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?

Gives a concrete triggering example ('vitamin D deficiency in vegetarians') and an explicit exclusion routing to lookup_food for a single food's values. The only gap is that it does not distinguish itself from compare_foods or protein_target, though those cover clearly different intents.

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