Power Interconnection Queue (MISO) API v1
Generated from
core.contract.describe_power_interconnection_queue_v1()and checked fixture-backed examples. Do not hand-edit the example JSON files.
Capability
- Capability:
power.interconnection_queue - Primitive:
query_power_interconnection_queue_v1 - Status:
available - Current source:
energy.miso.giqueue - Source publisher: Midcontinent Independent System Operator (MISO)
- Snapshot behavior:
as_of = latestresolves to an exact snapshot date in every response.
What It Can Answer
- Which generation projects have REQUESTED to connect to the MISO grid, by state/county, fuel, technology, and status.
- The requested net summer / net winter megawatts of each queued project, cited to its source row.
- The as-reported application status, study phase, and post-GIA status of each project (kept separate, never collapsed).
- The count of queued projects in a scope (active vs withdrawn vs done, by filtering application_status).
- Row-level detail records when
include_recordsis true. - Raw JSON record evidence for any returned row-level citation.
Represented Facts
MISO's generator interconnection queue reports each project's REQUESTED interconnection capacity (net summer / net winter MW) — a request, not built capacityMISO's queue reports each project's location (state, county), fuel and technology, three as-reported status dimensions (application status, study phase, post-GIA status), and lifecycle dates (queue, withdrawn, in-service, done)MISO also reports two sparse lifecycle dates served under MISO's own field labels — gia_to_exec_date and neg_in_service_date; MISO publishes no data dictionary, so these are served as-reported and not reinterpreted (present where MISO reports them, null otherwise)
Data Point Contract
- Data point:
power.interconnection_queue - Product spec:
blocks/power_interconnection_queue/card.md - Grain:
project_snapshot - Source basis:
energy.miso.giqueue - Represented fact: The MISO generator interconnection queue (GI Queue) — the public waiting line of every project that has REQUESTED to connect to the MISO grid, served as-reported, project by project, with its requested megawatts and its three as-reported status dimensions (applicationStatus / studyPhase / postGIAStatus). This is a REQUEST, not built, committed, or planned capacity: historically the large majority of queued MW withdraws before it is built, so every MW field is named requested_* and is never summed as operating capacity. This is the only forward-looking slice in the power surface (capacity/generation/demand are backward-looking actuals). MISO carries no county_fips and no lat/lon; county_fips is derived by name where it resolves and left null otherwise. It is NOT a data-center product — MISO reports no load/data-center type and we never infer one.
Does not answer:
built, installed, operating, or nameplate capacity (that is power.capacity / EIA-860M; queue MW is REQUESTED, not built)a sum of requested MW treated as planned or operating capacity (most queued MW withdraws — requested totals are labeled, never read as built)a cross-ISO or national queue total (methodologies, inclusion, and withdrawal rates differ per ISO — never summed or deduped across ISOs)which projects are data-center- or load-driven (MISO reports no load/data-center type; that inference is the analyst's, never tagged here)the probability that a queued project will actually be built or reach commercial operationgeneration MWh, demand, prices, retail sales, or transmissionlat/lon or plant-level attribution (MISO supplies none; only state, as-reported county, and derived county_fips)queues for other ISOs/RTOs (PJM, CAISO, NYISO, ISO-NE, ERCOT, SPP) — each is a separate block under the same gate
REST Surface
GET /v1/healthGET /v1/capabilitiesGET /v1/power/interconnection-queue/schemaPOST /v1/power/interconnection-queue/queryPOST /v1/evidence/source-row
MCP Surface
list_capabilities_v1describe_power_interconnection_queue_v1query_power_interconnection_queue_v1get_source_evidence_v1
Local MCP Setup
Some MCP clients launch servers from the user's home directory or ignore a configured cwd. Use uv run --directory so the server always starts from the repository project.
{
"command": "uv",
"args": [
"run",
"--directory",
"/absolute/path/to/OSINT",
"python",
"-m",
"core.mcp_server"
]
}
Leave EXASCALE_PARQUET_BASE / EXASCALE_RAW_BASE unset: the one server hosts every data point's tools, and with no override it resolves each block's promoted snapshots and raw archive from the repository layout. Setting either env var points ALL tools at one directory — a per-block path breaks every other block's tools. They exist only for single-source sandboxes and tests.
Request Schema
Filters:
as_ofstatecounty_fipsapplication_statusstudy_phasepost_gia_statusfuel_typefacility_typeservice_typestudy_groupstudy_cycleis_hybrid
Group by:
statecounty_fipsapplication_statusstudy_phasepost_gia_statusfuel_typefacility_typeservice_typestudy_groupstudy_cycleis_hybrid
Date range parameters:
queue_date_fromqueue_date_to
Controls:
include_recordsinclude_evidencelimitorder_bytop_norderrollup_other
Ranking (how order_by / top_n / order join — order_by ranks groups by a metric, never a group_by dimension; top_n needs both a group_by and an order_by):
{
"no_ranking": "Omit order_by and top_n to return all groups in group-key order.",
"order": {
"default": "desc",
"valid_values": [
"desc",
"asc"
]
},
"order_by": {
"accepts": "one of output.metrics",
"note": "Ranks the groups by a metric (a measure). Not a group_by dimension \u2014 rows already come back grouped by each group_by field.",
"requires": [
"group_by"
],
"valid_values": [
"requested_summer_mw",
"requested_winter_mw",
"source_record_count"
]
},
"top_n": {
"note": "Keeps the top N groups by order_by; the rest fold into one (other) remainder (additive metrics sum into it, non-additive ones are nulled) so the result still reconciles to summary.totals.",
"requires": [
"group_by",
"order_by"
],
"type": "positive integer"
}
}
Output Schema
Aggregate metrics:
requested_summer_mwrequested_winter_mwsource_record_count
Metric groups:
{
"records": [
"source_record_count"
],
"requested_mw": [
"requested_summer_mw",
"requested_winter_mw"
]
}
Response summary fields:
group_counttotals
Accepted fact policy:
- Query responses contain accepted, gate-passed facts only.
- Gate, monitor, and audit quality signals are internal controls, not agent-facing answer caveats.
- If a source snapshot is not fit to serve, the source must fail closed before it reaches this API.
Metric metadata:
| Metric | Category | Unit | Aggregation | Additive Across Groups | Authoritative Total | Definition |
|---|---|---|---|---|---|---|
requested_summer_mw |
requested_mw | MW | sum | true | summary.totals.requested_summer_mw |
The project's requested net summer interconnection capacity (MW), as MISO reports it on the queue. |
requested_winter_mw |
requested_mw | MW | sum | true | summary.totals.requested_winter_mw |
The project's requested net winter interconnection capacity (MW), as MISO reports it on the queue. |
source_record_count |
records | count | count source records | true | summary.totals.source_record_count |
Count of queued projects in the current result scope (one atom = one MISO project). |
Rollup rules:
summary.totals.<metric>is the authoritative total for the full matched query.- Grouped row metrics may be summed only when
additive_across_groupsistrue.
Detail record fields returned when include_records is true:
source_idsheet_nameisoproject_idmiso_internal_idtransmission_ownerpoi_namestatestate_rawcountycounty_fipscounty_fips_sourcecounty_fips_unresolvedservice_typefuel_typefacility_typeis_hybridrequested_summer_mwrequested_winter_mwrequested_dp1_eris_mwrequested_dp1_nris_mwrequested_dp2_eris_mwrequested_dp2_nris_mwapplication_statusstudy_phasepost_gia_statusstudy_groupstudy_cyclequeue_datewithdrawn_datein_service_datedone_dategia_to_exec_dateneg_in_service_datereport_periodsource_record_keysource_row_numberas_ofraw_file_sha256citation
Row-level citation fields:
source_idsource_urlsource_filesheetsource_rowraw_file_sha256as_of
Aggregate citation fields:
source_idpublishersource_urlsource_fileraw_file_sha256as_ofsource_rows_countsource_rows_sampleverifylineage_filter
Codebooks
| Field | Coverage | Codes | Examples | Note |
|---|---|---|---|---|
fuel_type |
the distinct fuel values observed in the served MISO snapshot | 14 | Solar = Solar, Wind = Wind, Battery Storage = Battery storage, Gas = Natural gas, Hybrid = Hybrid (multi-technology — see facility_type for the components) |
Filter fuel_type by MISO's EXACT value shown here — e.g. Gas for natural gas (NOT 'Natural Gas'). Hybrid is MISO's multi-technology catch-all; the slash-joined components (e.g. 'Solar/Battery') live in facility_type. Values are as-reported, so an early-stage request with no fuel is null, not a category. |
application_status |
the distinct status values observed in the served MISO snapshot | 6 | Active = Active — a live request still in the queue (requested, not built), Withdrawn = Withdrawn — the request left the queue (the queue is withdrawn-dominated), Done = Done — completed / in service, Pending Revision Approval = Pending revision approval, Pending Transfer = Pending transfer |
ALWAYS scope by application_status — the full queue is dominated by Withdrawn requests. Active is the live pipeline of REQUESTED (not built) capacity; Withdrawn requests have left the queue; Done are completed / in service. A queue-MW total is requested capacity, never built — for built/operating capacity use query_power_capacity_v1. |
The complete machine-readable codebooks are included in capability-schema.json.
Checked Examples
| Agent question | Request params | Checked output |
|---|---|---|
| How much requested capacity and how many projects sit in the MISO queue, by status? | {"group_by": ["application_status"]} |
miso-queue-by-status.json |
| Which states have the most requested interconnection capacity in MISO's queue? | {"group_by": ["state"], "order_by": "requested_summer_mw", "top_n": 10} |
requested-mw-by-state.json |
| What fuels are the active MISO interconnection requests, and how much capacity? | {"application_status": "Active", "group_by": ["fuel_type"]} |
active-requests-by-fuel.json |
| Return one MISO queue project with a row-level citation. | {"include_records": true, "limit": 1, "state": "MI"} |
queue-detail-with-citation.json |
| Verify the raw workbook row behind a returned citation | citations[ref].verify (aggregate) or records[0].citation (detail) |
source-row-evidence.json |
| Dogfood the tool sequence as an agent | list -> describe -> query -> evidence |
agent-dogfood-transcript.json |
The checked schema output is capability-schema.json.
Agent Workflow
- Call
list_capabilities_v1and selectpower.interconnection_queue. - Call
describe_power_interconnection_queue_v1to inspect valid filters, groupings, metrics, and citation fields. - Call
query_power_interconnection_queue_v1with bounded JSON params. - If the answer needs proof, pass a returned row-level
citationobject toget_source_evidence_v1. - Answer with the resolved
as_ofand relevant citations. Present returned metrics as authoritative for their declared source, snapshot, grain, and aggregation.