MCP automation
What it does
Phasor makes its model and study operations available as an MCP server. MCP is the Model Context Protocol. This is the same tool surface that the in-app assistant uses. Everything that the assistant can do, your own scripts and agents can also do — over a documented protocol, not through the user interface.
This makes repetitive engineering work practical:
- Batch studies. Run a power flow for forty demand scenarios. Collect the violation lists.
- Sweeps. Change a transformer tap or a cable size in steps. Record where the result crosses a limit.
- Report generation. Pull the results into your own document template.
- Regression checks. After a model change, run the cases from last month again. Compare the answers.
- Bulk edits. Apply a naming convention or a rating update to hundreds of elements.
How it connects
MCP is a client–server protocol. Phasor is the server. Your agent, editor or script is the client.
- Start the server. Select Settings → Automation. The server listens on the local machine only.
- Connect a client. Each MCP-capable client works — a coding agent, an orchestration script, or a notebook with an MCP client library.
- Discover the tools. The client asks the server what it can do. The tool list describes itself, including the argument schemas. You do not need a separate API document.
- Call the tools. Open a project. Read elements. Run a study. Read the results. Apply edits.
The tool surface
The tools are in groups, by what they touch:
| Group | What it does |
|---|---|
| Project | Open a project, save it, and report what is loaded. |
| Model read | List and examine elements, connectivity, ratings and settings. |
| Model write | Create, change and delete elements — through the command gate. |
| Scenarios | Create and select loading scenarios. |
| Studies | Configure, run and cancel a power flow, a short circuit study and the other cases. |
| Results | Read results, violations and study metadata, by run. |
| Topology | Islands, cycles and path traces, as in Graph Space. |
Each write goes through the same command gate as a human edit. Because of this:
- You can undo a scripted change.
- Each scripted change appears in the project history.
- A script cannot go around the validation of the model.
An example sequence
A typical automation session has this shape:
- Open the project file.
- Select the scenario — for example, peak demand.
- Run the power flow case.
- Read the violation list from the run.
- Change one value — for example, a tap position.
- Run the case again and compare the two runs.
- Write the comparison into a report.
Each step is one tool call. The client decides the sequence.
Notes
The server is local. The server binds to the local machine only. There is no remote endpoint. There is no authentication token that can leak, because nothing listens off the machine.
Writes are real. A script that deletes elements deletes them. While you develop an automation, work on a copy of the project. Use the undo history as your protection. Do not depend on the script being careful.
Each result belongs to a run. Phasor keeps each study run with its timestamp. A report can name the exact run that it came from. A regression check can compare two named runs — not "before" and "after".
The same tools, two callers
The assistant and your scripts share one tool surface. If you can get a result from the assistant interactively, you can automate the same steps. The automated version behaves identically.