Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

build.exascale/osint

REMOTE · API.EXASCALE.BUILD · SCANNED SEP 22

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

0 this week 81 Trust /100
Trust breakdown (7 categories)

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. How we score → Why this is hard to score →

Endpoint Security80
Transport & Reachability100
Schema Quality & AI Usability56
  • AI-judged instruction clarity (good).Pass
  • Context-footprint check failed: tool/resource definitions use about 19016 tokens (~297/item across 64 items; 64 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management97
  • Stability check failed: schema churn in the 30 days we've observed: 2 tool removals, 0 breaking changes, 0 auth/transport breaks, 0 additions. See how to fix → Fail
Tool Coverage71
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 0% of tool parameters carry a description.Fail
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 64 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 65 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a current MCP spec version (2026-07-28).Pass
Install

How do I install the build.exascale/osint MCP server?

build.exascale/osint is a hosted endpoint at https://api.exascale.build/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

remote · api.exascale.build

# add to Claude Code
claude mcp add --transport http build-exascale-osint 'https://api.exascale.build/mcp'
// .cursor/mcp.json
{
  "mcpServers": {
    "build-exascale-osint": {
      "url": "https://api.exascale.build/mcp"
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "build-exascale-osint": {
      "type": "http",
      "url": "https://api.exascale.build/mcp"
    }
  }
}
# ~/.codex/config.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
    }
  }
}
# add to OpenClaw
openclaw mcp add build-exascale-osint --url 'https://api.exascale.build/mcp' --transport streamable-http
# ~/.hermes/config.yaml
mcp_servers:
  build-exascale-osint:
    url: "https://api.exascale.build/mcp"
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "build-exascale-osint": {
      "Transport": "http",
      "Url": "https://api.exascale.build/mcp"
    }
  }
}
# add to Vellum
assistant mcp add build-exascale-osint -t streamable-http -u 'https://api.exascale.build/mcp'
// mcp.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 we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 10 Sept 26 −1
    • Stability: pass → fail security
    • A breaking change shipped without a version bump: still 1.0.0 security
    • Tool “describe_ai_infrastructure_employment_v1” was removed security
    • Tool “query_ai_infrastructure_employment_v1” was removed security
  • 8 Sept 26 0
    • Tool “query_power_capacity_accreditation_miso_v1” rewrote its description, which is the text the model reads security
    • Tool “query_power_capacity_accreditation_pjm_v1” rewrote its description, which is the text the model reads security
    • Tool “query_power_capacity_market_miso_v1” rewrote its description, which is the text the model reads security
    • Tool “query_power_capacity_market_pjm_v1” rewrote its description, which is the text the model reads security
  • 3 Sept 26 +1
    • Stability: fail → pass security
  • 1 Sept 26 −1
    • Stability: pass → fail security
  • 26 Aug 26 +2
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
  • 25 Aug 26 0
    • Stability: 0.97 → pass security
  • 16 Aug 26 0
    • Authorization: unverified → partial security
    • TLS certificate: unverified → pass security
    • HSTS header: unverified → pass security
    • Transport: fail → pass security
    • Endpoint reachability: unreachable → reachable functional
    • Tool coverage: unverified → 100 functional
    • MCP protocol: unverified → pass functional
    • Stability: unverified → 0.70 functional
  • 15 Aug 26 0
    • Endpoint reachability: reachable → unreachable security
    • Stability: 0.63 → unverified security
    • Authorization: partial → unverified security
    • TLS certificate: pass → unverified security
    • HSTS header: pass → unverified security
    • Transport: pass → fail security
    • Capabilities: pass → unverified functional
    • Tool coverage: 100 → unverified functional
    • First check of Schema quality: unverified functional
Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 22 Sept 2026 · Probed https://api.exascale.build/mcp

TLS valid

Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .

Subject Issuer Valid from Valid until Key Signature Serial
CN=api.exascale.build CN=YE1,O=Let's Encrypt,C=US 7 Aug 2026 5 Nov 2026 ECDSA 256 ECDSA-SHA384 585f9f3998d7de97b1ffc1c7a0f73c33325
SANs: api.exascale.build
CN=YE1,O=Let's Encrypt,C=US (CA) CN=Root YE,O=ISRG,C=US 3 Sept 2025 2 Sept 2028 ECDSA 384 ECDSA-SHA384 5ddd70dd31f801c85c186a7a04b80afe
CN=Root YE,O=ISRG,C=US (CA) CN=ISRG Root X2,O=Internet Security Research Group,C=US 13 May 2026 2 Sept 2032 ECDSA 384 ECDSA-SHA384 872165fc34b6e5fba8add5b3705fb53a
CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) CN=ISRG Root X1,O=Internet Security Research Group,C=US 13 May 2026 2 Sept 2032 ECDSA 384 SHA256-RSA 6c8f1dc727c7117f7baf853ac980f9cd

Background: What to check on a remote MCP endpoint →

DNSSEC insecure

Validation of api.exascale.build. Not signed

Zone DS Keys Algorithms Outcome
. trust_anchor 20326, 38696 8, 8 Verified
build. present 30770, 38839 8, 8 Verified
exascale.build. absent Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation
Authentication No authorisation required

The endpoint answered without asking for a token. Anyone who knows the URL can reach it.

Result No authorisation required
HTTP status 200
Header Value
strict-transport-security max-age=31536000; includeSubDomains
x-content-type-options nosniff

