Skip to main content
Glama
Asquarer02
by Asquarer02

calculate_macros

Calculate exact macros and calories for a specified food portion. Provide food name, amount, and unit to get protein, carbs, fat, and calorie values from USDA data.

Instructions

Calculate exact macros and calories for a specific portion of one food.

All arithmetic happens in Python. Do not compute these numbers yourself.

Args: name: The food name. Resolved the same way as get_food. amount: How much of the food, as a number, e.g. 150 or 2.5. unit: The unit amount is expressed in, e.g. "g", "oz", "cup", "tbsp". Case-insensitive and plural-tolerant ("grams" and "Gram" both work).

    The unit is converted to the food's native unit when both belong to the
    same family: mass (g, kg, oz, lb) or volume (ml, tsp, tbsp, fl_oz,
    quarter_cup, cup). Conversion is REFUSED across families -- grams to
    tablespoons needs a density this database does not store -- and refused
    for countable units ("large", "slice", "container", "scoop", "half",
    "cake", "medium"), which have no fixed mass.

Returns: {"food", "amount", "unit", "protein_g", "carb_g", "fat_g", "calories", ...} with calories derived as protein4 + carb4 + fat*9.

On an unknown food: {"error": "food_not_found", "suggestions": [...]}.
On an impossible conversion: {"error": "unit_mismatch", "native_unit": ...}
naming the unit the food is actually stored in -- retry with that unit.
Negative amounts return {"error": "invalid_amount"}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
unitYes
amountYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains internal behavior: arithmetic in Python, unit conversion rules and refusals (cross-family, countable units), calorie derivation formula, and exact error outputs (food_not_found, unit_mismatch, invalid_amount). The negative-amount behavior is also disclosed. This is exemplary transparency.

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 description is long but tightly structured with Args and Returns sections. Every sentence earns its place: the arithmetic warning, parameter details, conversion rules, return structure, and error handling are all necessary for correct use. No fluff or redundancy. Front-loaded with the core purpose.

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 calculation tool with three parameters and no annotations, the description is fully complete. It covers all inputs, outputs (including sample response), edge cases (unknown food, impossible conversion, negative amounts), and the internal calorie formula. Even without an output schema shown, the example return structure provides clarity.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must fully compensate. It does: name is defined as resolved like get_food, amount is described as a number with examples, and unit is extensively explained including case-insensitivity, plural tolerance, and conversion rules. Every parameter gets detailed semantics well beyond the bare 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?

The description opens with a specific verb and resource: 'Calculate exact macros and calories for a specific portion of one food.' This clearly distinguishes it from siblings like get_food (which looks up food info) and build_meal (which assembles meals). The purpose is unmistakable.

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 description does not explicitly say 'when not to use' or compare against alternatives, but it provides strong contextual guidance: 'All arithmetic happens in Python. Do not compute these numbers yourself' implies this is the tool for macro calculations. It also references sibling get_food for name resolution, establishing a relationship. Clear enough, though exclusions are not spelled out.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Asquarer02/usda-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server