Claude for Weight Loss: A Setup That Checks Its Own Numbers

Using Claude for weight loss works better than most chat-based approaches for one structural reason: it can call a food database instead of recalling one. This is the setup, the prompts, the weekly loop, and the point where it stops being the right tool.

Why this is different from prompting

Most AI weight loss advice is prompt engineering. Better instructions, better persona, better structure. All of it operates on a model that is producing calorie figures from memory, so the output gets better organised without getting more accurate.

Claude Code and Cursor can attach an external tool over the Model Context Protocol. With a nutrition server attached, the assistant searches a food catalog, gets back a row with macros per 100 g, and scales that row to your gram weight. The numbers in your log then came from a database, and you can ask which row produced any of them.

That is the entire difference, and it is the difference between a log you can audit and one you cannot.

Setting it up

You need a client that can send a request header. Claude Code and Cursor both can. Claude.ai, Claude Desktop and Claude mobile cannot connect to this server yet, because their connector flow expects browser sign-in and that is not enabled here. Do not follow a guide that tells you to sign in from a Claude app.

In Claude Code:

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

The key comes from the dashboard after starting a plan on MCP pricing. The full connect walkthrough for both clients is in connect a remote MCP server, and the tool reference is in the docs.

Write the profile once

Weight loss is a long feedback loop and the assistant needs to remember where you are in it. Put that in a file your client reads on startup. In Claude Code, a markdown file in the working directory works:

# Weight loss profile
- 34, male, 82 kg, 180 cm. Lifts 4x/week, desk job.
- Target: 2,150 kcal, 175 g protein.
- Allergy: shellfish. Will not eat cottage cheese.

## House rules
- Always search the catalog before quoting a macro. Never estimate from memory.
- State the gram weight you assumed for anything I describe in words.
- Append to the Log. Never rewrite it. Mark estimated entries.

## Log

Those house rules matter more than any prompt. Without them the assistant will sometimes answer a food question directly because it is faster, which is the exact behaviour the setup exists to prevent.

Getting a target

I am 34, male, 82 kg, 180 cm, lifting four times a week, otherwise
desk-bound. I want to lose fat. Give me maintenance and a moderate
deficit, and tell me what would make this estimate wrong for me.

One tool call. What comes back is a formula estimate scaled by an activity multiplier, not a measurement of your metabolism, and two people with identical inputs genuinely differ by several hundred calories a day.

Treat it as a hypothesis with a test attached: hold it two weeks, track a weekly average weight rather than daily numbers, and adjust from what the scale actually did. Daily weight is mostly water and reacting to it is how people make themselves miserable.

The daily loop

After each meal, one line:

Had 220 g skyr, 60 g dry oats, a banana. Search each, tell me the
weight you assumed for the banana, and append to the log.

You should see two calls per food: a search that returns a row and an identifier, then a portion scale to your gram weight. That is the mechanism working. A full worked day is in calorie tracking in Claude.

At the end of the week, the review:

Read the last 14 days of the log. Give me days logged out of 14, average
calories per week, average protein, and weekly average weight. Then say
hold or adjust, and which number drove it.

Days logged comes first on purpose. If it is four out of fourteen, the averages only cover the days you chose to record, and those are the good ones.

The first week

Concretely, because "set it up and log your food" skips the part where people give up.

Day one. Write the profile file and get a target. Do not log anything yet. Ten minutes.

Day two. Resolve your core foods. Ask the assistant to search the fifteen or twenty things you actually eat most weeks and write each one into the file with its per 100 g values and its identifier. This is the highest-value hour in the whole setup, because from here on most log entries cost no lookup at all: the values are already in the file.

Days three to five. Log properly, weighing things. Expect this to feel slow. It is slow, and it is the part that calibrates your eye for portions, which pays off permanently.

Day six. Total a recipe you cook often and save the per-serving row. One calculation, four logged meals later.

Day seven. Run the weekly review even though a week of data barely means anything yet. The point is to run the loop once so you know what it looks like.

