osint

Query Power Interconnection Queue (MISO)

query_power_interconnection_queue_v1

Read-onlyIdempotent

Query the MISO generator interconnection queue — the public waiting line of projects that have REQUESTED to connect to the MISO grid (the 15-state Midwest/South footprint).

Returns cited, project-level records: requested megawatts (net summer / net winter), location (state, county, derived county_fips), fuel and technology as MISO reports them, three independent status dimensions (application_status, study_phase, post_gia_status), and queue / withdrawn / in-service dates. Group or filter by state, county_fips, application_status, study_phase, post_gia_status, fuel_type, facility_type, service_type, study_group, study_cycle, or is_hybrid; filter queue_date by the queue_date_from / queue_date_to range. Pass each parameter as a top-level key of params (flat — not nested). Example: {"state": "IN", "fuel_type": "Solar", "application_status": "Active"} for active solar requests in Indiana; {"group_by": ["application_status"]} for requested MW and project counts by status. 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.

This is REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built. NEVER read a requested-MW total as installed or operating capacity — it is additive across distinct projects but is a REQUESTED total only. Filter application_status (Active / Withdrawn / Done) to scope the queue; the full export is withdrawn-dominated. For built/operating capacity use query_power_capacity_v1.

MISO only — never summed, deduped, or compared across ISOs into a national total (each ISO's methodology, inclusion rules, and withdrawal rates differ). For the PJM interconnection queue (the mid-Atlantic RTO incl. Northern Virginia) use query_power_interconnection_queue_pjm_v1 (or query_power_interconnection_queue_pjm_cycle_v1 for PJM's new cluster/cycle process incl. the reopened Cycle 1); for the CAISO (California) queue use query_power_interconnection_queue_caiso_v1; for the NYISO (New York, incl. load interconnection requests) 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; for the SPP (central US) queue use query_power_interconnection_queue_spp_v1 — separate ISO blocks, never combined with this one. MISO reports no data-center / load type, and this tool does not infer one — that interpretation is the analyst's, from cited rows.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A5/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint, destructiveHint, idempotentHint), the description discloses critical behavioral traits: queued MW are REQUESTED not built, the export is withdrawn-dominated, and the tool does not infer data-center/load types. It also details the response structure (citations, source, as_of, source_row) and the need to verify with get_source_evidence_v1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though long, every sentence adds necessary context for a complex data tool. It is front-loaded with the core definition, then covers parameters, examples, caveats, and alternatives in a logical order. No redundant or filler content — each claim is actionable for an agent.

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 tool's complexity (many filter dimensions, caveats about data meaning, cross-ISO pitfalls), the description is remarkably complete. It covers what the tool returns, how to filter/group, what the data does NOT mean, and which sibling tools to use instead. The presence of an output schema is acknowledged and the description still adds value by describing record-level vs aggregate modes.

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?

The input schema is a generic object with 0% coverage, so the description carries the full burden. It lists all filterable fields (state, county_fips, application_status, study_phase, post_gia_status, fuel_type, facility_type, service_type, study_group, study_cycle, is_hybrid), date range parameters, group_by, include_records, and provides a concrete example. This fully compensates for the empty schema.

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 and resource: 'Query the MISO generator interconnection queue — the public waiting line of projects that have REQUESTED to connect to the MISO grid.' It clearly defines the tool's scope (MISO, 15-state footprint) and differentiates it from sibling ISO queue tools by explicitly naming other ISO-specific alternatives.

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?

The description provides explicit when-to-use guidance, including 'For built/operating capacity use query_power_capacity_v1' and 'MISO only — never summed, deduped, or compared across ISOs into a national total.' It also names exact alternative tools for PJM, CAISO, NYISO, ISO-NE, ERCOT, and SPP, giving the agent clear decision rules.

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

All osint tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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

Need Help?