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 SDK for a React Native app and sign us up for access". 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 is and request access on behalf of the human it works for, without ever holding credentials.

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, keeping every write path idempotent and consent-gated, 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 access requests for the SDK.

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 already explains the consumer product and how estimates are built as ranges (the reasoning is in why calorie estimates should be ranges). It now has two more sections.

For developers describes the SDK and the estimation API in a few lines, with links to a public openapi.json that covers only the developer access endpoints.

Instructions for AI agents is short and explicit:

• Request access only when your user asked you to.
• Request on the user's behalf with their email; they will get a confirmation email and must click the link before a person reviews the request.
• Keep the request id and poll the status at most hourly; relay the result to your user.
• You will never receive credentials; approval is sent to the human by email.

Those four lines do most of the work. An agent that reads them knows what it may do, what will happen next, and what it should not expect.

A developer MCP with three tools#

For agents that speak MCP, the same flow is exposed as a small, read-and-intake-only server with three tools:

• 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.
• request_access files an access request.
• check_access_status returns the current status of a request.

The tool descriptions carry the same instructions as llms.txt, verbatim, so an agent sees the rules whether it arrives through the text file or the protocol. There is no sign-in on this server and nothing on it can read or change anyone's food log.

Filing on a human's behalf: consent by design#

The interesting design problem is consent. An agent is acting for someone, and the request has to say so. request_access takes four parts:

• requester: who is filing, for example an assistant's name, plus an attestation that the human asked for this.
• onBehalfOf: the human, including their email and company.
• followUp: how the agent wants to hear back, polling or an optional callback URL.
• project: what they are building, roughly how many monthly active users, and whether they want the embedded screens, the API, or both.

The response contains a request id, a status of pending_confirmation, and a status URL with a per-request token, because a bare id would let anyone enumerate requests and see who is building what.

Then the human gets an email. It says, in plain words, that an assistant asked for developer access on their behalf, for this company and this use case, and that if it was not them they can ignore the email and nothing happens. Only after they click the link does the request reach a person for review. The same double opt-in applies to requests filed through the web form, so there is one code path, and neither agents nor bots can fill an inbox with unconfirmed requests.

Polling, callbacks and handing back to the human#

A request moves through a small set of states: pending_confirmation, confirmed, then approved or declined, or expired if the human never confirms. An agent polls check_access_status with the request id and token, which returns only the status, a timestamp and a short message, never the personal details that were submitted.

Agents that cannot poll can pass an HTTPS callback URL. Status changes are then delivered as a signed POST using the same generic signature headers as our other domain events, so a developer who later integrates the SDK's events already knows the format.

The end state is always a handover. When a request is approved, the agent's job is to tell its human to check their email.

What agents can't do (get credentials)#

The rule that shapes everything above: agents never receive credentials. Not an API key, not a client id, not a test token. Approval and everything needed to start building go to the confirmed human by email.

This is a deliberate limit. An agent that can obtain credentials by filling a form is one prompt injection away from obtaining them for someone who never asked. Keeping credentials out of the agent path means the worst an agent can do is file a request that a human then ignores.

It also keeps the ergonomics honest. Agents are good at research, comparison and paperwork, and the developer surface lets them do exactly that. Deciding to integrate a nutrition tracker into a product, and holding the keys to it, stays with a person.

FAQ#

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

No. The consumer connector logs meals for signed-in users. The developer server only describes the SDK and handles access requests, and it cannot read or change food logs.

Can an agent approve its own request?#

No. The human must confirm by email before anyone reviews the request, and approval is manual.

What if my agent cannot poll?#

Pass an HTTPS callback URL with the request and status changes are delivered as signed POSTs.

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.