If by day seven the file feels like something you own and logging feels routine, this will work for you. If you have not opened it since day three, it will not, and a phone app with a barcode scanner is the better answer.

Common mistakes

Logging from memory at the end of the day. The entries you forget are the ones that were not meals: the oil, the handful, the milk. Log as you eat or accept that your average is a fiction.

Reacting to the daily scale. Daily weight is mostly water and glycogen. Compare week averages against week averages, never days.

Rebuilding the target every week. Changing calories and protein at the same time tells you nothing about either. Hold protein, move calories, wait a fortnight.

Letting the assistant answer food questions directly. It will sometimes, because it is faster. The house rules in the profile file are what prevent it, and a spot check every few days is what tells you whether they are holding: ask which tool produced a figure. If the answer is vague, it did not come from a tool.

When the scale stops moving

Two explanations, opposite responses, and telling them apart is the whole skill.

Either your logging has drifted, which is much more common, or your expenditure has fallen. Both look identical from inside.

The test: weigh everything strictly for four days, including cooking oil and the milk in coffee. If the logged total rises above your usual, it was drift, and the fix is accuracy rather than fewer calories. If four strict days land on the number you had been logging all along, it was expenditure, and you lower the target by 100 to 150 kcal or add activity.

The longer treatment, including the four places a deficit quietly leaks, is in running a cut in Claude.

What the lookups actually change

It is worth being precise about the size of this, because it is easy to oversell.

Attaching a database does not make your log correct. It removes one of the two large error sources and leaves the other one entirely intact.

Removed: the per-food figures. A catalog row for cooked chicken thigh is a well-sourced population figure rather than a recollection, and the same query returns the same row tomorrow. Branded products resolve to the actual product rather than a generic lookalike. Raw and cooked are different rows, so the ambiguity that costs a factor of three on rice becomes a question you get asked instead of a guess made silently.

Not removed: your portions. Nobody can tell you what your bowl weighed. If you are estimating weights by eye, you have swapped a soft number for a hard number and then multiplied it by a soft one. The kitchen scale is still doing most of the work, and it costs less than a month of any subscription in this category.

So the honest framing is that a database makes your log auditable and repeatable. Auditable means you can ask where a figure came from. Repeatable means the same meal logs the same way every time, which is what makes a weekly average meaningful. Neither of those is the same as accurate, and both of them are worth having.

Where this stops being the right tool

It has no history of its own. The server stores nothing. Your log is a file you keep and back up. That is why you own it, and also why losing the file loses everything.

It cannot see you. No labs, no medication, no sleep, no menstrual cycle, and that last one affects water weight enough to distort a weekly average, which is an argument for comparing like phases rather than adjacent weeks.

It is not clinical. With coeliac disease, kidney disease, insulin-dosed diabetes, a diagnosed allergy, a history of disordered eating, or in pregnancy or breastfeeding, a self-directed deficit guided by an assistant is not appropriate and a qualified human needs to be involved.

It does not supply adherence. Nothing here makes you log the day. There are no reminders, no streaks and nothing that notices you have stopped. A rough log kept for four months beats an immaculate one kept for nine days, and the tooling has no opinion about which one you produce.

It is a desk workflow. No phone app, no barcode scanner camera, no reminders. Barcode lookup exists, but you type the digits rather than point a camera. If you log on the move, an app is the better answer and there is no shame in it. The honest comparison is in logging food in a chat instead of an app.

What we have not measured

We have not run a weight loss phase on this setup and published the log. No adherence rate, no comparison of logged against weighed intake, no outcome of any kind. The guidance on deficits and protein above is published general advice presented as ranges, not our findings.

What is documented is mechanism: which tool produces which number, and where the error enters. That you can verify in a few minutes, on your own food, without taking our word for any of it. When we do run a phase on this setup, the log and the method will be published together, including the weeks it went badly.

Related

• Running a cut: the weekly loop and what drifts
• Calorie tracking in Claude, a full day logged
• ChatGPT weight loss prompts that do something useful
• Nutrition MCP server: what the tools do