Ask Claude what you pay per kilowatt-hour on PG&E. Go ahead. The answer will be wrong — and the scary part is it'll sound completely confident.
We built an MCP server with 28 domain-informed tools to fix this. Here's why it was harder than it sounds.
Nobody Knows What They Actually Pay
PG&E billing is extraordinarily complex. Your effective rate depends on your rate schedule, provider (bundled PG&E vs. Community Choice Aggregation), PCIA vintage year, NEM version, time-of-use period, and income tier. Rates change roughly twice a year, and CCA rates change independently.
The same kilowatt-hour costs 2-3x more during peak than off-peak. Most customers have no idea.
What Claude Gets Wrong
Without domain-specific tools, Claude makes specific, confident errors:
These aren't edge cases. They're the core of every energy cost question a solar customer asks.
Built from Personal Frustration
This project started when I realized I had no idea what I was actually paying per kilowatt-hour — and neither did my solar installer. I read every PG&E tariff sheet, decoded the CCA billing structure, mapped the PCIA vintage system, and built the rate engine to make sure nobody else has to do the same detective work.
How It Works
Upload your PG&E data. Have a conversation about it. Get real answers.
4. Ask any question about your energy costs
The tool walks you through everything — rate plan comparison, usage profiling, true-up projection, battery optimization — personalized to your actual data.
28 Tools, Four Layers
Data Ingestion (5 tools)
Parse every data format a PG&E solar customer might have:
Analysis (8 tools)
Powerwall Control (6 tools)
If you have a Tesla Powerwall, the tool reads live status and controls your battery directly through the Tesla FleetAPI:
The Powerwall control layer came from wanting to actually act on the analysis — not just know the optimal dispatch schedule, but execute it.
The Rate Engine: The Hard Part
All rates are verified against PG&E tariff sheets. The engine encodes:
Getting a rate schedule comparison right means knowing that EV2-A peak is 4-9 PM every day, while E-TOU-D peak is 5-8 PM weekdays only. That single difference changes the math for every solar customer with a battery.
Battery Optimization with Real Math
The battery optimizer uses mixed-integer linear programming (Pyomo + CBC solver) because energy arbitrage with TOU rates, NEM credits, and reserve constraints is genuinely a hard optimization problem. This isn't a heuristic — it finds the mathematically optimal charge/discharge schedule given your actual rate plan, usage pattern, and battery constraints.
Try It Live
PG&E Energy MCP runs as a live server. Connect it to Claude:
4. Paste the server URL: https://pge-energy-mcp.up.railway.app/mcp
Then upload your Green Button data and latest bill, and ask: "What are the best ways to optimize my energy costs?"
The Design Philosophy
Like our PocketScout MCP server, the design philosophy is the same: the gap in the MCP ecosystem isn't more API wrappers. It's domain expertise encoded into tool design — the rate engine that knows your exact per-kWh cost for every hour of the day, the battery optimizer that understands NEM credits accumulate monthly and settle annually.
The best tools don't just expose APIs. They encode domain knowledge into the interface between human intent and machine capability.
PG&E Energy MCP is open source. View on GitHub or connect it to Claude right now.