Skip to main content

FERC Open Data in AI Agents: Seller Authorizations, PPAs, and What the Catalog Actually Covers

· 6 min read
Tony Lewis
MCPBundles
Ask AI:
PerplexityClaudeChatGPTGoogleGrok

TL;DR​

  • The FERC Open Data MCP server exposes 28 datasets across 6 program assets on data.ferc.gov — including 4,435 market-based rate seller authorization rows and 44,563 entity-to-PPA links in the live catalog.
  • Ask for seller authorizations, PPA tables, company registration, or pending NEPA infrastructure projects and the agent discovers the dataset, reads metadata, and samples rows — no clicking through the portal asset tree.
  • Built for energy analysts, infrastructure researchers, and regulatory teams who need MBR and PPA context for power-market work — not a substitute for Electric Quarterly Reports or FERC Form 1 financials, which are not on this API yet.

If you work in power markets, you've probably hit the same wall: someone asks for FERC seller-authorization context or a sample of PPAs tied to entities, and twenty minutes later you're still in the open-data portal wondering which asset holds the table you actually need. The data is public. The friction is finding the right dataset ID and knowing what the API will not filter for you.

Start with discovery, not a download​

FERC's open-data surface is organized by program asset — Market-Based Rate Database, Company Registration, NEPA schedules, and others — each with nested datasets. The trap is jumping straight to row pulls before you know which dataset_id is current.

The agent's first move on a topic question is keyword discovery: "What FERC datasets cover market-based rate seller authorizations?" returns ranked matches with IDs, parent asset names, and descriptions. That one step replaces the portal walk.

For a full orientation ask "what FERC data do you have" and the agent returns the asset count, dataset count, and a compact list — plus an honest note that EQR and Form 1 are outside this API.

MBR authorizations and PPAs are the workhorse tables​

Market-based rate research usually lands on two tables.

MBR Authorizations (dataset id 9 in the current catalog) holds about 4,435 seller authorization rows — reporting entity, parent company, docket, effective dates, and related fields. A natural follow-up is "sample a few rows of MBR seller authorizations and tell me what fields are available" — details, dictionary, then a small page read.

Entities to PPAs (dataset id 17) is larger — 44,563 rows linking entities to power purchase agreements. "Find FERC PPA datasets and show me 3 sample rows" is the pattern: find, details, data.

These are paginated reads. There is no server-side "give me only solar" or "only PJM" filter. If the question implies a regional or balancing-authority slice, the honest answer is what the catalog contains and what it cannot filter — not a silent full-table scan pretending to be a filter.

Named company lookups work; geography filters do not​

When the user names a counterparty, row search is the right tool. "Find Summit Grid parent's market-based rate seller authorization" can resolve a docket after dataset discovery — the same path that surfaces a named utility's authorization row in MBR data.

What does not work is treating row search as a geographic query engine. "Active solar PPAs in PJM" sounds reasonable in conversation, but the API does not expose a balancing-authority column you can filter server-side. The agent should discover the PPA dataset, explain the limitation, and avoid paging through tens of thousands of rows hunting for a column that is not there.

That boundary is worth stating up front in any datacenter or interconnection research brief: this connector is catalog navigation plus deliberate sampling, not a replacement for EQR contract exports.

NEPA and registration fill different drawers​

Infrastructure diligence often needs the NEPA schedule — about 233 rows in the current NEPA Schedule dataset, with project names, statuses, and dates. "Show me three pending NEPA infrastructure projects from FERC" is a find → details → data path that returns real project names from the live table.

Company registration is a separate asset. "Look up a FERC company identifier for a named parent" routes through registration datasets rather than MBR authorizations. Keep the drawers separate — registration IDs are not the same question as seller-authorization dockets.

EQR and Form 1: say no early​

The most expensive mistake is substituting the wrong table when someone asks for Electric Quarterly Reports or FERC Form 1 utility financials. Neither is published on data.ferc.gov today.

A terse prompt like "datacenter power contracts ferc eqr" should come back with an honest gap statement and a pointer to what is available — MBR authorizations and entity-to-PPA links for market-based-rate context — not a fabricated answer built from unrelated annual-charge tables.

Connect and try it​

Enable the FERC Open Data server in your workspace — no separate FERC sign-in on your side — and ask from Claude, Cursor, ChatGPT, or wherever you already run research. A solid opener is "what FERC open data do you have, then find market-based rate seller authorization datasets and sample three rows" — it proves catalog coverage and field names in one pass.