get_refined_queue
Use this when you need interconnection queue projects filtered server-side. 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 interconnectio...
This record as markdown: /tools/cloud-dchub-mcp-server/get-refined-queue.md
What get_refined_queue does on Mcp Server
AI agents call get_refined_queue to retrieve information from Mcp Server without modifying anything. It is typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
iso | string | — | Restrict 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 |
limit | integer | — | Max results to return (1-500; default varies by tool) |
min_mw | number | — | Minimum project capacity in MW, e.g. 1000 for 1 GW+ |
status | string | — | Queue status filter. Default 'active' = still progressing (excludes withdrawn/cancelled/suspended/in-commercial-operation) — cross-ISO safe (SPP labels live pro |
developer | string | — | ERCOT only: keep projects whose developer name contains this text (case-insensitive substring, e.g. 'tenaska'). Developer names come from ERCOTQueue (ercotqueue |
fuel_type | string | — | Isolate 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 bot |
max_fiber_km | number | — | Keep 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-c |
baseload_only | boolean | — | Keep only firm/dispatchable fuel (nuclear, gas, steam, geothermal, hydro, coal); exclude wind/solar/storage. Firm-vs-intermittent split only — does NOT sub-divi |
geocoded_only | boolean | — | Keep 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_months | integer | — | Max 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, ERC |
Parameters from the server's own tool schema.
Why get_refined_queue is rated Low
Tool retrieves and filters interconnection queue data with no side effects or state changes.
From the tool's definition filtered server-side query returning queue_results; no creation, modification, deletion, or execution.
Risk signalsHigh parameter count (10 properties)
Attacks that exploit this kind of access
The rule that runs get_refined_queue safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Mcp Server, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For get_refined_queue, this is the rule to start with:
get_refined_queue is read-only, so it stays allowed. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Mcp Server, apply this rule, and every get_refined_queue call is checked against it from then on.
Questions about get_refined_queue
Use this when you need interconnection queue projects filtered server-side. 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. Answers "show me 1 GW+ gas projects that can connect in under three years", "what is in the queue that actually fits my timeline". 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. It is categorised as a Read tool in the Mcp Server MCP Server, which means it retrieves data without modifying state.
get_refined_queue accepts 10 parameters: iso, limit, min_mw, status, developer, fuel_type, max_fiber_km, baseload_only, geocoded_only, max_ttp_months. The full parameter table on this page comes from the server's own tool schema.
Register the Mcp Server MCP server in PolicyLayer and add a rule for get_refined_queue: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Mcp Server. Nothing to install.
get_refined_queue is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the get_refined_queue rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for get_refined_queue. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
get_refined_queue is provided by the Mcp Server MCP server (https://dchub.cloud/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Mcp Server, and thousands of servers like it.
This server
Across the catalogue