# build.exascale/osint (remote · api.exascale.build)

Source-cited US machine-economy data: power, AI infra, chips, robot trade + adoption, satellites.

- Trust score: 67/100 (medium)
- Change this week: +10
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `api.exascale.build`: 67/100 (this document), [markdown](https://verifymcp.io/servers/build-exascale-osint/api.md), [page](https://verifymcp.io/servers/build-exascale-osint/api)

## Channel facts

- Endpoint: `https://api.exascale.build/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.1.6`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 74/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 57/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 20552 tokens (~331/item across 62 items; 62 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 71/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http build-exascale-osint https://api.exascale.build/mcp
```

### Codex

```toml
[mcp_servers.build-exascale-osint]
url = "https://api.exascale.build/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "build-exascale-osint": {
      "type": "remote",
      "url": "https://api.exascale.build/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add build-exascale-osint --url https://api.exascale.build/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  build-exascale-osint:
    url: "https://api.exascale.build/mcp"
```

### Other

```json
{
  "mcpServers": {
    "build-exascale-osint": {
      "type": "http",
      "url": "https://api.exascale.build/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-02 (score 67, +2)

- [functional] Schema quality: good → excellent
- [functional] New tool “query_power_renewable_output_hourly_v1”
- [functional] New tool “query_power_capacity_contribution_ercot_v1”
- [functional] New tool “describe_power_renewable_output_hourly_v1”
- [functional] New tool “describe_power_capacity_contribution_ercot_v1”

### 2026-08-01 (score 65, −1)

- [security] Tool “query_power_price_ercot_v1” rewrote its description, which is the text the model reads
- [functional] Schema quality: excellent → good

### 2026-07-31 (score 66, +6)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 60, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 59, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-28 (score 58, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 57, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 57)

First indexed and scored.

## MCP tools (62)

### `list_capabilities_v1` (~67 tokens)

List Capabilities

List available exascale.build data capabilities for agent discovery before querying. Also call this BEFORE stating that a capability is not available — client tool lists are cached and this surface grows; anything listed here is reachable via query_capability_v1 even if your tool list predates it.

### `get_source_evidence_v1` (~122 tokens)

Get Source Evidence

Fetch and hash-verify the raw source row behind a returned citation.

Pass a citation object inside `params`. Two ready-to-pass shapes come straight from
the query tools: each aggregate row's `citations[ref].verify` object, or a detail
record's `citation` (from include_records). Either proves the number with no
re-query. The tool verifies the raw workbook SHA-256 before returning source-header
row values. Use this when an agent must prove an answer from the underlying source row.

Input parameters:

- `params`

### `describe_capability_v1` (~156 tokens)

Describe Capability

Describe any served capability by name — the generic twin of the named describe tools.

Pass `capability` as either a capability id from list_capabilities_v1 (e.g. "power.capacity")
or a query primitive name (e.g. "query_power_capacity_v1"). Returns the same schema payload
as the named describe tool: valid filters, groupings, metrics, detail fields, and citation
fields. Use the generic pair (this + query_capability_v1) when list_capabilities_v1 names a
capability that has no named tool in your client's tool list — clients cache tool lists, and
capabilities shipped after that cache are still fully reachable here.

Input parameters:

- `capability` (string, required)

### `query_capability_v1` (~177 tokens)

Query Capability

Query any served capability by name — the generic twin of the named query tools, reaching every capability including ones newer than your client's cached tool list.

Pass `capability` as either a capability id from list_capabilities_v1 (e.g. "power.price_ercot")
or a query primitive name (e.g. "query_power_price_ercot_v1"), and `params` as the same flat
JSON object the named query tool accepts — call describe_capability_v1 first for valid filters,
e.g. {"capability": "power.capacity", "params": {"state": "TX", "group_by": ["energy_source_code"]}}.
Returns the identical cited envelope as the named tool: same rows, same citations, same as_of.

Input parameters:

- `capability` (string, required)
- `params`

### `describe_power_capacity_v1` (~30 tokens)

Describe Power Capacity

Describe valid filters, groupings, metrics, detail fields, and citation fields for power.capacity.

### `query_power_capacity_v1` (~277 tokens)

Query Power Capacity

Query verified U.S. generator-level operating, planned, retired, or canceled power capacity from EIA-860M.

Use this for capacity questions by state/jurisdiction, county FIPS,
source-reported balancing authority code, fuel, prime mover, technology,
lifecycle, or year. Pass filters inside the `params` object. The
operating/planned/retired/canceled selector is `lifecycle` (e.g.
\`lifecycle: "operating"`, the default) — there is no `status` or `status_group`
parameter. Returns JSON aggregates with
citations and optional generator-level records when `include_records` is true.
Does not determine electricity supplied, generation MWh, real-time dispatch,
capacity factor, battery storage throughput/duration, demand/load, prices,
data-center load, or transmission deliverability. For capacity REQUESTED in an ISO
interconnection queue (projects pending interconnection, not yet built), use the relevant ISO's
queue tool: query_power_interconnection_queue_v1 (MISO), query_power_interconnection_queue_pjm_v1
(PJM — or query_power_interconnection_queue_pjm_cycle_v1 for PJM's cluster/cycle grid), or
query_power_interconnection_queue_caiso_v1 (CAISO).

Input parameters:

- `params`

### `describe_power_generation_v1` (~33 tokens)

Describe Power Generation

Describe valid filters, groupings, atoms, metrics, detail fields, and citation fields for power.generation.

### `query_power_generation_v1` (~390 tokens)

Query Power Generation

Query verified U.S. monthly net electricity generation (MWh) from EIA-923.

Use this for "how much was generated" questions by state, source-reported balancing
authority code, fuel, prime mover, sector, plant, or generator, for a given month.
For a fuel total or a fuel mix (e.g. "coal generation", "top fuels"), filter or group
by `fuel_group` — it sums the several energy_source_code values a fuel spans (coal
alone is 6 codes), so a total is correct-by-construction; use the raw `energy_source_code`
only when you want one exact as-reported code, since it splits coal/biomass across
sub-codes. Select one `atom`: `by_fuel` (default — the complete plant total) or
\`by_generator` (generator-level, joinable to EIA-860M); never sum across atoms. History
runs monthly from 2014-01 onward and is served by default: a bare `data_month` anywhere
in that window answers from the newest promoted vintage covering it, and the response
\`as_of` is that knowledge cut (pin `as_of` to any date to reproduce what was served
then — it resolves to the newest vintage at or before it; an empty result names the
served window in an `empty_scope` note).
\`balancing_authority_code` is reported by EIA only from 2018 onward — a BA-filtered
query cannot see earlier months. Pass
filters inside the `params` object. Returns JSON aggregates with citations down to the
exact source month-cell. Does not determine installed capacity (MW — use power.capacity),
demand/load, wholesale prices, fuel cost, heat rate, capacity factor, or
real-time/hourly dispatch.

Input parameters:

- `params`

### `describe_power_asset_ownership_v1` (~31 tokens)

Describe Power Asset Ownership

Describe annual EIA-860 ownership filters, convention, metrics, and exact-cell citations.

### `query_power_asset_ownership_v1` (~267 tokens)

Query Power Asset Ownership

Query verified annual EIA-860 generator ownership.

Returns the Owner schedule's raw owner names and ownership shares for each
\`eia_plant_id` + `generator_id`. `percent_owned` is the workbook's raw fraction of
one (0.6 = 60%), not a whole-number percent. Filter by plant, generator, exact raw
owner name, state, owner state, annual vintage, or source-reported balancing
authority code; `{"state":"TX","balancing_authority_code":"ERCO"}` returns an ERCOT
slice in one call. Owner-name matching is exact and intentionally performs no
normalization or entity resolution.

Critical EIA convention: the Owner schedule contains only jointly owned generators
and generators wholly owned by an entity other than the operator. A generator absent
from it is wholly owned by the operator in that same annual EIA-860 Generator
schedule. An exact plant+generator query exposes this as `ownership_resolution`;
it does not fabricate an Owner row or a 1.0 source share. Annual vintages remain
independently queryable. Every returned share cites its exact ZIP member, sheet, row,
and `Percent Owned` cell for SHA-256 verification.

Input parameters:

- `params`

### `describe_power_fuel_cost_v1` (~34 tokens)

Describe Power Fuel Receipts and Costs

Describe EIA-923 receipt/cost filters, raw units, missing semantics, and exact-cell citations.

### `query_power_fuel_cost_v1` (~252 tokens)

Query Power Fuel Receipts and Costs

Query verified raw EIA-923 fuel receipts and delivered fuel costs.

Returns one Page 5 Fuel Receipts and Costs row per published receipt: plant/month,
fuel, supplier, purchase type, source physical quantity, and delivered cost in
EIA's stated cents/MMBtu. Filter by plant, month/range, exact source strings, state,
fuel, cost status, or source-reported balancing authority code;
\`{"state":"TX","balancing_authority_code":"ERCO"}` returns an ERCOT slice in one
call. Quantity units remain fuel-specific (short tons, barrels, or Mcf).

EIA withholds costs for some plants. The raw `.` marker is preserved in
\`fuel_cost_raw`, the numeric cost is null, and `fuel_cost_status` explicitly reports
\`withheld` for unregulated receipts. Missing is never zero or imputed. This tool
does not derive heat rates, efficiency, marginal cost, generation cost, or $/MWh;
combine the cited raw atoms outside exascale.build if analysis requires those
judgments. Every quantity or cost can be verified against its exact workbook cell.

Input parameters:

- `params`

### `describe_power_plant_costs_v1` (~36 tokens)

Describe FERC Form 1 Plant Costs

Describe native-XBRL Form 1 plant-cost facts, units, coverage, and exact-fact citations.

### `query_power_plant_costs_v1` (~276 tokens)

Query FERC Form 1 Plant Costs

Query accepted native-XBRL FERC Form 1 large-steam plant facts.

Returns one separately cited XBRL fact per respondent, report year, raw plant name,
and source concept: installed capacity, net generation, plant-cost balance items,
fuel expense, and individual operation and maintenance lines. Values and units are
as filed; nominal dollars are not adjusted, allocated, divided by generation, or
combined into a derived O&M total. Plant names remain raw strings with no EIA ID
matching. Every value verifies against its exact archive member, XBRL fact ID,
context, concept, and SHA-256.

Coverage is the Form 1 filing population, not the full fleet. ERCOT-only merchant
entities largely do not file, so ERCOT coverage is partial and plant absence means
not present in served filings—not zero. `ercot_relevance=true` is a one-call filter
based only on the respondent's raw states-served disclosure mentioning Texas; it is
not a plant-location claim. v0 covers accepted native XBRL (report year 2021 onward)
and the large-steam schedule including nuclear; hydro, pumped storage, migrated
historical XBRL, and Visual FoxPro-era filings are explicitly outside v0.

Input parameters:

- `params`

### `describe_natural_gas_prices_v1` (~42 tokens)

Describe Natural Gas Prices

Describe the EIA Henry Hub and state electric-power gas-price atoms, units, aggregate grain, missingness, vintages, and citations.

### `query_natural_gas_prices_v1` (~291 tokens)

Query Natural Gas Prices

Query verified EIA natural-gas price records from two public series.

\`atom="henry_hub_daily_spot"` returns one trading-day Henry Hub spot price in
EIA's published $/MMBtu unit (series RNGWHHD). `atom="state_electric_power_monthly"`
returns one state-month average price paid by electric-power consumers in EIA's
published $/Mcf unit; `{"atom":"state_electric_power_monthly","state":"TX"}` is
the Texas power-sector proxy slice in one call. Filter either atom by `date`,
\`date_from`/`date_to`, series, state, or price status.

The state series is an aggregate of what the state's power sector paid that month,
not a plant-level fact. EIA null values remain explicit `price=null` records with
\`price_status="source_missing"`—never zero or imputed. The two source units are
never converted or blended; mixed-unit avg/min/max are null. This tool does not
assign proxies to plants or derive heat rates, $/MWh, spark spreads, or any ratio.
API revisions are preserved as immutable capture vintages selected by `as_of`.
Every price cites its exact archived response record, series id, period, value cell,
and SHA-256 for source-evidence verification.

Input parameters:

- `params`

### `describe_power_capacity_contribution_ercot_v1` (~40 tokens)

Describe ERCOT Capacity Contribution Assumptions

Describe ERCOT planning capacity-contribution classes, seasons, peak definitions, methodologies, vintages, and exact-cell citations.

### `query_power_capacity_contribution_ercot_v1` (~63 tokens)

Query ERCOT Capacity Contribution Assumptions

Query ERCOT's as-published planning capacity-contribution assumptions. These are planning assumptions, not realized performance or plant firm MW; classes, seasons, peak definitions, methodologies, and vintages are never blended.

Input parameters:

- `params`

### `describe_power_renewable_output_hourly_v1` (~39 tokens)

Describe ERCOT Hourly Renewable Output

Describe ERCOT hourly actual wind/solar output, published regions, coverage, DST identity, and exact-cell citations.

### `query_power_renewable_output_hourly_v1` (~62 tokens)

Query ERCOT Hourly Renewable Output

Query ERCOT's actual hourly wind and solar output in MW, system-wide and by published region. Actual is never substituted with forecast/capability and is not accreditation, firm MW, or capacity factor.

Input parameters:

- `params`

### `describe_power_demand_v1` (~32 tokens)

Describe Power Demand

Describe valid filters, groupings, metrics, detail fields, and citation fields for power.demand.

### `query_power_demand_v1` (~572 tokens)

Query Power Demand

Query verified U.S. hourly electricity demand (MW) by balancing authority from EIA-930.

Use this for "how much load" questions at the hourly balancing-authority grain:
filter or group by `balancing_authority_code`, `region`, `data_date` (or the
\`data_date_from`/`data_date_to` range), `hour_number`, `datetime_utc`, or
\`is_imputed`. Pass filters inside the `params` object. Returns JSON aggregates
with citations and optional row-level records when `include_records` is true.
\`demand_mw` is EIA's own cleaned (Adjusted) series, with receipts: the
as-reported `demand_mw_raw` and the `is_imputed` flag ride every detail record.
\`demand_forecast_mw` is the same row's day-ahead forecast, so
forecast-vs-actual misses need no second query. History runs hourly from
2015-07-01 onward and is served by default: a bare `data_date` anywhere in
that window answers from the newest promoted vintage covering it, and the
response `as_of` is that knowledge cut. A query with NO calendar window (no
\`data_date`, `data_date_from`, or `data_date_to`) and no calendar-axis
\`group_by` defaults to the latest day that has reported demand — not the full
history — and says so in a `default_latest_day` note; group by `data_date` or
\`datetime_utc`, or pass a date range, to read a series over time. Pin `as_of`
to an earlier vintage to
reproduce exactly what was served then; one response may cite several source
files, and every citation carries its own file and vintage. An empty result
names the served coverage window in an `empty_scope` note. Demand is NOT additive across
balancing authorities: a result summing more than one BA carries a
\`ba_aggregation` scope note and ranking remainders omit the demand metrics —
group by `balancing_authority_code` for the source-grain series. Does not
determine plant, generator, county, or state attribution (EIA-930 carries no
such IDs, and BA footprints do not follow state lines), US48 or regional
totals (computed rollups are refused; EIA's own published series is the…

Input parameters:

- `params`

### `describe_power_demand_rollup_v1` (~36 tokens)

Describe Power Demand (national / region rollup)

Describe valid filters, groupings, metrics, detail fields, and citation fields for power.demand_rollup.

### `query_power_demand_rollup_v1` (~820 tokens)

Query Power Demand (national / region rollup)

Query verified U.S. hourly electricity demand (MW) as EIA's own published national and regional totals from the EIA Grid Monitor (region-data).

Use this for "how much load for the whole country, or a region" questions. Filter by
\`respondent` (US48 = the Lower-48 national total, or one of the 13 EIA regions — CAL, CAR,
CENT, FLA, MIDA, MIDW, NE, NW, NY, SE, SW, TEN, TEX), `data_date` (one day) or the
\`data_date_from`/`data_date_to` range, and `hour_number`. To pin one specific UTC hour,
combine `data_date` + `hour_number`. Group by any of `respondent`, `respondent_level`
(national vs region), `data_date`, `hour_number`, or `datetime_utc`. `datetime_utc` and
\`respondent_level` are grouping/output axes only — not filters. Pass each parameter as a
top-level key of `params` (flat — not nested under a `filter`, `filters`, or `where` key).
Example: `{"respondent": "US48", "data_date": "2026-06-10", "hour_number": 14}` for the
US48 total at one hour; add `"group_by": ["datetime_utc"]` over a
\`data_date_from`/`data_date_to` range for a series. Returns JSON aggregates with citations
and optional row-level records when `include_records` is true.

\`demand_mw` is EIA's OWN published demand total, served verbatim — the Adjusted series (the
same canonical definition as power.demand's `demand_mw`), NOT a sum exascale computed. This
closes power.demand's refusal of national/region totals (BA demand is non-additive across
balancing authorities). `demand_forecast_mw` is the same respondent-hour's day-ahead forecast,
so forecast-vs-actual misses need no second query.

History runs hourly from 2019-01-01 onward — this published series begins about 3.5 years later
than power.demand's balancing-authority history — and is served by default; the response
\`as_of` is the knowledge cut. A query with NO calendar window and no calendar-axis `group_by`
defaults to the latest day with reported demand and says so in a `default_latest_day` note —
group by `data_date` or `datetime_utc`, or pass a d…

Input parameters:

- `params`

### `describe_power_retail_sales_v1` (~34 tokens)

Describe Power Retail Sales

Describe valid filters, groupings, metrics, detail fields, and citation fields for power.retail_sales.

### `query_power_retail_sales_v1` (~559 tokens)

Query Power Retail Sales

Query verified U.S. annual retail electricity sales — billed MWh, revenue, and customer counts — by utility, state, and customer sector from EIA-861.

Use this for "who sold how much power to whom" questions at the annual
utility×state×sector grain: filter or group by `data_year`, `state`, `sector`
(residential / commercial / industrial / transportation), `part`,
\`service_type`, `ownership`, `ba_code`, `data_type`, `eia_utility_id`, or
\`utility_name`. Pass filters inside the `params` object. Returns JSON
aggregates with citations down to the exact stacked sector/measure cell, and
optional row-level records when `include_records` is true. Defaults keep
totals faithful: the in-row `total` sector block is excluded unless named
explicitly (it duplicates the four sectors); EIA's state-level Adjustment
(99999) and Withheld (88888) sentinel rows stay in state totals but are
auto-excluded from any utility-keyed query; territories are excluded unless
\`included_in_default_us_metrics` is false. A result mixing service types
carries a `service_type_mix` note quoting the file's own law — revenue sums
Parts A,B,C,D but sales/customers sum A,B,D only (Part C delivery re-counts
Part B energy). History spans data years 2016–2024, one annual census per
year, each its own vintage. Reach an earlier year through `as_of`, not
\`data_year`: `as_of` resolves to the newest census at or before it (so `as_of`
2018-06-01 — or just 2018 — returns the 2018 census) and the response echoes
that resolved `as_of`. `data_year` only filters within the resolved vintage, so
\`data_year` 2018 under the default `as_of` (latest = 2024) returns an empty
scope, not 2018; the default serves 2024, a multi-year trend is one query per
year, and an `as_of` before 2016 is refused, naming the floor. Does not
determine hourly or peak load (sales are billed MWh over a year — use
power.demand), facility-level or data-center-specific load, county-level
detail, average retail price (cents/kWh — deferred), the ~1,700 smal…

Input parameters:

- `params`

### `describe_power_interconnection_queue_v1` (~34 tokens)

Describe Power Interconnection Queue (MISO)

Describe valid filters, groupings, metrics, detail fields, and citation fields for power.interconnection_queue.

### `query_power_interconnection_queue_v1` (~655 tokens)

Query Power Interconnection Queue (MISO)

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 fo…

Input parameters:

- `params`

### `describe_power_interconnection_queue_pjm_v1` (~38 tokens)

Describe Power Interconnection Queue (PJM)

Describe valid filters, groupings, metrics, detail fields, and citation fields for power.interconnection_queue_pjm.

### `query_power_interconnection_queue_pjm_v1` (~758 tokens)

Query Power Interconnection Queue (PJM)

Query the PJM New Services (interconnection) queue — the public waiting line of projects that have REQUESTED to connect to the PJM grid (the mid-Atlantic RTO incl. Northern Virginia, PA, NJ, MD, OH, VA, WV and more).

Returns cited, project-level records with PJM's full published structure: requested megawatts
(`requested_max_output_mw` = MFO, `requested_summer_mw` = MW Capacity / summer net,
\`requested_winter_mw` = MW Energy / winter net), the realized built `in_service_mw` for completed
projects, location (`state`, `county`, derived `county_fips`), `fuel` and `project_type` as PJM
reports them, the single as-reported `status`, the study-document URLs and per-stage statuses, and
lifecycle dates. Group or filter by `state`, `county_fips`, `status`, `project_type`,
\`capacity_or_energy`, `fuel`, `project_ac_dc`, `transmission_owner`, the study statuses, or (group
only) `is_hybrid`; filter `submitted_date` by the `submitted_date_from` / `submitted_date_to`
range. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"state":
"VA", "project_type": "Generation Interconnection", "status": "Active"}` for active generation
requests in Virginia; `{"group_by": ["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.

The `requested_*` figures are 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
\`status` (Active / Withdrawn / In Service / Under Construction / …) to scope the queue; the full
export is withdrawn-dominated. PJM also reports `in_service_mw` — the realized BUILT MW for
in-service projects (a separate, built figure). For built/o…

Input parameters:

- `params`

### `describe_power_interconnection_queue_pjm_cycle_v1` (~40 tokens)

Describe Power Interconnection Queue (PJM cluster/cycle)

Describe valid filters, groupings, metrics, detail fields, and citation fields for power.interconnection_queue_pjm_cycle.

### `query_power_interconnection_queue_pjm_cycle_v1` (~665 tokens)

Query Power Interconnection Queue (PJM cluster/cycle)

Query PJM's cluster/cycle service-request grid — the cluster view of PJM's interconnection process: the TC1/TC2 transition cycles (re-processing the pre-Order-2023 serial backlog) and the reopened steady-state cycles (C01+, the new intake). A SEPARATE PJM publication from the full New Services queue (query_power_interconnection_queue_pjm_v1) — richer per-project cluster detail; the two share rows and are never combined.

Returns cited, project-level records with PJM's full cluster schema: the cluster `cycle` (TC1 / TC2 /
C01 …) and `stage` (phase / decision point), the `developer`, requested megawatts
(`requested_max_output_mw` = MFO, `requested_summer_mw`, `requested_winter_mw`), the realized built
\`in_service_mw`, long-term-firm transmission `ltf_mw`, location (`state`, `county`, derived
\`county_fips`), `fuel` and `project_type` as PJM reports them, the single `status`, and the phased
System-Impact-Study report URLs + statuses. Group or filter by `cycle`, `stage`, `status`, `state`,
\`county_fips`, `project_type`, `capacity_or_energy`, `fuel`, `developer`, `transmission_owner`, or
(group only) `is_hybrid`; filter `submitted_date` by range. Pass each parameter as a top-level key of
\`params` (flat). Example: `{"cycle": "C01", "status": "Active"}` for the live reopened-cycle pipeline;
\`{"group_by": ["cycle"]}` for counts by cluster cycle. 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.

The `requested_*` figures are REQUESTED capacity, not built: historically the large majority of queued
megawatts withdraw before they are built. NEVER read a requested-MW total as installed/operating
capacity — additive across distinct projects but a REQUESTED total only. PJM also reports
\`in_service_mw` (the realized built MW). For built/operating capacity use query_power_capacity_v1.

PJM cluster grid only. This and PJM's New Service…

Input parameters:

- `params`

### `describe_power_interconnection_queue_caiso_v1` (~38 tokens)

Describe Power Interconnection Queue (CAISO)

Describe valid filters, groupings, metrics, detail fields, and citation fields for power.interconnection_queue_caiso.

### `query_power_interconnection_queue_caiso_v1` (~897 tokens)

Query Power Interconnection Queue (CAISO)

Query the CAISO generator interconnection queue — California ISO's public Public Queue Report, the waiting line of projects that have REQUESTED to connect to the CAISO grid (California, plus the out-of-state edges it studies: NV, AZ).

Returns cited, project-level records with CAISO's full published structure: the net megawatts to grid (`net_mw_to_grid`, CAISO's own headline figure) and the per-component Type/Fuel/MW triplets for hybrids (`type_1..3`, `fuel_1..3`, `mw_1..3`, plus an `is_hybrid` flag), the as-reported `application_status`, the cluster `study_process` (C01..C14, plus serial/legacy tracks), the three-valued deliverability status (`deliverability_status` = Full Capacity / Partial Capacity / Energy Only) with `tpd_allocation_percentage` / `tpd_allocation_group` / `offpeak_deliverability`, location (`state`, `county`, derived `county_fips`, `utility`, `pto_study_region`), the per-phase study statuses, and lifecycle dates (`ir_receive_date`, `queue_date`, `proposed_online_date`, `current_online_date`, and — for completed projects — `actual_online_date`). Group or filter by `application_status`, `state`, `county_fips`, `deliverability_status`, `study_process`, `fuel_1`, `type_1`, `utility`, `pto_study_region`, `offpeak_deliverability`, `tpd_allocation_group`, `suspension_status`, `ia_status`, or (group only) `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: `{"application_status": "ACTIVE", "fuel_1": "Battery", "state": "CA"}` for active battery requests in California; `{"group_by": ["application_status"]}` for net MW and project counts by status; `{"application_status": "ACTIVE", "group_by": ["deliverability_status"]}` for the active pipeline split by deliverability. 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…

Input parameters:

- `params`

### `describe_power_interconnection_queue_nyiso_v1` (~38 tokens)

Describe Power Interconnection Queue (NYISO)

Describe valid filters, groupings, metrics, detail fields, and citation fields for power.interconnection_queue_nyiso.

### `query_power_interconnection_queue_nyiso_v1` (~1042 tokens)

Query Power Interconnection Queue (NYISO)

Query the NYISO generator + load interconnection queue — New York ISO's public waiting line of projects that have REQUESTED to connect to the New York grid. Uniquely among ISOs, NYISO publishes a Load Projects tab — load interconnection requests (large-load demand), served as-reported — and since its 2026-07 edition tags each load request with its own `End-Use` class (`end_use`, e.g. DAT / DAT-AI / DAT-CM, served verbatim).

Returns cited, project-level records with NYISO's full published structure across every lifecycle tab (nine tabs through 2026-06; seven since NYISO's 2026-07 restructure): summer and winter peak megawatts kept SEPARATE (`sp_mw` = SP, the max summer output; `wp_mw` = WP, the max winter output), the Load Projects tab's `peak_mw_load` with NYISO's own `end_use` class and `sis_bundle` study-batch code (both 2026-07 onward, null before), the as-reported study-phase code (`study_status_code` — NYISO's numeric key, labeled `S` through 2026-06 and `Project Status #` / `NYISO Status` since), the request `record_type` and `project_type`, the `type_fuel` codebook, the energy-storage capability, the NYISO load `zone` (A–K), location (`state`, `county`, derived `county_fips`, `point_of_interconnection`, `utility`), and lifecycle dates (`ir_date`, `last_update`, the milestone dates, and the Year/Qualifier `proposed_cod` kept verbatim). Group or filter by `application_status`, `sheet_name`, `state`, `county_fips`, `study_status_code`, `record_type`, `type_fuel`, `zone`, `utility`, `studies_available`, or `end_use`; filter `ir_date` by the `ir_date_from` / `ir_date_to` range. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"application_status": "ACTIVE", "type_fuel": "S"}` for active solar requests; `{"sheet_name": "Load Projects"}` for the load interconnection requests; `{"end_use": "DAT-AI", "application_status": "ACTIVE"}` for the load requests NYISO itself codes DAT-AI; `{"group_by": ["application_status"]}` for requested…

Input parameters:

- `params`

### `describe_power_interconnection_queue_isone_v1` (~38 tokens)

Describe Power Interconnection Queue (ISO-NE)

Describe valid filters, groupings, metrics, detail fields, and citation fields for power.interconnection_queue_isone.

### `query_power_interconnection_queue_isone_v1` (~860 tokens)

Query Power Interconnection Queue (ISO-NE)

Query the ISO-NE generator interconnection queue — ISO New England's public IRTT "public queue" report, the waiting line of projects that have REQUESTED to connect to the New England grid (CT, MA, ME, NH, RI, VT).

Returns cited, project-level records with ISO-NE's full published structure (all 31 columns of the rendered report): the three megawatt readings kept SEPARATE (`net_mw`, `summer_mw` = max summer output, `winter_mw` = max winter output — `net_mw` is 0 for the many Capacity-Network-Resource-only requests, a real value, not missing), the request `request_type` (G = Generation / ETU = Elective Transmission Upgrade / TS = Transmission Service), the space-delimited multi-value `fuel_type` (EIA energy-source codes, e.g. "SUN BAT"), the `unit_type` and service code `serv` (CNR = Capacity Network Resource / NR = Network Resource), the `jurisdiction` (F = FERC / N = Non-FERC), the ISO-NE load `zone`, the per-stage study statuses (`fs_status` … `ia_status`) with their study-document links, location (`state`, `county`, derived `county_fips`, `poi`), and lifecycle dates. Group or filter by `application_status`, `project_status`, `request_type`, `unit_type`, `fuel_type`, `serv`, `jurisdiction`, `zone`, `state`, `county_fips`, or `cluster`; filter `requested_date` by the `requested_date_from` / `requested_date_to` range. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"application_status": "A", "request_type": "G", "state": "MA"}` for active generation requests in Massachusetts; `{"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.

\`net_mw` / `summer_mw` / `winter_mw` are REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built, so the queue is withd…

Input parameters:

- `params`

### `describe_power_interconnection_queue_ercot_v1` (~40 tokens)

Describe Power Interconnection Queue (ERCOT)

Describe valid filters, groupings, metrics, detail fields, and citation fields for power.interconnection_queue_ercot.

### `query_power_interconnection_queue_ercot_v1` (~1056 tokens)

Query Power Interconnection Queue (ERCOT)

Query the ERCOT generator interconnection queue — ERCOT's public GIS Report (EMIL PG7-200-ER), the waiting line of generation projects that have REQUESTED to connect to the ERCOT (Texas) grid.

Returns cited, project-level records with ERCOT's full published structure across four lifecycle sheets (Large Gen + Small Gen = active; Inactive Projects; Cancellation Update): the requested `capacity_mw` (ERCOT publishes ONE capacity figure — no summer/winter split), the ERCOT `fuel` and `technology` codes (e.g. SOL/PV solar, OTH/BA battery, GAS/CC combined-cycle, WIN/WT wind — HYD is HYDROGEN, hydro is WAT), the `cdr_reporting_zone` (NORTH/SOUTH/WEST/COASTAL/HOUSTON/PANHANDLE), the `interconnecting_entity`, the `poi_location`, the composite `gim_study_phase` token string, and the milestone dates (`screening_study_started`, `fis_approved`, `ia_signed`, `construction_start`/`construction_end`, `approved_for_energization`/`approved_for_synchronization`, `projected_cod`). Group or filter by `application_status`, `size_category`, `fuel`, `technology`, `cdr_reporting_zone`, `county_fips`, `state`, `gim_study_phase`, or `interconnecting_entity`; filter `projected_cod` by the `projected_cod_from` / `projected_cod_to` range. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"application_status": "ACTIVE", "fuel": "SOL"}` for active solar requests; `{"application_status": "ACTIVE", "group_by": ["fuel"], "order_by": "capacity_mw", "top_n": 5}` for the active pipeline's biggest fuels by requested MW. The GIS Report is published MONTHLY and its full history is queryable — this is NOT a single point-in-time snapshot. Omit `as_of` for the latest month, or pass `as_of` (a date) to get the queue as it stood at a past month: `as_of` resolves to the newest monthly snapshot at or before it, with vintages back to 2018-12 (the floor; an earlier `as_of` is refused, naming the floor). Example: `{"application_status": "ACTIVE", "as_of": "2019-06-30"}` returns the…

Input parameters:

- `params`

### `describe_power_interconnection_queue_spp_v1` (~38 tokens)

Describe Power Interconnection Queue (SPP)

Describe valid filters, groupings, metrics, detail fields, and citation fields for power.interconnection_queue_spp.

### `query_power_interconnection_queue_spp_v1` (~1003 tokens)

Query Power Interconnection Queue (SPP)

Query the SPP generator interconnection queue — Southwest Power Pool's public GI Summary report, the waiting line of generation projects that have REQUESTED to connect to the SPP grid (the ~14-state central-US RTO: OK, KS, TX panhandle, NE, NM, MO, CO, ND, SD, AR, LA and more).

Returns cited, project-level records with SPP's full published structure: the requested `capacity_mw` (SPP's headline `Capacity` figure) PLUS five other labeled MW columns SPP publishes — `max_summer_mw`, `max_winter_mw`, `requested_max_injection_mw`, `requested_nrd_mw`, `nameplate_capacity_mw` — served separately and NEVER blended; the `generation_type` (Wind / Solar / Battery/Storage / Thermal / Hybrid / Hydro — SPP encodes hybrids natively as `Hybrid`, so no is-hybrid is invented) and free-text `fuel_type` (slash-delimited combos like `Solar/Storage` kept whole); the study `current_cluster` (e.g. `DISIS-2024-001`, `Surplus`, `RTOE Transitional Cluster`) and regional `cluster_group` (`01 NORTH` … `05 SOUTHWEST`); the transmission owner `to_at_poi`; the `service_type` (`ER/NR`, `ER`, `NR`); the `substation_or_line`; and the lifecycle dates (`request_received`, `in_service_date`, `commercial_operation_date`, `date_withdrawn`). Group or filter by `native_status`, `generation_type`, `fuel_type`, `service_type`, `current_cluster`, `cluster_group`, `to_at_poi`, `county_fips`, or `state`; filter `request_received` / `commercial_operation_date` by their `_from` / `_to` ranges. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"native_status": "DISIS STAGE", "generation_type": "Solar"}` for solar in the DISIS study stage; `{"native_status": "DISIS STAGE", "group_by": ["state"], "order_by": "capacity_mw", "top_n": 5}` for the active study pipeline's biggest states by requested MW. 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_e…

Input parameters:

- `params`

### `describe_power_price_ercot_v1` (~36 tokens)

Describe Power Prices (ERCOT day-ahead)

Describe valid filters, groupings, metrics, detail fields, and citation fields for power.price_ercot.

### `query_power_price_ercot_v1` (~851 tokens)

Query Power Prices (ERCOT day-ahead)

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_eviden…

Input parameters:

- `params`

### `describe_ai_infrastructure_construction_v1` (~36 tokens)

Describe AI Infrastructure Construction (data centers + fabs)

Describe valid filters, groupings, metrics, detail fields, and citation fields for ai_infrastructure.construction.

### `query_ai_infrastructure_construction_v1` (~758 tokens)

Query AI Infrastructure Construction (data centers + fabs)

Query verified U.S. private construction spending ($ millions) for data centers and semiconductor/computer-electronics manufacturing plants, from the U.S. Census Bureau's Value of Construction Put in Place (C30).

Use this for "how much is being spent BUILDING data centers (or chip fabs) in the US" questions —
the construction buildout in dollars, not capacity or investment. Filter by `category`
("data_center" — Census's named subcategory under Office; or "computer_electronic_electrical" — the
semiconductor/computer-electronics manufacturing line under Manufacturing), `basis`
("seasonally_adjusted" = a seasonally-adjusted ANNUAL RATE, or "not_seasonally_adjusted" = the
NOT-adjusted MONTHLY LEVEL), `data_month` (one month, ISO first-of-month e.g. "2026-04-01") or the
\`data_month_from`/`data_month_to` range, `year`, and `revision_status` ("preliminary", "revised", or
"final"). Group by any of `category`, `basis`, `data_month`, `year`, or `revision_status`. Pass each
parameter as a top-level key of `params` (flat — not nested under a `filter`, `filters`, or `where`
key). Example: `{"category": "data_center", "basis": "seasonally_adjusted", "data_month":
"2026-04-01"}` for one month; add `"group_by": ["data_month"]` over a `data_month_from`/`data_month_to`
range for a series. Returns JSON aggregates with citations and optional row-level records when
\`include_records` is true — every value cites the exact Census workbook, sheet, row, and column.

The two categories are DISTINCT series and are never conflated: `data_center` is data-center
buildings; `computer_electronic_electrical` is the chip/electronics-manufacturing (fab) line — the
CHIPS-Act build-out. `basis` is the other fork: the seasonally-adjusted series is an ANNUAL RATE
(what the current monthly pace annualizes to), while the not-seasonally-adjusted series is the actual
MONTHLY LEVEL. `revision_status` carries Census's own preliminary/revised/final marking verbatim.

Data is monthly; the data-center series beg…

Input parameters:

- `params`

### `describe_ai_infrastructure_employment_v1` (~36 tokens)

Describe AI Infrastructure Employment (data centers + semiconductors)

Describe valid filters, groupings, metrics, detail fields, and citation fields for ai_infrastructure.employment.

### `query_ai_infrastructure_employment_v1` (~1717 tokens)

Query AI Infrastructure Employment (data centers + semiconductors)

Query verified U.S. employment, establishments, and wages — total and by industry (data centers, semiconductors, construction, retail, accommodation, food service) — for any county, state, or the nation, from the U.S. Bureau of Labor Statistics' Quarterly Census of Employment and Wages (QCEW).

Use this for two families of questions: (1) "how many people work in / how many establishments / what
wages in data centers or chip fabs" — INDUSTRY employment, not an "AI jobs" count; and (2) the
place-based question — "what happened to a county's employment, wages, construction, or local economy
(e.g. during and after a data-center / fab buildout)": total covered employment plus the buildout-phase
and induced-sector series for every US county, quarterly since 2014.

Filter by `industry_code` — each code lives at ONE aggregation depth, shown here with its agglvl codes
(national/state/county):
  "10"     Total, all industries — every covered job (agglvl 10/50/70 = all ownerships combined;
           11/51/71 = split by ownership)
  "23"     Construction (sector; 14/54/74)
  "44-45"  Retail trade (sector; 14/54/74)
  "721"    Accommodation (3-digit; 15/55/75)
  "722"    Food services & drinking places (3-digit; 15/55/75)
  "236220" Commercial & institutional building construction (6-digit; 18/58/78)
  "518210" Computing infrastructure / data processing / web hosting — the data-center industry
           (6-digit; 18/58/78)
  "334413" Semiconductor & related device manufacturing (6-digit; 18/58/78)
\`agglvl`'s first digit is geography (1 national / 5 state / 7 county); pick ONE industry_code and the
matching agglvl for its depth to get a clean additive scope. Also filter by `own_code` ("5" = Private —
the usual one; "1"/"2"/"3" = federal/state/local government; "0" = Total Covered, only on industry
"10"), geography (`state` USPS e.g. "VA", `county_fips` 5-digit e.g. "51107" Loudoun County, or
\`area_fips`), and time (`year`, `qtr` "1"-"4", the `quarter` ISO first-of-quarter e.g.…

Input parameters:

- `params`

### `describe_ai_infrastructure_trade_v1` (~34 tokens)

Describe AI Infrastructure Trade (chip imports)

Describe valid filters, groupings, metrics, detail fields, and citation fields for ai_infrastructure.trade.

### `query_ai_infrastructure_trade_v1` (~613 tokens)

Query AI Infrastructure Trade (chip imports)

Query verified U.S. monthly IMPORTS of integrated circuits (HS-8542) — customs value (USD) by country of origin — from the U.S. Census Bureau's International Trade data.

Use this for "how much $ of chips did the US import (from Taiwan / South Korea / in total) and how is it trending" questions. HS-8542 is ALL integrated circuits (processors, memory, amplifiers, parts) — NOT AI-accelerator / GPU-specific. Filter by `country` (the verbatim Census name, e.g. "TAIWAN", "KOREA, SOUTH"), `cty_code` (the Census country code, e.g. "5830"), `country_level` ("total" = the all-countries TOTAL, "country" = an individual country, "grouping" = a Census bloc/continent like ASIA / APEC / EU), `year`, `data_month` (one month, ISO first-of-month e.g. "2026-04-01") or the `data_month_from`/`data_month_to` range. Group by any of `country`, `cty_code`, `country_level`, `data_month`, or `year`. Pass each parameter as a top-level key of `params` (flat — not nested under a `filter`, `filters`, or `where` key). Example: `{"country_level": "country", "group_by": ["country"], "order_by": "general_value_usd", "top_n": 5}` for the top source countries; `{"country_level": "total", "group_by": ["data_month"]}` for the national trend. Returns JSON aggregates with citations and optional row-level records when `include_records` is true — every value cites the exact Census response row, re-verifiable via get_source_evidence_v1.

Measures: `general_value_usd` (general imports value) and `consumption_value_usd` (imports for consumption) — value only; HS-8542 reports no meaningful quantity at this level, so there is no chip count. NEVER SUM across country rows: Census's groupings (ASIA, APEC, EU, OECD, ASEAN, the continents) OVERLAP each other and the individual countries, and the all-countries TOTAL contains everything — so adding rows double-counts. Filter `country_level=total` for the U.S. national figure, `country_level=country` for individual countries, or group_by country for the per-country ser…

Input parameters:

- `params`

### `describe_ai_infrastructure_equipment_trade_v1` (~38 tokens)

Describe AI Infrastructure Equipment Trade (chip-making tools)

Describe valid filters, groupings, metrics, detail fields, and citation fields for ai_infrastructure.equipment_trade.

### `query_ai_infrastructure_equipment_trade_v1` (~691 tokens)

Query AI Infrastructure Equipment Trade (chip-making tools)

Query verified U.S. monthly IMPORTS of semiconductor-manufacturing EQUIPMENT (HS-8486) — customs value (USD) by country of origin — from the U.S. Census Bureau's International Trade data.

Use this for "is the fab buildout actually tooling up, and who supplies the machines" questions — the equipment leg of the fab lifecycle: construction spending (ai_infrastructure.construction) measures the shell, this measures the tools flowing in, and chip imports (ai_infrastructure.trade) measure the output side. HS-8486 covers machines and apparatus used solely or principally to MANUFACTURE semiconductor boules/wafers, devices, and integrated circuits — AND flat-panel displays (Census does not split them at this level); it is NOT the chips themselves (those are HS-8542). Filter by `country` (the verbatim Census name, e.g. "JAPAN", "NETHERLANDS", "KOREA, SOUTH"), `cty_code` (the Census country code), `country_level` ("total" = the all-countries TOTAL, "country" = an individual country, "grouping" = a Census bloc/continent like ASIA / APEC / EU), `year`, `data_month` (one month, ISO first-of-month e.g. "2026-04-01") or the `data_month_from`/`data_month_to` range. Group by any of `country`, `cty_code`, `country_level`, `data_month`, or `year`. Pass each parameter as a top-level key of `params` (flat — not nested under a `filter`, `filters`, or `where` key). Example: `{"country_level": "country", "group_by": ["country"], "order_by": "general_value_usd", "top_n": 5}` for the top tool-supplying countries; `{"country_level": "total", "group_by": ["data_month"]}` for the national trend. Returns JSON aggregates with citations and optional row-level records when `include_records` is true — every value cites the exact Census response row, re-verifiable via get_source_evidence_v1.

Measures: `general_value_usd` (general imports value) and `consumption_value_usd` (imports for consumption) — value only; no tool counts, and no tool-type or vendor breakdown (one HS4 heading: no lithography-vs…

Input parameters:

- `params`

### `describe_ai_infrastructure_production_v1` (~35 tokens)

Describe AI Infrastructure Production (semiconductor output and utilization)

Describe valid filters, groupings, metrics, detail fields, and citation fields for ai_infrastructure.production.

### `query_ai_infrastructure_production_v1` (~666 tokens)

Query AI Infrastructure Production (semiconductor output and utilization)

Query verified U.S. semiconductor & electronic-component PRODUCTION and CAPACITY UTILIZATION — the Federal Reserve's monthly G.17 industrial-production index (2017=100) and capacity-utilization rate (percent) for NAICS 3344 — from the Board's own release, history to 1972.

Use this for "are the domestic fabs actually producing / how hot are they running" questions — the OUTPUT leg of the fab lifecycle: construction spending (ai_infrastructure.construction) measures the shell, equipment imports (ai_infrastructure.equipment_trade) the tools flowing in, chip imports (ai_infrastructure.trade) what crosses the border; this measures domestic production and how much of the installed capacity is in use. NAICS 3344 is "semiconductor and OTHER electronic component" manufacturing — the finest split the Fed publishes here (broader than semiconductors alone, and NOT the same slice as QCEW's 334413). Filter by `series_kind` ("ip" = the production index, on both bases; "capacity_utilization" = percent of capacity in use, seasonally adjusted only; "capacity" = the capacity index behind the rate), `series_name` (the verbatim Fed series, e.g. "IP.G3344.S", "CAPUTL.G3344.S"), `basis` ("seasonally_adjusted" / "not_seasonally_adjusted" — IP only), `year`, `data_month` (ISO first-of-month, e.g. "2026-05-01") or the `data_month_from`/`data_month_to` range. Group by any of `series_name`, `series_kind`, `basis`, `data_month`, or `year`. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"series_kind": "capacity_utilization", "group_by": ["data_month"], "data_month_from": "2024-01-01"}` for the utilization trend; `{"series_kind": "ip", "basis": "seasonally_adjusted", "group_by": ["year"]}` for the production index by year (an average per year). Returns JSON aggregates with citations and optional row-level records when `include_records` is true — every value cites the exact Fed SDMX observation, re-verifiable via get_source_evidence_v1.

Measures are avg/min/m…

Input parameters:

- `params`

### `describe_robotics_trade_v1` (~31 tokens)

Describe Robotics Trade (industrial-robot imports, value + robot counts)

Describe valid filters, groupings, metrics, detail fields, and citation fields for robotics.trade.

### `query_robotics_trade_v1` (~755 tokens)

Query Robotics Trade (industrial-robot imports, value + robot counts)

Query verified U.S. monthly IMPORTS of INDUSTRIAL ROBOTS — customs value (USD) AND unit counts (number of robots) — by country of origin, from the U.S. Census Bureau's International Trade data.

Use this for "how many robots is the US importing, from whom, and what are they worth" questions — the only high-frequency official U.S. robotics series. Covers the nomenclature's two robot-specific HS-10 codes, served as the `commodity` dimension: "8479500000" (INDUSTRIAL ROBOTS, NESOI — multipurpose: welding/assembly arms, AMRs) and "8428700000" (INDUSTRIAL ROBOTS FOR LIFTING, HANDLING, LOADING OR UNLOADING — created by HS 2022; no data before 2022-01, a structural absence, never zero). Filter by `commodity`, `country` (the verbatim Census name, e.g. "JAPAN", "CHINA", "KOREA, SOUTH"), `cty_code` (the Census country code), `country_level` ("total" = the all-countries TOTAL, "country" = an individual country, "grouping" = a Census bloc/continent like ASIA / APEC / EU), `year`, `data_month` (one month, ISO first-of-month e.g. "2026-04-01") or the `data_month_from`/`data_month_to` range. Group by any of `commodity`, `country`, `cty_code`, `country_level`, `data_month`, or `year`. Pass each parameter as a top-level key of `params` (flat — not nested under a `filter`, `filters`, or `where` key). Example: `{"commodity": "8479500000", "country_level": "country", "group_by": ["country"], "order_by": "general_quantity_units", "top_n": 5}` for the top robot-supplying countries by unit count; `{"country_level": "total", "group_by": ["data_month", "commodity"]}` for the national trend per code. Returns JSON aggregates with citations and optional row-level records when `include_records` is true — every value cites the exact Census response row, re-verifiable via get_source_evidence_v1.

Measures: `general_value_usd` / `consumption_value_usd` (customs value) and `general_quantity_units` / `consumption_quantity_units` (Census's "NO" unit of measure = the number of robots). NEVER SUM acro…

Input parameters:

- `params`

### `describe_robotics_adoption_v1` (~33 tokens)

Describe Robotics Adoption (share of plants using robots, workers exposed, robotics capex)

Describe valid filters, groupings, metrics, detail fields, and citation fields for robotics.adoption.

### `query_robotics_adoption_v1` (~738 tokens)

Query Robotics Adoption (share of plants using robots, workers exposed, robotics capex)

Query the verified share of US manufacturing plants USING industrial robots — plus workers exposed and robotics capex — from the Census Industrial Robotic Equipment product (the first official federal robotics-adoption statistics).

Use this for "are factories actually adopting robots" questions — the INSTALLED-BASE reading the import data cannot see. Serves the percent of plants with robots and the percent of employees at plants with robots (both published as FRACTIONS of 1: 0.121 = 12.1%), Census's demeaned variants, and capital expenditures for robotic equipment ($1000) — by manufacturing industry (`naics_code`, 2/3-digit), by `state`, and by `plant_size` band. Filter by `edition` ("asm_2018_2021" = the ASM annual series; "ec_2022" = the 2022 Economic Census), `table` (the workbook sheet — exactly one of: "Percent of... NAICS", "Percent of... Geo", "Percent of... Geo demean", "Robot adopters vs not", "Robot adoption and plant size", "CapEx... NAICS", "CapEx... Geo", "CapEx and plant size"), `data_year` (2018-2022), `naics_code`, `state`, `plant_size`, or `geo_area_name` ("United States" for the national row). Group by any of `edition`, `table`, `naics_code`, `naics_title`, `state`, `plant_size`, `data_year`. Pass each parameter as a top-level key of `params` (flat — not nested under a `filter`, `filters`, or `where` key). Example: `{"table": "Percent of... Geo", "data_year": 2022, "group_by": ["state"], "order_by": "avg_pct_plants_with_robots", "top_n": 10}` for the most-automated states; `{"table": "Percent of... NAICS", "edition": "asm_2018_2021", "naics_code": "336", "group_by": ["data_year"]}` for transportation-equipment adoption over the ASM years. Returns JSON aggregates with citations and optional row-level records when `include_records` is true — every value cites its exact workbook cell-group, re-verifiable via get_source_evidence_v1.

THE ENGRAVED BOUNDARY: the two editions are NEVER spliced into one trend — the 2022 Economic Census reaches the small-…

Input parameters:

- `params`

### `describe_space_satellite_filings_v1` (~36 tokens)

Describe Space Satellite Filings (FCC satellite licensing docket)

Describe valid filters, groupings, metrics, detail fields, and citation fields for space.satellite_filings.

### `query_space_satellite_filings_v1` (~746 tokens)

Query Space Satellite Filings (FCC satellite licensing docket)

Query the verified FCC satellite licensing docket — every space-station (SAT) filing in the FCC's own daily IBFS database dump, back to the 1960s — by applicant, application type, status, and filing date.

Use this for "who is authorized to operate what in orbit, what has been filed, and where does each filing stand" questions — the satellite-buildout licensing pipeline. Each filing carries the FCC's public filing key (`file_number`, e.g. "SATLOA2025061800149"), the `callsign` (e.g. "S3069" = SpaceX Gen2), the application type and status in the FCC's OWN vocabulary — verbatim codes plus the FCC's own decode text from the same dump vintage (`app_type_code` "LOA" = Launch and Operating Authority, "STA" = Special Temporary Authority, "MOD" = Modification; `status_code` "A/C" = Action Complete, "ATPN" = Action Taken Public Notice — codebooks in describe) — the full lifecycle date family (filed / granted / expires / …), the FCC's plain-English `description` of the filing, and the applicant identity (`applicant_name`, the FCC's verbatim registrant, e.g. "Space Exploration Holdings, LLC"). Filter by `applicant_name`, `app_type_code`, `status_code`, `callsign`, `file_number`, `state` (the APPLICANT's address state), `applicant_country`, `report_period` (the filing date) via `report_period_from`/`report_period_to`, or `date_grant`/`date_expire` ranges. Group by any of `applicant_name`, `app_type_code`, `status_code`, `state`, `applicant_country`. Pass each parameter as a top-level key of `params` (flat — not nested under a `filter`, `filters`, or `where` key). Example: `{"applicant_name": "Space Exploration Holdings, LLC", "group_by": ["app_type_code"]}` for one operator's filing mix; `{"report_period_from": "2020-01-01", "group_by": ["applicant_name"], "order_by": "source_record_count", "top_n": 10}` for the most active filers of the 2020s. Returns JSON aggregates with citations and optional row-level records when `include_records` is true — every record cites its exact ro…

Input parameters:

- `params`

### `describe_capacity_factor_v1` (~39 tokens)

Describe Power Capacity Factor

Describe capacity factor: net generation / (operating nameplate × hours), joined across EIA-860M and EIA-923.

### `query_capacity_factor_v1` (~256 tokens)

Query Power Capacity Factor

Query verified U.S. capacity factor — how hard a fleet actually runs — by joining EIA-860M capacity and EIA-923 generation.

Requires `data_month`: one ISO month start, e.g. "2026-01-01". If the user names no month, ask which one (or state the month you chose); if a month is not covered, the error lists the months that are — do not retry blindly.

capacity_factor = net generation (MWh) / (operating nameplate capacity (MW) × hours in the month), computed over plant×fuel present in BOTH sources, so scope is auto-aligned. Optional `group_by` of `state` and/or `fuel_group`, and `state`/`fuel_group` filters. Returns the capacity factor per group with its generation and capacity, a `coverage` declaration (what share of in-scope capacity/generation matched), and a citation to BOTH the capacity and the generation source row. Basis is nameplate; storage is excluded; the capacity snapshot is matched to the month. Does not determine per-generator capacity factor, a net-summer/winter basis, or months absent from either source.

Input parameters:

- `params`

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/build-exascale-osint/api#diagnostics

## Score history

- 2026-08-03: 67
- 2026-08-02: 67
- 2026-08-01: 65
- 2026-07-31: 66
- 2026-07-30: 60
- 2026-07-29: 59
- 2026-07-28: 58
- 2026-07-27: 57
- 2026-07-26: 57

## Links

- Remote endpoint: https://api.exascale.build/mcp
- Website: https://exascale.build/
- Changelog RSS feed: https://verifymcp.io/servers/build-exascale-osint/api/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/build-exascale-osint/api/changelog.json
- HTML version of this page: https://verifymcp.io/servers/build-exascale-osint/api