Skip to main content
Glama

get_refined_queue

Read-onlyIdempotent

Filter the US ISO interconnection queue by capacity, fuel type, ISO, and time-to-power, returning only matching projects with site evaluation handoffs for siting and arbitrage scans.

Instructions

Server-side SET-REDUCTION over the US ISO interconnection queue (~5,300 projects, 7 ISOs, ~1,744 GW). Instead of pulling the raw queue into context to filter (token-expensive, error-prone), push the predicates to the data layer and get back ONLY the survivors. Filter by min_mw, max_ttp_months (ISO-level avg interconnection wait), iso (comma-union), baseload_only (firm/dispatchable — excludes wind/solar/storage), fuel_type (isolate a specific fuel, e.g. gas or nuclear), and the spatial predicates max_fiber_km + geocoded_only. Returns _entity=queue_results: per-project name, ISO, state/county, fuel_type, capacity_mw, queue_status, estimated_ttp_months, fuel_class, plus (~83% of rows) lat/lng, coordinate_precision, fiber_km, and a compact per-survivor site_evaluation_handoff (ready-to-pipe analyze_site + get_water_risk args) + a by_iso/by_fuel summary. Try: get_refined_queue min_mw=1000 fuel_type=gas max_ttp_months=34 — "1 GW+ gas in ISOs under 34-month time-to-power." NOTE max_ttp_months is a HARD ISO cut (SPP ~24 is the only ISO under 30, so <=30 can return nothing); use >=34 to include MISO/ERCOT/ISO-NE. Use for high-cardinality siting/arbitrage scans; do NOT use for the ISO-level GW aggregate (use get_interconnection_queue) or a single-site read (use analyze_site). Phase 2 LIVE: pipe a survivor's site_evaluation_handoff straight into analyze_site for a one-call composite viability read. CANDIDATE CONTRACT (2026-07-11): every survivor also mints a durable opaque candidate_id + snapshot_id (7-day TTL, deterministic candidate_expired on lapse — never a silent recompute). ZERO-DRIFT CHAINING: pass candidate_id to analyze_site / rank_sites instead of transposing coordinates — downstream reads the FROZEN mint, eliminating param-rename/rounding/lost-context drift. geocoded_only=true guarantees every survivor carries both the handoff AND frozen coordinates. Contract doc: dchub.cloud/docs/candidate-lifecycle.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
isoNoRestrict to one or more ISOs, comma-separated for a union: PJM, ERCOT, MISO, CAISO, SPP, NYISO, ISONE (ISO-NE). e.g. iso=ERCOT,PJM. Omit for all; combines with max_ttp_months as an intersection
limitNoMax results to return (1-500; default varies by tool)
min_mwNoMinimum project capacity in MW, e.g. 1000 for 1 GW+
statusNoQueue status filter. Default 'active' = still progressing (excludes withdrawn/cancelled/suspended/in-commercial-operation) — cross-ISO safe (SPP labels live projects 'IA FULLY EXECUTED/ON SCHEDULE' not 'active'). Pass 'all' for every status, or a literal label to substring-match
fuel_typeNoIsolate a fuel by inclusive substring match on the raw label; comma/semicolon-separated for a union, e.g. 'gas' hits GAS/Natural Gas, 'nuclear,hydro' unions both. Runs the fuel filter server-side instead of post-filtering survivors in context
max_fiber_kmNoKeep only survivors within N km of the nearest MAPPED long-haul fiber route endpoint — coarse backbone proximity from a sparse ~260-node dataset over a county-centroid origin, NOT last-mile fiber. Implies geocoded rows only
baseload_onlyNoKeep only firm/dispatchable fuel (nuclear, gas, steam, geothermal, hydro, coal); exclude wind/solar/storage. Firm-vs-intermittent split only — does NOT sub-divide peaker vs combined-cycle gas (no duty-cycle field in the queue). Default false
geocoded_onlyNoKeep only survivors that carry lat/lng (~83% of the queue) — the ones with a ready site_evaluation_handoff you can pipe into analyze_site. Default false
max_ttp_monthsNoMax time-to-power in months (ISO-level avg interconnection wait; HARD cut keeping projects in ISOs at/under this — PJM ~51, CAISO ~40, ISO-NE ~34, MISO ~34, ERCOT ~33, NYISO ~31, SPP ~24; <=30 leaves only SPP)
Behavior5/5

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds substantial behavioral details: returns only survivors, includes a site_evaluation_handoff for chaining, describes the candidate lifecycle (candidate_id, snapshot_id, TTL, zero-drift chaining), and notes that geocoded_only=true guarantees coordinates. No contradictions with 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 comprehensive but somewhat lengthy (approximately 400 words). However, every section serves a purpose: main function, usage, example, parameter nuances, chaining mechanism. It is front-loaded with the core concept. Some minor redundancy (e.g., repeated mention of site_evaluation_handoff) but overall well-structured for a complex tool.

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 9 parameters, no output schema, and many sibling tools, the description is exceptionally complete. It explains return structure (_entity, per-project fields, summary), covers all parameters, includes usage constraints (e.g., max_ttp_months behavior), and describes how to chain results with analyze_site. The candidate contract details future-proof chaining. No gaps identified.

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

Parameters4/5

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

Schema description coverage is 100% (all 9 parameters documented). The description adds practical semantics beyond the schema, e.g., explaining max_ttp_months is a HARD ISO cut with specific ISO thresholds, and clarifying that baseload_only does not sub-divide gas types. This extra context merits a 4, slightly above baseline 3.

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 clearly states the tool performs server-side filtering (SET-REDUCTION) over the US ISO interconnection queue, returning only survivors that match predicates. It explicitly distinguishes from siblings get_interconnection_queue (ISO-level aggregate) and analyze_site (single-site read). The verb 'get' and resource 'refined queue' are specific.

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 usage guidance: 'Use for high-cardinality siting/arbitrage scans; do NOT use for the ISO-level GW aggregate (use get_interconnection_queue) or a single-site read (use analyze_site).' Includes an example query and notes on max_ttp_months thresholds, giving clear when-to-use and when-not-to-use context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/azmartone67/dchub-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server