1
Grid-Orch: An LLM-Powered Orchestrator for Distribution Grid Simulation and Analytics
arXiv:2605.12728v1 [eess.SY] 12 May 2026
Boming Liu, Member, IEEE, Jin Dong, Senior Member, IEEE, Jamie Lian, Senior Member, IEEE
Abstract—The power distribution engineering workforce faces a projected shortage of up to 1.5 million engineers by 2030, creating urgent demand for more accessible analysis tools. This paper introduces Grid-Orch, a framework that bridges Large Language Models (LLMs) and power system simulation through the Model Context Protocol (MCP), enabling engineers to perform complex distribution analyses via natural language. Using OpenDSS as the reference implementation, Grid-Orch provides 36 domain-specific tools across eleven categories—covering power flow, voltage analysis, quasi-static time-series (QSTS) simulation and automated optimization. A provider-agnostic LLM layer supports both cloud-hosted (Gemini, Claude) and locally deployed (Ollama, llama-cpp) models, enabling air-gapped operation for security-sensitive utility environments. Three optimization skills—capacitor placement, voltage violation analysis, and overvoltage mitigation—extend the platform beyond single-tool queries to multi-step engineering workflows. The developed GridOrch has an interactive web platform with chat-based interaction, a QSTS dashboard, and feeder topology visualization renders simulation results inline. Workflow demonstrations show that distribution analyses formerly requiring hours of scripting—such as distributed energy resource (DER) interconnection screening complete in under two minutes through natural language, producing numerically identical results to direct OpenDSS scripting. Index Terms—Distribution Grid Analytics, Agentic AI, Power Flow Analysis, LLM Agents, Model Context Protocol, Visualization
I. I NTRODUCTION
T
HE power distribution engineering workforce faces an acute capacity crisis. IEEE PES and Kearney project a shortage of up to 1.5 million qualified engineers by 2030 [1], driven by accelerating grid modernization, mass retirements, and explosive DER integration [2], [3]. The IEA reports that more than 60% of energy companies cite labor shortages as a primary operational constraint [4]. This imbalance (growing grid complexity against a shrinking workforce) calls for tools that let engineers run distribution analyses without specialized scripting skills. B. Liu, J. Dong and J. Lian are with the Electrification and Energy Infrastructures Division, Oak Ridge National Laboratory, Oak Ridge, TN 37830 USA (e-mail: [email protected]). This material is based upon work supported by the U.S. Department of Energy, Office of Critical Minerals and Energy Innovation (CMEI), specifically the Solar Energy Technologies Office (SETO) and Office of Cybersecurity, Energy Security, and Emergency Response (CESER). This manuscript has been authored by UT-Battelle, LLC, under contract DE-AC05-00OR22725 with the US Department of Energy (DOE). The US government retains and the publisher, by accepting the work for publication, acknowledges that the US government retains a non-exclusive, paid-up, irrevocable, worldwide license to publish or reproduce the submitted manuscript version of this work, or allow others to do so, for US government purposes. DOE will provide public access to these results of federally sponsored research in accordance with the DOE Public Access Plan.
Existing simulation platforms fall short on accessibility. OpenDSS [5], the open-source distribution power-flow and quasi-static time-series (QSTS) simulation, requires practitioners to author DSS scripts or navigate its Python bindings. Commercial alternatives (Synergi, CYME, PSCAD) offer graphical interfaces but carry substantial licensing costs that may be prohibitive for smaller utilities and research groups. Neither category provides a conversational interface: engineers must still formulate correct API calls rather than asking questions in natural language. Recent advances in large language models (LLMs) demonstrate that natural language can serve as a practical interface for technical software. Function-calling capabilities [6], [7], [8] allow LLMs to reason over a tool library and invoke domain-specific operations on behalf of the user. Early powersystem applications confirm the potential: LLM-based frameworks have been applied to simulation orchestration [9], optimal dispatch [10], grid control [11], [12], and voltage regulation [13], establishing that LLMs can parse engineering intent, select tools, and interpret simulation outputs. Despite this progress, four critical gaps remain unaddressed in the literature. (i) No standardized tool-integration protocol. Existing integrations define bespoke function registries tied to a single codebase; no published work adopts a vendorneutral, community-standardized protocol for exposing simulator capabilities. (ii) Vendor lock-in. Current platforms couple their LLM layer to a specific proprietary API, precluding openweight or locally hosted models and creating dependency on external service pricing and availability. (iii) No comprehensive distribution analysis interface. Existing tools address isolated tasks; none provides a single interface covering load-shape management, QSTS simulation, equipment sizing, topology visualization, and optimization. (iv) No support for air-gapped deployments. Utility OT networks routinely prohibit outbound cloud traffic; no existing LLM simulation tool supports fully local operation with both inference and simulation running on-premises. The Model Context Protocol (MCP) [14], an open standard for exposing tools to LLMs, addresses gap (i) directly. Because MCP is model- and transport-agnostic, a single server can be queried by cloud or local models without modification, resolving gap (ii). Building Grid-Orch on MCP cleanly separates the simulation layer (OpenDSS) from the inference layer (any compliant LLM). This paper makes four primary contributions:
2
Fig. 1: Comparative workflow for power distribution analysis. (a) Traditional five-step manual process spanning several hours. (b) Grid-Orch autonomous workflow completing the same analysis in under two minutes through five stages: LLM tool selection, MCP routing, OpenDSS execution, Skills optimization, and synthesized visualization.
1) MCP adaptation for distribution simulation. We present an integrated adaptation of MCP to a power system simulation engine, exposing 36 domain-specific tools across eleven categories through a standards-compliant server backed by OpenDSS. 2) Multi-provider LLM layer with local-deployment support. Grid-Orch supports four backends (Gemini, Claude, Ollama, llama-cpp) via a provider-agnostic abstraction, enabling fully air-gapped operation with no cloud dependency. 3) Interactive web platform with integrated visualization. The web application delivers a chat interface, a QSTS results dashboard, and an interactive feeder topology map, all rendered inline during conversation. 4) Skills framework for multi-step optimization workflows. A composable skills layer encapsulates voltage violation analysis, overvoltage mitigation, and capacitor placement as natural-language-invocable multi-tool pipelines. These skills reason over user prompts, decide which tools to call and in what order, and execute multi-step optimization workflows. Because the underlying OpenDSS engine supports three-phase unbalanced distribution systems, all tools and skills operate on full three-phase models; this enables accurate and trustworthy analysis of feeders such as the IEEE 13-bus test system. Fig. 1 illustrates the resulting workflow transformation: a five-step manual process spanning several hours is compressed into a single natural-language query completed in under two
minutes. Section II reviews related work; Section III describes the system architecture; Section IV details the tool library and skills framework; Section V covers the web platform and visualization; Section VI presents workflow demonstrations; and Section VII concludes with deployment considerations and future work. II. R ELATED W ORK A. LLMs in Power Systems The application of LLMs to power systems has grown rapidly, spanning control, planning, fault diagnosis, and operator assistance [17], [18]. Agent-level frameworks [8] underlie recent work on real-time grid control [11], [12], simulation orchestration and dispatch [9], [10], ACOPF and contingency analysis [16], topology reasoning [19], voltage regulation [13], control decision support [20], and grid-state visualization [15]. Across this body of work, integrations are task-specific or coupled to proprietary APIs; none exposes a standards-compliant, auditable tool protocol to the LLM. B. The Model Context Protocol MCP [14] standardizes LLM-to-tool communication via a capability-negotiation handshake, with demonstrated generalization to IoT contexts [21] and analyzed security properties [22]. MCP is structured around three core primitives— tools, resources, and prompts—which collectively enable standardized interaction between LLM agents and external systems. General-purpose LLM orchestration frameworks such
3
TABLE I: Comparison of Grid-Orch with Representative Related Systems on Distribution Analysis Dimensions. Systems differ in primary scope; see text for discussion. System
Focus
Protocol
Tools
Multi-LLM
Local Deploy
Grid-Agent [11] X-GridAgent [12] Jia et al. [9] OptDisPro [10] ChatGrid [15] Jena et al. [13] GridMind [16]
Grid control Grid analysis Power flow sim. Optimal dispatch Grid visualization Voltage regulation ACOPF + N-1 contingency
Custom API Custom API Custom API Custom API Custom API Custom API PydanticAI
<10 <10 <5 <5 <5 <5 7
No No No No No No Yes
No No No No No No No
Grid-Orch (this work)
Full distrib. analysis
MCP
36
Yes
Yes
Fig. 2: Overall Schematic of Grid-Orch, which translates natural-language grid-analysis requests into typed tool calls, validates them through a shared MCP interface, dispatches them to swappable simulation engines, and grounds all responses and visualizations in structured simulator outputs.
as LangChain [23] provide tool-calling abstractions but lack domain-specific schema validation and the standardized capability negotiation that MCP offers. During the preparation of this manuscript, the PowerAgent project [24] released an open-source collection of MCP servers spanning multiple power system simulators. PowerAgent focuses on providing raw MCP tool interfaces and APIs for individual simulators, but does not offer an end-to-end analysis workflow. GridOrch complements this effort by providing a comprehensive orchestration layer with multi-provider LLM support, domainspecific tools, optimization skills, and an interactive web platform. This framework transforms raw tool calls into trustworthy, autonomous grid analytics. Future work will integrate the MCP tools developed in PowerAgent into the Grid-Orch workflow, enabling seamless access to diverse power system software through a unified natural-language interface. To the best of our knowledge, no existing open-source platform integrates a standardized tool protocol, multi-provider LLM support with air-gapped inference, a 36-tool distribution-
system library, and a multi-step optimization Skills framework within a single system; Table I summarizes the comparison with related work. III. S YSTEM A RCHITECTURE A. Overview Fig. 2 illustrates the overall Grid-Orch workflow, in which natural-language requests are translated into validated MCP tool calls, dispatched to swappable simulation engines, and returned as simulator-grounded responses and visualizations based on structured simulator outputs. Fig. 3 further shows that this workflow is implemented through a four-layer architecture that cleanly separates user interaction from simulation. Layer 1 – UI Layer. A React/Next.js application provides a persistent chat panel and a QSTS results dashboard with voltage time-series plots, load-shape viewers, and a force-directed feeder topology map. The UI communicates exclusively with the backend REST API, with no direct knowledge of the LLM provider or OpenDSS.
4
User Interface Layer Web UI (Next.js)
CLI Tool
HTTP / WebSocket
LLM Provider Layer Gemini
Claude
Ollama
llama-cpp
MCP (JSON-RPC 2.0)
MCP Server Layer (36 Tools) Core (6)
LoadSh. (6)
Profile (3)
QSTS (4)
Export (2)
Cap. (3)
Reactor (3)
Skills (3)
injects domain knowledge such as per-unit notation and standard voltage limits into every session. The end-to-end interaction sequence is detailed in Fig. 7 (Section V). The server validates each incoming request against its JSON Schema, executes the corresponding handler, and returns a structured result to the LLM. Multiple tool calls may be chained within a single user turn. Error handling supports LLM self-correction: failed calls return structured hints enabling the model to recover without user intervention [26] (detailed in Section IV). Beyond the vendor-neutrality and multi-provider support that motivated this work (Section I), MCP provides a standardized resource primitive for exposing non-tool data (e.g., circuit files) without custom endpoints [6], [23].
Reg/Tap (3)
C. Multi-LLM Provider Support Python API
OpenDSS Engine
Fig. 3: Grid-Orch four-layer architecture. The MCP boundary (dashed) decouples the LLM Abstraction Layer from the Simulation Engine Layer, allowing either side to be replaced independently. Layer 2 – LLM Abstraction Layer. A FastAPI backend hosts the provider-agnostic LLM service, running a tool-use loop: the LLM emits tool-call requests, the service dispatches them to the MCP layer, appends results as tool-response messages, and repeats until the LLM produces a final text reply. PostgreSQL persists chat sessions and circuit metadata; MinIO holds binary circuit files. Layer 3 – MCP Server Layer. A dedicated Python process exposes all 36 domain tools through the Model Context Protocol, owning JSON Schema validation, parameter coercion, and error formatting. It maintains a single shared OpenDSS manager instance so that successive tool calls within one conversation operate on the same live circuit state. Layer 4 – Simulation Engine Layer. OpenDSS [5] performs all numerical computation via the opendssdirect.py bindings [25], enabling in-process deployment on Linux-based Docker containers. The MCP boundary acts as a capability firewall: the LLM interacts with the simulator only through the 36 defined tools, never through arbitrary code execution. B. MCP Integration The Model Context Protocol is an open standard defining a JSON-RPC 2.0 transport for connecting LLMs to external tools and data [14]. Conceptually, MCP serves as a universal adapter between LLMs and external tools, analogous to how SCADA protocols standardize communication between control centers and field devices in power system operations. Grid-Orch uses all three MCP primitives. The 36 simulation capabilities are registered as Tools with typed JSON Schema parameters. Active circuit DSS files are exposed as Resources for topology queries. A power-engineering Prompt template
The LLM Abstraction Layer implements a provider adapter interface with four concrete backends: Gemini (Google DeepMind), Claude (Anthropic), Ollama (local Docker inference), and llama-cpp (GGUF-quantized models for resourceconstrained hosts). All four adapters share identical upstream and downstream interfaces—receiving an MCP tool-schema list and message history, returning either a final text reply or a list of tool calls—so adding a new provider requires no changes to the MCP layer or UI. Utility environments subject to NERC CIP cybersecurity standards [27] can select the Ollama or llama-cpp adapter for fully air-gapped operation, ensuring circuit files and simulation results never leave the security perimeter. D. OpenDSS Integration Grid-Orch accesses OpenDSS [5], [28] exclusively through the opendssdirect.py Python package [25], which wraps the native engine as an in-process shared library, eliminating COM interop latency and enabling Linux-based Docker deployment. The OpenDSSManager class maintains a single engine instance per server process across circuit loading, powerflow solve, QSTS time-stepping, and equipment state updates (capacitor switching, reactor placement, regulator tap writes). Security controls at the circuit-loading boundary validate that requested file paths resolve to a whitelisted directory and block symbolic-link traversal, preventing path-traversal attacks in multi-tenant deployments. The current implementation maintains a single OpenDSS engine instance per server process; concurrent sessions are serialized through a request queue. Multi-user deployments requiring parallel simulations can scale horizontally by running multiple backend containers behind a load balancer, each owning an independent engine instance. IV. T OOL L IBRARY AND S KILLS In the context of LLM–simulator integration, a tool is a single callable operation, such as solving a power flow or reading a bus voltage, while a skill is a multi-step workflow that chains several tools together to accomplish a complex engineering task (e.g., optimizing capacitor placement). Tools and skills
5
TABLE II: Grid-Orch MCP Tool Library (36 tools, 11 categories) Category
Tools
Core Circuit
6
LoadShape
6
QSTS Simulation
4
Profile Library
3
Results Export
2
Capacitor Mgmt
3
Reactor Mgmt
3
Regulator/Tap
3
Circuit Library
2
Topology
1
Skill Invocation
3
Total
36
Natural Language Query
Key Capabilities Circuit loading, Newton–Raphson power flow, single-bus and system-wide voltage queries, circuit metadata Create, edit, delete, and assign time-series load profiles to load objects Run quasi-static time-series simulations; retrieve voltage and loss time-indexed results Browse and load built-in, NREL, and custom CSV load profiles CSV/JSON data export and HTML report generation Add/remove shunt capacitor banks at any bus Add/remove shunt reactors for overvoltage absorption Read and adjust voltage regulator tap positions Load pre-packaged IEEE and SmartDS test feeders Bus coordinates and branch connectivity for visualization Recommend, execute, and monitor multistep optimization skills
are critical for OpenDSS integration because they provide a structured, auditable interface between the LLM’s natural language understanding and the simulation engine’s numerical computation: every analysis step is traceable to a specific tool invocation with typed inputs and outputs, preventing the LLM from fabricating results. Grid-Orch exposes 36 tools in 11 categories (Table II), spanning the full distribution-engineering workflow from circuit loading to optimization invocation; the LLM selects tools autonomously from the full schema list. A. Tools All 36 tools share three implementation patterns that promote reliability and LLM self-correction. First, every parameter carries a typed JSON Schema object with a plain-English description; the MCP server validates incoming calls before executing any handler code. Second, all tools return a uniform JSON envelope with explicit unit annotations to prevent silent unit-mismatch errors. Third, failed calls include a hint field with actionable recovery guidance—e.g., “load the circuit first”—enabling the LLM to self-correct workflow-ordering errors without user intervention [26], [29]. In the following, we present two example user queries to illustrate how the LLM autonomously orchestrates tool usage. User: Are there any voltage violations on the feeder?
Grid-Orch: The LLM triggers a power flow solve followed by a system-wide bus voltage scan, filtering
LLM + invoke_skill
intent routing
Skill Registry
discovery
Skill Orchestrator
coordination
Voltage Analysis
Capacitor Optimization
Overvoltage Mitigation
MCP Tools (36)
Fig. 4: Skills Framework architecture showing query flow from natural language through skill orchestration to MCP tool execution. buses outside the acceptable range (0.95–1.05 p.u.). It returns a natural-language summary identifying any violations with per-unit values. Tools chained: solve power flow → get all bus voltages
User: Run a 24-hour simulation and show voltages.
Grid-Orch: The LLM chains load-shape assignment, a 24-hour QSTS run, and a voltage profile extraction, identifying the worst-case interval and bus. Results populate the QSTS dashboard automatically. Tools chained: create loadshape → assign loadshape → run qsts → get qsts voltage profile The nine equipment-management tools (Capacitor, Reactor, and Regulator/Tap categories) enable closed-loop what-if analysis: for example, engineers can add or remove shunt banks, adjust regulator taps (−16 to +16), and re-solve power flow iteratively—transforming Grid-Orch from a read-only assistant into an interactive design environment. B. Skills Framework While individual tools are deliberately atomic, practical distribution tasks (diagnosing undervoltage, optimizing capacitor placement, mitigating overvoltage) require coordinating multiple tools in sequence. Delegating this sequencing entirely to the LLM would introduce non-determinism, risking incorrect tool ordering or missed steps in safety-relevant analyses. To address this, Grid-Orch introduces a Skills layer [30]: each skill is a Python class that encapsulates a complete multistep workflow, calling MCP tools programmatically through an inversion-of-control callback (Fig. 4). The LLM selects the appropriate skill; the skill itself executes deterministically.
6
MCP Tool
Skill
Granularity Algorithm State Calls per use Determinism LLM role
Single operation None Stateless 1 Deterministic Argument extraction
Multi-step workflow PSO, classification Tracks iterations 5–50+ Deterministic Skill selection only
Three skills are currently implemented. 1) The capacitor placement optimization skill addresses chronic undervoltage using Particle Swarm Optimization (PSO) [31], proceeding through baseline voltage assessment, candidate bus selection, PSO iteration over (bus, kvar) placement pairs, optimal placement, and post-optimization verification; in preliminary tests on the IEEE 13-bus feeder it substantially reduced undervoltage violations. 2) The voltage violation analysis skill classifies each bus against standard voltage limits— severe (>3% deviation), moderate (2–3%), or minor (<2%)— performs root-cause correlation with feeder topology and load density, and returns ranked corrective recommendations. All bus voltages are reported as positive-sequence magnitudes; per-phase analysis for unbalanced feeders is supported at the tool level but is not currently exposed through this skill. 3) The overvoltage mitigation skill resolves buses above 1.05 p.u. [32] through a prioritized three-strategy sequence: tap changer adjustment, shunt reactor placement sized by 2 2 Qreactor = (Vactual − Vtarget )/X, and excess capacitor removal. Preliminary testing resolved all overvoltage buses across the tested scenarios. Table III summarizes the structural differences between tools and skills. The key distinction is granularity: tools provide elementary operations from which skills compose deterministic workflows. The tools and skills described above are made accessible through an interactive web platform that unifies conversational control, data access, and integrated visualization, as described next.
Frontend (Next.js 16) React
TypeScript
Recharts
Tailwind
REST API (JSON)
Data Tier Application Tier (Layers 2–3) (Layer 4 + persist.)
Dimension
UI Tier (Layer 1)
TABLE III: Comparison of MCP Tools and Grid-Orch Skills
Backend API (FastAPI 0.110) — LLM + MCP Server SQLAlchemy
Pydantic
JWT Auth
LLM Service MCP Server
ORM (SQLAlchemy) / Provider SDK
Data Layer PostgreSQL
MinIO / S3
OpenDSS Engine
Fig. 5: Three-tier web platform architecture with technology stack.
sidebar lists all conversations for the authenticated user, restoring the full message history along with circuit, provider, model, and profile context on selection. A compact control header exposes four inline selectors that define the simulation context for the active session. When the LLM invokes MCP tools, a collapsible Tool Call panel above the reply lists each tool, its arguments, and the raw OpenDSS JSON result, allowing engineers to audit every simulation call underlying an answer. Each tool returns a structured JSON envelope containing a success flag, result data with explicit unit annotations (e.g., per-unit voltages, kW losses), and, on failure, a field with actionable recovery suggestions. The frontend parses these typed JSON responses to automatically select the appropriate chart component. For example, a voltage query triggers a bar chart, while a QSTS result populates the timeseries viewer.
V. P LATFORM AND V ISUALIZATION A. Architecture and Chat Interface The UI tier hosts Layer 1 (the Next.js frontend [33]). The application tier consolidates Layers 2–3 (LLM Service and MCP Server) inside a single FastAPI container [34], communicating with the frontend via RESTful APIs and with the data tier through provider SDKs and an SQLAlchemy [35] ORM layer [36] that translates Python data objects into PostgreSQL queries for user sessions, chat histories, circuit metadata, and load profiles. The data tier hosts Layer 4 (the OpenDSS simulation engine) alongside PostgreSQL [37] for relational state and MinIO/S3 for circuit package storage. Services are orchestrated by Docker Compose with JWT-based authentication and path-sanitized circuit uploads at the API boundary. The chat interface (Fig. 6) is the primary interaction mode, mirroring general-purpose LLM assistants while adding power-system-specific controls inline. A collapsible session
B. Provider and Data Libraries The provider-agnostic LLM layer (Section III) supports four backends, including two local options for air-gapped operation where no prompts or simulation data leave the operator’s network. Load profiles govern per-unit load scaling during QSTS simulations. Ten built-in synthetic profiles derived from the End-Use Load Profiles dataset [38] cover archetypes from residential and commercial office to data center, industrial, solar generation, and a peak-stress worst-case; engineers can upload custom profiles as two-column CSV files. The circuit library bundles the IEEE 13-bus and 123-bus test feeders [39] with bus coordinate data for topology visualization, and supports download of the Smart-DS synthetic feeders [40]. Each circuit package bundles the OpenDSS master DSS file, component files, and optional bus coordinates into a versioned archive registered in PostgreSQL for simulation reproducibility.
7
Fig. 6: Grid-Orch chat interface showing a voltage analysis session. The sidebar lists conversation sessions; the control header provides circuit, provider, model, and profile selectors; the message area displays tool invocations and inline analysis results.
C. Visualization and User Interface Grid-Orch renders simulation results across three integrated surfaces—inline chat, the QSTS dashboard, and exported reports—all sharing the same component library so charts are identical regardless of surface. Charts auto-render whenever a tool response contains structured data. Fig. 8 illustrates a typical interaction: the user asks “What are the bus voltages,” and Grid-Orch retrieves system-wide bus voltages, returning both a natural-language summary identifying the elevated voltage at bus rg60 (1.056 p.u., the regulator-output bus) and an inline voltage profile bar chart with green/amber/red limit shading. The tool-call panel (collapsed in the figure) lets engineers audit every OpenDSS call underlying the response. Fig. 7 traces the end-to-end data flow for a representative voltage query through six stages. The user’s natural-language prompt is converted by the LLM into a typed MCP tool call (step 2); the MCP server validates the call against its JSON Schema before forwarding to OpenDSS (step 3); OpenDSS solves the power flow and returns a structured JSON result with explicit unit annotations (step 4); the frontend patternmatches the JSON payload to auto-render the appropriate chart (step 5); and the LLM grounds its textual reply on the same JSON (step 6). If the tool call fails schema validation, the MCP server rejects it and the LLM retries with corrected parameters. Because all numerical values originate from OpenDSS through schema-validated calls, the LLM serves as an interface and interpreter rather than a source of simulation results, substantially mitigating hallucination. The end-to-end data flow is also summarized in Algorithm 1.
Algorithm 1 End-to-End LLM–MCP–OpenDSS Interaction Pipeline Require: User query q in natural language Ensure: Grounded textual answer and visualization 1: Receive user query q 2: Convert q into a MCP function call with JSON parameters 3: Validate the function call using the MCP server’s JSON Schema 4: Execute the validated request in OpenDSS 5: Return structured JSON outputs from OpenDSS 6: Ground the LLM response on the returned JSON outputs 7: Render charts or tables in the frontend from the same typed JSON payload
The feeder topology map (Fig. 9) renders the circuit as an interactive SVG with voltage-colored nodes and five elementtype shapes, scaling adaptively from the 13-bus to the 2,356bus SmartDS feeder. For post-simulation exploration, a five-tab QSTS dashboard [41] rendered with the Recharts visualization library provides comprehensive analysis tools, reusing the same component set as the inline chat charts so that visual output is identical across surfaces (Figs. 10–11). The Overview tab summarizes simulation KPIs including minimum and maximum voltage, violation count, and total real and reactive losses. The Voltage Analysis tab allows users to select individual buses via clickable chips; selected timeseries are overlaid with interactive hover tooltips. The Losses tab renders time-indexed real and reactive power losses as a stacked area chart. The
8
1
User Query “bus voltages?”
3
2
NL query
LLM
tool call
function select
MCP Server
5
4
API call
JSON Schema
OpenDSS
JSON
power flow
Frontend
6
render
auto-render chart
Reply text + chart
structured JSON reject malformed {"voltages":{"650":{"per_unit":1.00}, "671":{...}}}
Fig. 7: End-to-end pipeline for a natural-language voltage query. The user’s prompt traverses six stages: LLM function selection, MCP schema validation, OpenDSS power flow execution, structured JSON return, frontend chart rendering, and grounded textual reply. Malformed tool calls are rejected at step 3 and retried.
Fig. 8: Inline visualization in the Grid-Orch chat interface. The user’s natural-language query triggers a system-wide voltage scan; the response includes a textual analysis and an autorendered voltage profile bar chart with per-unit limit shading.
Fig. 10: QSTS Dashboard — Overview tab showing simulation summary KPIs, top-10 bus voltage profile (left), and 24hour power loss chart (right) for the IEEE 13-bus feeder with residential load pattern. Five tabs (Overview, Voltage Analysis, Losses, Voltage Heatmap, Topology Map) provide comprehensive post-simulation exploration with CSV/JSON export.
underlying data. User sessions, chat history, and uploaded circuit packages are persisted per authenticated user with JWTbased email/password signup and login. VI. W ORKFLOW D EMONSTRATIONS To illustrate the proposed autonomous workflow, three representative use cases are presented below.
A. Session Initialization Fig. 9: Interactive feeder topology map for the IEEE 13-bus test feeder. Nodes are colored by per-unit voltage with five shapes encoding element types. Hovering displays bus name, voltage, and base kV.
Voltage Heatmap displays a bus-by-time matrix color-mapped by per-unit voltage, making violation periods visible at a glance. The Topology Map reuses the interactive SVG map from the chat surface to show spatial voltage distribution. Every tab supports one-click CSV and JSON export of the
On session startup, the user selects a feeder from the circuit library (IEEE 13-bus, 123-bus, or a SmartDS feeder); the selected package is fetched from local storage or pulled from MinIO cloud storage, and its bus coordinates are registered for topology rendering. In parallel, a residential load profile is assigned by default to every load object via the LoadShape tools, so the circuit is immediately ready for power flow or QSTS simulation without further user input. Users can override the default profile, upload a custom CSV, or modify per-load assignments through natural-language commands at any time.
9
Analysis tab lets engineers drill into individual bus timeseries with interactive tooltips. D. Use Case 3: Automated Voltage Optimization User: Fix the voltage violations using capacitor optimization. Grid-Orch routes the request to the capacitor optimization skill, which runs PSO to find optimal placements while excluding overvoltage buses. After convergence, the skill substantially reduces the violation count; the LLM synthesizes the results into a plain-language recommendation with a before/after voltage profile chart. Fig. 11: QSTS Dashboard — Voltage Analysis tab. Engineers select buses via clickable chips (five buses selected: 645, 652, 670, 680, 684) and inspect their 24-hour voltage timeseries with interactive hover tooltips. Dashed red lines indicate the upper (1.05 p.u.) and lower (0.95 p.u.) voltage limits.
B. Use Case 1: DER Interconnection Screening Scenario. A distribution planner needs to evaluate the voltage impact of interconnecting a 2 MW photovoltaic installation at bus 675 of the IEEE 13-bus feeder. This is a routine but time-consuming interconnection screening task encountered regularly in distribution planning departments. As illustrated in Fig. 1(a), the conventional approach requires five sequential manual steps taking several hours. Steady-state voltage compliance is evaluated against standard voltage limits; full IEEE 1547 screening [42] (including fault current and protection coordination) is outside the current scope. With Grid-Orch, the engineer submits a single query: User: What is the impact of adding 2 MW solar PV at bus 675? Grid-Orch autonomously modifies the circuit model, runs a power flow solve, retrieves system-wide bus voltages, invokes the voltage violation analysis skill, and renders a voltage profile chart inline—completing the full sequence in under two minutes. The MCP protocol introduces no numerical distortion: all computation is performed by the OpenDSS engine; the LLM layer handles only tool selection and result interpretation. C. Use Case 2: 24-Hour QSTS Analysis User: Run a 24-hour simulation with residential profile on load 671 and find any voltage violations. Grid-Orch executes a six-step sequence without further user input: load-shape creation, assignment to load objects, QSTS execution, voltage profile extraction, violation analysis, and inline chart generation. The QSTS dashboard (Figs. 10–11) is automatically populated: the Overview tab reports 5 violation steps with minimum voltage 0.9608 p.u., while the Voltage
VII. D ISCUSSION AND C ONCLUSION A. Limitations and Future Work LLM reliability remains a practical concern for engineering applications: in multi-tool query chains the model may select semantically similar but incorrect tools, misinterpret intermediate results, or hallucinate parameters not present in the user query. Grid-Orch mitigates these risks at three points: the MCP boundary constrains the LLM to the 36 defined tools (never arbitrary code execution), the Skills framework executes multi-step workflows deterministically once the LLM selects the appropriate skill, and the error-handling design returns structured hints that enable self-correction without user intervention. Despite these safeguards, results should be treated as preliminary analyses subject to engineering review; human-in-the-loop verification is essential before any results inform investment decisions or operational changes. Tool selection accuracy may degrade as the catalog grows with overlapping functionality; hallucination risk also increases for complex multi-tool chains that exceed the model’s recovery capability. Three directions for future investigation are: expanding the tool library to transient stability and protection coordination domains while integrating additional simulation engines (ANDES [43], CYME, PSCAD, GridLAB-D, PSS/E, etc.) via the MCP server interface; conducting a formal user study to validate usability improvements; and developing a semantic tool-retrieval layer that dynamically selects relevant tools per query rather than exposing the full catalog. B. Conclusion This paper has introduced Grid-Orch, an MCP-based platform for conversational distribution system analysis. The system provides 36 OpenDSS tools across eleven categories, three optimization skills, a multi-provider LLM backend with airgapped support, and a web platform with inline visualization and an interactive QSTS dashboard. Workflow demonstrations show that analyses ranging from DER interconnection screening to QSTS violation detection complete in under two minutes through natural language, producing numerically identical results to direct OpenDSS scripting. By removing the scripting requirement from distribution analysis, Grid-Orch demonstrates that the MCP protocol can make simulation tools
10
accessible to engineers who lack programming expertise, offering a practical step toward mitigating the projected workforce shortage.
R EFERENCES [1] IEEE Power & Energy Society and Kearney, “The future of the energy workforce,” https://resourcecenter.ieee-pes.org/industry-reports/ pes ir 01 081925, IEEE PES/Kearney, Tech. Rep., 2025. [2] U.S. Department of Energy, “U.S. energy and employment report 2024,” https://www.energy.gov/sites/default/files/2024-06/2024-USEER-0.pdf, DOE, Tech. Rep., 2024. [3] ——, “Grid modernization strategy 2024,” https://www.energy.gov/sites/ default/files/2024-12/Grid%20Modernization%20Strategy%202024.pdf, DOE, Tech. Rep., 2024. [4] International Energy Agency, “World energy employment 2025,” https:// www.iea.org/reports/world-energy-employment-2025, IEA, Tech. Rep., 2025, 60% of energy companies report labor shortages. [5] Electric Power Research Institute, “OpenDSS: Open distribution system simulator,” https://www.epri.com/pages/sa/opendss, 2023, version 9.x. [6] OpenAI, “Function calling with large language models,” https://platform. openai.com/docs/guides/function-calling, 2023, accessed: 2026-01-05. [7] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, “ReAct: Synergizing reasoning and acting in language models,” in International Conference on Learning Representations (ICLR), 2023. [8] L. Wang, C. Ma, X. Feng, Z. Zhang, H. Yang, J. Zhang, Z. Chen, J. Tang, X. Chen, Y. Lin et al., “A survey on large language model based autonomous agents,” Frontiers of Computer Science, vol. 18, no. 6, p. 186345, 2024. [9] M. Jia, Z. Cui, and G. Hug, “Enhancing LLMs for power system simulations: A feedback-driven multi-agent framework,” IEEE Transactions on Smart Grid, vol. 16, no. 6, pp. 5556–5559, 2025. [10] Z. Li, H. Yang, Y. Liu, Y. Xiang, H. Gao, J. Liu, and J. Liu, “OptDisPro: LLM-based multi-agent framework for flexibly adapting heuristic optimal DisFlow,” IEEE Transactions on Smart Grid, vol. 17, no. 1, pp. 794–796, 2026. [11] Y. Zhang, A. M. Saber, A. Youssef, and D. Kundur, “Grid-Agent: An LLM-powered multi-agent system for power grid control,” arXiv preprint arXiv:2508.05702, 2025. [12] Y. Wen and X. Chen, “X-GridAgent: An LLM-powered agentic AI system for assisting power grid analysis,” arXiv preprint arXiv:2512.20789, 2025. [13] A. Jena, F. Ding, J. Wang, Y. Yao, and L. Xie, “LLM-based adaptive distribution voltage regulation under frequent topology changes: An incontext MPC framework,” IEEE Transactions on Smart Grid, vol. 16, no. 5, pp. 4297–4299, 2025. [14] Anthropic, “Model context protocol specification,” https: //spec.modelcontextprotocol.io/, 2024, version 1.0, Released November 2024. [15] S. Jin and S. Abhyankar, “ChatGrid: Power grid visualization empowered by a large language model,” in 2024 IEEE Workshop on Energy Data Visualization (EnergyVis). IEEE, 2024, pp. 12–16. [16] H. Jin, K. Kim, and J. Kwon, “GridMind: LLMs-powered agents for power system analysis and operations,” arXiv preprint arXiv:2509.02494, 2025. [17] M. Sarwar, M. Rizwan, M. Aziz, and A. R. Sudais, “Large language models for power system applications: A comprehensive literature survey,” arXiv preprint arXiv:2512.13004, 2025. [18] Y. Chen and A. Anderson, “Connecting minds: AI use cases to bridge power systems and large language models for practical applications,” Pacific Northwest National Laboratory, Richland, WA, Tech. Rep. PNNL38003, May 2025, prepared for the U.S. Department of Energy under Contract DE-AC05-76RL01830. [19] F. Bernier, J. Cao, M. Cordy, and S. Ghamizi, “PowerGraph-LLM: Novel power grid graph embedding and optimization with large language models,” IEEE Transactions on Power Systems, vol. 40, pp. 5483–5486, 2025. [20] S. L. Choi, R. Jain, P. Emami, K. Wadsack, F. Ding, H. Sun, K. Gruchalla, J. Hong, H. Zhang, X. Zhu, and B. Kroposki, “eGridGPT: Trustworthy AI in the control room,” National Renewable Energy Laboratory, Golden, CO, Tech. Rep. NREL/TP-5D00-87440, May 2024. [Online]. Available: https://www.nrel.gov/docs/fy24osti/87440.pdf
[21] N. Yang, G. Lyu, M. Ma, Y. Lu, Y. Li, Z. Gao, H. Ye, J. Zhang, T. Chen, and Y. Chen, “IoT-MCP: Bridging LLMs and IoT systems through model context protocol,” in Proceedings of the 19th ACM Workshop on Wireless Network Testbeds, Experimental evaluation & Characterization (WiNTECH ’25). Washington, DC: ACM, 2025. [22] X. Hou, Y. Zhao, S. Wang, and H. Wang, “Model context protocol (MCP): Landscape, security threats, and future research directions,” arXiv preprint arXiv:2503.23278, 2025. [23] H. Chase, “LangChain: Building applications with LLMs through composability,” https://github.com/langchain-ai/langchain, 2023, v0.1+; open-source LLM application framework. [24] Q. Zhang and L. Xie, “PowerAgent: A road map toward agentic intelligence in power systems: Foundation model, model context protocol, and workflow,” IEEE Power and Energy Magazine, 2025. [25] NREL and Contributors, “OpenDSSDirect.py: Python interface for OpenDSS,” https://github.com/dss-extensions/OpenDSSDirect.py, 2023, version 0.9.x. [26] Y. Qin, S. Liang, Y. Ye, K. Zhu, L. Yan, Y. Lu, Y. Lin, X. Cong, X. Tang, B. Qian et al., “Tool learning with foundation models,” ACM Computing Surveys, 2024. [27] North American Electric Reliability Corporation (NERC), “Cip-007-6 cyber security – system security management,” https://www.nerc.com/ standards/reliability-standards/cip/cip-007-6, 2016, reliability Standard. [28] R. C. Dugan and D. Montenegro, “Reference guide: The open distribution system simulator (OpenDSS),” Electric Power Research Institute, Tech. Rep., 2019, includes QSTS methodology and time-series simulation procedures. [29] T. Schick, J. Dwivedi-Yu, R. Dessı̀, R. Raileanu, M. Lomeli, E. Hambro, L. Zettlemoyer, N. Cancedda, and T. Scialom, “Toolformer: Language models can teach themselves to use tools,” Advances in Neural Information Processing Systems, vol. 36, 2023. [30] B. Zhang, K. Lazuka, and M. Murag, “Equipping agents for the real world with agent skills,” https://www.anthropic.com/engineering/ equipping-agents-for-the-real-world-with-agent-skills, 2025, anthropic Engineering Blog, October 2025. [31] J. Kennedy and R. Eberhart, “Particle swarm optimization,” in Proceedings of ICNN’95 - International Conference on Neural Networks, vol. 4. IEEE, 1995, pp. 1942–1948. [32] H. Sun, Q. Guo, J. Qi, V. Ajjarapu, R. Bravo, J. Chow, Z. Li, R. Moghe, E. Nasr-Azadani, U. Tamrakar et al., “Review of challenges and research opportunities for voltage control in smart grids,” IEEE Transactions on Power Systems, vol. 34, no. 4, pp. 2790–2801, 2019. [33] Vercel, “Next.js: The react framework for production,” https://nextjs.org/, 2024, accessed: 2026-04-13. [34] S. Ramı́rez, “Fastapi: A modern, fast (high-performance) web framework for building apis with python,” https://fastapi.tiangolo.com/, 2018, accessed: 2026-04-13. [35] M. Bayer, “Sqlalchemy: The python sql toolkit and object relational mapper,” https://www.sqlalchemy.org/, 2026, version 2.0 Documentation, Accessed: 2026-04-13. [36] S. W. Ambler, “Mapping objects to relational databases: O/r mapping in detail,” IBM DeveloperWorks, 2003. [37] P. G. D. Group, “Postgresql: The world’s most advanced open source relational database,” https://www.postgresql.org/, 2024, accessed: 202604-13. [38] National Renewable Energy Laboratory, “End-use load profiles for the U.S. building stock,” https://www.nrel.gov/buildings/ end-use-load-profiles.html, 2022. [39] K. P. Schneider, B. A. Mather, B. C. Pal et al., “Analytic considerations and design basis for the IEEE distribution test feeders,” IEEE Transactions on Power Systems, vol. 33, no. 3, pp. 3181–3188, 2017. [40] B. Palmintier, C. Mateo Domingo, F. E. Postigo Marcos, T. Gomez San Roman, F. de Cuadra, N. Gensollen, T. Elgindy, and P. Duenas, “Smart-ds synthetic electrical network data opendss models for sfo, gso, and aus,” Open Energy Data Initiative (OEDI), National Renewable Energy Laboratory (NREL), 2020, accessed: 2026-04-08. [Online]. Available: https://data.openei.org/submissions/2981 [41] D. Montenegro and R. C. Dugan, “Quasi-static time-series simulation using OpenDSS,” Electric Power Research Institute, Tech. Rep., 2016. [42] IEEE Standards Association, IEEE Standard for Interconnection and Interoperability of Distributed Energy Resources with Associated Electric Power Systems Interfaces, IEEE Std. 1547-2018, 2018. [43] H. Cui, F. Li, and K. Tomsovic, “Hybrid symbolic-numeric framework for power system modeling and analysis,” IEEE Transactions on Power Systems, vol. 36, no. 2, pp. 1373–1384, 2020.