osint

Query Power Prices (ERCOT day-ahead)

query_power_price_ercot_v1

Read-onlyIdempotent

Query verified ERCOT wholesale electricity prices — ERCOT's Day-Ahead Market Settlement Point Prices ($/MWh, EMIL NP4-190-CD), the price cleared the day before each operating day at every ERCOT (Texas) settlement point, served hourly.

Returns cited prices for each (settlement_point, delivery_date, hour_ending): the per-hour price_usd_per_mwh in detail records, plus avg_price_usd_per_mwh, min_price_usd_per_mwh, and max_price_usd_per_mwh over the result scope. Each settlement_point is one of ERCOT's locations — a trading Hub (e.g. HB_NORTH, HB_HOUSTON — the regional benchmark prices), a Load Zone (e.g. LZ_HOUSTON), a Resource Node (one generator's connection point), or a DC-tie — and settlement_point_type carries ERCOT's OWN verbatim classification code (HU/LZ/RN/LZ_DC and finer codes) so an agent can tell a regional benchmark from a single-plant node. Filter or group by settlement_point, settlement_point_type, hour_ending, or delivery_date; filter a date window with delivery_date_from / delivery_date_to, or one day with delivery_date. Pass each parameter as a top-level key of params (flat — not nested). Example: {"settlement_point": "HB_NORTH", "delivery_date": "2026-06-20", "group_by": ["hour_ending"]} for the North hub's 24 hourly day-ahead prices; {"delivery_date": "2026-06-20", "group_by": ["settlement_point_type"]} for the average price by location type. With no date filter the result defaults to the latest delivery day with prices (it does not scan all history); served delivery coverage begins 2014-05-02 from ERCOT's official Data Access Portal archive. Historical settlement-point names remain exactly as published, and names absent from the current pinned type list have a null type rather than being rewritten. Returns JSON with citations and optional row-level records when include_records is true; every value carries source, as_of (the delivery day), and a source_row verifiable with get_source_evidence_v1.

A price is INTENSIVE ($/MWh): it is AVERAGED, min'd, and max'd over a scope — NEVER summed (a "total price" is meaningless, so no sum is offered). An average across more than one settlement point (e.g. a hub and a resource node together) is indicative, not a settlement value — group_by settlement_point for the per-point series, or filter to one point/type. This is the DAY-AHEAD hourly market, NOT real-time / 5-minute prices. ERCOT's day-ahead settlement-point price is a TOTAL only — there is no energy/congestion/loss component split and no loss component, and none is synthesized. ERCOT's own hour-ending label (01:00..24:00) and dst_flag are carried verbatim (a day is 24 hours normally, 25 on the fall-back DST date with 02:00 repeated, 23 on spring-forward). A settlement point is an electrical/aggregate location, not a plant — ERCOT supplies no county or lat/lon, so the only geography anchor is state = TX.

This is a PRICE ($/MWh) — not capacity (MW) or generation (MWh): for installed/operating capacity use query_power_capacity_v1, for electricity generated use query_power_generation_v1. ERCOT only — prices are NEVER blended, averaged, or compared across ISOs (each ISO's market design and redistribution license differ); this tool serves ERCOT's day-ahead settlement-point prices alone.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations (read-only, idempotent), the description discloses default date behavior (latest delivery day if no date), date coverage starting 2014-05-02, historical name handling (null type instead of rewriting), DST hour count (23/24/25), source citation fields, and absence of energy/congestion split. No contradiction 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 long but logically structured: overview, aggregation/units, market scope, and sibling differentiation. Every section conveys necessary nuance (DST, no sum, settlement point types, source citations). It is slightly verbose but earns its length given the domain complexity.

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?

The description is exceptionally complete for an agent to select and invoke the tool: it covers all key parameters, unit semantics, return fields (with citations), default behavior, geographic scope, and appropriate alternatives. The output schema handles the return structure, and the description adds the contextual rules needed for correct use.

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 just a free-form params object, so the description carries full responsibility. It lists specific parameters (settlement_point, delivery_date, hour_ending, delivery_date_from/to, group_by, include_records), provides an example JSON, and explains how to pass them flat. This fully compensates for 0% schema coverage.

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 queries ERCOT day-ahead settlement point prices ($/MWh), specifying the resource (ERCOT wholesale electricity) and the exact market (Day-Ahead Market). It distinguishes from siblings by explicitly contrasting with capacity and generation tools, and by stating this is day-ahead, not real-time.

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 provides explicit when-not-to-use guidance: 'for installed/operating capacity use query_power_capacity_v1, for electricity generated use query_power_generation_v1'. It also warns against cross-ISO comparisons and summing prices, giving clear alternatives and exclusions.

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?