supp.fit over the Model Context Protocol

This server gives an AI assistant read access to supplement evidence taken from published studies, a catalogue of real supplement products, and — if you allow it — your own stack and intake log. It is one endpoint, it is read-only, and every tool needs a signed-in supp.fit account.

What it is

The Model Context Protocol, or MCP, is how an AI assistant reaches data that is not in its training set. A client such as Claude or ChatGPT connects to an MCP server, reads the list of tools it offers, and calls one when a question needs it. This server is the supp.fit side of that connection.

Without it, an assistant answering a question about a supplement writes from memory: no study, no year, no participant count, and no way for you to check. With it, the assistant reads the same evidence base the supp.fit website is built on, and every claim it repeats can be traced back to the paper it came from.

What you can ask it

These are questions the tools below can answer. The wording is yours; the tool is what the assistant picks.

What does the evidence say about ashwagandha for anxiety, and how many studies is that based on?
How strong is the evidence behind creatine for muscle strength?
Show me the individual trials behind magnesium and sleep, with participant counts and years.
What is in my supplement stack right now, and what is the evidence for each item?
Which supplements did I stop taking, and when?
Did I actually take my vitamin D over the last thirty days?
How many capsules of each item did I take in July?
Find products that contain magnesium bisglycinate and show me the Supplement Facts panel.

How to connect it

Point your MCP client at the endpoint and follow the sign-in it offers. There is nothing to install and no API key to copy.

POST https://mcp.supp.fit/mcp

Some clients ask only for a host. The bare host works too — a POST to the root is the same endpoint. https://mcp.supp.fit

In a client that is configured from a file, the entry is:

{
  "mcpServers": {
    "supp-fit": {
      "type": "http",
      "url": "https://mcp.supp.fit/mcp"
    }
  }
}

What each tool does

The list is deliberately short. The supp.fit API has well over forty endpoints; a tool for each would give an assistant a list it cannot choose from, in which two entries differ by a single word.

Evidence, products and brands — `evidence.read`

Tool	What it returns
`search_supplements` Search supplements	Find supplements by name or by a known synonym, with how many benefits and how many studies supp.fit holds for each. Use this first when a question names a supplement, to get its slug for the other tools.
`get_supplement` Get one supplement	Everything supp.fit holds about one supplement: every benefit it has evidence for, how strong that evidence is, how many studies support it, and the measured impacts. Takes a slug from search_supplements.
`get_benefit_evidence` Get the studies behind one benefit	The individual studies behind one supplement-and-benefit pair: PubMed id, title, year, participant count, trust score and supp.fit's own summary. This is the large answer; call it only when a question is about the strength of the evidence rather than about what the evidence says.
`get_article` Get one study	One study by its PubMed id: title, year, and supp.fit's summary of what it found for each supplement it covers. The full paper text is never returned — it is licensed. Follow the `url` to PubMed for the paper.
`search_products` Search the product catalogue	Search real supplement products by name, brand or ingredient. A query is required: there is no way to list the whole catalogue, because no column in it can honestly rank one product above another.
`get_product` Get one product	One product: its brand, category, price and its Supplement Facts panel. IMPORTANT: the panel is present only when the product's barcode matched a registered label AND the brand agreed. When `has_confirmed_label` is false there is no panel, and that means the match could not be confirmed — it does NOT mean the product has no ingredients. Never tell a reader a product contains nothing.

Your own data — `me.read`

Tool	What it returns
`whoami` Who this connection belongs to	The supp.fit account this connection was authorised by. Use it to confirm whose data the personal tools will return.
`get_my_favourites` Saved supplements and bottles	What this person has saved on supp.fit: supplements and products.
`get_my_stack` What this person takes now	The supplements and products this person is currently taking, with the dose, the unit and the schedule for each.
`get_my_stack_history` What this person used to take	Periods that have ended, newest first. Stopping something does not delete it, so a supplement taken twice appears as two periods.
`get_my_log` Whether this person actually took it	The daily intake answers inside a date window, capped at 400 days. IMPORTANT: a date with no answer means nobody said, which is NOT the same as a missed dose. Do not count silence as a skip.
`get_my_consumption` How much of each item was taken	How much of each item this person took over a window, grouped per item AND per unit. IMPORTANT: do not add these figures together across items or across units, and do not convert them into milligrams of a nutrient. Capsules, softgels and millilitres are different things, and no compound-to-element conversion table exists here — a guess is typically seven times too high, in the direction that hides an upper-limit warning. Report the figures as they come back.

What it may read, and what it may not

Two scopes, ticked separately on the consent page, so the evidence half can be granted without the personal one.

Scope	Covers
`evidence.read`	supplements, benefits, findings, study summaries, products, brands. Nothing about you.
`me.read`	your favourites, your current stack, the periods that have ended, and your intake log.

Everything is read-only. No tool writes, edits or deletes anything, and the server has no write path to the database. It holds no secret of its own either: it carries the token your client was issued and nothing else, and every decision about what that token may read is made by the API rather than here.

Full paper text is never returned. It is licensed, so the tools return supp.fit's own summary and a link to the paper on PubMed.

Questions people ask

Do I need a supp.fit account to use this MCP server?

Yes. Every tool needs a signed-in supp.fit account, including the ones that read evidence the website shows to anybody. Your MCP client sends you to the consent page, you sign in with Google, and you choose what to share.

Why does public evidence need a sign-in?

An assistant is a loop, and almost every useful question mixes the public half with the private one: what the studies say, and what you are actually taking. One rule for every tool is a rule that can be tested. A per-tool judgement is a thing somebody eventually forgets.

Can it change anything in my account?

No. Every tool is read-only. There is no tool that adds a supplement to your stack, records a dose, edits your log or deletes anything, and the server has no write path to the database at all.

What can it read about me?

Only what the scope you granted covers. The evidence.read scope covers supplements, benefits, studies, products and brands, and says nothing about you. The me.read scope covers your own favourites, your current stack, the periods that have ended and your intake log. They are separate tick boxes, so you can grant the evidence half and withhold the personal one.

Which clients can connect to it?

Anything that speaks the Model Context Protocol over Streamable HTTP and can follow an OAuth 2.1 flow. That includes Claude, ChatGPT's connectors and the MCP command line tools. The server is stateless, so it issues no session id and opens no event stream.

Where does the evidence come from?

From published studies on PubMed, read and summarised on supp.fit. Every finding carries the study it came from, so an assistant can name the paper, the year and the number of participants rather than asserting a claim on its own authority. The full paper text is never returned, because it is licensed.

What does a missing Supplement Facts panel mean?

That the product's barcode could not be matched to a registered label, not that the product has no ingredients. The two look identical in the data and mean opposite things, so the tool description says so in words and an assistant is told never to report that a product contains nothing.

Endpoints

URL	What it is
`POST https://mcp.supp.fit/mcp`	the MCP conversation. A POST to the root is the same thing.
`GET https://mcp.supp.fit/.well-known/oauth-protected-resource`	where to get a token, as RFC 9728 describes it.
`https://api.supp.fit`	the authorization server. It issues every token this server spends.
`GET https://mcp.supp.fit/llms.txt`	this page as plain text, for an agent reading rather than browsing.