Skip to main content
Glama

foodbe_cart_breakdown

Read-only

Analyzes a grocery list, cart, order, menu or recipe. Call this when a user asks you to analyze one. Send up to 50 ingredient names in items. For the whole list it returns the health effects, the total carbon and water, the food group balance with foods to add, the flavor and texture it carries with the missing ones, and the diets it suits. It also returns swaps that keep flavor and texture. The chefy_read field gives each food its cooking method, a substitute if you run out, and its pairings. A closing note names the list's biggest gap with its carbon and water. Every value comes from Foodbe's stored, human-approved data, never from a model, so the same list always returns the same result. Names Foodbe does not have are listed in not_found. Send diet and allergies to get diet_check, which lists the foods that break the diet or hold an allergen. A food with no stored diet or allergen data is marked unknown, never safe. Send grams, a map of food name to grams, to get impact_for_quantities, the carbon and water for the amounts bought. Without grams, environmental_impact is for 1 kg of each food.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "items": "<items>"
    },
    "name": "foodbe_cart_breakdown"
  }
}

Input Schema

NameRequiredDescriptionDefault
dietNoOptional. The diet the cart must suit, such as vegan or gluten-free.
gramsNoOptional. A map of food name, as sent in items, to grams bought.
itemsYesThe ingredient names in the cart, up to 50.
allergiesNoOptional. Allergens the cart must not hold.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / allergies
      Added value: +{
      +  "description": "Optional. Allergens the cart must not hold.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / diet
      Added value: +{
      +  "description": "Optional. The diet the cart must suit, such as vegan or gluten-free.",
      +  "type": "string"
      +}
    • addedInput schema / properties / grams
      Added value: +{
      +  "additionalProperties": {
      +    "type": "number"
      +  },
      +  "description": "Optional. A map of food name, as sent in items, to grams bought.",
      +  "type": "object"
      +}
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

Adds substantial context beyond the readOnly/openWorld annotations: results are deterministic and come from stored human-approved data, missing names land in not_found, foods lacking diet/allergen data are marked 'unknown, never safe,' and the 50-item cap is stated. These are exactly the edge-case behaviors an agent needs before calling.

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?

Front-loads the purpose and item limit, then moves through outputs, the chefy_read field, the closing note, data provenance, and edge cases. It is long, but with no output schema most of that length is load-bearing; a few return-value sentences could be tightened.

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?

For a tool with four parameters, no output schema, and a wide return surface, the description covers the outputs (health, carbon/water, food group balance, flavor/texture, diets, swaps, chefy_read, closing gap note), the not_found and unknown cases, and quantity semantics. Nothing essential is left for the agent to guess.

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 already 100%, but the description adds real meaning: grams is a name-to-grams map that switches the output from per-1kg to purchased-quantity impacts, and diet/allergies drive diet_check with an explicit 'unknown never safe' fallback. That is more than the schema descriptions alone convey.

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?

Opens with a specific verb and resource: 'Analyzes a grocery list, cart, order, menu or recipe,' and the scope (up to 50 ingredient names) is concrete. It doesn't explicitly contrast itself with siblings like foodbe_compare or foodbe_ingredient, so an agent must infer the boundary from the word 'analyze' rather than being told.

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?

Gives a clear trigger ('Call this when a user asks you to analyze one') plus conditional guidance for optional parameters: send diet/allergies to get diet_check, send grams to get impact_for_quantities, omit grams for per-1kg impact. No explicit when-not or named alternative for non-analytic lookups, which keeps it 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.

Resources