Skip to content

How to Make Claude Your Personal Dietitian Without It Guessing the Calories

Published July 30, 2026

Search for how to turn Claude into your nutritionist and you will find a dozen good prompts. They follow the same shape: paste a detailed intake, list the foods you actually eat, ask for a plan, keep the thread open. The shape is right. People get real value from it.

There is one weak joint. Every number in that conversation (the calories in your oats, the protein in the chicken, the total for the day) is generated the same way the advice is generated. The model is recalling food composition, not consulting it. So the plan is coherent and the arithmetic is confident, and you have no way to tell which entries are off or by how much.

This post is the same workflow with that joint fixed. The assistant still does the coaching. A food catalog does the numbers.

What you need first

A client that can send a request header, and a key.

Claude Code and Cursor both can. Claude.ai, Claude Desktop and Claude mobile cannot connect to this server yet. Their connector flow is built around OAuth sign-in and OAuth is off here. That is worth saying twice, because most of the "Claude as your nutritionist" guides assume the chat app, and this part of the setup is the one that does not transfer. Use Claude Code or Cursor.

The key comes from the dashboard after you start a plan on MCP pricing. Then, in Claude Code:

claude mcp add --transport http calorie-api \
  https://calorieapiadmin.com/mcp \
  --header "X-API-Key: YOUR_KEY"

Or in Cursor's MCP config:

{
  "mcpServers": {
    "calorie-api": {
      "url": "https://calorieapiadmin.com/mcp",
      "headers": { "X-API-Key": "YOUR_KEY" }
    }
  }
}

The full connect walkthrough is here, and the tool reference is in the docs. Once the server is attached, the assistant has eight tools: food search, a full nutrient lookup, autocomplete, barcode lookup, portion scaling, recipe totals, macro targets, and a photo estimate. The overview of all eight is in nutrition MCP server.

Step 1: write the profile once, in a file

A dietitian takes an intake and keeps notes. Do the same thing, but put it somewhere that survives the conversation.

Make a plain text or markdown file. In Claude Code, CLAUDE.md in your working directory is read automatically, which is the least friction you will find. Cursor has project rules that work the same way. If neither fits, a file you paste at the start of a thread is fine.

What goes in it:

# Nutrition profile

- 34, male, 82 kg, 180 cm
- Lifts 4x/week, desk job otherwise
- Goal: lose fat, keep strength
- Targets: 2,150 kcal, 175 g protein, 70 g fat, rest carbs
- Non-negotiables: no shellfish (allergy), vegetarian on weekdays
- Eats most days: oats, skyr, eggs, tofu, lentils, rice, olive oil, bananas
- Dislikes: cottage cheese, tuna
- Cooks: 30 min on weeknights, longer Sunday
- House rule: always call search_foods before quoting a macro. Never estimate a
  food from memory. If the catalog misses, say so and give a range instead.

## Log

That last house rule is the whole point of the file. Without it, an assistant will sometimes answer a food question directly because it is faster and it feels helpful. With it, you get a lookup, and on the occasions the catalog misses you get told rather than guessed at.

The allergy line and the dislikes line matter more than they look. Most of the friction in AI meal planning is not the macros, it is being handed food you will not eat.

Step 2: get the targets from a tool, then argue with them

Ask for targets and the assistant will call calculate_macro_targets with your age, sex, weight, height, activity level and goal, and return calorie and macro numbers.

Understand what that is. It is a formula: a standard estimate of resting expenditure scaled by an activity multiplier. It does not know your thyroid, your sleep, your medication, or that your job involves stairs. Two people with identical inputs can differ by several hundred calories a day.

So treat the output as a hypothesis with a test attached: hold it for two weeks, track your weight as a weekly average rather than a daily number, and adjust from what the scale actually did. Write the adjusted target back into the profile file. That loop, estimate then observe then adjust, is most of what a good coach does, and it is a thing you can genuinely run yourself.

Protein is the number worth being stubborn about. Published guidance for people in a deficit who lift clusters somewhere around 1.6 to 2.2 g per kg of bodyweight, which is a range and not a rule; pick a point in it, put it in the file, and hit it.

Step 3: the daily loop

Three interactions, none of them longer than a sentence.

Morning. What am I eating today? The assistant reads the profile, reads yesterday's log, proposes a day that hits the targets, and checks each food against the catalog rather than asserting it.

After each meal. Had 220 g skyr, 60 g oats, a banana. It searches each food, scales each to the gram weight, sums them, appends a line to the log, and tells you what is left for the day. That is where the tool sequence earns its keep: every item resolved to a catalog row, every gram weight scaled by calculate_portion rather than multiplied in prose.

Evening. Where did I land? Totals against targets, and one observation about tomorrow.

A well-logged meal costs two to four tool calls. A day is under a dozen. On the paid plan that is 20 calls a minute and 10,000 successful calls a month, which this workflow will not trouble. On the 7-day trial it is 5 a minute and 200 calls total, not reset on the first. That is enough to run several honest days and decide.

