Nutrition MCP Server: Connect a Food Database to Claude

Ask an assistant how much protein is in 180 g of cooked chicken breast and you will get a number. The number will usually be close. It is also produced the same way the rest of the sentence is produced, which means it is a plausible number rather than a looked-up one. On a single question that does not matter much. Across a week of meals it compounds, and you cannot tell which entries drifted.

A nutrition MCP server fixes the mechanism rather than the prompt. Instead of asking the model to remember a food composition table, you give it a tool that queries one.

What an MCP server actually is

Model Context Protocol is the standard way an assistant calls an outside tool. The assistant sees a list of tools, each with a name, a description, and a schema for its arguments. When your question matches one, the assistant fills in the arguments, sends the call, reads the JSON that comes back, and writes its reply from that.

Three things follow from this, and they are the whole reason the setup is worth doing:

• The numbers in the reply came from a database, not from the model's training.
• You can see the call. Most clients will show you the tool name and arguments if you ask, so a wrong answer is diagnosable.
• The assistant decides which tool to call. You do not write requests. You describe the meal.

If you want the protocol-level version of that (the handshake, the transport, why this server is stateless), the developer article in this series covers it: how to build a remote MCP server in Python.

The problem this solves, stated plainly

There are two ways an assistant can answer a nutrition question.

The first is from its own weights. This is what happens by default, and what every "turn Claude into your nutritionist" prompt template relies on. It is fast, it needs no setup, and it is confidently wrong in specific and predictable places: cooked versus raw weights, brand-specific products, anything regional, and portion arithmetic on a food whose per-100 g row it half-remembers.

The second is a lookup. The assistant searches a food catalog, gets back a row with an identifier and macros per 100 g, then scales that row to the weight you gave it. The arithmetic is done by a tool, on a number that came from a database.

The second one is slower by a second or two and it costs a subscription. What you buy is the ability to check the answer.

The eight tools

This server exposes eight tools. The names matter, because the assistant picks between them, and because when something goes wrong you will want to know which one failed.

Two prompts ship alongside them, log_a_meal and plan_my_macros, and one resource, nutrition://limits, which reports the limits on your own plan.

The single most important thing to understand about this set is the food_id. It comes from search_foods and nothing else. calculate_portion, calculate_recipe and get_food_nutrition all need one. An assistant that skips the search and invents an id will get an error on the next call. That is the correct behaviour, but it looks like a bug if you do not know why. The fix is one sentence in your request: ask it to search first.

The argument-schema reasoning behind that design is in designing MCP tools an LLM actually calls correctly.

Connect it

You need two things: an API key, and a client that can send a header.

The key comes from the dashboard after you start a plan on MCP pricing. It is shown once, when you create it. It is not emailed, and it should not go in a public repository or a screenshot.

Claude Code. One command:

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

Cursor. Add the server to your MCP config:

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

Any client that lets you set a request header will work with the same URL and the same header name. The per-client walkthrough is in connect a remote MCP server to Claude Code, Desktop and Cursor, and the reference lives at the MCP docs.

One limitation to be clear about. Browser sign-in is not available on this server. Claude.ai, Claude Desktop and Claude mobile add remote servers through a connector flow built around OAuth, and OAuth is off here. Use Claude Code or Cursor with the header above. When sign-in is enabled the MCP page will say so; until then, assume any guide telling you to open a Claude app and sign in to this server is describing something that does not work yet.

The first three things to ask

Once it is connected, do not start with a week of meal planning. Start with three questions that tell you the wiring is good.

One food, one weight. How many calories and how much protein are in 180 g of cooked chicken breast? Search the catalog first. You should see two calls: a search, then a portion scale on the id that search returned. If you only see one, the assistant answered from memory and you should say so.

A barcode. Read the digits off something in your kitchen and paste them. What are the macros per 100 g for barcode 0123456789012? One call, no search needed.

A target. I am 34, male, 82 kg, 180 cm, moderately active, trying to lose fat. What should my daily calories and macros be? One call to calculate_macro_targets. Treat the output as a starting point, not a prescription. It is a formula, and formulas are wrong for individuals in both directions.

