Nutrition MCP Servers: What Exists and How to Choose One

There are more nutrition MCP servers than most people expect and they are less different from each other than the listings suggest. Most are a wrapper over one of a small number of underlying data sources, and knowing which source you are getting tells you more than any feature list.

What this is and is not. This is a survey of what was listed publicly on the MCP directories and on GitHub as of September 2026. We did not install and test each one. Where a post in this category says "we ran all of these and here is what worked", be sceptical unless it shows you the transcripts. Everything below is either a property of the underlying data source, which is checkable, or a category description. Anything specific may have changed since, so check the repository or vendor page.

Group them by data source, not by features

Almost every nutrition MCP server falls into one of five groups.

USDA FoodData Central wrappers. The largest group by a wide margin, and several are free and open source. FDC is the US government's food composition database, it is authoritative for whole and generic foods, and its API key is free. The reasons there are so many wrappers are that the data is free and the API is simple.

What you get: excellent whole-food coverage, real provenance, no cost. What you do not: branded and international products, where coverage is thin to absent, and any convenience layer, since FDC's raw responses are large and its nutrient model takes some learning. There are specific integration traps that catch almost everyone, and a post later in this series covers them.

Local-dataset servers. At least one ships a food database as a local file and answers queries on your machine with no outbound network call. Best privacy story in the category, by a distance. Bounded by whatever is in the bundled snapshot, and updated only when you update the package.

Vendor-run servers over a commercial API. At least one established nutrition API vendor publishes its own official MCP server, requiring that vendor's key. This is the group this server is in. You get the vendor's data and the vendor's support, and you pay the vendor.

Community wrappers over a commercial API. Several exist over commercial nutrition APIs, written by third parties rather than by the vendor. These work, and they carry a licence subtlety covered below that is easy to miss.

Trackers with their own store. These keep your meals and history, which most of the others do not, and several are free. If persistent logging is the feature you want, this is the group to look at, and the trade is that your food history lives in someone else's account.

The licence trap in community wrappers

This one is worth a section because it catches people who are being conscientious.

A community MCP wrapper over a commercial nutrition API is usually published under a permissive open-source licence, often MIT. That licence governs the wrapper's source code. It says nothing whatsoever about what you may do with the data flowing through it.

The data licence is the underlying vendor's, and it attaches to you as the person holding the key. So an MIT-licensed wrapper does not make a vendor's data usable in a commercial product, and "the MCP server was MIT" is not a defence. If you are doing anything beyond personal use, read the terms of whoever owns the data, not the repository.

This applies to us too. This server's plan is personal use, a commercial usage header on an MCP key is rejected, and a product that resells the data needs a REST plan and a commercial licence. The distinction gets a full treatment later in this series.

Six questions that actually decide it

Feature tables in this category are mostly noise. These six are the questions whose answers change your choice.

1. What data is underneath, and does it have your food? The single most important question, and the easiest to test. Pick ten things you actually eat, including two supermarket own-brand products and something regional, and look for them. A server that misses four of your ten is not going to work for you regardless of how good its tooling is. This matters most outside the US, where USDA-backed servers thin out fast.

2. Does it store your log, and do you want it to? A genuine fork in the road rather than a feature gap. Servers that store your history give you sync and continuity, at the cost of your food diary living in their database. Servers that store nothing, including this one, mean your log is a file you own and back up yourself. Neither is the right answer for everyone.

3. How does it authenticate, and can your client do that? This determines whether you can use it at all. A header-based key works in Claude Code and Cursor. Browser sign-in through a connector flow is what Claude.ai, Claude Desktop and Claude mobile use. A server offering only one of those excludes the clients that need the other. This server is header-based today, which is why every post in this series tells you to use Claude Code or Cursor.

4. Local or remote? Local means no network call and no data leaving your machine, bounded by a bundled snapshot. Remote means a live catalog and a maintained dataset, and your queries go somewhere. If a photo of your dinner leaving your machine matters to you, that is a local-server requirement.

