EthosPowerAI
Name the project and its owner
PyPowSyBl MCP is a Model Context Protocol server that puts the pypowsybl power-system library behind tools an AI agent can call: load a network, run an AC or DC load flow, clone a variant, run security analysis, plot a single-line diagram. It sits in the PowSyBl organisation on GitHub, carries the MPL-2.0 licence with the line "Copyright (c) 2026, RTE", and lists Jérôme Picault and Clément Goubet of RTE as its authors. On 2026-10-17 the repository was 115 days old, with 7 stars, 2 forks, 4 open items and roughly 10 commits, the last on 2026-09-29 (a73d46d, a migration to version 2 of the MCP Python SDK). The package calls itself 0.1.0.dev1 and "Development Status :: 3 - Alpha"; it has no releases and is not on PyPI, and its own README opens by calling it a prototype whose use in critical production systems is "discouraged".
That candour deserves to be taken at face value, because the code agrees with it: the server pins pypowsybl 1.15.0, speaks Streamable HTTP only on port 9992, and keeps every session in memory, up to 100 sessions of 10 networks each with a one-day lifetime, all of it gone the moment the process restarts and none of it written anywhere an operator would look for it.
Ask the planner's question
A developer wants to know whether a 50 MW battery exporting at bus 3 overloads anything when one line trips. The solution I would build on this server answers that question in the order a planner would. The agent loads the model, runs the base-case load flow, clones a variant so the base case stays untouched, applies the export, runs security analysis with N-1 line contingencies generated automatically, lists post-contingency overloads and voltage violations, draws the substation, and asks for a Python script the engineer can rerun. The engineer signs the study, and nothing in the design writes back to an operational model, because the server's sessions are scratch space and should stay that way.
Correct two easy assumptions
The first assumption is that the agent can add a battery to the model; it cannot. The released code has no tool that creates an element — issue #17 asks for one and pull request #20 is still open — and modify_network changes only what already exists. So the design emulates the battery by setting target_p on a generator already connected at the bus, or by modelling the export as a negative load, and the study records which. That is a workaround, and the report should call it one.
The second is that generate_python_script replays the session. It asks a second language model to write the script, which needs an OPENAI_API_KEY, so what comes back is a draft to review rather than a deterministic record of what the agent ran. The engineer reruns it and compares the numbers before relying on it.
Run it before trusting it
The same steps ran directly in pypowsybl 1.15.0 on the IEEE 14-bus case on 2026-10-17, with generator B3-G raised from 0 to 50 MW in a cloned variant. Both load flows converged in three iterations; the flow on line L1-2 fell from 156.9 MW to 115.4 MW, and bus voltages stayed between 1.01 and 1.09 per unit. All 17 single-line contingencies converged, and the worst post-contingency flow fell from 240.1 MW on L1-2 with L1-5 out to 189.7 MW on L1-5 with L1-2 out. That is one textbook case, not anybody's connection study.
Two findings matter more than those numbers. With the default 'distributed slack', the load flow shaved the battery to 32.4 MW by spreading the mismatch across every generator, so the agent has to switch slack distribution off or the study answers a different question. And the security analysis reported zero violations because the case carries zero current limits and no voltage limits; 'no overloads' on a model without ratings is an empty sentence, so the agent checks for limits before it says it.
See the design
See the design, its diagram and the demo at the solution, where the demo replays the run above with its real values. The server is young, honest about it and useful for screening. A signature still belongs to an engineer.