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. It also gives the dose per serving that product labels in the catalogue print (`dose_per_serving`), the daily dose study groups took (`research_dose`), each with the median, the middle half, the bands and the most common band, and what study groups commonly took with it (`commonly_taken_with`). These are printed and studied amounts, not a recommended dose. Each keeps its own unit: do not convert IU into a mass and do not add amounts together. Takes a slug from search_supplements.
`get_supplement_protocols` Get what each study gave of one supplement	The study protocols for one supplement: one row per study group, with what it took a day, the unit, for how many days, how many people, the design and relevance grades, the PubMed id, and what else the same group took (`together`). Pass `with` to keep only the groups that also took every one of those supplements, each row then carrying their daily doses. A study dose is not a recommendation. Each amount is in its own unit: do not add amounts across rows or units, and do not convert IU into a mass.
`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. For each supplement on the label (`label_supplements`) it gives the label's own lines, the middle half of what other bottles print per serving and of what study groups took a day, and what studies commonly gave with it, split into in this product and not in it. Never add the lines or the amounts together, and do not call this bottle's dose too high or too low from them. `claims` are what the label prints; an absent claim is silence, never a NOT. IMPORTANT: the panel is present only when a registered label was matched and confirmed, or the label's photograph was read with confidence. 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.proof.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.