Skip to main content
Glama
malonestar

gov-data-mcp

by malonestar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

interconnection-queue-tracker

Normalize keyless US ISO/RTO generator interconnection queues and track new, withdrawn, status-change, and COD-slip deltas across SPP, MISO, NYISO, CAISO, PJM, ERCOT, and ISO-NE.

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. 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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
isosNoISO/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: [].
modeNosnapshot = 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".
deltaOnlyNoSnapshot 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.
maxResultsNoMaximum 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.
priorItemsNoDelta 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: [].
priorKvKeyNoDelta 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.

  1. First observedv1.0.2

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond annotations with unusual precision: keyless access, live reads from the official source, no writes to external systems, but every call starts a metered Apify run billed $0.008/result (down to $2.40/1,000 on paid plans) and nothing is charged on failure. This directly explains why readOnlyHint is false — state/cost accrues on the caller's account — without contradicting the 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?

Front-loaded with purpose in the first two sentences, then audience, source, and a clearly labeled COST AND SIDE EFFECTS block. The pricing sentence is dense but earns its place for a paid actor; only the store URL and audience line are marginal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers cost model, data source, keylessness, delta categories, and a pointer to a companion tool for example input — enough to call it correctly for a six-parameter, two-mode actor with no output schema. Return-shape detail (beyond named monitor fields) is left implicit, which is the only real gap.

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 each of the six parameters is already fully documented in-schema (including mode, deltaOnly, maxResults truncation semantics). The prose adds the delta-row taxonomy and nothing new about parameter syntax or defaults, so the baseline 3 applies.

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?

States a specific verb and resource: normalizes US ISO/RTO interconnection queues for seven named ISOs into one schema and tracks new/withdrawn/status-change/COD-slip deltas. Names the exact sources (SPP, MISO, NYISO, CAISO, PJM, ERCOT, ISO-NE) and the audience, so it is unmistakable against the gov-data siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the snapshot vs delta intent indirectly ('track new, withdrawn, status-change and COD-slip deltas') and points to describe-gov-data-tool for a verified example input. It does not explicitly say when to change maxResults or when deltaOnly is preferred over mode=delta, but the context for a monitoring workflow is clear.

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

Deploy Server

Other Tools