Use PipePilot from an AI app
Connect Claude or another app that speaks MCP to PipePilot, and ask it to run, check and compare networks with EPANET.
PipePilot also runs as an MCP server, the standard way AI apps call outside tools. Add the address https://geopilotai.com/api/mcp/pipepilot to an app that takes a remote MCP server by URL, and the app can run a network with EPANET 2.2, read its results and check it against CPHEEO, the same way the workspace does. No account or key is needed.
Connect an app
- Claude Code: run claude mcp add --transport http pipepilot https://geopilotai.com/api/mcp/pipepilot.
- Claude and other chat apps: add a custom connector (it may be called an MCP server) and paste the address.
- Your own code: any MCP client that speaks Streamable HTTP can call the address with POST requests.
Give it a network
Every tool except pipepilot_import_gis and pipepilot_create takes one network, in one of three ways:
- example: one of the networks in the Start gallery, such as net1 or esr-town-zone. pipepilot_list_examples lists them.
- url: a public link to an .inp file, such as the Raw link of a file on GitHub. This is the best way for a large network, because the app does not have to copy the whole file into its request.
- inp: the .inp text itself, for a small network the app already has.
Each call opens the network afresh, runs it if the tool needs results, and closes it. PipePilot keeps no copy. The app you use sends the network and your questions to its own AI provider, under that provider's terms.
The tools
| Tool | What it returns |
|---|---|
| pipepilot_list_examples | The example networks, by id. |
| pipepilot_run | Counts, units and options, the lowest pressures and highest velocities with their times, a CPHEEO verdict at the peak hour, the model check counts and EPANET's warnings. |
| pipepilot_find_objects | Nodes or links whose property or result is below, above or equal to a value, worst first. |
| pipepilot_get_object | One node or link: its inputs, its connections and its results at a chosen hour. |
| pipepilot_compliance | The CPHEEO check of the compliance article: counts, the worst failures and every threshold with its clause. |
| pipepilot_explain_node | Why a junction has the pressure it has: the upstream path, the pipe that loses most head, its elevation and demand. |
| pipepilot_check_model | The model check from Fixing problems, without a run. |
| pipepilot_what_if | The network run before and after a set of edits (diameters, roughness, demands, settings and others), with the junctions whose pressure changed most, and the edited .inp if asked for. |
| pipepilot_import_gis | A new network from GeoJSON (pipes as lines, optional points) or CSV pipe and node tables: the .inp, counts, problems, the attribute mapping used and a run summary. |
| pipepilot_create | A new network from a JSON description of its junctions, reservoirs, tanks, pipes, pumps, valves, patterns, curves, controls and options: the .inp and a run summary. |
| pipepilot_edit | A network after a list of edits (add, delete or move objects, set any property, patterns, curves, controls, options and times): the new .inp, what changed and the run before and after. |
| pipepilot_field_compare | The model against field readings (logger pressures, heads, tank levels or meter flows, as CSV or rows): error statistics per location and overall, the worst locations, and every reading that could not be matched, with the reason. |
| pipepilot_calibrate | Hazen-Williams C per pipe group (and optionally a demand multiplier) fitted to field readings by the search of the Calibration window, from several starts and with a prior per group from its material and age: RMSE before and after, C per group with its uncertainty, whether the readings or the prior decided it, how far the starts disagree, where one more logger would help, a plain verdict on the fit, and the calibrated .inp. |
| pipepilot_plan_loggers | Before a field campaign, the k logger sites (pressure, and optionally flow) that make the C of every pipe group most identifiable, by a greedy D-optimal design over the sensitivities of the model, with the expected uncertainty of each C against a naive even spread. |
| pipepilot_twin_check | Live sensor readings against the model: each sensor's deviation level, a drift score, freshness, a water balance, and ranked anomaly hypotheses (sensor fault, leak or burst, network-wide bias, localized deviation) with their evidence. |
| pipepilot_twin_locate | The junctions where an added leak best explains the live readings, each with a score, an estimated leak flow and the expected against observed change at every sensor. |
| pipepilot_twin_update | Recalibration of pipe roughness and demand on the recent readings when the model has drifted past a band, with the drift before and after and the updated .inp. |
Limits
- About 30 calls a minute from one address.
- A network sent as text must be under about 4 MB; up to 5 MB can be fetched from a link.
- Links must be public http or https addresses. Private and local addresses are refused.
- Results are in the network's own units, as in the workspace. A US-unit network reports pressure in psi.
The AI app chooses which tools to call and writes the answer. Check any number it quotes against a run in the workspace before you rely on it.