Connect an AI client with MCP

Use the endpoint for your ISO

Choose ERCOT, CAISO, NYISO, PJM, SPP, MISO, or ISO-NE on the MCP Servers page, then copy that page's resource endpoint into your MCP client. Each connection covers exactly one market.

1. 1Open MCP Servers and choose a live market.
2. 2Copy the resource endpoint shown on that market page.
3. 3Add the endpoint as a remote Streamable HTTP server in your client.
4. 4Follow the browser prompt to sign in and approve the requested scopes. Alert and hydration writes are never included unless the client explicitly requests the matching write scope.

OAuth is handled by your client

Compatible clients discover Ask the Grid's authorization server automatically and use OAuth 2.1 with PKCE. You never paste an Ask the Grid password or long-lived API key into the client.

One connection, every market

The global MCP server exposes the same tools as the per-ISO servers, but every data tool takes an explicit iso argument (ERCOT, CAISO, NYISO, PJM, SPP, MISO, or ISO-NE) instead of fixing the market in the connection itself. Use it when one agent session needs to move between markets.

1. 1Open MCP Servers and use the global server's endpoint instead of a per-ISO one.
2. 2Pass iso on every search_data, describe_data, query_data, query_grid_assets, get_live_grid_status, get_asset_profile, get_asset_intelligence, and request_asset_hydration call.
3. 3The global connection covers ERCOT, CAISO, NYISO, PJM, SPP, MISO, and ISO-NE; any other market value is rejected.

Manage your own connections

The global server adds list_grants and revoke_grant for your MCP authorizations, plus list_saved and manage_saved for your saved assets and portfolios. Connection management and saved-workspace access use separate OAuth scopes. You can also review every client, scope, and market from Settings → Connections.

Discover before querying

search_data finds query-ready datasets for the connected ISO. describe_data returns a dataset's schema, time semantics, measures, relationships, and required scope predicates.

Run bounded read-only queries

query_data accepts read-only SQL against catalog-registered tables. Queries are table-allowlisted, ISO-validated, timed out, and capped at 200 returned rows.

Resolve the physical grid

query_grid_assets searches plants, nodes, zones, substations, and transmission lines. get_live_grid_status returns current headline values and freshness metadata for the connected ISO.

Keep SPP identities and gaps explicit

SPP MCP catalog coverage includes prices, load, fuel mix, forecasts, reserves, constraints, interchange, published DC-tie flow, and ISO-scoped grid assets. SPP East, SWPW/SPP West, balancing-area, reserve-zone, and market labels remain separate. The MCP catalog does not currently expose an SPP interconnection queue or operational-event feed. Some public location records have no verified coordinates. query_grid_assets returns only published identities and never invents coordinates, ownership, settlement exposure, or a relationship between market identities.

Read the Energy Wire

search_wire searches collected US grid, market, and regulatory news across roughly 225 publishers, ISO newsrooms, utilities, and regulators — newest first, optionally scoped to one market or sector. get_wire_briefings returns the operator briefings written over closed windows, each stating the knowledge cutoff it was written against and citing the publishers behind it. Both are on the global server only, since most wire stories are national rather than market-scoped, and both return the publisher's canonical URL for every story — cite that rather than Ask the Grid. Article bodies are never stored and never returned.

Work with hydrated asset intelligence

get_asset_profile returns a compact published summary. Enterprise users can retrieve the complete reviewed dossier with get_asset_intelligence, queue a missing profile with request_asset_hydration, and follow it with get_asset_hydration_status. Hydration only accepts an exact existing asset from query_grid_assets.

Read and manage alerts

get_alert_capabilities returns the executable market, target, signal, and condition combinations in the shared capability registry, with filters that keep the response focused. A market accepted by an input enum is not necessarily executable: SPP currently returns an explicit unavailable state and no executable combinations. list_alerts filters rules by lifecycle status; get_alert returns one owned rule and its recent evidence history, including archived rules. create_alert saves only a registry-backed rule. manage_alert pauses, resumes, updates, or archives one rule. Per-ISO connections can only reach alerts in that market; the global connection can act only on combinations returned by get_alert_capabilities.

1. 1Call get_alert_capabilities when the requested target, metric, or comparison type may not be supported.
2. 2Resolve exact asset and price-node references with query_grid_assets, then copy the returned id unchanged. For example, LZ_AEN resolves to node:LZ_AEN; its LZ_ name does not make the MCP target zone:LZ_AEN.
3. 3Ask the client to list your alerts before changing one whose exact id is not already known.
4. 4Explicitly ask to create an alert and describe the market, target, metric, direction, and threshold.
5. 5Review any warning that the threshold is unusually common, rare, or backwards for the stated goal.
6. 6Explicitly ask to pause, resume, update, or archive the chosen alert. Pausing is reversible; archiving removes it from evaluation.

Explicit requests only

A question such as “What is the Houston price?” or “How is ERCOT doing?” is not permission to create an alert. The client should call create_alert only after you explicitly ask for an alert, notification, warning, watch, or monitor. Management intent is action-specific too: asking to pause does not authorize archiving, and asking to inspect does not authorize an update. The server requires the exact user request and rejects implicit or mismatched actions.

Check the threshold against recent data

Before creating or updating a value alert, the client should inspect recent market data and compare the proposed threshold with the signal's normal range. If the rule would be almost always true, almost never true, or point in the wrong direction for the stated goal, it should explain the mismatch and ask you to confirm or revise it rather than silently changing the number.

Know what an average comparison means

A moving-average alert compares the latest observation with the trailing window you choose, such as the previous 24 hours. It does not yet compare one clock interval with that same interval across prior days. For ERCOT grid price, the evaluator uses the HB_HUBAVG historical series; node-specific price alerts use the exact node returned by query_grid_assets.

Alerts are state transitions, not polling

Ask the Grid evaluates supported sources on their real cadence and notifies when a rule changes state. It does not send one message for every matching sample. Per-second and sub-minute alert requests are rejected; use a meaningful threshold, confirmation window, recovery rule, and rolling delivery cap instead.

Signed-in, scoped, and revocable

MCP access requires an Ask the Grid account. Tokens are short-lived and audience-bound to one resource — a single market, or every market for the global server; refresh tokens rotate. You can revoke an approved client from Settings → Connections at any time, or ask the global server's revoke_grant tool to do it.

Read and write scopes stay separate

Market, catalog, SQL, profile, alert-list, status, and Energy Wire tools are read-only. Asset hydration uses mcp:assets.write; alert changes use mcp:alerts.write; saved-workspace reads and writes use mcp:saved.read and mcp:saved.write; connection management uses mcp:account.read and mcp:account.write; the wire uses mcp:wire.read. No write scope is included in the default read-only authorization. Writes are ownership-scoped, rate-limited, and recorded in the MCP audit trail.