Skip to main content
Glama

Query Power Interconnection Queue (ISO-NE)

query_power_interconnection_queue_isone_v1
Read-onlyIdempotent

Query the ISO-NE generator interconnection queue — ISO New England's public IRTT "public queue" report, the waiting line of projects that have REQUESTED to connect to the New England grid (CT, MA, ME, NH, RI, VT).

Returns cited, project-level records with ISO-NE's full published structure (all 31 columns of the rendered report): the three megawatt readings kept SEPARATE (net_mw, summer_mw = max summer output, winter_mw = max winter output — net_mw is 0 for the many Capacity-Network-Resource-only requests, a real value, not missing), the request request_type (G = Generation / ETU = Elective Transmission Upgrade / TS = Transmission Service), the space-delimited multi-value fuel_type (EIA energy-source codes, e.g. "SUN BAT"), the unit_type and service code serv (CNR = Capacity Network Resource / NR = Network Resource), the jurisdiction (F = FERC / N = Non-FERC), the ISO-NE load zone, the per-stage study statuses (fs_statusia_status) with their study-document links, location (state, county, derived county_fips, poi), and lifecycle dates. Group or filter by application_status, project_status, request_type, unit_type, fuel_type, serv, jurisdiction, zone, state, county_fips, or cluster; filter requested_date by the requested_date_from / requested_date_to range. Pass each parameter as a top-level key of params (flat — not nested). Example: {"application_status": "A", "request_type": "G", "state": "MA"} for active generation requests in Massachusetts; {"group_by": ["application_status"]} for requested MW and project counts by status. 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.

net_mw / summer_mw / winter_mw 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 rows but is a REQUESTED total only. ISO-NE publishes net, summer-peak and winter-peak MW separately — served under ISO-NE's own labels and never blended into one nameplate. Scope by application_status: A = Active (the live pipeline), C = Commercial (built and in service — the built reading), W = Withdrawn. ISO-NE ALSO carries a separate build-progress project_status (Under Study / Under Construction / In Service / …) — kept distinct from application_status, never collapsed. For built/operating capacity use query_power_capacity_v1.

ISO-NE 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 NYISO (New York, incl. load interconnection requests) queue use query_power_interconnection_queue_nyiso_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. ISO-NE publishes no data-center / load request type (all rows are generation or transmission), and this tool does not infer one — that interpretation is the analyst's, from cited rows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations (read-only, idempotent, non-destructive), the description discloses that requested MW is not built capacity ('NEVER read a queue-MW total as installed or operating capacity'), that net_mw is a real value (not missing) for CNR-only requests, and that records include citation fields. It also distinguishes application_status from project_status, adding important interpretative context.

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

Conciseness4/5

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

The description is lengthy but each paragraph has a clear function: data scope, value semantics/caveats, and regional alternatives. It is front-loaded with the core purpose and uses structured enumeration. Some redundancy exists but overall it is efficiently organized.

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?

For a tool with many undocumented parameters, the description covers filtering, grouping, value codes, geography, and caveats, and points to sibling tools for other ISOs. It also explains return citation behavior and the relationship to output schema, making it complete for an agent to select and invoke correctly.

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?

Despite zero schema parameter documentation, the description enumerates all filterable fields (application_status, request_type, fuel_type, zone, etc.), explains allowed values (e.g., 'A'=Active, 'C'=Commercial, 'W'=Withdrawn), and gives concrete parameter examples with flat top-level keys. It fully compensates for the schema's lack of detail.

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 uses a specific verb ('Query') and resource ('ISO-NE generator interconnection queue — ISO New England's public IRTT public queue report'), and immediately distinguishes it from sibling ISO-specific tools. It clearly states the geographic region and report type, making its purpose unambiguous.

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?

Explicit guidance is provided: 'For built/operating capacity use query_power_capacity_v1' and a full list of ISO-specific alternatives ('For the MISO interconnection queue use query_power_interconnection_queue_v1; for PJM use...'). It also notes the tool never infers data-center/load requests, ruling out misinterpretation.

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