What does a client need to connect to IZeat?
IZeat is the calorie tracker inside ChatGPT, Claude or any other assistant. Tell the assistant you already use what you ate instead of searching for foods and entering them one by one. "Any other" is meant: IZeat is a remote MCP server over HTTP with its own sign-in page, and a client built for one can record meals through it. You need an IZeat account, created on the web with Google or with an email and a password, and a client that reads a list of MCP servers and supports a remote HTTP server with sign-in.
Three things the client must be able to do, in plain words. Connect to a server by address rather than by launching a local program. Open a sign-in page in a browser when the server asks for it, without needing a client id or a secret from IZeat, and hold the result; that sign-in is IZeat's own, tied to the account you choose, and revocable from your Assistants page. And relay the server's replies to the model and to you as they are, so that the receipt you read is the one IZeat wrote. Whether a given client does all three is what the check question tells you; IZeat has not tested clients beyond those its docs name.
Cursor and Windsurf are named as examples rather than as clients we have tested, and every client has its own file and its own menu: if yours differs, its own documentation says where the servers go. On the IZeat side, the connection guide is the page kept current.
How do you add IZeat to a client that reads a list of servers?
With one address and a sign-in. Every client that speaks MCP over HTTP reads a list of servers somewhere; where that list lives is the client's business, and the per-client paths we have tested are on the connection guide rather than duplicated here.
https://izeat.app/api/mcpThe block below is the shape most file-based clients read. It is an example rather than a format every client shares, and the only parts that are IZeat's are the address and the type: http, because IZeat is remote. There is nothing to download and no command to launch.
{ "mcpServers": { "izeat": { "type": "http", "url": "https://izeat.app/api/mcp" } } }The sign-in is IZeat's own page, opened in your browser, where you say which IZeat account this client may write to; Allow, and the client holds the connection until you revoke it from your Assistants page.
How do you check it works before trusting it with a meal?
Ask one question that reads your account and records nothing: "Who am I in IZeat?" What proves the connection is that IZeat identifies the account: the answer names the account and the email the connection belongs to, and today's date in your time zone. A line beginning with "IZeat ·" is the convention the model is asked to keep, and it can be missing on a call that worked, so it is the account that settles it and not the prefix. If IZeat does not know your time zone yet, the reply says so; giving your city is a separate step, a profile change, and the reply to it is signed too.
“Who am I in IZeat?”
IZeat · Connected account: Sam Lee (sam@example.com). Today is Friday 11 September 2026 in Europe/Paris.
This question is also the test of the client itself, and it is read on the account rather than on the wording: if it names an account that is not yours, revoke the connection from the Assistants page. A missing "IZeat ·" prefix says nothing either way, on one reply or on every reply, because a model can drop it. A client that names your account can reach IZeat and relay a result. It does not yet prove the client will follow the protocol for a meal, so the next test is a meal with weights, followed by a read of the day; if both come back with the same figures, the client does the whole job.
What do you say for the first meal, and what comes back?
The same sentence as in any assistant: the meal, the foods, how much of each, a weight in grams or a volume in millilitres when you have it, and what a dish was cooked in. For example:
“For lunch I had 180 g of grilled chicken breast, no oil, 80 g of steamed sweet potato and about 40 g of my homemade sauce.”
IZeat sends the model its instructions when the client connects, and a model that follows them asks what the words leave open, then calls IZeat once with the whole meal, each item with its grams, calories, macros and source.
IZeat · Recorded for Friday 11 September 2026 (today): lunch — grilled chicken breast 180 g, steamed sweet potato 80 g, homemade sauce 40 g — 455 kcal · P 58g · C 20g · F 15g (estimated). Total: 455 kcal · P 58g · C 20g · F 15g. Against the target: 1545 kcal remaining · 92g protein remaining.
Read the receipt, not the chat around it. It begins with "IZeat ·", lists each food with its quantity in grams, the meal's calories and macros, then the day's total and, once you have set a target, what is left. Each row keeps its own source: here the chicken and the potato are reference values for the grams you gave and the sauce is an estimate, which is why the meal is marked estimated; ask "what is in my lunch?" or open the web app to see the source row by row.
| What IZeat's instructions ask of the model | What the client has to allow, as we reason it | What you see if it works |
|---|---|---|
| Ask one bundled question when the amount, the serving of a homemade dish or the cooking fat is left open | Show the model's question before any tool call, without a prefix | A question, then a receipt; never a number from a bare photo |
| Call IZeat once with the whole meal, each item with its source | Pass the tool call and its result through as returned | One receipt per meal, beginning with "IZeat ·", with the total and what is left |
| Keep the "IZeat ·" prefix on every answer built on an IZeat result, reads included | Not rewrite or strip the tool result | A read of the day signed the same way as a write |
| Relay a refusal as returned; it says "Nothing was recorded" and what to do next | Not paper over an error | A signed refusal, and nothing written |
| Read a meal back before correcting it, then update it | Let the model read, then write, in the same turn | The change and the new total, the previous state kept |
Bottom line: the client's job is to get out of the way; if the receipt reads as IZeat wrote it, the client did.
What do you do when it goes wrong?
Connected to any client, IZeat is designed to make the diary easier to keep while you work toward your goal; when something is off, the receipt is what tells you, and these are the cases that differ from the named assistants.
- The client asks for a client id and a secret. IZeat has none to give: it identifies the client by itself and brings its own sign-in page. In Claude that is the "Requires sign-in" switch, left off; in another client, leave those fields empty or look for the option that lets the server bring its own sign-in. A client that only supports servers without any sign-in cannot connect.
- The client asks for a command to launch. IZeat is remote; there is no command. Look for the remote, http or url option in the client's server settings, and use the address alone.
- A missing "IZeat ·" prefix. It is not a fault and not a test. The prefix is a convention the model is asked to keep, so a reply can lose it after a call that worked, and a question back from the assistant carries none at all. Whether the connection works is settled by the check question: ask "Who am I in IZeat?" and read whether it names your account.
- A photo of a plate got a number without a question. That is not the protocol; the model did not follow the instructions it was given, or the client did not pass them. Say the portion and the cooking fat and ask for the item to be corrected.
- The model ignores IZeat and answers from memory. Some clients may keep a server's tools off until you enable them for the session, or need the model to be told; say "record this in IZeat" and look for the receipt. If it never appears, the client's own documentation says how its tools are enabled.
The limit, plainly: IZeat has tested the assistants its docs name and makes no claim about any other client or model, whether Gemini, Mistral, a local model or a tool of your own; the check question and the receipt are how you find out, and the sentence is only as good as the weights it carries.
Frequently asked questions
Short answers to the questions people type, each one sourced above.
Does IZeat work with Gemini, Mistral or a local model?
IZeat makes no claim about any client it has not tested, and its docs name ChatGPT, Claude and Claude Code. What it offers is a remote MCP server over HTTP with its own sign-in; any client that can connect to one, open the sign-in page and relay tool results as returned can record meals through it. The check question shows whether it can reach IZeat and relay a result; only a meal recorded and read back shows it does the whole job, which we have done with the three clients named and no other.
What is MCP, in plain words?
MCP, the Model Context Protocol, is an open standard that lets an assistant use outside tools during a conversation: a server publishes what it can do, the assistant calls it with what you said, and the server answers with facts. IZeat is such a server: it can record a meal, read a day, set a target. The assistant supplies the model that understands your sentence; IZeat supplies the record, the calculations and the instructions that ask the model to question before it estimates.
Is there a token or an API key to paste?
No. IZeat uses a sign-in page of its own: when the client connects, it opens that page in your browser, you sign in to your IZeat account and allow the connection, and the client holds the result. Nothing is pasted into a file but the address. A client that asks for a client id and a secret is asking for something IZeat does not issue: in Claude that is the "Requires sign-in" switch, left off; elsewhere, leave those fields empty and let IZeat bring its own page.
Can several clients use the same IZeat account?
Yes: each is a connection to the same account, listed in the connection guide, and each can be revoked on its own. A meal recorded from one client is in the day another reads, with the same sources and totals, because IZeat holds one record. The web app shows that record on any device, read-only.
What if my client shows the tool result raw?
Then you are reading the receipt itself, which is the point: the result carries a statement that begins with "IZeat ·" and states what was recorded, the meal total and what is left, next to the same figures as data. A client that shows it raw is relaying it as returned. What matters is that the model's own words around it do not replace it, and that a figure about your food without the prefix is read as the model's, not IZeat's.
Does IZeat send the client anything besides tool results?
Its instructions, once, when the client connects: what the tools do, what to ask before estimating, how to sign a reply, and that the target is the customer's. A model that reads them follows IZeat's protocol; a client that drops them leaves the model to guess, which is one reason a bare photo can come back with a number. Every tool result then carries a statement that begins with "IZeat ·" and the same figures as data, so the receipt you read is what was written.
Is the JSON block the same for every client?
The content is: a server named izeat, type http, the address https://izeat.app/api/mcp. The file it goes in, and the key it goes under, differ by client; mcpServers is the usual shape, and Cursor and Windsurf are the connection guide's examples. Some clients take the address in a form instead of a file. The address and the transport are all IZeat needs; the rest is the client's convention.
Does the same setup work in ChatGPT, Claude or Claude Code?
Those three have their own guides, because their menus are known: ChatGPT adds an MCP server from its own settings, Claude adds a custom connector or uses a one-tap button, and Claude Code takes one command; the connection guide carries each path. Once connected, the meal is the same sentence and the receipt the same receipt, because the record and the protocol are IZeat's.