The mechanics of a full day, including what to do when the catalog does not have your exact brand, are the subject of the next post in this series.

Step 4: know where it stops

A dietitian is not a lookup table with a friendly voice. Here is what this setup does not do, stated without hedging.

It does not hold your history. The server has no logging tool. It answers about foods; it does not remember your week. Your log is whatever file you keep. That is a real limitation and also the reason your data is not in someone else's account.

It does not know your labs. No blood panel, no continuous glucose data, no medication interactions. It cannot see that your iron is low or that a drug you take changes how you should time meals.

It is not safe as a sole source for clinical diets. If you have coeliac disease, kidney disease, diabetes you are dosing insulin for, a diagnosed allergy, an eating-disorder history, or you are pregnant or breastfeeding, a plan from an assistant needs a qualified human to review it. This is not a disclaimer for form's sake. Therapeutic diets have failure modes that a calorie total does not capture.

It does not do adherence. Nothing here makes you eat the food. The published research on food journaling is consistent on one point: consistency beats precision. A rough log you keep for a year beats a perfect log you keep for nine days.

Three ways this breaks, and the fix

The assistant answers without looking anything up. It will happen. The reply arrives fast, sounds right, and no tool ran. Usually it is a short question like is peanut butter high in protein?, where a lookup feels like overkill. The problem is that the same habit then applies to the number you are going to log. The fix is the house rule in the profile file, and a spot check: every few days, ask which tool produced a figure. If the answer is vague, it did not come from a tool.

The target is wrong and you keep grinding against it. Someone eats to 2,150 kcal for three weeks, loses nothing, and concludes the tracking is broken. The tracking is probably fine. The formula gave a number that is too high for this particular body, or the portion estimates are running light, and both look identical from the inside. Distinguish them: weigh everything for four days. If the totals move, it was portions. If they do not, it was the target, and you drop it by 150 to 200 kcal and give it another two weeks.

You stop mid-week and the log has a hole. This is the normal failure and it is not a tooling problem. Do not backfill from memory. A reconstructed Wednesday is fiction that then pollutes your averages. Mark the gap and carry on:

- 2026-11-12: not logged

A log with honest holes is usable. A log with invented days is worse than no log, because you will make decisions from it.

What this costs against the alternatives

Be clear-eyed about the price. There are free nutrition MCP servers, some of which also store your food history, which this one does not. There are free apps with barcode scanners, graphs, streaks and a phone widget. This plan is $29 a month, or $228 a year.

What the money buys is a large catalog with provenance behind it, an international barcode fallback, and portion arithmetic done by a tool instead of by a language model. What it does not buy is a scanner, a chart, a reminder, or your history.

So the comparison is not "this versus MyFitnessPal". It is "this versus an assistant guessing", for someone who was going to use the assistant either way.

What the honest version of the pitch is

The prompt-only approach gives you a coach with an unreliable memory of food composition. This gives you a coach that looks things up. That is the entire upgrade, and it is worth $29 a month to some people and not to others.

Who it is worth it for: someone who already tracks, is annoyed by app UI, lives in a terminal or an editor anyway, and wants the numbers checkable. Who it is not worth it for: someone who has never logged food and is hoping the tooling will supply the habit. It will not. Start with a free app, build the habit, then come back if the interface is what is in your way.

What we have not measured

We have not run a multi-day comparison of assistant totals against weighed and labelled food. We have not measured how often the assistant picks the right tool without being told, or how often the catalog misses a supermarket own-brand item. We have published no accuracy percentage, and we are not going to quote one from someone else's blog as though it were ours.

What is documented here is mechanical: which tool produced which number, what the limits are, and where the workflow stops. When we run the measurements, they will come with a method you can re-run.

Frequently Asked Questions

Can I do this in the Claude app on my phone?

Not with this server yet. Claude.ai, Claude Desktop and Claude mobile add remote servers through a connector flow built around OAuth sign-in, and OAuth is off here. Claude Code and Cursor send an API key header and work today.

How is this different from a nutritionist prompt template?

A prompt template still has the model recall food composition. Here the assistant calls a catalog, gets macros per 100 g and a food id, and scales that row to your gram weight. The coaching is the same; the numbers stop being guesses.

Where does my food log live?

In a file you keep. The server has no logging tool and no history. Most people put a profile and a running log in a markdown file the client reads automatically, such as CLAUDE.md in Claude Code.

Can it replace a dietitian?

No. It has no access to your labs or medication and it cannot review a therapeutic diet. With coeliac disease, kidney disease, insulin-dosed diabetes, a diagnosed allergy, an eating-disorder history, or in pregnancy, a qualified human needs to review the plan.

Are the macro targets it gives me reliable?

They come from a standard formula scaled by an activity level, which is a starting estimate, not a measurement. Hold the target for two weeks, watch a weekly average weight rather than daily numbers, then adjust and write the new target down.

← Back to all articles

Start building with the Calorie API

Get a free API key and access 4M+ foods with search, barcode lookup, and full macro data.