query_ai_infrastructure_construction_v1
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 begins 2014-01. The response `as_of` is the release vintage
(Census revises monthly); pin `as_of` to an earlier vintage to reproduce what was served then.
NOT additive: `construction_spending_musd` is a published per-(category, basis, month) reading, so a
total that mixes the two bases (an annual rate + a monthly level), or that sums the seasonally-adjusted
ANNUAL-RATE series across months, is not a real figure â such a result carries a
`construction_aggregation` scope note and ranking remainders omit the metric. Filter to one `basis`
and `group_by data_month` for a series over time.
Does not determine total data-center INVESTMENT (servers, chips, cooling, equipment â this is
construction put-in-place only; Census does not publish an investment total), data-center MW capacity,
count, square footage, or location (use the power.* capabilities for capacity and the interconnection
queue), which company or project is building (Census C30 has no operator breakdown), public or
government construction (this is PRIVATE construction only), or construction outside these two categories.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_ai_infrastructure_equipment_trade_v1
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-deposition-vs-etch split, no per-manufacturer series such as ASML). 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; a cross-row sum returns a country_aggregation note and nulls the metric in ranking remainders. Filter `country_level=total` for the U.S. national figure. Country is the country of ORIGIN (Census attribution), not which U.S. fab, state, or operator receives the equipment â there is no U.S. place breakdown. Imports only (not exports), customs value (not landed/CIF/duty), and recent months are preliminary and revised in later Census releases.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_ai_infrastructure_production_v1
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/max per reading â `avg_ip_index`, `avg_capacity_utilization_pct`, `avg_capacity_index` (+ min/max variants): an index or a rate is INTENSIVE, so multi-month figures are AVERAGES, never sums (the Fed publishes its own quarterly/annual aggregations, which this block does not serve â monthly grain only). An index is not dollars and not unit counts (2017=100). Capacity and utilization exist seasonally adjusted only â their not-seasonally-adjusted cells are structurally absent, never zero. Averaging the IP index across both bases returns a production_aggregation note â filter or group by basis instead. National industry aggregate: no state, county, fab, or company breakdown. Every monthly release revises history (as_of carries the vintage).
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_ai_infrastructure_trade_v1
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 series; a cross-row sum returns a country_aggregation note and nulls the metric in ranking remainders. Country is the country of ORIGIN (Census attribution), not where a chip is installed â there is no U.S. state/county breakdown. Imports only (not exports), customs value (not landed/CIF/duty), and recent months are preliminary and revised in later releases.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_power_demand_rollup_v1
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 date range, for a series over time. Pin
`as_of` to an earlier vintage to reproduce what was served then.
INVERTED additivity: `demand_mw` is ALREADY a published total, so it is NOT additive across
respondents â US48 already equals the sum of the 13 regions. A result spanning more than one
respondent without grouping by it carries a `respondent_aggregation` scope note and ranking
remainders omit the demand metrics: filter `respondent=US48` for the national total, or group
by `respondent` for the per-respondent series. Occasional source-quality anomalies (an hour EIA
did not publish; a rare impossible value EIA published) are served verbatim and cited, never altered.
Does not determine balancing-authority-level demand (use power.demand for the BA series),
demand before 2019-01-01, the raw un-Adjusted series (this route publishes the Adjusted series
only), plant, generator, county, or state attribution, installed capacity (use power.capacity),
monthly plant generation (use power.generation), retail sales, revenue, or customers (use
power.retail_sales), wholesale prices, or long-horizon forecasts (the forecast is day-ahead only).
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_power_interconnection_queue_caiso_v1
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_source_evidence_v1.
`net_mw_to_grid` is REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built, so the report is withdrawn-dominated. NEVER read a queue-MW total as installed or operating capacity â it is additive across distinct projects but is a REQUESTED total only. Scope by `application_status`: `ACTIVE` is the live pipeline, `COMPLETED` is built and in service (and carries an `actual_online_date`), `WITHDRAWN` left the queue. CAISO publishes no separate built-MW column â `net_mw_to_grid` is served under CAISO's own name and never relabeled or duplicated as a built figure. For built/operating capacity use query_power_capacity_v1.
CAISO only â never summed, deduped, or compared across ISOs. For the MISO interconnection queue use query_power_interconnection_queue_v1; for PJM use query_power_interconnection_queue_pjm_v1 (or query_power_interconnection_queue_pjm_cycle_v1 for PJM's cluster/cycle grid); for the NYISO (New York) 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. This tool serves CAISO's Public Queue Report (Cluster 14 and prior, plus the serial/legacy tracks); CAISO's separate current-cluster intake file is a distinct publication and is not served here. CAISO reports no data-center / load type, and this tool does not infer one â that interpretation is the analyst's, from cited rows.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_power_interconnection_queue_ercot_v1
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 active queue as of mid-2019. Each month is a full point-in-time snapshot (a project that has since withdrawn is simply absent from later months â query the earlier `as_of` to see it), so a multi-month trend is one query per month; `as_of` is the history axis, not a row filter. 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.
`capacity_mw` is REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built. NEVER read a queue-MW total as installed or operating capacity â it is additive across distinct rows but is a REQUESTED total only. ERCOT prints NO status column, so `application_status` is derived from the sheet ERCOT files the project on: `ACTIVE` is the live pipeline (Large/Small Gen), `INACTIVE` and `CANCELLED` are projects that recently left the queue (the Inactive / Cancellation sheets list RECENT departures, NOT the full historical withdrawn set). The build-progress reading is carried SEPARATELY in `gim_study_phase` (e.g. "SS Completed, FIS Completed, IA") + the milestone dates and is never collapsed into `application_status`. For built/operating capacity use query_power_capacity_v1.
ERCOT only â never summed, deduped, or compared across ISOs. For the MISO interconnection queue use query_power_interconnection_queue_v1; for PJM use query_power_interconnection_queue_pjm_v1 (or query_power_interconnection_queue_pjm_cycle_v1 for PJM's cluster/cycle grid); for the CAISO (California) queue use query_power_interconnection_queue_caiso_v1; for the NYISO (New York) queue use query_power_interconnection_queue_nyiso_v1; for the ISO-NE (New England) queue use query_power_interconnection_queue_isone_v1; for the SPP (central US) queue use query_power_interconnection_queue_spp_v1. This tool serves ERCOT's GIS Report, which is GENERATION-only; ERCOT's separate large-load / data-center interconnection queue is an unstructured source (TAC-meeting PDF slides) and is NOT served here, and this tool does not infer which projects are data-center-driven â that interpretation is the analyst's, from cited rows.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_power_interconnection_queue_isone_v1
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 withdrawn-dominated. NEVER read a queue-MW total as installed or operating capacity â it is additive across distinct rows but is a REQUESTED total only. ISO-NE publishes net, summer-peak and winter-peak MW separately â served under ISO-NE's own labels and never blended into one nameplate. Scope by `application_status`: `A` = Active (the live pipeline), `C` = Commercial (built and in service â the built reading), `W` = Withdrawn. ISO-NE ALSO carries a separate build-progress `project_status` (Under Study / Under Construction / In Service / â¦) â kept distinct from `application_status`, never collapsed. For built/operating capacity use query_power_capacity_v1.
ISO-NE only â never summed, deduped, or compared across ISOs. For the MISO interconnection queue use query_power_interconnection_queue_v1; for PJM use query_power_interconnection_queue_pjm_v1 (or query_power_interconnection_queue_pjm_cycle_v1 for PJM's cluster/cycle grid); 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 ERCOT (Texas) queue use query_power_interconnection_queue_ercot_v1; for the SPP (central US) queue use query_power_interconnection_queue_spp_v1. ISO-NE publishes no data-center / load request type (all rows are generation or transmission), and this tool does not infer one â that interpretation is the analyst's, from cited rows.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_power_interconnection_queue_nyiso_v1
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 MW and project counts by lifecycle. 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.
`sp_mw` / `wp_mw` / `peak_mw_load` are REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built, so the queue is withdrawn-dominated. NEVER read a queue-MW total as installed or operating capacity â it is additive across distinct project-rows but is a REQUESTED total only. NYISO publishes summer (SP) and winter (WP) peak MW separately â they are served under NYISO's own names and never blended into one nameplate. Scope by `application_status` (ACTIVE / WITHDRAWN / IN_SERVICE / AFFECTED_SYSTEM / AFFECTED_SYSTEM_WITHDRAWN â the lifecycle tab's reading, overridden to the withdrawn form when a row carries NYISO's own status code 0, per the workbook's printed '0=Withdrawn' key) or by `sheet_name`; the `In Service` tab is the built reading. A project may appear on more than one tab (the grain is sheet + queue_position), so the counts are project-rows, not deduped projects. For built/operating capacity use query_power_capacity_v1.
NYISO only â never summed, deduped, or compared across ISOs. For the MISO interconnection queue use query_power_interconnection_queue_v1; for PJM use query_power_interconnection_queue_pjm_v1 (or query_power_interconnection_queue_pjm_cycle_v1 for PJM's cluster/cycle grid); for the CAISO (California) queue use query_power_interconnection_queue_caiso_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. NYISO's Load Projects tab is served as-reported: `end_use` is NYISO's OWN classification (NYISO publishes no key for the codes), and this tool does NOT infer an end use NYISO did not print â interpretation beyond the code is the analyst's, from cited rows.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_power_interconnection_queue_pjm_cycle_v1
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 Services queue (query_power_interconnection_queue_pjm_v1)
are different publications that share rows â never summed or compared across them; never across ISOs
(the MISO queue is query_power_interconnection_queue_v1; the CAISO queue is
query_power_interconnection_queue_caiso_v1; the NYISO queue is
query_power_interconnection_queue_nyiso_v1; the ISO-NE queue is
query_power_interconnection_queue_isone_v1; the ERCOT queue is
query_power_interconnection_queue_ercot_v1; the SPP queue is
query_power_interconnection_queue_spp_v1). PJM reports no data-center / load type, and this tool
does not infer one.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_power_interconnection_queue_pjm_v1
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/operating capacity use query_power_capacity_v1.
PJM only â never summed, deduped, or compared across ISOs. For the MISO interconnection queue use
query_power_interconnection_queue_v1; 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. For PJM's NEW cluster/cycle process â the TC1/TC2
transition cycles and the reopened steady-state Cycle 1 (C01+), with cycle/stage/developer detail â
use query_power_interconnection_queue_pjm_cycle_v1 (a separate PJM publication; never combined with
this one). PJM reports no data-center / load type, and this tool does not infer one â that
interpretation is the analyst's, from cited rows.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_power_interconnection_queue_spp_v1
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_evidence_v1.
`capacity_mw` is REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built â in the SPP file ~66% of rows are `WITHDRAWN`. NEVER read a queue-MW total as installed or operating capacity â it is additive across distinct rows but is a REQUESTED total only. Always scope by `native_status`, which is SPP's OWN status vocabulary served VERBATIM (`IA FULLY EXECUTED/ON SCHEDULE`, `IA FULLY EXECUTED/COMMERCIAL OPERATION`, `IA FULLY EXECUTED/ON SUSPENSION`, `IA PENDING`, `DISIS STAGE`, `FACILITY STUDY STAGE`, `SPECIAL STUDY`, `ERAS`, `TERMINATED`, `WITHDRAWN`, â¦); it is never mapped to a lifecycle enum and there is no derived active/withdrawn flag â that equivalence is the analyst's. For built/operating capacity use query_power_capacity_v1. SPP's GI Summary is regenerated on demand and SPP keeps no per-vintage archive, so this serves SPP's CURRENT queue (the response `as_of` is SPP's own "Last Updated On" stamp); it is NOT a deep point-in-time history â history accrues forward from first capture, so there is no `as_of` time-travel parameter.
SPP only â never summed, deduped, or compared across ISOs. For the MISO interconnection queue use query_power_interconnection_queue_v1; for PJM use query_power_interconnection_queue_pjm_v1 (or query_power_interconnection_queue_pjm_cycle_v1 for PJM's cluster/cycle grid); for the CAISO (California) queue use query_power_interconnection_queue_caiso_v1; for the NYISO (New York) 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. SPP's GI queue is GENERATION-only and infers no load/data-center type â that interpretation is the analyst's, from cited rows.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_power_interconnection_queue_v1
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 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.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_power_price_ercot_v1
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_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.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_power_retail_sales_v1
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 small
short-form (EIA-861S) utilities, or monthly freshness (this is the annual
census, not the monthly EIA-861M sample).
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_robotics_adoption_v1
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-plant universe the ASM sample does not (US plants-with-robots: 12.1% ASM-2021 vs 6.4% EC-2022 â a COVERAGE change, not a decline; every cross-edition scope carries an edition_scope note). Percents are INTENSIVE shares: avg/min/max over a scope, never summed. Capex sums UNDERSHOOT below the published totals wherever suppression bites (the published "United States" / "31-33" rows are the totals). Suppressed cells (D/S/A, decoded by the file's own footnotes) are null values with their verbatim letter â never zero; (s)-flagged estimates (standard error > 40%) carry their flag. Manufacturing plants only; adoption SHARES and capex, never robot counts (no official count of installed robots exists â the import unit-count series is query_robotics_trade_v1); an EXPERIMENTAL Census product (its own label); no edition after 2022 exists.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_robotics_trade_v1
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 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 â adding rows double-counts; a cross-row sum returns a country_aggregation note and nulls the metrics in ranking remainders; filter `country_level=total` for the U.S. national figure. The two commodity codes ARE disjoint â adding them is legitimate â but a combined time series changes composition at 2022-01 (a commodity_scope note flags it). This is the import FLOW, not the installed base or operational stock of robots in U.S. factories; no maker, model, or humanoid breakdown (customs-classified); country is the country of ORIGIN, not which U.S. state or factory receives the robots; imports only (not exports); customs value (not landed/CIF/duty); recent months are preliminary and revised in later Census releases.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_space_satellite_filings_v1
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 row in the FCC's dump, re-verifiable via get_source_evidence_v1.
THE ENGRAVED BOUNDARY: new-filing intake into IBFS structurally ENDED at the FCC's ICFS system cutover (~mid-2025), and ICFS publishes no bulk data â so filings SUBMITTED after the cutover are not in this docket, and counts near/after 2025 UNDERCOUNT new filing activity (say so when answering; every response carries an icfs_cutover note). The FCC has not regenerated this dump since 2026-07-16 (it previously updated daily), so status changes after that date are not reflected. For filings and actions since the cutover, use query_space_satellite_notices_v1 (the FCC's weekly satellite public notices). A filing is an authorization EVENT: never a satellite count (one NGSO grant can cover thousands of satellites), never an orbital catalog (satellites in orbit are not served here), never launch activity (FAA data, not served here). `state`/`applicant_city` are the APPLICANT's mailing address â satellites are not in states. Earth stations (SES) and non-satellite FCC dockets are out of scope. The one measure is `source_record_count` (filings in scope).
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}
query_space_satellite_notices_v1
Query Space Satellite Notices (FCC weekly satellite public notices)
Query the FCC Space Bureau's weekly satellite public notices since the ICFS cutover (2025-06-18) â every satellite application the FCC accepted for filing and every action it took (grants, partial grants, dismissals, surrenders), as printed.
Use this for "what satellite filings has the FCC received or acted on since mid-2025" questions â the current licensing pipeline, which the pre-cutover docket (query_space_satellite_filings_v1) does not carry. Each record is one listing of a filing in one notice: the notice (`report_number` e.g. "SAT-02040", `notice_kind` "Applications Accepted for Filing" or "Actions Taken", `release_date`), the FCC `file_number` (e.g. "SAT-MOD-20260603-00225") and its `filing_type_code` (LOA, MOD, STA, AMD, T/Câ¦), the `call_sign`, the `applicant` as printed (e.g. "Space Exploration Holdings, LLC"), the printed `date_filed` and `filing_type`, on Actions Taken notices the `action` (e.g. "Grant of Authority") and `action_date`, and the entry's full text as printed (`entry_text`, which carries the FCC's description of the request). Filter by `notice_kind`, `filing_type_code`, `action`, `applicant`, `report_number`, `file_number`, `call_sign`, `informative`, or the ranges `report_period_from`/`report_period_to` (release date), `date_filed_from`/`date_filed_to`, `action_date_from`/`action_date_to`. Group by `notice_kind`, `filing_type_code`, `action`, `applicant` or `report_number`. Pass each parameter as a top-level key of `params`. Example: `{"applicant": "Space Exploration Holdings, LLC", "include_records": true}` for SpaceX's listings; `{"notice_kind": "Actions Taken", "action": "Grant of Authority", "group_by": ["applicant"], "order_by": "source_record_count", "top_n": 10}` for the operators granted most often. Every record cites its line in the FCC's notice text, re-verifiable via get_source_evidence_v1.
Read carefully: one filing can be listed in several notices, so `source_record_count` counts listings, not distinct filings. Values are what each notice prints: the same filing can show a different `date_filed` or applicant name in different notices. `action_date` is null when the notice prints none (the notice states its release date is then the effective date). The notices carry no status history and omit filings the FCC has not listed; a filing is never a satellite count, an orbital catalog or launch activity. Earth-station (SES) notices are out of scope.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'query_toolArguments', 'properties': {'params': {'anyOf': [{'type': 'object', 'additionalProperties': True}, {'type': 'null'}], 'title': 'Params', 'default': None}}}
Output schema
{'type': 'object', 'title': 'query_toolDictOutput', 'additionalProperties': True}