Ask a reasoning model to design an experiment and it will hand you something plausible in seconds — an assay type, a set of controls, a target concentration range. That output is not an experiment. It's a draft that no lab can act on yet, and the gap between the two is exactly what most "AI agent + biology" demos skip over.
Litmus closes that gap with an open MCP server that any agent — Claude, ChatGPT, or your own reasoning loop — can call directly. This is a walkthrough of what actually happens between an agent deciding what it wants to test and a lab receiving a sample.
"Designing the experiment is the easy part. Submitting one a lab can act on is the part that usually gets skipped."
1An experiment is a spec, not a sentence
"Test whether compound X inhibits target Y" isn't submittable — it's missing the parts a lab actually needs to quote and run the work. Before anything gets routed anywhere, an experiment needs:
- Acceptance criteria — a metric, an operator, and a threshold (e.g.
IC50 lte 10 µM), plus the statistical requirements that make the result meaningful - Budget constraints — a maximum spend and how flexible it is (strict, or flexible by 10/25/50%)
- Turnaround constraints — a target number of days and a priority (standard, expedited, urgent)
- Privacy terms — open, delayed 6 or 12 months, or fully private, each with its own pricing
An agent that only produces the first sentence hasn't designed an experiment — it's produced a research idea. The MCP server's job is turning that idea into the structured spec above, automatically.
2The four calls a connected agent makes
Once an agent is authenticated against the Litmus MCP server, going from a plain-language question to a submitted experiment is four tool calls:
intake.draft_from_text does the work described in step one — turning a plain-language request into the structured spec, filling in acceptance criteria and constraints an agent didn't think to specify. intake.validate catches problems before they cost anything: insufficient replicates, missing controls, statistically underpowered designs. routing.match_labs returns real turnaround and cost estimates from the qualified network. intake.submit is the only call that actually spends money or reserves lab time.
3What happens after intake.submit
A submitted experiment moves through a fixed lifecycle: Open → Claimed → In Progress → Results Submitted → Approved / Disputed. Your agent doesn't need to babysit any of it — it polls or receives a webhook when the state changes, and the only decision it has to make comes at the end, when results land against the acceptance criteria it defined in step one.
Because the result references the criteria the agent set going in, it can decide on its own whether to approve, dispute, or move straight to the next design round — no human re-reading a PDF to figure out whether the run actually worked.
4Two different integration paths
Everything above describes an agent — Claude, ChatGPT, your own reasoning system — calling the MCP server directly with its own credentials. That's the right path if you're building or running the agent yourself; the tool schemas and setup are in the MCP integration guide and the open-source server repo.
If you're building a product that other people use — and you want your own users to connect their Litmus account and have your product call these tools on their behalf — that's a different flow: OAuth, not a shared API key. The full walkthrough, including the PKCE authorization flow and token handling, is at platform.litmus.science/docs.
The short version
An agent that can only produce a research idea hasn't done anything a lab can act on. One that can call four tools — draft, validate, match, submit — has turned that idea into a tracked, priced, running experiment, and gets a structured result back it can reason over directly. That's the actual distance between "AI for science" as a demo and as something that produces real evidence.