gov-data-mcp

interconnection-queue-tracker

Normalize US ISO/RTO interconnection queues into one schema and track new, withdrawn, status-change and COD-slip deltas across seven keyless live sources.

Instructions

US Interconnection Queue Tracker - 7 ISO Queues & Deltas API. Normalize US ISO/RTO generator interconnection queues (SPP, MISO, NYISO, CAISO, PJM, ERCOT, ISO-NE) into one schema and track new, withdrawn, status-change and COD-slip deltas. For renewables developers, land agents, and energy consultants. Keyless. INPUTS: leave isos empty for all seven ISOs, or name one or two to keep a first call small. maxResults is applied in ISO order, so a low value silently drops the later ISOs; raise it or narrow isos instead. For change monitoring use deltaOnly in snapshot mode rather than re-pulling the full queue. Reads live from the official government source. Call describe-gov-data-tool (free) for a verified example input. COST AND SIDE EFFECTS: read-only with respect to the government source — it never writes to any external system — but each call starts a metered run on YOUR Apify account, billed $0.008 per result ($8 per 1,000). Lower on paid Apify plans, down to $2.40 per 1,000. Nothing is charged when a run fails. Store page: https://apify.com/malonestar/interconnection-queue-tracker

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "interconnection-queue-tracker"
  }
}

Input Schema

Name	Required	Description
`isos`	No	ISO/RTO codes to pull. Leave empty to pull ALL 7 live sources (SPP, MISO, NYISO, CAISO, PJM, ERCOT, ISO-NE) in one run. All 7 are keyless - no account or API key needed. An unrecognised code now FAILS the run before anything is billed, rather than being silently dropped (which used to fall through to "all seven"). Example: ["SPP"]. Applied by default if omitted: [].
`mode`	No	snapshot = emit the current normalized queue, automatically annotated with monitor fields (is_new_since_last_run, status_changed, previous_status) vs. the actor's own self-managed KV snapshot, plus synthetic withdrawn and per-ISO iso_summary rows. delta = legacy manual mode: compare against a prior snapshot YOU supply (priorItems/priorKvKey) and emit only change rows (new / withdrawn / status_change / cod_slip). Applied by default if omitted: "snapshot".
`deltaOnly`	No	Snapshot mode only. When true, suppress unchanged queue rows and emit ONLY new/status-changed rows, synthetic withdrawn rows, and one iso_summary roll-up row per ISO — ideal for a scheduled weekly/daily monitor run that only cares about what changed. When false (default), the full queue is emitted as before, PLUS the same withdrawn/iso_summary rows as free bonus monitoring signal. Applied by default if omitted: false.
`maxResults`	No	Maximum number of queue records to fetch across ALL selected ISOs combined. The cap is applied in ISO order, so a low value truncates the last ISOs: any ISO that is cut short or never reached is marked iso_status=truncated / not_fetched on its iso_summary row and is excluded from withdrawn-project detection for that run. The default is deliberately low (500) so an unconfigured call cannot run away; raise it to about 20000 to pull the whole federation (~18,200 records). Example: 100. Applied by default if omitted: 500.
`priorItems`	No	Delta mode: the prior run's unified queue items (the array of records this actor produced before). The diff is computed purely against these. Ignored in snapshot mode. Applied by default if omitted: [].
`priorKvKey`	No	Delta mode alternative to priorItems: a key in this actor's key-value store holding the prior snapshot. When set, the current snapshot is also SAVED under this key so scheduled runs diff automatically against the previous run.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.2.7Nov 6, 2026

changedInput schema / properties / maxResults / description

Previous value: -"Maximum number of queue records to fetch across ALL selected ISOs combined. The cap is applied in ISO order, so a low value truncates the last ISOs: any ISO that is cut short or never reached is marked iso_status=truncated / not_fetched on its iso_summary row and is excluded from withdrawn-project detection for that run. The default is deliberately low (500) so an unconfigured call cannot run away; raise it to about 20000 to pull the whole federation (~18,200 records). Applied by default if omitted: 500."New value: +"Maximum number of queue records to fetch across ALL selected ISOs combined. The cap is applied in ISO order, so a low value truncates the last ISOs: any ISO that is cut short or never reached is marked iso_status=truncated / not_fetched on its iso_summary row and is excluded from withdrawn-project detection for that run. The default is deliberately low (500) so an unconfigured call cannot run away; raise it to about 20000 to pull the whole federation (~18,200 records). Example: 100. Applied by default if omitted: 500."

First observedv1.0.2Aug 20, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The cost/side-effects block goes well beyond the annotations, disclosing metered billing at $0.008 per result ($8/1,000, down to $2.40/1,000 on paid plans), no charge on failed runs, and that the run is read-only against the government source but still a metered run on the caller's account. It also warns that an unrecognised ISO code now fails the run before billing and that `maxResults` truncation excludes an ISO from withdrawn-project detection.

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?

Purpose and audience come first, then INPUTS, then COST, so it is front-loaded and skimmable. It is on the long side and the INPUTS section duplicates schema text, but no sentence is wholly wasted and the pricing detail is decision-relevant for a metered 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?

With no output schema, the description carries the burden of describing returns and does so, naming monitor fields (is_new_since_last_run, status_changed, previous_status), synthetic withdrawn rows, and per-ISO iso_summary rows including truncated/not_fetched status. For a six-parameter, zero-required tool with an unfamiliar billing model, an agent has everything needed to call it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all six parameters in depth, including enum semantics for `mode` and the ISO-order truncation behavior. The description's INPUTS section mostly restates that, adding only the decision rule of raising `maxResults` versus narrowing `isos`; baseline 3 is appropriate.

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 names a specific verb and resource: normalizing US ISO/RTO generator interconnection queues from seven named ISOs (SPP, MISO, NYISO, CAISO, PJM, ERCOT, ISO-NE) into one schema while tracking new, withdrawn, status-change and COD-slip deltas. That is precise enough to separate it from every sibling, which are all screening/lookup tools for other datasets.

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?

It gives explicit operating instructions: leave `isos` empty for all seven or name one or two to keep a first call small, use `deltaOnly` in snapshot mode for change monitoring rather than re-pulling the full queue, and raise `maxResults` or narrow `isos` when truncation matters. It also points at the free sibling `describe-gov-data-tool` for a verified example input.

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

Deploy Server