Recipe Macros Without a Spreadsheet
Published August 20, 2026
The spreadsheet version of this is familiar to anyone who has tried. One row per ingredient, a per-100 g lookup pasted in from somewhere, a gram column, four formula columns, a divide-by-servings at the bottom. It works. It takes twenty minutes and you will not do it twice.
calculate_recipe is that spreadsheet as one tool call. Up to 40 ingredients as {food_id, grams} pairs plus a serving count, returning totals and the per-serving split.
The tool is the easy part. The two things that make recipe macros wrong are not arithmetic problems, and no tool fixes them for you.
The call
Ingredients have to be resolved first, because the tool takes ids and ids come from search_foods. So a recipe is a search per ingredient, then one recipe call:
You: Total this for four servings: 400 g dry red lentils, 800 g chopped tinned tomatoes, 200 g onion, 60 g olive oil, 20 g ginger, spices. Search each ingredient first.
{
"ingredients": [
{ "food_id": "<lentils, dry>", "grams": 400 },
{ "food_id": "<chopped tomatoes>", "grams": 800 },
{ "food_id": "<onion>", "grams": 200 },
{ "food_id": "<olive oil>", "grams": 60 }
],
"servings": 4
}
Out comes the total and the per-serving figures. The spices are a rounding error and dropping them is fine. The oil is not.
Once it is totalled, save it. Put the per-serving row in your profile file with the ingredient list, and the next four times you eat it the log entry costs no tool calls at all:
## Recipes (per serving)
- Red lentil dahl (4 servings): 512 kcal, 22 g P, 17 g F, 66 g C
That is the actual workflow advantage over a spreadsheet: not the twenty minutes saved once, but that the result lands somewhere your assistant reads every day.
Problem one: cooking yield
This is the mistake almost everyone makes, and it is worth being precise about.
Weigh your ingredients raw. Cook. The pot now weighs less than the sum of its ingredients, because water evaporated. The calories did not evaporate. So the finished dish has the same total energy in less mass, which means it is more energy-dense per gram than the ingredient list suggests.
That does not matter if you divide by servings. Four equal portions of the pot are a quarter of the total, whatever the pot weighs.
It matters enormously if you weigh a portion of the finished dish and look it up as if it were the raw ingredients. A hundred grams of cooked dahl is not a hundred grams of the ingredient mixture.
Two consistent approaches, and the rule is to pick one and never mix them:
Divide by servings. Total the raw ingredients, divide by however many portions you will get. Simple, and correct as long as the portions really are equal.
Weigh the finished dish. Total the raw ingredients, then weigh the whole cooked pot. Now you have total calories and total cooked grams, so you can derive a per-100 g figure for the cooked dish and weigh your actual portion. More work, and the only method that handles unequal servings honestly.
The second one is what to do for anything you will eat over several days out of the same container, because those portions are never equal. The first is fine for a dinner served four ways at once.
Where this bites hardest is the staples. Dry rice roughly triples in weight when cooked; dry pasta roughly doubles. Dry oats absorb their own weight several times over. If you weighed dry, say dry. The catalog has both rows and they are very different per gram, as the portion arithmetic in calorie tracking in Claude shows.
Problem two: the fat you cooked in
Sixty grams of olive oil is over 500 kcal. In a four-serving recipe that is more than 130 kcal a portion, and it is the item most often left out of a recipe calculation, because it went in the pan rather than into the bowl, and because nobody measures oil.
Stop pouring and start weighing it, at least for a week, until you know what your pour actually is. Most people are surprised. A generous glug is easily 30 g.
Related omissions worth naming: butter on bread, dressing on salad, the oil a stir-fry absorbed, and anything added at the table. None of them is in the recipe as you wrote it down. All of them are calories.
Fibre is a smaller and opposite-direction issue: the energy your body gets from a high-fibre food is somewhat less than the label figure suggests, because some of it is not absorbed. This is real, it is modest, and it is not worth adjusting for manually. If you want to know how the sausage is made, the arithmetic behind calorie values is in food API calorie data accuracy.
The shape of a worked recipe
To make the structure concrete, here is the full sequence for a batch dinner, with the decisions called out. The figures below are structure, not a transcript of a run. Your rows will differ by brand and by which catalog entries resolve.
Write the recipe in grams. Not cups, not "a tin", not "a splash". 400 g dry red lentils, 800 g tinned chopped tomatoes, 200 g onion, 60 g olive oil, 20 g ginger, 8 g salt and spices.
Resolve every ingredient. One search each. Four of the six matter; the ginger and the spices are a rounding error you can drop without meaningfully changing the answer. Four searches.
Decide the serving count honestly. Four servings means four equal portions, and if you are going to eat this out of a container over three days, they will not be equal. For a container, weigh the cooked pot and derive a per-100 g cooked figure instead. For four bowls served at once, four is fine.
One recipe call. The four ingredient pairs plus the serving count.
Read both outputs. The total tells you whether the recipe is calorie-sensible at all. The per-serving figure is what goes in the log. If a serving lands at 512 kcal with 22 g of protein, you now know something useful: this is a carbohydrate-forward meal and the day it appears in needs protein elsewhere.
Save it. Per-serving row into the profile file, with the ingredient list and the serving basis next to it, so future-you knows whether that 512 was "a quarter of the pot" or "per 100 g cooked".
Total cost: four searches and one recipe call. Five tool calls for a meal you will eat four times, which is the best call-to-meal ratio available anywhere in this workflow.
If you are publishing the recipe
A different use case, and it comes with a hard constraint worth stating.
Putting a nutrition panel on a recipe you publish, whether a food blog, a printed card or a product, is commercial use of the data. The MCP plan is personal use only, and a commercial usage header on an MCP key is rejected. That is not an oversight; it is what the plan is.
For a published label you want a REST plan and, for a paid product, a commercial licence. The specific workflow of generating labels for recipe content is covered in the recipe nutrition label generator guide.
There is also a regulatory dimension the tools do not address. A nutrition panel that appears on packaged food for sale is subject to labelling rules about rounding, mandatory nutrients, reference intakes and permitted tolerances, and those rules differ by jurisdiction. A correctly-summed calculation from a food catalog is the input to that process, not the output of it.
Scaling and halving
Because per-serving numbers are derived rather than asserted, changing the recipe is cheap:
You: Same recipe but six servings, and swap the oil down to 30 g.
One call, no re-searching. Ids do not change.
Scaling up is where a hidden assumption lives. Doubling ingredients does not double cooking losses, since a bigger pot loses proportionally less water in the same time, so a doubled recipe is slightly less energy-dense per cooked gram than the original. If you are using the divide-by-servings method this is invisible and fine. If you are weighing the cooked dish, re-weigh it rather than doubling the previous weight.
Halving is the safer direction. A halved recipe cooked in the same pan loses proportionally more water, so it ends up slightly more energy-dense per cooked gram. Again that is invisible if you divide by servings, and again a reason to re-weigh if you do not.
Forty ingredients, and what to do beyond that
The cap is 40 ingredient pairs. Very few home recipes get near it. If yours does, the usual reason is that you are treating the recipe as a whole day of food, and the answer is to split it into components: total a sauce, total a base, then combine the per-serving rows.
Baking is the case where 40 is tight, because baked goods have a lot of small-weight ingredients. It is also the case where yield matters most, since bread and cakes lose a lot of water in the oven. Weigh the finished loaf.
Drinks are the other overlooked case. A smoothie is a recipe, and it is one where people routinely underestimate, because a blended drink does not look like the four hundred grams of fruit and the tablespoon of nut butter that went into it. Total it as a recipe with one serving and you will get an honest number rather than a hopeful one.
Connect it
Claude Code:
claude mcp add --transport http calorie-api \
https://calorieapiadmin.com/mcp \
--header "X-API-Key: YOUR_KEY"
Cursor:
{
"mcpServers": {
"calorie-api": {
"url": "https://calorieapiadmin.com/mcp",
"headers": { "X-API-Key": "YOUR_KEY" }
}
}
}
Browser sign-in for Claude apps is off on this server until OAuth is enabled, so use one of those two with the header. The MCP page is the overview, the docs carry the arguments, and MCP pricing has the plan and the 7-day trial.
If what you need is this calculation inside software rather than inside a chat, the REST version is documented in recipe nutrition for multiple ingredients, and that needs a REST plan.
What we have not measured
We have not taken a set of recipes, calculated them by hand, and compared the results to the tool's output. That comparison would only be testing arithmetic, which is not where recipe error comes from, but it is a measurement we have not run and we are not going to imply otherwise.
The two error sources described above are structural rather than measured: cooking yield and omitted fat are why hand-calculated and tool-calculated recipes both go wrong, and both are on your side of the interface. The tool sums catalog rows correctly. What it cannot know is what evaporated and what you poured.
Related
Frequently Asked Questions
How many ingredients can one recipe call take?
Up to 40 ingredient pairs of food_id and grams, plus a serving count. Each ingredient has to be resolved with a search first, since ids come only from search_foods. Beyond 40, total the components separately and combine the per-serving rows.
Do I weigh ingredients raw or cooked?
Weigh raw, then either divide the total by servings, or weigh the whole cooked dish to derive a per-100 g cooked figure. Pick one method and never mix them. Water evaporates during cooking but calories do not, so cooked food is more energy dense per gram than its raw ingredient list.
What is the most commonly missed item in a recipe calculation?
The cooking fat. Sixty grams of olive oil is over 500 kcal, which is more than 130 kcal a serving in a four-serving recipe, and it went in the pan rather than in the bowl. Weigh oil for a week until you know what your pour actually is.
Can I reuse a recipe without recalculating it?
Yes, and you should. Save the per-serving row in the profile file your client reads. Logging that meal then costs no tool calls. Rescaling to a different serving count is one call, since the ingredient ids do not change.
Does dry versus cooked matter for rice and pasta?
A great deal. Dry rice roughly triples in weight when cooked and dry pasta roughly doubles, so per-gram macros are very different. The catalog holds both rows, and only you know which one you weighed.