RsNLME meets MCP: the pharmacometric AI assistant scientists have been asking for

For decades, a steep technical wall has stood between a pharmacometrician’s scientific theory and the software required to run it. Scientists got into the field to push medicine forward, only to find themselves acting as amateur software administrators and programmers. We built this new MCP server to tear that wall down. By loading purpose-built tools and a curated PML knowledge base directly into your coding assistant, we created a system that understands both the science and the software simultaneously. You bring the scientific problem, and the tool handles the translation.

What we built

The result is a local MCP server, installed as part of the RsNLME package, that gives any MCP compatible AI assistant structured, purpose built tools for the full NLME modeling workflow. It sits between a coding assistant and the same NLME engine that powers Phoenix, and it comes loaded with a curated PML and NLME knowledge base, so recommendations reflect current pharmacometric practice rather than a generic guess at what R code might work.

This isn’t a passive chatbot that simply talks about pharmacometrics. Think of it as a highly trained personal assistant for your modeling workflow, one that executes the work while you remain responsible for the science. Rather than losing time to manual scripting, a modeler can delegate specific workflow steps while retaining review and control:

• Inspect a PK dataset and propose a column mapping
• Build and fit an NLME model, and judge whether it converged cleanly
• Run a VPC and produce a stratified plot by study
• Generate goodness of fit and covariate diagnostic plots
• Translate legacy model code into PML, then fit it

That last one is worth explaining, because it shows how the assistant actually reasons. It builds an abstract syntax tree of the original model code, reasons over our PML knowledge base to reconstruct the equivalent model, and then sends the result back through RsNLME to validate that it compiles and fits before it is ever handed back to the user. Our focus here is on the built-in expertise. The MCP server bridges the gap between software environments automatically, meaning you don’t need to learn how to connect package A and package B manually, the system orchestrates the integration for you

Proving it against the literature

We did not want to hand this to modelers on faith, so we validated it against real published models first. Working with Mark Sale, a longtime academic collaborator, we compared the MCP driven workflow against a well known population pharmacokinetic dataset with a published reference model. The assistant approached the problem the way an experienced modeler does: structural model first, covariate testing second, decisions made afterward using likelihood ratio tests and prediction corrected visual predictive checks, the same criteria a human would apply. The model it converged on had a meaningfully better objective function than the original published model, not because it cheated the process, but because it followed the same process a careful modeler follows, consistently and without fatigue.

We also asked it to go further than a single fit. In one demonstration, we gave it a single instruction: perform a full population PK analysis, including exploratory data analysis, base model development, stepwise covariate modeling, a visual predictive check, and goodness of fit plots, then write it up in an R Markdown report following EMA guidance, and build a QC package a colleague could use to reproduce the whole thing. It did exactly that. This level of traceability is woven into the entire workflow because the assistant explains its reasoning and documents each step in real time. It ran the exploratory analysis first, compared four structural models on minus twice log likelihood and AIC, tested residual error structures, ran a stepwise covariate search, and saved an independent, inspectable R script at every stage. That last detail mattered to us as much as the science did. It showed its work, the way we would want any collaborator to, instead of handing back a black box result.

Keeping the Modeler in the Driver’s Seat

No tool gets to decide whether a model is scientifically sound; that judgment stays with the modeler. The assistant proposes, validates, and executes. The modeler still decides what a good model is, what a defensible covariate relationship looks like, and when a numerically better fit is not actually a scientifically meaningful one.

What it does change is where a modeler’s time goes. Someone who knows exactly what they want can give the assistant precise, step by step instructions and it will execute them exactly, in R, using RsNLME, backed by the NLME engine. Someone less certain can describe the objective in plain language, closer to how they would brief a colleague, and let the assistant plan the workflow, confirm the plan before committing to anything, and explain its reasoning whenever asked why it made a particular decision.

One of our colleagues described it well after watching it run for the first time: it behaves like a senior pharmacometrician sitting next to you, one who happens to also know R, RsNLME, and PML fluently, and who never gets tired of writing the twelfth version of a goodness of fit script.

Bridging the Gap Between Modeling and Code

That is the version of this tool we set out to build, not because we do the science ourselves, but because we have spent our careers close enough to the people who do to know what was missing.

RsNLME’s new MCP server runs on the same engine behind Phoenix NLME, and it works today with Claude, Cursor, Codex, and any other MCP compatible coding assistant, right where pharmacometricians already do local, script based work. We built what pharmacometricians have always wanted: a tool that understands both the science and the software at once, so they no longer have to translate between the two themselves.