5. What are the rate limits, and what happens when an agent loops? Agents make many small calls and will occasionally loop. A server with no limits will eventually be abused and then throttled or shut down; a server with visible, documented limits has thought about it. Ours are 20 calls a minute and 10,000 successful calls a month on the paid plan, and 5 a minute with a 200-call total on the trial. The design reasoning is in rate limiting an MCP server.

6. Are the tool responses compact? Underrated and it matters more than it sounds. Every tool reply consumes context your conversation also needs. A server that returns a full nutrient panel on every search result burns through a window fast. Ask for a search and look at the size of what comes back. Why this shapes the whole design is in giving an AI agent a 4M-food nutrition database.

How to actually test one in ten minutes

Whatever you are evaluating, this sequence tells you most of what you need:

1. Ten real foods. Two own-brand supermarket products, something regional, a cooked staple, a cut of meat. Count the misses.
2. A barcode from your own cupboard. Not a famous product, a normal one.
3. A portion. Ask for 180 g of something and check the arithmetic is scaled from a looked-up per-100 g row rather than asserted.
4. A cooked-versus-raw pair. Ask for both dry and cooked rice. A server that returns one row for "rice" is going to mislead you constantly.
5. The 4/4/9 check. Protein and carbohydrate at roughly 4 kcal per gram, fat at roughly 9, against the stated calories. A gap over about 40% usually means a transcription error somewhere in the data.
6. Watch the calls. Ask which tools ran with which arguments. If the answer is vague, nothing was looked up and you are back to the model guessing.

Step 6 is the one people skip and it is the one that matters. The entire value of a nutrition MCP server is that a database answered instead of the model. If you cannot confirm that happened, you have paid for nothing.

The directories, and what they do not tell you

Most people find these servers through an aggregator rather than through a repository. Several exist, they index overlapping sets, and they are useful for discovery.

What they are good for: finding out that a server exists, and getting its install snippet.

What they are not good for: currency, and quality. A directory entry is generated from a repository's metadata, so an abandoned project and an actively maintained one look identical in a listing. A listing also cannot tell you whether the underlying data licence permits what you intend to do with it, and it will not tell you whether the tool responses are compact enough to live in a context window.

So treat a listing as a pointer. Before depending on anything you find there, open the repository and look at two things: when it was last committed, and whether the issues are being answered. For a vendor-run server, look at the vendor's own documentation page rather than the directory entry, because that is the page that gets updated.

Where this one sits

Stated plainly, and with the weaknesses included.

Strong on: catalog size and breadth including branded products, barcode lookup with an Open Food Facts fallback for international coverage, provenance tracking with a verified_only filter, portion and recipe arithmetic as tools rather than as model output, and a photo estimate. Documented limits.

Weak on: it stores no history, so there is no log and no sync. It is header-auth only, so Claude.ai, Claude Desktop and Claude mobile cannot connect yet. It is paid, $29 a month or $228 a year with a 7-day trial, where several alternatives are free. It is personal use only.

If free and stores-your-log is what you want, one of the tracker servers is a better fit and we would rather say so. If you want a large catalog with provenance and traceable arithmetic, that is what this plan is for, and the docs list every argument.

Connect it

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

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

Claude Code and Cursor. Browser sign-in is off until OAuth is enabled. The MCP page has the current position.

What we have not measured

We did not install every server in this category and drive it through a test suite. No hit-rate comparison, no latency comparison, no tool-accuracy comparison across servers. The categories above come from public listings and repository descriptions as of September 2026, and the properties attributed to each group are properties of the underlying data sources rather than measured results.

We also have not measured our own catalog's hit rate against a fixed basket, which is the number we would need to make a coverage claim about ourselves. The ten-food test in this post is the version you can run in a few minutes, and we would rather you ran it than took our word.

Related

• What the MCP plan includes
• Pricing and the 7-day trial
• Tool reference
• Giving an AI agent a 4M-food nutrition database over MCP
• Nutrition MCP server: the eight tools
• MCP vs REST: when to ship a server instead of an SDK