Skip to main content
Glama

Rank foods by a nutrient

nutrient_ranking
Read-onlyIdempotent

Ranks whole plant foods by the amount of one nutrient per 100 g of edible portion, optionally within one food category. Each row of results gives the value per 100 g, the number of sources behind it and, where heathy.org holds a typical serving for the food, that serving and the amount in it; the order is per 100 g. Foods eaten a few grams at a time (dried herbs, spices, tea leaves, and dried seaweed, mushrooms and vegetables) are not ranked in results. They are reported beside it in also_higher.small_amounts: a count of those holding more per 100 g than the last row, and the first five. They are ranked in results when include_small_amounts is true, and when the category filter selects mostly such foods ("spice", "tea", "seaweed"). With min_sources above 1, foods measured by fewer sources are reported in also_higher.fewer_sources in the same way. A nutrient that reads 0 on every food returns an explanation in all_zero and no ranking.

Input Schema

NameRequiredDescriptionDefault
limitNoMax results, 1–100. Default 20.
categoryNoOptional substring filter on the food category — e.g. "fruit", "legume", "millet".
nutrientYesNutrient slug or name — e.g. "iron", "vitamin-c", "folate".
min_sourcesNoSmallest number of sources behind a value for its food to be ranked in results (1–32). Default 1. Above 1, foods measured by fewer sources are counted in also_higher.fewer_sources.
include_small_amountsNotrue ranks the foods eaten a few grams at a time (dried herbs, spices, tea leaves, dried seaweed, mushrooms and vegetables) in results with every other food. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / include_small_amounts
      Added value: +{
      +  "description": "true ranks the foods eaten a few grams at a time (dried herbs, spices, tea leaves, dried seaweed, mushrooms and vegetables) in results with every other food. Default false.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / min_sources / description
      Previous value: -"Only include values backed by at least this many datasets (1–32). Default 1; use 2+ to drop single-source values."New value: +"Smallest number of sources behind a value for its food to be ranked in results (1–32). Default 1. Above 1, foods measured by fewer sources are counted in also_higher.fewer_sources."
  2. Changed1 schema field changed
    • changedInput schema / properties / min_sources / description
      Previous value: -"Only include values backed by at least this many datasets (1–31). Default 1; use 2+ to drop single-source values."New value: +"Only include values backed by at least this many datasets (1–32). Default 1; use 2+ to drop single-source values."
  3. Changed1 schema field changed
    • changedInput schema / properties / min_sources / description
      Previous value: -"Only include values backed by at least this many datasets (1–11). Default 1."New value: +"Only include values backed by at least this many datasets (1–31). Default 1; use 2+ to drop single-source values."
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover only the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it explains the content of each results row, the per-100 g ordering, the exclusion of small-amount foods, the also_higher.small_amounts and also_higher.fewer_sources side channels, and the all_zero no-ranking case. This is rich behavioral disclosure.

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

Conciseness5/5

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

The core purpose is front-loaded in the first clause, then each subsequent sentence covers one distinct behavior (row contents, exclusions, side channels, zero case) with no filler.

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

Completeness5/5

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

With no output schema, the description carries the full burden of describing return values, and it does so completely: results row semantics, ordering basis, the also_higher sub-objects, and the all_zero fallback are all covered.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains how include_small_amounts and min_sources reroute values into side channels and notes that category filters selecting mostly small-amount foods ('spice', 'tea', 'seaweed') change ranking behavior. That detail is not in the schema.

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

Purpose5/5

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

States a precise verb and resource: 'Ranks whole plant foods by the amount of one nutrient per 100 g of edible portion,' with the optional category narrowing stated up front. This is clearly distinguishable from siblings like search_foods or lookup_food, which retrieve rather than rank.

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?

The scope ('whole plant foods,' per 100 g, optional category) gives strong context for when this tool applies, and the small-amount exclusion/reporting behavior clarifies edge cases. It never names an alternative sibling or states explicitly when to reach for this over search_foods, so it stops short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.