build.exascale/osint
REMOTE · API.EXASCALE.BUILD · SCANNED SEP 22
Source-cited US machine-economy data: power, AI infra, chips, robot trade + adoption, satellites.
Available components
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
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one. See how to fix → View diagnostics → Partial
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
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
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
claude mcp add --transport http build-exascale-osint 'https://api.exascale.build/mcp'
{
"mcpServers": {
"build-exascale-osint": {
"url": "https://api.exascale.build/mcp"
}
}
} {
"servers": {
"build-exascale-osint": {
"type": "http",
"url": "https://api.exascale.build/mcp"
}
}
} [mcp_servers.build-exascale-osint] url = "https://api.exascale.build/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"build-exascale-osint": {
"type": "remote",
"url": "https://api.exascale.build/mcp",
"enabled": true
}
}
} openclaw mcp add build-exascale-osint --url 'https://api.exascale.build/mcp' --transport streamable-http
mcp_servers:
build-exascale-osint:
url: "https://api.exascale.build/mcp" {
"McpServers": {
"build-exascale-osint": {
"Transport": "http",
"Url": "https://api.exascale.build/mcp"
}
}
} assistant mcp add build-exascale-osint -t streamable-http -u 'https://api.exascale.build/mcp'
{
"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.
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
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 |
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 →
query_power_interconnection_queue_caiso_v1 Query Power Interconnection Queue (CAISO) ~897
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…
| Name | Type | Req | Description |
|---|---|---|---|
| params | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
query_power_interconnection_queue_ercot_v1 Query Power Interconnection Queue (ERCOT) ~1,056
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…
| Name | Type | Req | Description |
|---|---|---|---|
| params | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
query_power_interconnection_queue_isone_v1 Query Power Interconnection Queue (ISO-NE) ~860
Query the ISO-NE generator interconnection queue — ISO New England's public IRTT "public queue" report, the waiting line of projects that have REQUESTED to connect to the New England grid (CT, MA, ME, NH, RI, VT). Returns cited, project-level records with ISO-NE's full published structure (all 31 columns of the rendered report): the three megawatt readings kept SEPARATE (`net_mw`, `summer_mw` = max summer output, `winter_mw` = max winter output — `net_mw` is 0 for the many Capacity-Network-Resource-only requests, a real value, not missing), the request `request_type` (G = Generation / ETU = Elective Transmission Upgrade / TS = Transmission Service), the space-delimited multi-value `fuel_type` (EIA energy-source codes, e.g. "SUN BAT"), the `unit_type` and service code `serv` (CNR = Capacity Network Resource / NR = Network Resource), the `jurisdiction` (F = FERC / N = Non-FERC), the ISO-NE load `zone`, the per-stage study statuses (`fs_status` … `ia_status`) with their study-document links, location (`state`, `county`, derived `county_fips`, `poi`), and lifecycle dates. Group or filter by `application_status`, `project_status`, `request_type`, `unit_type`, `fuel_type`, `serv`, `jurisdiction`, `zone`, `state`, `county_fips`, or `cluster`; filter `requested_date` by the `requested_date_from` / `requested_date_to` range. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"application_status": "A", "request_type": "G", "state": "MA"}` for active generation requests in Massachusetts; `{"group_by": ["application_status"]}` for requested MW and project counts by status. Returns JSON aggregates with citations and optional row-level records when `include_records` is true; every value carries `source`, `as_of`, and a `source_row` verifiable with get_source_evidence_v1. `net_mw` / `summer_mw` / `winter_mw` are REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built, so the queue is withd…
| Name | Type | Req | Description |
|---|---|---|---|
| params | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
query_power_interconnection_queue_nyiso_v1 Query Power Interconnection Queue (NYISO) ~1,042
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…
| Name | Type | Req | Description |
|---|---|---|---|
| params | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
query_power_interconnection_queue_pjm_cycle_v1 Query Power Interconnection Queue (PJM cluster/cycle) ~665
Query PJM's cluster/cycle service-request grid — the cluster view of PJM's interconnection process: the TC1/TC2 transition cycles (re-processing the pre-Order-2023 serial backlog) and the reopened steady-state cycles (C01+, the new intake). A SEPARATE PJM publication from the full New Services queue (query_power_interconnection_queue_pjm_v1) — richer per-project cluster detail; the two share rows and are never combined. Returns cited, project-level records with PJM's full cluster schema: the cluster `cycle` (TC1 / TC2 / C01 …) and `stage` (phase / decision point), the `developer`, requested megawatts (`requested_max_output_mw` = MFO, `requested_summer_mw`, `requested_winter_mw`), the realized built `in_service_mw`, long-term-firm transmission `ltf_mw`, location (`state`, `county`, derived `county_fips`), `fuel` and `project_type` as PJM reports them, the single `status`, and the phased System-Impact-Study report URLs + statuses. Group or filter by `cycle`, `stage`, `status`, `state`, `county_fips`, `project_type`, `capacity_or_energy`, `fuel`, `developer`, `transmission_owner`, or (group only) `is_hybrid`; filter `submitted_date` by range. Pass each parameter as a top-level key of `params` (flat). Example: `{"cycle": "C01", "status": "Active"}` for the live reopened-cycle pipeline; `{"group_by": ["cycle"]}` for counts by cluster cycle. Returns JSON aggregates with citations and optional row-level records when `include_records` is true; every value carries `source`, `as_of`, and a `source_row` verifiable with get_source_evidence_v1. The `requested_*` figures are REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built. NEVER read a requested-MW total as installed/operating capacity — additive across distinct projects but a REQUESTED total only. PJM also reports `in_service_mw` (the realized built MW). For built/operating capacity use query_power_capacity_v1. PJM cluster grid only. This and PJM's New Service…
| Name | Type | Req | Description |
|---|---|---|---|
| params | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
query_power_interconnection_queue_pjm_v1 Query Power Interconnection Queue (PJM) ~758
Query the PJM New Services (interconnection) queue — the public waiting line of projects that have REQUESTED to connect to the PJM grid (the mid-Atlantic RTO incl. Northern Virginia, PA, NJ, MD, OH, VA, WV and more). Returns cited, project-level records with PJM's full published structure: requested megawatts (`requested_max_output_mw` = MFO, `requested_summer_mw` = MW Capacity / summer net, `requested_winter_mw` = MW Energy / winter net), the realized built `in_service_mw` for completed projects, location (`state`, `county`, derived `county_fips`), `fuel` and `project_type` as PJM reports them, the single as-reported `status`, the study-document URLs and per-stage statuses, and lifecycle dates. Group or filter by `state`, `county_fips`, `status`, `project_type`, `capacity_or_energy`, `fuel`, `project_ac_dc`, `transmission_owner`, the study statuses, or (group only) `is_hybrid`; filter `submitted_date` by the `submitted_date_from` / `submitted_date_to` range. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"state": "VA", "project_type": "Generation Interconnection", "status": "Active"}` for active generation requests in Virginia; `{"group_by": ["status"]}` for requested MW and project counts by status. Returns JSON aggregates with citations and optional row-level records when `include_records` is true; every value carries `source`, `as_of`, and a `source_row` verifiable with get_source_evidence_v1. The `requested_*` figures are REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built. NEVER read a requested-MW total as installed or operating capacity — it is additive across distinct projects but is a REQUESTED total only. Filter `status` (Active / Withdrawn / In Service / Under Construction / …) to scope the queue; the full export is withdrawn-dominated. PJM also reports `in_service_mw` — the realized BUILT MW for in-service projects (a separate, built figure). For built/o…
| Name | Type | Req | Description |
|---|---|---|---|
| params | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
query_power_interconnection_queue_spp_v1 Query Power Interconnection Queue (SPP) ~1,003
Query the SPP generator interconnection queue — Southwest Power Pool's public GI Summary report, the waiting line of generation projects that have REQUESTED to connect to the SPP grid (the ~14-state central-US RTO: OK, KS, TX panhandle, NE, NM, MO, CO, ND, SD, AR, LA and more). Returns cited, project-level records with SPP's full published structure: the requested `capacity_mw` (SPP's headline `Capacity` figure) PLUS five other labeled MW columns SPP publishes — `max_summer_mw`, `max_winter_mw`, `requested_max_injection_mw`, `requested_nrd_mw`, `nameplate_capacity_mw` — served separately and NEVER blended; the `generation_type` (Wind / Solar / Battery/Storage / Thermal / Hybrid / Hydro — SPP encodes hybrids natively as `Hybrid`, so no is-hybrid is invented) and free-text `fuel_type` (slash-delimited combos like `Solar/Storage` kept whole); the study `current_cluster` (e.g. `DISIS-2024-001`, `Surplus`, `RTOE Transitional Cluster`) and regional `cluster_group` (`01 NORTH` … `05 SOUTHWEST`); the transmission owner `to_at_poi`; the `service_type` (`ER/NR`, `ER`, `NR`); the `substation_or_line`; and the lifecycle dates (`request_received`, `in_service_date`, `commercial_operation_date`, `date_withdrawn`). Group or filter by `native_status`, `generation_type`, `fuel_type`, `service_type`, `current_cluster`, `cluster_group`, `to_at_poi`, `county_fips`, or `state`; filter `request_received` / `commercial_operation_date` by their `_from` / `_to` ranges. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"native_status": "DISIS STAGE", "generation_type": "Solar"}` for solar in the DISIS study stage; `{"native_status": "DISIS STAGE", "group_by": ["state"], "order_by": "capacity_mw", "top_n": 5}` for the active study pipeline's biggest states by requested MW. Returns JSON aggregates with citations and optional row-level records when `include_records` is true; every value carries `source`, `as_of`, and a `source_row` verifiable with get_source_e…
| Name | Type | Req | Description |
|---|---|---|---|
| params | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
query_power_interconnection_queue_v1 Query Power Interconnection Queue (MISO) ~655
Query the MISO generator interconnection queue — the public waiting line of projects that have REQUESTED to connect to the MISO grid (the 15-state Midwest/South footprint). Returns cited, project-level records: requested megawatts (net summer / net winter), location (`state`, `county`, derived `county_fips`), fuel and technology as MISO reports them, three independent status dimensions (`application_status`, `study_phase`, `post_gia_status`), and queue / withdrawn / in-service dates. Group or filter by `state`, `county_fips`, `application_status`, `study_phase`, `post_gia_status`, `fuel_type`, `facility_type`, `service_type`, `study_group`, `study_cycle`, or `is_hybrid`; filter `queue_date` by the `queue_date_from` / `queue_date_to` range. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"state": "IN", "fuel_type": "Solar", "application_status": "Active"}` for active solar requests in Indiana; `{"group_by": ["application_status"]}` for requested MW and project counts by status. Returns JSON aggregates with citations and optional row-level records when `include_records` is true; every value carries `source`, `as_of`, and a `source_row` verifiable with get_source_evidence_v1. This is REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built. NEVER read a requested-MW total as installed or operating capacity — it is additive across distinct projects but is a REQUESTED total only. Filter `application_status` (Active / Withdrawn / Done) to scope the queue; the full export is withdrawn-dominated. For built/operating capacity use query_power_capacity_v1. MISO only — never summed, deduped, or compared across ISOs into a national total (each ISO's methodology, inclusion rules, and withdrawal rates differ). For the PJM interconnection queue (the mid-Atlantic RTO incl. Northern Virginia) use query_power_interconnection_queue_pjm_v1 (or query_power_interconnection_queue_pjm_cycle_v1 fo…
| Name | Type | Req | Description |
|---|---|---|---|
| params | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
query_power_plant_costs_v1 Query FERC Form 1 Plant Costs ~276
Query accepted native-XBRL FERC Form 1 large-steam plant facts. Returns one separately cited XBRL fact per respondent, report year, raw plant name, and source concept: installed capacity, net generation, plant-cost balance items, fuel expense, and individual operation and maintenance lines. Values and units are as filed; nominal dollars are not adjusted, allocated, divided by generation, or combined into a derived O&M total. Plant names remain raw strings with no EIA ID matching. Every value verifies against its exact archive member, XBRL fact ID, context, concept, and SHA-256. Coverage is the Form 1 filing population, not the full fleet. ERCOT-only merchant entities largely do not file, so ERCOT coverage is partial and plant absence means not present in served filings—not zero. `ercot_relevance=true` is a one-call filter based only on the respondent's raw states-served disclosure mentioning Texas; it is not a plant-location claim. v0 covers accepted native XBRL (report year 2021 onward) and the large-steam schedule including nuclear; hydro, pumped storage, migrated historical XBRL, and Visual FoxPro-era filings are explicitly outside v0.
| Name | Type | Req | Description |
|---|---|---|---|
| params | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
query_power_price_ercot_v1 Query Power Prices (ERCOT day-ahead) ~851
Query verified ERCOT wholesale electricity prices — ERCOT's Day-Ahead Market Settlement Point Prices ($/MWh, EMIL NP4-190-CD), the price cleared the day before each operating day at every ERCOT (Texas) settlement point, served hourly. Returns cited prices for each (`settlement_point`, `delivery_date`, `hour_ending`): the per-hour `price_usd_per_mwh` in detail records, plus `avg_price_usd_per_mwh`, `min_price_usd_per_mwh`, and `max_price_usd_per_mwh` over the result scope. Each `settlement_point` is one of ERCOT's locations — a trading Hub (e.g. `HB_NORTH`, `HB_HOUSTON` — the regional benchmark prices), a Load Zone (e.g. `LZ_HOUSTON`), a Resource Node (one generator's connection point), or a DC-tie — and `settlement_point_type` carries ERCOT's OWN verbatim classification code (`HU`/`LZ`/`RN`/`LZ_DC` and finer codes) so an agent can tell a regional benchmark from a single-plant node. Filter or group by `settlement_point`, `settlement_point_type`, `hour_ending`, or `delivery_date`; filter a date window with `delivery_date_from` / `delivery_date_to`, or one day with `delivery_date`. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"settlement_point": "HB_NORTH", "delivery_date": "2026-06-20", "group_by": ["hour_ending"]}` for the North hub's 24 hourly day-ahead prices; `{"delivery_date": "2026-06-20", "group_by": ["settlement_point_type"]}` for the average price by location type. With no date filter the result defaults to the latest delivery day with prices (it does not scan all history); served delivery coverage begins 2014-05-02 from ERCOT's official Data Access Portal archive. Historical settlement-point names remain exactly as published, and names absent from the current pinned type list have a null type rather than being rewritten. Returns JSON with citations and optional row-level records when `include_records` is true; every value carries `source`, `as_of` (the delivery day), and a `source_row` verifiable with get_source_eviden…
| Name | Type | Req | Description |
|---|---|---|---|
| params | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
query_power_retail_sales_v1 Query Power Retail Sales ~559
Query verified U.S. annual retail electricity sales — billed MWh, revenue, and customer counts — by utility, state, and customer sector from EIA-861. Use this for "who sold how much power to whom" questions at the annual utility×state×sector grain: filter or group by `data_year`, `state`, `sector` (residential / commercial / industrial / transportation), `part`, `service_type`, `ownership`, `ba_code`, `data_type`, `eia_utility_id`, or `utility_name`. Pass filters inside the `params` object. Returns JSON aggregates with citations down to the exact stacked sector/measure cell, and optional row-level records when `include_records` is true. Defaults keep totals faithful: the in-row `total` sector block is excluded unless named explicitly (it duplicates the four sectors); EIA's state-level Adjustment (99999) and Withheld (88888) sentinel rows stay in state totals but are auto-excluded from any utility-keyed query; territories are excluded unless `included_in_default_us_metrics` is false. A result mixing service types carries a `service_type_mix` note quoting the file's own law — revenue sums Parts A,B,C,D but sales/customers sum A,B,D only (Part C delivery re-counts Part B energy). History spans data years 2016–2024, one annual census per year, each its own vintage. Reach an earlier year through `as_of`, not `data_year`: `as_of` resolves to the newest census at or before it (so `as_of` 2018-06-01 — or just 2018 — returns the 2018 census) and the response echoes that resolved `as_of`. `data_year` only filters within the resolved vintage, so `data_year` 2018 under the default `as_of` (latest = 2024) returns an empty scope, not 2018; the default serves 2024, a multi-year trend is one query per year, and an `as_of` before 2016 is refused, naming the floor. Does not determine hourly or peak load (sales are billed MWh over a year — use power.demand), facility-level or data-center-specific load, county-level detail, average retail price (cents/kWh — deferred), the ~1,700 smal…
| Name | Type | Req | Description |
|---|---|---|---|
| params | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
query_robotics_adoption_v1 Query Robotics Adoption (share of plants using robots, workers exposed, robotics capex) ~738
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-…
| Name | Type | Req | Description |
|---|---|---|---|
| params | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
query_robotics_trade_v1 Query Robotics Trade (industrial-robot imports, value + robot counts) ~755
Query verified U.S. monthly IMPORTS of INDUSTRIAL ROBOTS — customs value (USD) AND unit counts (number of robots) — by country of origin, from the U.S. Census Bureau's International Trade data. Use this for "how many robots is the US importing, from whom, and what are they worth" questions — the only high-frequency official U.S. robotics series. Covers the nomenclature's two robot-specific HS-10 codes, served as the `commodity` dimension: "8479500000" (INDUSTRIAL ROBOTS, NESOI — multipurpose: welding/assembly arms, AMRs) and "8428700000" (INDUSTRIAL ROBOTS FOR LIFTING, HANDLING, LOADING OR UNLOADING — created by HS 2022; no data before 2022-01, a structural absence, never zero). Filter by `commodity`, `country` (the verbatim Census name, e.g. "JAPAN", "CHINA", "KOREA, SOUTH"), `cty_code` (the Census country code), `country_level` ("total" = the all-countries TOTAL, "country" = an individual country, "grouping" = a Census bloc/continent like ASIA / APEC / EU), `year`, `data_month` (one month, ISO first-of-month e.g. "2026-04-01") or the `data_month_from`/`data_month_to` range. Group by any of `commodity`, `country`, `cty_code`, `country_level`, `data_month`, or `year`. Pass each parameter as a top-level key of `params` (flat — not nested under a `filter`, `filters`, or `where` key). Example: `{"commodity": "8479500000", "country_level": "country", "group_by": ["country"], "order_by": "general_quantity_units", "top_n": 5}` for the top robot-supplying countries by unit count; `{"country_level": "total", "group_by": ["data_month", "commodity"]}` for the national trend per code. Returns JSON aggregates with citations and optional row-level records when `include_records` is true — every value cites the exact Census response row, re-verifiable via get_source_evidence_v1. Measures: `general_value_usd` / `consumption_value_usd` (customs value) and `general_quantity_units` / `consumption_quantity_units` (Census's "NO" unit of measure = the number of robots). NEVER SUM acro…
| Name | Type | Req | Description |
|---|---|---|---|
| params | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
query_space_satellite_filings_v1 Query Space Satellite Filings (FCC satellite licensing docket) ~746
Query the verified FCC satellite licensing docket — every space-station (SAT) filing in the FCC's own daily IBFS database dump, back to the 1960s — by applicant, application type, status, and filing date. Use this for "who is authorized to operate what in orbit, what has been filed, and where does each filing stand" questions — the satellite-buildout licensing pipeline. Each filing carries the FCC's public filing key (`file_number`, e.g. "SATLOA2025061800149"), the `callsign` (e.g. "S3069" = SpaceX Gen2), the application type and status in the FCC's OWN vocabulary — verbatim codes plus the FCC's own decode text from the same dump vintage (`app_type_code` "LOA" = Launch and Operating Authority, "STA" = Special Temporary Authority, "MOD" = Modification; `status_code` "A/C" = Action Complete, "ATPN" = Action Taken Public Notice — codebooks in describe) — the full lifecycle date family (filed / granted / expires / …), the FCC's plain-English `description` of the filing, and the applicant identity (`applicant_name`, the FCC's verbatim registrant, e.g. "Space Exploration Holdings, LLC"). Filter by `applicant_name`, `app_type_code`, `status_code`, `callsign`, `file_number`, `state` (the APPLICANT's address state), `applicant_country`, `report_period` (the filing date) via `report_period_from`/`report_period_to`, or `date_grant`/`date_expire` ranges. Group by any of `applicant_name`, `app_type_code`, `status_code`, `state`, `applicant_country`. Pass each parameter as a top-level key of `params` (flat — not nested under a `filter`, `filters`, or `where` key). Example: `{"applicant_name": "Space Exploration Holdings, LLC", "group_by": ["app_type_code"]}` for one operator's filing mix; `{"report_period_from": "2020-01-01", "group_by": ["applicant_name"], "order_by": "source_record_count", "top_n": 10}` for the most active filers of the 2020s. Returns JSON aggregates with citations and optional row-level records when `include_records` is true — every record cites its exact ro…
| Name | Type | Req | Description |
|---|---|---|---|
| params | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
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.