Letting AI agents add nutrition tracking: MCP and llms.txt

Your next integrator might be an agent#

A developer evaluating a nutrition API today increasingly starts by asking an AI assistant: "find me a calorie-tracking API for a React Native app and set it up". The assistant reads documentation, compares options and, if it can, fills in the forms. If your developer surface only makes sense to a human clicking through a website, the assistant either gives up or guesses.

We already run a consumer connector: people log meals from ChatGPT and other assistants that speak the Model Context Protocol (our ChatGPT app post describes it). The developer surface is separate, and it is designed for a different job: letting an agent learn what the nutrition SDK and estimation API are, try an estimate, and send the human it works for to a free, self-serve API key, without ever handling that key itself.

There is a user-side reason this matters too. The evidence on food logging keeps pointing at friction. Self-monitoring is consistently associated with weight loss, but adherence to it falls over time²; when the same programme was delivered by app, website or paper, the app group logged on a mean of 92 days in six months against 29 on paper¹; and in a separate trial, people self-monitoring diet with a mobile app recorded intake more often than those using a website³. Logging survives where people already are. For more and more products that place includes an assistant, which is why the integrations themselves are starting to be requested by one.

That puts a different kind of reader in front of your developer documentation. A human skims for the code sample and the pricing. An agent reads everything literally, follows links, and acts on what it finds. It will happily submit a form ten times if nothing tells it not to, and it will trust an instruction it finds in a page it was pointed at. Designing for that reader means stating the rules plainly, removing every step that needs a person to approve something, and making sure there is nothing valuable an agent could obtain by being tricked. The rest of this post is how we applied those three rules to the API.

llms.txt: a front door agents can read#

llms.txt is a plain-text file at the root of a site that summarises what the site offers in a form language models can read without scraping HTML. Ours explains the consumer product and how estimates are built as ranges (the reasoning is in why calorie estimates should be ranges). Its For developers section says, in a few lines, everything an agent needs to make a first call:

• The endpoint: POST /v1/estimate with a bearer key and a meal as text, a photo or a barcode.
• What comes back: components and totals, each with a low, likely and high calorie value plus protein, carbs and fat.
• Where the key comes from: a self-serve keys page, free, 100 estimates per key per day, no approval.
• Where the full contract lives: a public openapi.json.

An agent that reads those lines knows what the API does, what it costs and what it should tell its human to do next.

Self-serve keys, no approval#

An earlier version of this surface asked agents to file an access request for a human, who then confirmed by email and waited for a person to review it. It was careful, and it was slow: every integration started with a queue.

Now the human signs in on the keys page and creates a key in one click. The key is shown once, can be revoked at any time, and has a fixed daily allowance, so there is nothing to review. The limits do the job the review used to do: a leaked key can spend at most a day's free estimates, and the person who made it can revoke it.

A first call, and the errors worth handling#

The first call is deliberately boring. The agent sends a meal in words, such as "two eggs on toast", and gets back two components and a total, each with a low, likely and high calorie value and grams of protein, carbs and fat. A photo or a barcode goes to the same endpoint and comes back in the same shape, so an integration written against the text case keeps working when the product later adds a camera.

The errors are just as plain, and each one says what to do next:

• 401 means the key is missing or revoked. The agent should ask its human to check their environment, not to paste the key into the chat.
• 400 names the field that is wrong: empty input, text that is too long, a barcode that is not 6 to 14 digits, or a file that is not a photo.
• 422 means the input was understood but is not food, so there is nothing to estimate.
• 429 means the key has used today's allowance. The response says when it resets, and the rate-limit headers on every reply let an agent slow down before it gets there.

Every estimate is read-only. Nothing is logged to anyone's diary, so an agent can retry a call safely or run the same meal twice to compare answers without leaving anything behind.

A developer MCP with three tools#

For agents that speak MCP, the same guidance is exposed as a small server with three tools and no sign-in:

• describe_nutrition_sdk returns a static description of the SDK and the API: packages, platforms, locales, authentication model, events, and links. It lets an agent answer "is this the right fit?" without guessing from marketing pages.
• get_api_key returns the keys page, the limits and a ready-to-run request, so the agent can tell its human exactly what to do.
• try_estimate runs one text estimate through the keyless playground, so the agent can show a real result before anyone creates a key.

Each tool description carries the same short instructions for agents: keys are self-serve, never ask the human to paste a key into the chat, and use the playground for a sample. Nothing on this server can read or change anyone's food log.

What agents still can't do (hold the key)#

The rule that has not changed: the agent never receives the key. The human creates it on a page they are signed in to and puts it in their own environment. The MCP never returns one, and the instructions tell agents not to ask for it in the chat.

This is a deliberate limit. An agent that can mint keys is one prompt injection away from minting them for someone who never asked. Keeping keys out of the agent path means the worst an agent can do is run a few playground estimates.

It also keeps the ergonomics honest. Agents are good at research, comparison and wiring up code, and the developer surface lets them do exactly that. Creating and holding the key stays with a person, and now that takes a minute instead of a review.

FAQ#

Is this the same MCP server as the ChatGPT app?#

No. The consumer connector logs meals for signed-in users. The developer server describes the SDK, explains how to get a key and runs playground estimates; it cannot read or change food logs.

Do I need approval to use the API?#

No. Sign in on the keys page and create a free key; each key gets 100 estimates per day.

Can my agent create the key for me?#

No. You create it yourself on the keys page and keep it in your own environment.

Sources#

1. Carter MC, Burley VJ, Nykjaer C, Cade JE. Adherence to a smartphone application for weight loss compared to website and paper diary: pilot randomized controlled trial. J Med Internet Res. 2013.
2. Burke LE, Wang J, Sevick MA. Self-monitoring in weight loss: a systematic review of the literature. J Am Diet Assoc. 2011.
3. Turner-McGrievy GM, et al. Comparison of traditional versus mobile app self-monitoring of physical activity and dietary intake among overweight adults participating in an mHealth weight loss program. J Am Med Inform Assoc. 2013.

Source: BurnWeek — "Letting AI agents add nutrition tracking: MCP and llms.txt", https://burnweek.fit/blog/ai-agents-nutrition-tracking-mcp-llms-txt/. Licensed CC BY 4.0: free to quote or reuse with a link to this page.