nutrition-mcp

Overview Schema Source Related Servers Discussions Admin

find_foods

Read-onlyIdempotent

Rank Indian dishes and ingredients by a chosen nutrient or glycemic load per 100 kcal, 100 g, or serving, and filter by diet, region, and dish/ingredient to find high-protein or iron-rich options.

Instructions

Rank foods by one nutrient or by glycemic load, per 100 kcal, per 100 g or per serving (dishes only), for questions such as high-protein vegetarian dishes or iron-rich foods. Highest first, except lowest first for kcal, sugars, saturated fat, sodium and glycemic load; order says which. Foods with no value for the ranked nutrient are left out and counted in skipped_missing, and so is a dish with an incomplete value for the ranked nutrient. Per 100 g or per 100 kcal, seasonings, fats and salt can top a ranking though nobody eats 100 g of them; kind="dish" or per="serving" ranks foods eaten as a portion. Values are rounded to 2 decimals, so 0.0 can be a small amount.

Input Schema

Name	Required	Description	Default
`per`	No		100kcal
`diet`	No	Keep foods suitable for this diet: veg includes vegan.
`kind`	No	Keep only dishes or only ingredients.
`limit`	No
`region`	No	Keep dishes from this region. Ingredients have none, so leave it out with kind=ingredient.
`rank_by`	Yes

Output Schema

Name	Required	Description	Default
`per`	Yes
`order`	Yes
`rank_by`	Yes
`results`	Yes
`skipped_missing`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Beyond the read-only/idempotent annotations, the description discloses meaningful behavior: default sort direction, nutrient-specific exceptions, omission of missing values into skipped_missing, and rounding to 2 decimals. The reference to an `order` field that is not present in the schema is a notable transparency flaw, but the overall behavioral disclosure is strong.

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

Conciseness4/5

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

The description is dense but front-loaded with the core ranking behavior and then adds operational caveats. It is not bloated, though the reference to a nonexistent `order` parameter and the long run-on caveat sentence reduce structural crispness.

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

Completeness4/5

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

For a six-parameter ranking tool with an output schema, the description covers the core ranking semantics, missing-value handling, units, rounding, and a practical caveat about misleading top results. It is nearly complete, but the mention of `order` without a corresponding schema field and the absence of guidance on limit/region leave small gaps.

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

Parameters3/5

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

The description adds useful meaning for rank_by, per, kind, and diet-related filtering, including caveats about per-100 g and per-100 kcal rankings. However, it leaves limit and region unaddressed and misleadingly refers to an `order` parameter that does not exist in the input schema.

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

Purpose4/5

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

The description states a specific verb and resource: ranking foods by one nutrient or glycemic load, with units and example questions. It is clearly distinguishable from generic search/get tools, but it does not explicitly name the sibling tools or contrast itself with them.

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

Usage Guidelines4/5

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

It provides clear usage context through example questions such as high-protein vegetarian dishes and iron-rich foods, plus practical guidance to use kind="dish" or per="serving" when ranking portions. It does not offer explicit when-not conditions or direct alternatives among the sibling tools.

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

Deploy Server