How Can MCP Agents Run a Smart City Grid in Real Time?

MCP Agents in a Smart City Grid: The Short Answer

Model Context Protocol agents can run parts of a smart city's energy grid by reading from EMS, DERMS, weather feeds, and market platforms through standardised MCP servers, then proposing actions back into those systems through audited tool calls. The hard real-time control loop stays on physical controllers. The coordination loop, the part that today still relies on a human in the control room, is what shifts.

Most utilities have spent the last decade automating individual subsystems and stitching them together with custom APIs. The agentic AI layer changes how those subsystems talk to each other. Anthropic released MCP as an open standard on 25 November 2024, and within a year it became the default integration shape for production AI tooling. Grids are a natural next step, although MCP-native grid deployments are not public yet.

What Is an MCP-Enabled Agent Network in a Grid Context?

An MCP-enabled agent network is a set of large language model agents that read from and write to grid systems through Model Context Protocol servers, with one orchestration agent planning across them. Each MCP server wraps a backend with a typed schema, an authorisation contract, and an audit trail.

The specification defines three server primitives, Tools, Resources, and Prompts, all callable through JSON-RPC. Anthropic published pre-built MCP servers for Google Drive, Slack, GitHub, Git, Postgres and Puppeteer on launch day.

REST APIs and Kafka topics already connect grid systems, but every new integration still needs a custom client, custom auth and custom serialisation, and changing one vendor breaks the wiring. MCP fixes the shape of that wiring once: any agent that speaks the protocol can call any tool.

The agents split by function, typically like this:

• Forecasting agents take weather, calendar, and historical load data and produce day-ahead and intraday demand and generation profiles.
• Dispatch agents read those forecasts and propose set points for distributed energy resources, battery storage, and demand response programmes.
• Market agents talk to day-ahead and intraday exchanges such as Nord Pool and EPEX SPOT, and place flexibility bids.
• Fault-isolation agents watch SCADA alarms, correlate them with topology and weather, and propose switching schemes.
• A planner agent coordinates the others, brokers conflicts, and surfaces decisions for operator approval.

This is the same architectural move described in our piece on agents replacing REST controllers: the model becomes the reasoning layer between systems instead of a chatbot wrapper.

The Reference Architecture for Grid Agents

The reference architecture for an MCP-enabled grid agent network has three layers: MCP servers that wrap each backend, agents that reason and plan, and a coordination fabric that lets agents talk to each other.

MCP servers wrap the legacy stack

Every grid system gets one MCP server. SCADA over IEC 60870-5-104, ADMS such as Siemens Spectrum Power or GE Vernova PowerOn, DERMS, AMI head-end systems running DLMS/COSEM, weather and forecast feeds, market platforms. Each server exposes typed Tools (read meter, send curtailment signal, query forecast) and Resources (network topology, customer flex contract terms). The wrapper is thin. The grid system itself does not change.

Agents reason, plan, and act

Orchestration frameworks such as LangGraph, CrewAI and Microsoft Agent Framework (the successor to AutoGen, which is now in maintenance mode) host the agent population. Each agent uses a base model with grid-domain prompts and a constrained set of MCP tools. Token budgets stay small because each agent only sees the schemas it needs. We use the same pattern in agentic AI for utilities and other regulated industries, and it transfers well because the audit and authorisation primitives are already in place.

Agent-to-agent coordination

Cross-agent communication uses standardised patterns rather than ad-hoc message passing. MCP and A2A solve different problems: MCP standardises how an agent reaches a tool or data source, while A2A standardises how agents negotiate with each other. In the grid context, A2A handles the negotiation between the dispatch agent (wants to charge the battery now) and the market agent (sees a profitable export window in two hours). The planner agent breaks ties using a policy the operator can read in plain English.

What Grid Agents Will Build On

None of the examples below uses MCP, and MCP-native deployments on transmission grids are still ahead. They show the AI and platform building blocks that grid agents will sit on.

Google DeepMind on wind portfolios. In 2019, DeepMind applied a neural network to 700 MW of Google's wind farms in the US central plains, forecasting power output 36 hours ahead. The result was a roughly 20 per cent increase in the value of that wind energy, achieved by making the supply schedulable rather than purely intermittent. This is the kind of work a forecasting agent will own in an MCP network.

Octopus Energy and the Kraken platform. Kraken, originally built by Octopus Energy, runs its retail and flexibility operations. The platform is now licensed across more than 15 countries, covering more than 90 million customer accounts. Licensees include EDF Energy, E.ON Next, Good Energy, and Origin Energy in Australia. Kraken is a live example of agent-style automation at scale in European energy retail and balancing markets.

HEDGE-IoT, Horizon Europe. The HEDGE-IoT project runs from January 2024 to June 2027 with six large-scale demonstrators in Finland, Greece, Italy, the Netherlands, Portugal, and Slovenia. The framework deploys federated AI/ML at the grid edge and in the cloud, with explicit work on cross-system orchestration.

Alliander and Siemens Gridscale X. The largest Dutch DSO, Alliander, signed a strategic partnership with Siemens to deploy Gridscale X as a digital twin of the LV network. The vendor estimates a 10 to 30 per cent uplift in usable grid capacity through flexibility orchestration. This is the platform layer that grid agents will sit on top of, not replace.