Background: How OAuth 2.1 works in the 2026 MCP spec →

Transports 2 probes
Transport URL Outcome Status Location
streamable-http https://api.exascale.build/mcp Verified 200
http (plaintext) http://api.exascale.build/mcp HTTPS enforced 308 https://api.exascale.build/mcp
MCP tools · 64 exposed · ~18,587 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
describe_ai_infrastructure_construction_v1 ~36

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_ai_infrastructure_equipment_trade_v1 ~38

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_ai_infrastructure_production_v1 ~35

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_ai_infrastructure_trade_v1 ~34

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_capability_v1 ~156

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.

NameTypeReqDescription
capabilitystringyes

Structured output declared, but exposes no named fields.

No examples provided.

describe_capacity_factor_v1 ~39

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_natural_gas_prices_v1 ~42

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_asset_ownership_v1 ~31

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_capacity_accreditation_miso_v1 ~34

Describe MISO accreditation document kinds, resource classes, ratios, suppressions, and citations.

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_capacity_accreditation_pjm_v1 ~32

Describe PJM ELCC document identities, class dimensions, metrics, and citations.

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_capacity_market_miso_v1 ~31

Describe MISO PRA planning-year, season, zone, parameter, and citation fields.

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_capacity_market_pjm_v1 ~31

Describe PJM RPM delivery-year/LDA filters, UCAP metrics, and citations.

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_capacity_v1 ~30

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_demand_rollup_v1 ~36

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_demand_v1 ~32

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_fuel_cost_v1 ~34

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_generation_v1 ~33

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_interconnection_queue_caiso_v1 ~38

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_interconnection_queue_ercot_v1 ~40

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_interconnection_queue_isone_v1 ~38

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_interconnection_queue_nyiso_v1 ~38

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_interconnection_queue_pjm_cycle_v1 ~40

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_interconnection_queue_pjm_v1 ~38

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_interconnection_queue_spp_v1 ~38

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_interconnection_queue_v1 ~34

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_plant_costs_v1 ~36

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_price_ercot_v1 ~36

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_power_retail_sales_v1 ~34

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_robotics_adoption_v1 ~33

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_robotics_trade_v1 ~31

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

describe_space_satellite_filings_v1 ~36

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

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

get_source_evidence_v1 ~122

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.

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

list_capabilities_v1 ~67

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.

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

query_ai_infrastructure_construction_v1 ~758

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…

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_ai_infrastructure_equipment_trade_v1 ~691

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…

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_ai_infrastructure_production_v1 ~666

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…

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_ai_infrastructure_trade_v1 ~613

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…

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_capability_v1 ~177

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.

NameTypeReqDescription
capabilitystringyes
params

Structured output declared, but exposes no named fields.

No examples provided.

query_capacity_factor_v1 ~256

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.

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_natural_gas_prices_v1 ~291

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.

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_power_asset_ownership_v1 ~267

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.

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_power_capacity_accreditation_miso_v1 ~71

Query cited MISO Schedule 53 class-average and indicative-DLOL seasonal accreditation ratios, including published unit counts, storage variants, and explicit suppression atoms. Requires an API key (free during early access) while the source's redistribution terms are under review.

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_power_capacity_accreditation_pjm_v1 ~83

Query cited PJM marginal ELCC class ratings by document kind, auction, delivery year, and resource class. Preliminary, final, and incremental-auction documents remain separate; no value is preferred or reconciled. Requires an API key (free during early access) while the source's redistribution terms are under review.

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_power_capacity_market_miso_v1 ~67

Query cited MISO Planning Resource Auction seasonal zonal ACP, verbatim ERZ values, published CONE parameters, and IMM conduct thresholds. Requires an API key (free during early access) while the source's redistribution terms are under review.

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_power_capacity_market_pjm_v1 ~72

Query cited PJM Base Residual Auction UCAP clearing prices, RTO cleared MW, reliability requirement, and published administrative price collar by delivery year and LDA. Requires an API key (free during early access) while the source's redistribution terms are under review.

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_power_capacity_v1 ~277

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

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_power_demand_rollup_v1 ~820

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…

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_power_demand_v1 ~572

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…

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_power_fuel_cost_v1 ~252

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.

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

query_power_generation_v1 ~390

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.

NameTypeReqDescription
params

Structured output declared, but exposes no named fields.

No examples provided.

Common questions

What is the build.exascale/osint MCP server?

build.exascale/osint is an MCP server listed in the public MCP registry as build.exascale/osint. Source-cited US machine-economy data: power, AI infra, chips, robot trade + adoption, satellites. This page covers its hosted endpoint (https://api.exascale.build/mcp).

Is the build.exascale/osint MCP server safe to use?

build.exascale/osint scores 81 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the build.exascale/osint MCP server expose?

build.exascale/osint exposes 64 tools: list_capabilities_v1, get_source_evidence_v1, describe_capability_v1, query_capability_v1, describe_power_capacity_v1, and 59 more. Their descriptions and schemas cost roughly 18,587 tokens of context every time the server is loaded.

Does the build.exascale/osint MCP server require authentication?

No. We connected to build.exascale/osint without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

Is the build.exascale/osint MCP server still maintained?

build.exascale/osint is still listed as active in the MCP registry. We last reached this channel on 22 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.