Skip to main content
Glama

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

platepal_get_food_nutrition
Read-onlyIdempotent

Plate Pal. 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.1/5.0
Behavior5/5

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

The description adds substantial behavioral detail beyond the annotations: data-source selection, chain item handling, region-specific figures, null behavior when chain weights are unpublished, whole-meal aggregation, and return fields including traffic lights and caffeine. It is consistent with readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false.

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 long but front-loaded with the core purpose and then organized by data source and return behavior. The numerous examples are useful for an agent, though the text could be trimmed without losing essential guidance.

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?

Given no output schema and a read-only annotation profile, the description is complete enough for correct invocation and interpretation. It describes the return shape, edge cases, region handling, meal totals, and null-value behavior in detail.

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?

Schema description coverage is 100%, so the schema already documents q, grams, country, and servings. The description reinforces how q can carry amounts and that grams or servings can be supplied separately, but it adds little semantic detail beyond what the schema already provides.

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: fetching calories and macros for a food, dish or product for a user-specified amount. It is clear about scope (natural-language food/meal queries, generic foods, brands, chain items), but it does not explicitly name or distinguish the sibling platepal_get_barcode_nutrition alternative.

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 gives many usage examples and explains when different data sources apply (USDA, Open Food Facts, chain-published figures, fallback for missing chain items). However, it does not explicitly state when not to use this tool or direct users to the barcode-based sibling.

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.