NESO is moving in the same direction with smaller pieces. The operator has partnered with Open Climate Fix on satellite-based solar nowcasting and with the Alan Turing Institute on machine learning for balancing.

How Real-Time Works Across the Grid Stack

Real time in a smart city grid covers four tiers, and only one of them belongs to Model Context Protocol agents.

• Milliseconds (within a few cycles). Protection relays, IEC 61850 GOOSE messaging, fault clearing. Hard-wired physics. Not an agent decision.
• Few seconds. Automatic Generation Control, primary frequency response. Hard-coded controllers run the loop. An agent may advise, never dictate.
• 5 to 60 seconds. Voltage regulation, DER set point updates, congestion response on the LV feeder. Agents propose. Controllers execute through MCP write tools, gated by policy.
• Minutes to hours. Demand response activation, EV charging coordination, market bid submission, fault isolation planning, day-ahead procurement. This is where MCP agents live.

The taxonomy decides what the agents are allowed to touch. Our piece on AI agents processing industrial IoT streams covers the same latency budgets for factory floors. Grids are stricter because a wrong write can end in a black start, not a misshipped pallet.

A working rule of thumb: if the response time is short enough that a human cannot reasonably intervene, agents stay out of the actuation path. They observe, they explain, they propose. Set point execution stays with the physical controller, and the agent layer never bypasses it.

Governance, Compliance, and OT Cybersecurity

Any AI system used as a safety component in the management of electricity supply is high-risk under the EU AI Act. Grid agents that only forecast or place market bids, without affecting safety, usually fall outside that category, and Article 6(3) adds further exceptions.

Annex III, section 2 covers safety components in the management and operation of critical digital infrastructure, road traffic, and the supply of water, gas, heating and electricity. The Digital Omnibus on AI, Regulation (EU) 2026/1744 of the European Parliament and the Council, in force since 27 July 2026, moved the compliance deadline for Annex III high-risk systems to 2 December 2027, but the requirements themselves are unchanged. Risk management, data governance, technical documentation, human oversight, conformity assessment, and registration in the EU database all apply. Penalties run to €15 million or 3 per cent of global turnover. Our piece on EU AI Act compliance for AI agents covers the documentation burden in detail.

NIS2 (Directive EU 2022/2555) sits alongside. Large energy operators are essential entities under NIS2, and medium-sized ones are important entities with lighter supervision. Both must meet its incident reporting, supply chain security and management accountability requirements for cyber resilience. The transposition deadline passed in October 2024, and several member states are now actively enforcing.

For the OT layer itself, IEC 62443 remains the baseline. MCP servers that touch SCADA must sit on the right side of the Purdue model boundary, with network segmentation, signed binaries, and zero implicit trust between agent layers and physical controllers. Our broader cybersecurity work for utility clients tends to start with a Purdue model audit before any AI conversation begins.

Three practical implications fall out of this:

• Every MCP tool call to a write endpoint is logged with caller identity, timestamp, model version, and policy reference.
• Human-in-the-loop approval is mandatory for any agent action that changes a physical set point. Our blog post on human-in-the-loop for high-stakes AI gives the rationale.
• Agent model cards are stored in the same documentation lifecycle as the rest of the OT change management.

Where Smart-Grid Pilots Usually Break

Five failure modes show up across the smart grid AI deployments we have reviewed.

Schema drift in legacy SCADA. Tag names change during a routine ADMS upgrade and the MCP server returns the wrong field. The agent's reasoning chain still produces plausible output, which makes the bug harder to spot than a hard crash.

Forecast confidence collapses into policy. A dispatch agent receives a p50 demand forecast and treats it as certain. When a storm arrives, the agent has no learned behaviour for high uncertainty, and the operator gets a confident wrong recommendation at the worst possible moment.

Latency jitter under storm load. A coordination pattern that holds at 100 ms tail latency breaks at 800 ms. The fault-isolation agent times out, the planner picks a stale state, and the demand response activation lands ten minutes late.

Operator trust collapses on the first bad call. After one wrong recommendation during a real event, operators often switch auto-mode off until a post-event review is done. Trust comes back slowly, and only through transparent reviews backed by operational dashboards for grid teams.

Cultural distance between data science and the control room. The model performs well on validation data and badly on the desk's intuition. If the data team does not sit close enough to the operators to hear those reactions, the pilot dies politely.

Picture a Nordic DSO running 250,000 smart meters and a young agentic-AI pilot for low-voltage congestion. The model works on paper. On the third storm of the winter, the dispatch agent issues a curtailment recommendation that conflicts with a local flex contract the agent never saw. The operator overrides, calls the vendor, and the pilot enters a six-week governance review. Discovery work before the pilot starts can catch most of these failure modes.

What Leaders Should Remember

Model Context Protocol agents give grid operators a way to stop hand-writing integration code for every new AI use case. The agent network sits one layer above SCADA, ADMS, and DERMS, coordinating across them rather than displacing them.

Three principles follow. Slow loops sit with the agents, while fast ones stay with the controllers. Every write is audited, gated, and approved by a human at the boundary that matters. The architecture follows the existing OT stack, not the model.

The main saving is integration work: one MCP server per backend instead of a custom client for every AI use case. If you want to test where your stack sits, start with a discovery session and we will walk through the architecture with your team.