If all three behave, the rest of the series is just workflow.

What the calls cost you

The plan is $29 a month or $228 a year, with a 7-day trial that requires a card. Limits are per person, sized for someone logging their own food rather than for a service:

The trial budget is a total, not a monthly allowance, and it does not reset on the first of the month. Two hundred calls is enough to log several days properly and to find out whether the workflow suits you. It is not enough to plan a month of meals.

A useful way to think about the paid budget: a carefully logged meal is two to four calls. A day is under a dozen. Ten thousand a month is not a constraint you will notice unless you are looping the tools programmatically, which is what the limits exist to stop. The reasoning behind the shape of those limits is in rate limiting an MCP server.

What this is not

It is not the REST API. The MCP plan calls MCP tools. REST search, foods, calc and vision return 403 on this plan. Your account and billing pages still work normally. If you are building software that needs HTTP endpoints, you want a REST plan instead, and the trade-off between the two interfaces is spelled out in MCP vs REST.

It is not a commercial licence. This is personal use, in your own assistant. Sending a commercial usage header on an MCP key is rejected. Reselling the data, or putting it behind a product other people pay for, needs a REST plan and a commercial licence.

It is not a food diary. There is no log_meal tool and the server keeps no history for you. It answers questions about foods; it does not remember what you ate. That sounds like a gap and in one sense it is, but it also means your log is a file you own rather than a row in someone else's database. The next post in this series covers how to run a day that way.

It is not medical advice. A formula that turns your height and weight into a calorie target does not know about your thyroid, your medication, or your history. If you have a diagnosed condition, a therapeutic diet, an eating-disorder history, or you are pregnant or breastfeeding, a dietitian reviewing the plan is not optional.

How this sits next to the other nutrition MCP servers

There are several, and it is worth knowing the shape of the category before you pay for anything. From a survey of public listings and repositories in September 2026, which is a survey rather than a hands-on test of each one:

• USDA wrappers. The largest group. They put FoodData Central behind MCP tools, and several are free and open source. USDA data is authoritative for whole foods and weak on branded and international products, and it has its own quirks that will bite an agent. There is a post on those quirks later in this series.
• Locally-running servers. At least one ships a food database as a local dataset, so queries never leave your machine. Best privacy story in the category. Bounded by whatever the bundled snapshot contains.
• Vendor-run servers. At least one established nutrition API vendor now publishes an official MCP server for its own data, needing that vendor's key. This is the group we are in.
• Community wrappers over commercial APIs. Several exist over commercial nutrition APIs. They work, but the licence that governs the data is the underlying vendor's, not the wrapper author's, and a permissive licence on the wrapper repository says nothing about what you may do with the data flowing through it.
• Free tracker servers that keep your log. These store your meals and history, which is the feature this server does not have, and they are free.

Where that leaves this one: a large catalog with provenance tracking, barcode lookup with an international fallback, portion and recipe arithmetic as tools rather than as model output, and a photo estimate. Against a free server that stores your log, the honest trade is data breadth and checkable numbers versus history and no bill. Some people should pick the free one.

Anything in the list above may have changed since we looked. Check the repository or the vendor page rather than trusting a table in a blog post, including this one.

What we have not measured

We are going to be specific about this, because a lot of writing in this category is not.

We have not published an accuracy benchmark for photo estimates. We have not published a multi-day comparison of assistant totals against weighed-and-labelled food. We have not measured catalog hit rate against a fixed shopping basket, and we have not measured how often an assistant picks the right tool on the first try. Those measurements are worth running and we intend to run them; until we do, there is no number from us to quote, and any number you see attached to this product that does not link to a method is not ours.

What we can state is mechanical and checkable: which tool returned which field, what the limits are, and what the server does when a lookup misses. That is what this series sticks to.

Related

• Connect a client
• MCP pricing and the 7-day trial
• MCP tool reference
• Connect a remote MCP server to Claude Code, Desktop and Cursor
• MCP vs REST: when to ship a server instead of an SDK