Skip to main content
Glama

Query Power Interconnection Queue (SPP)

query_power_interconnection_queue_spp_v1
Read-onlyIdempotent

Query the SPP generator interconnection queue — Southwest Power Pool's public GI Summary report, the waiting line of generation projects that have REQUESTED to connect to the SPP grid (the ~14-state central-US RTO: OK, KS, TX panhandle, NE, NM, MO, CO, ND, SD, AR, LA and more).

Returns cited, project-level records with SPP's full published structure: the requested capacity_mw (SPP's headline Capacity figure) PLUS five other labeled MW columns SPP publishes — max_summer_mw, max_winter_mw, requested_max_injection_mw, requested_nrd_mw, nameplate_capacity_mw — served separately and NEVER blended; the generation_type (Wind / Solar / Battery/Storage / Thermal / Hybrid / Hydro — SPP encodes hybrids natively as Hybrid, so no is-hybrid is invented) and free-text fuel_type (slash-delimited combos like Solar/Storage kept whole); the study current_cluster (e.g. DISIS-2024-001, Surplus, RTOE Transitional Cluster) and regional cluster_group (01 NORTH05 SOUTHWEST); the transmission owner to_at_poi; the service_type (ER/NR, ER, NR); the substation_or_line; and the lifecycle dates (request_received, in_service_date, commercial_operation_date, date_withdrawn). Group or filter by native_status, generation_type, fuel_type, service_type, current_cluster, cluster_group, to_at_poi, county_fips, or state; filter request_received / commercial_operation_date by their _from / _to ranges. Pass each parameter as a top-level key of params (flat — not nested). Example: {"native_status": "DISIS STAGE", "generation_type": "Solar"} for solar in the DISIS study stage; {"native_status": "DISIS STAGE", "group_by": ["state"], "order_by": "capacity_mw", "top_n": 5} for the active study pipeline's biggest states by requested MW. 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.

capacity_mw is REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built — in the SPP file ~66% of rows are WITHDRAWN. NEVER read a queue-MW total as installed or operating capacity — it is additive across distinct rows but is a REQUESTED total only. Always scope by native_status, which is SPP's OWN status vocabulary served VERBATIM (IA FULLY EXECUTED/ON SCHEDULE, IA FULLY EXECUTED/COMMERCIAL OPERATION, IA FULLY EXECUTED/ON SUSPENSION, IA PENDING, DISIS STAGE, FACILITY STUDY STAGE, SPECIAL STUDY, ERAS, TERMINATED, WITHDRAWN, …); it is never mapped to a lifecycle enum and there is no derived active/withdrawn flag — that equivalence is the analyst's. For built/operating capacity use query_power_capacity_v1. SPP's GI Summary is regenerated on demand and SPP keeps no per-vintage archive, so this serves SPP's CURRENT queue (the response as_of is SPP's own "Last Updated On" stamp); it is NOT a deep point-in-time history — history accrues forward from first capture, so there is no as_of time-travel parameter.

SPP 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) queue use query_power_interconnection_queue_nyiso_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. SPP's GI queue is GENERATION-only and infers no load/data-center type — 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?

Despite annotations already declaring read-only/idempotent behavior, the description adds crucial context: capacity_mw is requested not built, ~66% of rows are WITHDRAWN, the data is current-only with no point-in-time history, and SPP keeps no per-vintage archive. This significantly enriches the safety and data-quality understanding beyond annotations.

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 dense and front-loaded with the core purpose, and every paragraph addresses a distinct concern (records returned, capacity semantics, status vocabulary, archival limits, cross-ISO guidance). However, there is some redundancy in warnings ('NEVER read...' repeated, and 'that equivalence/interpretation is the analyst's' used twice), so a small amount of trimming could make it tighter.

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?

Given the complexity (1 free-form parameter, many siblings, output schema present), the description is exceptionally complete. It explains return structure (cited project-level records, aggregates, source/as_of/source_row), the distinction from other ISOs, the difference between requested and built capacity, and the lack of historical depth. The output schema note is satisfied, and the description goes beyond it.

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?

Schema coverage is 0% since the only property is a free-form object. The description compensates by documenting key parameters (capacity_mw, generation_type, native_status, current_cluster, etc.) and gives concrete examples ('native_status': 'DISIS STAGE', 'generation_type': 'Solar') plus formatting guidance ('flat — not nested'). This fully makes up for the absent schema 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 opens with a specific verb ('Query') and resource ('SPP generator interconnection queue'), then explains exactly what SPP is and what the queue represents. It names the specific ISO and distinguishes from siblings by explicitly listing the other queue tools for MISO, PJM, CAISO, NYISO, ISO-NE, and ERCOT.

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: 'Always scope by native_status', warns against summing across ISOs, and directly names alternatives for each other ISO. It also points to query_power_capacity_v1 for built/operating capacity, making the usage context crystal clear.

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