Skip to main content
Glama

Plate Pal

by io.github.GoodTurnStudio
OverviewDiscussionsAdmin

Calories and macros for a food, dish or product, for the amount the user says

get_food_nutrition
Read-onlyIdempotent

Calories and macros for a food, dish or product, for the amount the user says. For requests like "how many calories in a Big Mac?", "protein in 200g chicken breast", "calories in chicken biryani", "a slice of pepperoni pizza", "a large latte" or a whole meal like "2 eggs, 2 slices of toast and a coffee". Takes the whole amount and food in q, or grams or servings separately. Generic foods and dishes (thousands, including fast food and restaurant dishes) use USDA values with real portion weights (slice, cup, small, medium, large, one item); brands come from Open Food Facts. Chain items ("McDonald's large fries", "a Greggs sausage roll", "KFC Zinger burger", "grande latte from Starbucks", "6 inch Italian BMT from Subway", "20 piece McNuggets") use the chain's own published figures for that size, UK or US by country, and return a chain object (name, region, item, size, weight_published); when the chain doesn't publish a weight, amount.grams is null and per_100 values are null. For a chain item not in the table, a typical USDA version is used and the say line says so. A whole meal returns items (each food with its amount and nutrition) and total. Returns nutrition for the amount, per_100 values, portions, UK traffic lights (per 100 g, or per 100 ml for drinks) and caffeine_mg for drinks that have it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesThe food or meal, optionally with amounts, for example 200g chicken breast, a large banana, or 2 eggs and a slice of toast.
gramsNoAmount in grams (1 to 5000). Overrides any amount in q.
countryNoTwo-letter country code. Picks UK or US chain figures (GB and IE get UK ones) and prefers local versions of branded products. Default from the request.
servingsNoNumber of servings or items (0.25 to 20).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare the read-only/idempotent/open-world profile, and the description adds substantial behavior beyond that: data provenance (USDA, Open Food Facts, chain-published figures), region selection (UK vs US by country), explicit fallback to a typical USDA version for unknown chain items, and the null-return contract when a chain publishes no weight. This is exactly the kind of context structured fields cannot carry.

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

Conciseness3/5

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

Purpose is front-loaded in the first sentence, which is good, but the remainder is a single dense block that enumerates many chain examples and edge cases at length. Much of the enumeration repeats the same pattern and could be trimmed without losing information.

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 return-value burden itself and does so: per-amount nutrition, per_100 values, portions, UK traffic lights, caffeine_mg for drinks, a chain object with named fields, and items+total for meals. An agent has everything needed to call and interpret the result.

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: q may hold a whole meal with quantities, grams/servings may be supplied separately, and country drives which chain figures (GB/IE -> UK) are used. It goes modestly beyond the schema text without fully restating it.

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?

States a specific verb+resource (calories/macros for a named food, dish or product) and scopes it to the amount the user gives, with concrete example inputs. It clearly implies a name-based lookup distinct from a barcode lookup, but it never names the siblings get_barcode_nutrition or get_meal_ideas to draw the boundary explicitly.

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?

Rich worked examples establish when the tool applies (single foods, sized portions, chain items, whole meals) and it describes how q vs grams vs servings are combined and overridden. It lacks explicit when-not guidance and any routing to the two sibling tools, so the alternative-selection condition is left implicit.

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

All Plate Pal toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources