Skip to main content
Glama

Query Power Interconnection Queue (NYISO)

query_power_interconnection_queue_nyiso_v1
Read-onlyIdempotent

Query the NYISO generator + load interconnection queue — New York ISO's public waiting line of projects that have REQUESTED to connect to the New York grid. Uniquely among ISOs, NYISO publishes a Load Projects tab — load interconnection requests (large-load demand), served as-reported — and since its 2026-07 edition tags each load request with its own End-Use class (end_use, e.g. DAT / DAT-AI / DAT-CM, served verbatim).

Returns cited, project-level records with NYISO's full published structure across every lifecycle tab (nine tabs through 2026-06; seven since NYISO's 2026-07 restructure): summer and winter peak megawatts kept SEPARATE (sp_mw = SP, the max summer output; wp_mw = WP, the max winter output), the Load Projects tab's peak_mw_load with NYISO's own end_use class and sis_bundle study-batch code (both 2026-07 onward, null before), the as-reported study-phase code (study_status_code — NYISO's numeric key, labeled S through 2026-06 and Project Status # / NYISO Status since), the request record_type and project_type, the type_fuel codebook, the energy-storage capability, the NYISO load zone (A–K), location (state, county, derived county_fips, point_of_interconnection, utility), and lifecycle dates (ir_date, last_update, the milestone dates, and the Year/Qualifier proposed_cod kept verbatim). Group or filter by application_status, sheet_name, state, county_fips, study_status_code, record_type, type_fuel, zone, utility, studies_available, or end_use; filter ir_date by the ir_date_from / ir_date_to range. Pass each parameter as a top-level key of params (flat — not nested). Example: {"application_status": "ACTIVE", "type_fuel": "S"} for active solar requests; {"sheet_name": "Load Projects"} for the load interconnection requests; {"end_use": "DAT-AI", "application_status": "ACTIVE"} for the load requests NYISO itself codes DAT-AI; {"group_by": ["application_status"]} for requested MW and project counts by lifecycle. Returns JSON aggregates with citations and optional row-level records when include_records is true; every value carries source, as_of, and a source_row verifiable with get_source_evidence_v1.

sp_mw / wp_mw / peak_mw_load are REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built, so the queue is withdrawn-dominated. NEVER read a queue-MW total as installed or operating capacity — it is additive across distinct project-rows but is a REQUESTED total only. NYISO publishes summer (SP) and winter (WP) peak MW separately — they are served under NYISO's own names and never blended into one nameplate. Scope by application_status (ACTIVE / WITHDRAWN / IN_SERVICE / AFFECTED_SYSTEM / AFFECTED_SYSTEM_WITHDRAWN — the lifecycle tab's reading, overridden to the withdrawn form when a row carries NYISO's own status code 0, per the workbook's printed '0=Withdrawn' key) or by sheet_name; the In Service tab is the built reading. A project may appear on more than one tab (the grain is sheet + queue_position), so the counts are project-rows, not deduped projects. For built/operating capacity use query_power_capacity_v1.

NYISO only — never summed, deduped, or compared across ISOs. For the MISO interconnection queue use query_power_interconnection_queue_v1; for PJM use query_power_interconnection_queue_pjm_v1 (or query_power_interconnection_queue_pjm_cycle_v1 for PJM's cluster/cycle grid); for the CAISO (California) queue use query_power_interconnection_queue_caiso_v1; for the ISO-NE (New England) queue use query_power_interconnection_queue_isone_v1; for the ERCOT (Texas) queue use query_power_interconnection_queue_ercot_v1; for the SPP (central US) queue use query_power_interconnection_queue_spp_v1. NYISO's Load Projects tab is served as-reported: end_use is NYISO's OWN classification (NYISO publishes no key for the codes), and this tool does NOT infer an end use NYISO did not print — interpretation beyond the code is the analyst's, from cited rows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes far beyond annotations by disclosing critical behavioral traits: requested vs built capacity, withdrawn-dominated queue, project-row grain, 'as-reported' data with no inference, and the 'never summed across ISOs' caveat. This context is essential for correct interpretation and is absent from the minimal annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is excessively verbose and repetitive. For instance, 'requested not built' appears twice, 'NYISO only' is stated multiple times, and the full list of sibling tools is redundantly enumerated. While comprehensive, it would benefit from tighter structuring and removal of repeated caveats.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is exhaustively complete for a tool of this complexity: it covers all key fields, tab structure, parameter semantics, grain, exclusions, and even how to verify results via get_source_evidence_v1. Given the minimal schema and rich domain, the description leaves no crucial gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is nearly empty (only a freeform 'params' object with 0% description coverage). The description fully compensates by enumerating numerous valid keys (application_status, sheet_name, end_use, ir_date_from/to, group_by, include_records, etc.) and providing usage examples with meanings, such as 'sp_mw = SP, the max summer output.'

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb+resource: 'Query the NYISO generator + load interconnection queue.' It explicitly distinguishes from siblings by naming the ISO and listing alternative tools for other ISOs (MISO, PJM, CAISO, etc.).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance and alternatives: 'For built/operating capacity use query_power_capacity_v1' and names each ISO-specific queue tool. Also gives concrete example parameter combinations (e.g., {"application_status": "ACTIVE", "type_fuel": "S"}).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Each capability has a clearly named describe/query pair, and domains like power, AI infrastructure, robotics, and space are distinct. The generic describe_capability_v1/query_capability_v1 could be confused with the named variants, and the many ISO-specific interconnection queues share similar names, but descriptions explicitly disambiguate them.

Naming Consistency5/5

All tools follow a consistent lowercase snake_case verb_noun pattern: describe_<capability>_v1 and query_<capability>_v1, with a few utility tools like list_capabilities_v1 and get_source_evidence_v1. There is no mixing of conventions.

Tool Count2/5

At 62 tools, the set is far too large for typical server scope. The describe/query pairs inflate the count even though each is justified, and the generic capabilities plus per-ISO variants make it feel heavy and hard to navigate.

Completeness4/5

The server covers each domain thoroughly with describe, query, and evidence verification, plus generic fallbacks for capabilities not yet in the client's tool list. Minor gaps exist (e.g., no county/state attribution for some data, no load types in ISO queues) but they are explicitly documented and workable.

Resources