Estimating Restaurant Meal Macros with an AI Agent

Restaurant food is where food logs die. Every other entry has something behind it: a label, a barcode, a gram weight, an ingredient list. A plate someone else cooked has none of that, and the honest error bar on it is wide.

The wrong response is to give up on the day, which is what most people do, and which costs far more accuracy than the estimate ever would. The right response is a hierarchy: use the best method available, mark how you got the number, and move on.

The hierarchy, best to worst

1. The chain publishes its numbers. Large chains are usually required to publish nutrition data, and many go further with an online builder that gives exact macros for a customised order. If you are eating at one of those, the guessing is over before it starts. Read the published figure. Some chains publish item-level detail and stand behind it; others publish broad ranges; some publish nothing. It varies by brand and by country, and it is worth knowing which of your regulars is which.

2. The catalog has the item. The food catalog carries restaurant items for chains that publish data. Ask before estimating:

You: Search the catalog for the chain and the item before you estimate anything.

3. You can reconstruct it. You know roughly what is in it and you can name the components. This is the method for independent restaurants, and it is better than it sounds. See below.

4. A photo. Last resort, and the loosest. The mechanics are in food photo to calories inside Claude, including the part where you have to pass the image as base64 rather than attaching it.

Most people jump straight to 4 because it feels modern. Working down from 1 is both more accurate and faster.

Reconstructing a plate

This is the method worth learning, because it covers every independent restaurant you will ever eat in.

Describe the meal as components with rough weights, then have each one resolved against the catalog:

You: Chicken thigh curry with rice at an independent place. My estimate: 200 g chicken thigh, a cream and tomato sauce, maybe 300 g cooked basmati, one small naan. Restaurant portion, so assume generous oil. Search each component and total it.

What that produces is four or five catalog-backed rows scaled to your stated weights. Every number came from a lookup; every weight came from you. Which is exactly the right division, because the weights are the part nobody can look up.

Three adjustments that make the reconstruction land closer:

Say generous. Restaurant cooking uses more fat than home cooking, structurally. Butter finishes the sauce, the pan gets more oil, the rice was fried. Telling the assistant to assume the higher-fat reading is not pessimism, it is calibration.

Name the cooking method. Grilled, fried, braised, and dressed are different by a lot at the same visible portion. A chicken breast is one thing; the same breast fried in batter is another.

Count the invisible things. Dressing on the salad. The oil the vegetables were tossed in. Butter under the steak. Bread and oil before the meal. These are almost never in anyone's estimate and they are frequently 200 to 400 kcal.

Portion size is the error, again

As with photos, the identification is not the problem. You know it was chicken and rice. The problem is that restaurant portions vary far more than home portions, in ways you cannot see from the plate.

Restaurant rice servings range from a modest scoop to nearly double that. The same dish at two branches of the same independent is not the same dish. So the genuinely correct output for a restaurant meal is a range, not a number:

You: Give me a range, low and high, not a single figure.

A meal that is "somewhere between 850 and 1,150 kcal" is a more truthful log entry than a confident 970. If your assistant will only give you one number, ask what assumption is driving it.

Then log the midpoint, and mark it:

- 2026-11-24 dinner: restaurant, reconstructed, est. 850-1150, logged 1000

The mark is what lets you find these entries later when a week's totals look strange. It also keeps you honest about how much of your week is estimated.

Where specific orders go wrong

Some meals mislead in consistent directions. Knowing which way a dish errs is worth more than any amount of estimating precision, because it tells you which way to adjust.

Salads are the biggest trap. A dressed salad can carry more calories than a burger, and essentially all of it is in the dressing and any cheese, nuts or croutons. The leaves are irrelevant. If you estimate a salad without separately accounting for what is on it, you will be low by hundreds of calories. Ask for the dressing as its own line.

Stir-fries and curries hide oil. The visible components are vegetables and protein. The invisible component is the cooking fat, which a restaurant wok uses generously and which coats everything. Reconstruct these with a deliberate oil line, not with the components alone.

Sushi is more rice than it looks. Rice is the bulk of most rolls, and rolls with mayonnaise-based sauces or anything tempura are substantially higher than plain nigiri. Count pieces and be specific about which kind.

Burritos and bowls are portion-variance champions. The same order at two branches can differ by several hundred calories, entirely in rice, beans and the size of the tortilla. These are also the meals most likely to have a published builder on the chain's website, which makes them the easiest case if you check first.

Pub and comfort food errs low. Pastry, batter, gravy, roasting fat, and a "portion of chips" that is not a portion. Reconstruct generously.

Coffee and drinks get forgotten entirely. A large milk-based coffee with syrup is a small meal. Alcohol is roughly 7 kcal per gram and is in nobody's estimate. If you drank it, log it.

Build yourself a restaurant file

The reason restaurant logging feels endless is that people re-estimate the same meals. You do not eat at a hundred restaurants; you eat at five, and mostly order the same things.

So do the estimate once properly and write it down, the same way you would save a pantry item or a recipe:

## Restaurant estimates
| Place | Order | Basis | kcal | P |
|---|---|---|---|---|
| Chain X | published builder | exact | ... | ... |
| Local curry | 200 g thigh + 300 g rice + naan, generous oil | reconstructed | 850-1150 | ... |

Note the basis column. An entry marked exact came from published data. One marked reconstructed came from your estimate, and you can revisit it if a month of weekly averages suggests it was optimistic.

After that, logging a regular haunt costs zero tool calls, because the assistant reads the row. This turns the hardest category of food log entry into the easiest one, and it is the single highest-value thing in this post.

Keeping the week intact

The practical question is not really how accurately you logged Thursday dinner. It is whether Thursday dinner wrecked the week, and that is a planning question rather than a measurement one.

Plan the day around it. If dinner is going to be 1,000 kcal and your target is 2,150, the rest of the day has 1,150. Protein-forward and low-fat earlier means the evening has room. This is a normal thing to ask for:

You: Dinner out tonight, estimate 1,000 kcal. Build the rest of my day around that and keep protein at 175 g.

Do not compensate afterwards. Restricting hard the next day to cancel out an estimate you are not confident in is chasing a number you do not have. Return to target and let the weekly average absorb it.

Order the same thing. The single most effective trick for a regular haunt: pick one order and repeat it. An estimate you use every time is consistent even if it is off, and consistency is what makes a weekly average informative.

Eat the range. If you are on the border of a decision, the high end of the range is the safer assumption.

Decide before you go. The most effective intervention has nothing to do with estimating at all: look at the menu beforehand and pick the order. Deciding at the table, hungry, produces a different meal than deciding in advance, and no amount of accurate logging afterwards changes what you ate.

Why the estimate being loose is fine

There is a reasonable objection to all of this: if a restaurant meal is plus or minus 200 kcal, what is the point of a catalog lookup that is accurate to the gram?

The answer is that the error does not spread. A logged week has twenty-odd entries. Nineteen of them are weighed food, labelled products and saved recipes, all tight. One of them is a restaurant meal with a wide band. The week's total carries that one meal's uncertainty and nothing more.

Compare that to the alternative, where the assistant estimates everything from recollection. Now every entry carries an unknown error, they do not cancel, and you cannot tell which ones were bad. That is how people end up eating in a deficit on paper for a month with nothing happening on the scale.

So the goal is not to make Thursday dinner precise. It is to keep Thursday dinner from being the norm.

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. The MCP page has the overview, the docs the reference, and MCP pricing the plan and trial. A reconstructed meal is five or six tool calls, which is well inside 20 a minute on the paid plan and noticeable against the trial's 5 a minute.

What we have not measured

We have not taken a set of chain restaurant items, estimated them through this workflow, and compared the results to the chains' own published figures. That is an obvious and cheap measurement and we have not done it, so there is no error figure from us for restaurant estimates.

We are also not going to quote the accuracy claims that other tools in this space publish. They mostly measure different things on different foods against different ground truth, and none of them measured this workflow.

What we can say without a measurement: published chain data beats every estimate, a component reconstruction beats a photo, the error is dominated by portion size rather than by food identification, and a marked range is a more useful log entry than a confident single number.

Related

• What the MCP plan includes
• Pricing and the 7-day trial
• Tool reference
• Nutrition MCP server: the eight tools
• Food photo to calories inside Claude
• Calorie tracking in Claude: a full day logged