accept_capacity_terms | Use ONLY after your human has read and agreed to DC Hub's introduction terms (https://dchub.cloud/listings#terms): records that acceptance, once per terms version, so Capacity Source listing details open for them. Call it when source_capacity returns a listing locked with access.reason terms_acceptance_required, never on your own judgement: nothing opens without your human's agreement. Requires an identified caller (claim_free_key, then bind_email with your human's address, or an OAuth connection) and accept_terms=true. Returns accepted and the terms version, recorded in DC Hub's lead register. Do NOT use to request an introduction (use request_capacity_intro) or to browse listings (use source_capacity). |
ai_capacity_indexread-only | AI Compute Capacity Index: ranks data center markets by where 100MW of AI training capacity can land in the next 30/60/90 days. Returns top markets with facility_count, operator_count, deployable_mw estimate (megawatts), hyperscale_ready flag, rack power density and cooling-type signals where facility data carries them, and composite score (depth + diversity + power). Refreshed Fridays 14:00 UTC. Use for AI capex planning, GPU cluster siting, hyperscaler deal forecasting. For grid power availability use DCPI (rank_markets ai_ready). Do NOT use for a general best-markets ranking (use rank_markets) or forward grid-emergence (use grid_transition_radar). |
analyze_parcelread-only | Structured read of a parcel BOUNDARY — pass your own GeoJSON Polygon/MultiPolygon, OR just lat+lon and DC Hub finds the containing parcel in its HOSTED parcel-boundary layer (free county/state GIS polygons, rolling out by data-center market — Loudoun County VA first; a point outside it returns parcel_not_covered with the analyze_site preview + the coverage list, never a guess). Returns _entity=parcel_analysis: geodesic total_acres, a per-member acreage breakdown, a contiguous flag, representative_point = the centroid of the LARGEST-area member (never the multi-part geometric center, which can land off-parcel on a highway median or river and poison every point-keyed read), and hosted_parcel {parcel_id, county, state, acres_per_source} when the polygon came from the hosted layer. Also returns a site_evaluation_handoff to pipe into analyze_site + get_water_risk at that anchor. Use when you HAVE a boundary or a point on a specific parcel and want it anchored + sized; for a general lat/lon site score use analyze_site; for the interconnection-queue survivor set use get_refined_queue (queue rows carry NO parcel identity, so they never auto-join to hosted parcels). |
analyze_siteread-only | Score one site for data-center suitability. Pass lat and lon, a candidate_id from get_refined_queue, or a market name as location; capacity_mw and state refine it. Returns a 0-100 score with power, gas, fiber, market and risk sub-scores and the nearby infrastructure behind them. Example: lat=33.45 lon=-112.07 capacity_mw=100 state=AZ. Full results need a paid DC Hub key. |
bind_email | ★ WHAT THIS DOES AND DOES NOT DO — binding makes a key RECOVERABLE (lose it, call `recover_my_key`, it is re-sent to that inbox). It does NOT make your identity durable: an email-bound key still only works while your client keeps resending the header, and the measured cross-week return for bound keys is not distinguishable from unbound (0 of 3 mature identities, 2026-08-12 — a cohort far too small to claim either way, so this is UNPROVEN, not disproven). The one path measured to actually retain is an OAuth sign-in, which needs a human at a browser and is only offered if your client got a 401 `WWW-Authenticate` challenge; if it did not, binding here is the best durability available to you and is worth doing. Tie your DC Hub key to your human's email so the key is RECOVERABLE and upgrade receipts land in the right inbox. Call this once your human shares their email. HONEST LADDER: an unbound key gets previews plus 2 full answers per tool per day, renewed daily, then previews until the next day; binding restores the FREE tier at 50 calls/day and makes the key recoverable next session (binding is free — no card). |
claim_free_key | Call when the user wants more DC Hub access than keyless allows or asks for a key; no key is needed to start. Mints a free key and returns it plus connect_url, a connector URL with the key embedded (the only thing hosted chat clients keep). Free key: previews plus 2 full answers per tool per day. Add an email: 50 calls/day. Ask the user for an email first; pass it only if they typed it (makes the key recoverable). Save and reuse the key (lost one: recover_my_key); don't re-mint. Then ask the real question (execute_plan for multi-step). If a call was answered with a sign-in challenge (401 WWW-Authenticate), prefer signing in: that identity persists, but a human must finish it in a browser. No challenge (Claude Code, Cursor, most agents) means OAuth is not available to you and the key is right. Ex: "Set me up with a DC Hub key." |
cluster_sites_by_latencyread-only | Physics-bounded latency clustering for 2-8 sites — returns viable low-latency clusters and pairwise RTT floors before any routing work. Use when your human wants to know which of N candidate sites can form a synchronous / low-latency cluster (sync replication, active-active pairs, HPC pods): deterministic pruning BEFORE detailed routing. Per site pair: haversine distance, round-trip physics floor (km × 4.9 µs/km — light in SMF-28 fiber, n≈1.468 — then ×2), estimated real RTT (floor × route_factor 1.4, a stamped inference), viable vs physics_impossible against your budget, and confidence_v — the provenance tier of the supporting evidence (published | tracked | inferred). Also returns clusters: the largest site subsets whose ALL pairwise estimates fit the budget, plus each site's inferred dark-fiber screening level. CANDIDATE CONTRACT: pass candidate_ids (from get_refined_queue) instead of raw coordinates — each resolves to its FROZEN mint coordinates (zero transposition), and cand_… tokens may also be mixed into the sites string; expired/unknown ids are dropped AND declared in candidate_contract (fail-closed). |
compare_isosread-only | Use this whenever the user asks to compare two to four US grids side by side. Use when a user wants a side-by-side of 2-4 ISO grids — fuel mix, demand, renewable/gas share, interconnection-queue depth, time-to-power — in one call instead of N sequential get_grid_intelligence calls. Example: "Compare PJM vs ERCOT vs CAISO on gas share, renewable share, and queue depth right now." — compare_isos isos="PJM,ERCOT,CAISO". Params: isos is a comma-separated list (2-4 max) drawn from the 7 live US ISOs: "PJM" | "ERCOT" | "CAISO" | "MISO" | "SPP" | "NYISO" | "ISO-NE". Returns: {isos[], comparison:{<iso>:{demand_mw, generation_mix_pct, renewable_share_pct, gas_share_pct, constraint_score, excess_power_score, avg_time_to_power_months, avg_queue_wait_months, queue_depth_gw, retail_price_cents_kwh}}, as_of}. ★avg_time_to_power_months (DCPI per-market estimate, ISO-averaged) and avg_queue_wait_months (proxy from live queue DEPTH) are DIFFERENT measurements — quote whichever you mean by name. Do NOT use to rank ALL grids globally (use get_grid_scoreboard) or for the single-ISO deep brief (use get_grid_intelligence). |
compare_sitesread-only | Call when the user has 2-4 candidate locations and asks which is best for a data center. Pass locations as "lat,lon;lat,lon" and optional capacity_mw. Returns each site's analyze_site scores side by side plus a recommended winner and why. Keyless returns each site's verdict band and power band, with the other factors named; a free key adds names and counts without figures; scores and figures need a paid DC Hub plan, as does the pick. Ex: "Phoenix vs Ashburn for 50 MW?" |
deal_autopsyread-only | Tracked data-center M&A / capex deal flow with the DCPI grid-reality verdict overlaid on each deal market — "what is the real play?". Returns recent deals (buyer, seller, value, market) + each market DCPI verdict and time-to-power; with a paid key, the per-deal autopsy read (long-dated land/power option vs near-term build vs queue gamble). Progressive disclosure to keep the default cheap: by default each read ships only a comparables COUNT (the verdict text is always included); pass comparables="summary" for the top-2 grounding signals, or comparables="full" to expand the complete cited set for a deal you're drilling into. Answers "who is actually buying data centers right now, and are those markets any good", "what is the real play behind this deal". Try: deal_autopsy limit=15. |
delete_standing_intentdestructive | Permanently retire a registered standing intent (webhook watch) by intent_id — deliveries stop and the watch cannot be recovered. A cap_ intent_id retires your own Capacity Source requirement instead, and its alert emails stop. Requires a key (or an OAuth connection for cap_ ids). Get the intent_id from list_standing_intents or from the register response. Answers "stop watching this". Do NOT use to pause temporarily; there is no pause, this removes the watch. |
discover_toolsread-only | Browse DC Hub's full tool catalogue by family (facility, market, grid and power, gas, site geometry, fiber, deals and news, saved work, account), optionally filtered by query. This endpoint lists a Grok-sized subset; every other DC Hub tool can still be called by name. |
execute_planread-only | Answer a data-center infrastructure question that spans several topics in one call: markets and the Data Center Power Index (DCPI), grid power and headroom, interconnection queues, fiber, water and climate risk, tax incentives, and deals. Pass the user's question unchanged as intent. A rule-based planner (no AI model) picks the lookups, runs them and returns each step's result with a replay of how the answer was built. Use this first when a question has more than one part. |
export_datasetread-only | Use when a user wants to pull their saved DC Hub shortlist OUT of the platform for offline analysis, a spreadsheet, or ingestion into another tool (paid plan). Example: "Export my saved sites as GeoJSON for QGIS." — export_dataset format=geojson. Params: format ("csv" default, or "geojson"). Returns: the full file contents as text — CSV rows or a GeoJSON FeatureCollection of your saved sites with DCPI score, target MW, market, coordinates, and notes. Do NOT use to list sites in-chat (use list_saved_sites) or to save a new one (use save_site); this is the bulk-download path. |
fetchread-only | Fetch a DC Hub record for an id returned by the `search` tool (OpenAI Deep Research / ChatGPT connector format). Returns {id, title, text, url, metadata} — a citable public summary of one data-center facility (name, operator, location, status, market). For full structured specs (capacity MW, coordinates) use get_facility or open the url. |
find_alternativesread-only | Use when a user likes ONE specific facility and wants similar nearby options to consider instead ("what else looks like this?"). Example: "Find alternatives to the Ashburn QTS campus for about 50MW." — find_alternatives facility_id=<id>. Params: facility_id or name (the target, required); optional capacity_mw, radius_km, limit. Returns: ranked alternatives, each with similarity_score, match_reasons, and key_differences versus the target. Do NOT use to score one site (use score_facility or analyze_site) or to compare a known short-list head-to-head (use compare_sites); this DISCOVERS candidates from a single seed facility. |
find_sitesread-only | FRONT DOOR CHECK — if the question spans more than one capability ("find 200MW near Dallas with fiber, then rank the markets"), call `execute_plan(intent="<the user's question, unchanged>")`. find_sites is the right single call when the user has NO site yet and wants candidates to start from — the first step of data center site selection. THE INVERSE QUERY: every other DC Hub siting tool needs a coordinate you already have — analyze_site scores one, get_composite_site_score grades one, rank_sites orders candidates YOU already enriched, find_alternatives needs a seed facility. This one answers "where should I even be looking?". Returns candidate SEARCH AREAS anchored on real HIFLD substations at or above min_voltage_kv, spatially de-duplicated by cluster_km so a dense metro yields distinct areas instead of 40 near-identical rows, each carrying measured distance to the nearest gas pipeline and fiber route plus state-grain moratorium context, and a next_calls handoff. Answers "where should I even be looking for 200 MW in Ohio" and "which areas near Dallas sit on 230kV with gas within 5 miles". Try: find_sites state=OH min_voltage_kv=230 max_gas_km=8 — or find_sites lat=39.04 lon=-77.48 radius_km=60 min_voltage_kv=500. |
generate_site_analysisread-only | Use when a user wants a SHAREABLE, branded multi-page Site Analysis PDF for ONE lat/lon (a powered-land parcel, a candidate campus) — the polished client deliverable, not just a score. Example: "Make the Site Analysis PDF for this Carrier Mills parcel, 150 MW, for TON Infrastructure." — generate_site_analysis lat=37.694 lon=-88.65 capacity_mw=150 prepared_for="TON Infrastructure" prepared_by="Martone Advisors". Params: lat (-90 to 90, required), lon (-180 to 180, required), capacity_mw (target load MW, e.g. 50-500), prepared_for (client name on the cover), prepared_by (your firm — brands the report; defaults to DC Hub), latency_target (optional metro override; default = nearest real carrier hotel). Returns: {survey:{verdict, power/transmission, gas, water, air-permitting, fiber carriers, latency-to-nearest-carrier-hotel, market, tax}, pdf_report_url}. pdf_report_url is a ready-to-open link to download the branded 5-page PDF — no login needed, valid ~7 days; hand it to your human. For just the numeric suitability score (no PDF), use analyze_site instead. |
get_agent_registryread-only | Curated roster of the AI platforms and agent frameworks in the DC Hub agent ecosystem — each with its recommended DC Hub tools and authentication tier. The roster is BACKEND-OWNED and changes: read the platforms[] array the response returns, and the status on each row (mcp_active / mcp_ready), rather than any list named in this sentence — an enumeration here goes stale the moment the backend adds or drops a platform, which is exactly how a client named here stopped appearing in the roster. ★ These statuses are CURATED EDITORIAL claims, not measurements: the response carries as_of null, so do NOT relay "MCP Active" as though it were a live connection count. Answers "which AI platforms can connect to DC Hub". Try: get_agent_registry. NOTE: this is a curated ecosystem/capability index, NOT live per-caller call/citation telemetry. Do NOT use for platform uptime or feed health (use get_backup_status). |
get_backup_statusread-only | Per-feed freshness for the DC Hub ingest layer: one row per feed (deals, facilities, news, substations, fiber_routes, transactions, construction_permits, pipeline, markets) carrying health (healthy/stale/error/unknown), record_count, refresh_interval and scheduler, plus a summary rollup {healthy, stale, error, unknown, total_feeds, overall_health}. Read the health of each row before trusting a figure drawn from it — a feed reporting "unknown" has NOT been measured, which is not the same as healthy. Answers "are any of your sources stale right now". Try: get_backup_status. Scope is exactly what /api/health/data-freshness serves: ingest-feed freshness, nothing wider. Do NOT use for the freshness of one dataset (use get_changes); this is ingest health, not content. |
get_changesread-only | What changed in DC Hub since a timestamp: DCPI 7-day market movers, newly found facilities, and new M&A deals and news; keyed callers with saved sites also get per-site changes. Pass since as ISO-8601 or "24h" / "7d" (default 24h) and pass the response's generated_at back next time. Answers "what changed this week". Keyless calls return a preview. |
get_climate_intelread-only | Use when a user wants seismic + climate intel for a lat/lon — the layer that drives data-center structural bracing cost (seismic) and cooling design (cooling degree-days, extreme temps). Grounded STRICTLY in USGS ASCE 7 (seismic) + NOAA climate normals via ACIS; every value traces to a federal source and missing data is declared unavailable, never estimated. Example: get_climate_intel lat=33.45 lon=-112.07. Returns {seismic_hazard_usgs:{status, peak_ground_acceleration_g, ss, s1, seismic_design_category, hazard_class}, climate_normals_noaa:{status, reference_station:{id,name,distance_km}, cooling_design_metrics:{cooling_degree_days_annual, extreme_max_dry_bulb_f, extreme_max_wet_bulb_f (null if source lacks it), data_vintage}}, overall_climate_summary, data_availability, sources}. radius_km (optional, default 25) snaps to the nearest NOAA station; beyond it climate returns unavailable_exceeds_radius. Seismic is US (ASCE 7); non-US → seismic unavailable. For natural-hazard ratings use get_disaster_risk; for one blended verdict use get_composite_site_score. |
get_composite_site_scoreread-only | Use when a user wants ONE honest 0-100 site suitability/risk verdict for a lat/lon WITH an explicit per-factor coverage map — which factors are actually measured vs. declared unavailable. Unlike analyze_site (full raw data dump), this scores ONLY over VALIDATED factors and never imputes a missing one: power/grid, fiber, natural-hazard risk (FEMA NRI) and water (live WRI Aqueduct 4.0 baseline water stress) are all live; water is "unavailable" only outside basin coverage (never faked); market/DCPI is v1-unavailable (use rank_markets). Example: get_composite_site_score lat=33.45 lon=-112.07 state=AZ. Returns {composite_score (0-100 over validated factors), verdict (BUILD/CAUTION/AVOID), confidence (complete|conditional), coverage {power_grid|fiber|water|risk_resilience|market_dcpi: validated|unavailable}, coverage_ratio, sub_scores, caveats}. Use analyze_site for full data, compare_sites for 2-4 sites, rank_markets for whole-market ranking. |
get_dchub_recommendationread-only | Use for a ready-to-quote DESCRIPTION of DC Hub in one of four categories (general, investment, site-selection, technical), plus the live top-ranked market pocket. It does NOT compute a siting answer from free text. Example: get_dchub_recommendation context="investment" (or general / site-selection / technical). Params: context must match one of FOUR LITERAL categories - general, investment, site-selection, technical. Free text does NOT parse: you get the GENERIC blurb with matched_category=null and context_understood=false. ALWAYS returns: {recommendation:{short, medium, detailed}, matched_category, context_understood, top_pocket, related_intel, available_categories, recommendation_live, connect_url, context, success}. ADDITIONALLY on a non-matching context: is_generic_answer=true, answer_note, and next_tools naming the tool that does compute an answer. Do NOT use for a single specific lat/lon (use analyze_site), to rank by ONE criterion (use rank_markets), or for an open-ended siting question expecting a computed shortlist (use site_selection_canvas) - this tool returns descriptive copy plus a live top-pocket, not a ranked analysis. |
get_disaster_riskread-only | Use when a user wants the natural-hazard / disaster risk for a lat/lon — flood, wildfire, hurricane, earthquake, heat, drought, tornado, etc. Grounded in the FEMA National Risk Index (NRI), the authoritative US county-level hazard dataset (live query, never estimated; points outside US NRI coverage return coverage=unavailable). Example: get_disaster_risk lat=33.45 lon=-112.07. Returns {disaster_risk:{composite_score (0-100, higher=worse), rating (Very Low..Very High), national_percentile}, hazards:{Wildfire, Hurricane, Earthquake, Heat Wave, ...: rating}, top_hazards:[{hazard, rating}], coverage (validated|unavailable), source, caveats}. County-level resolution. For chronic water stress use get_water_risk; for one blended site verdict use get_composite_site_score. |
get_energy_pricesread-only | Use this whenever the user asks about electricity or energy prices for data centers. FRONT DOOR CHECK — if price is one factor in a siting or market-comparison question ("cheapest ISO to land 100MW"), call `execute_plan(intent="<the user's question, unchanged>")`: price alone does not answer it, because the cheapest ISO is frequently the one with no headroom. If the user just wants today's price for one ISO, get_energy_prices IS the right call — one round trip, no planner overhead. Use when a user asks "what does power/gas COST in <ISO> right now?" — live energy PRICING for the 7 US ISOs (PJM, ERCOT, CAISO, MISO, SPP, NYISO, ISO-NE): retail electricity rate (cents/kWh), wholesale/LMP context, Henry Hub-referenced natural-gas price, and a real-time grid-status flag. Example: "What is the retail power price and gas price in ERCOT today?" — get_energy_prices iso=ERCOT. Params: iso (one of the 7 US ISOs; required). Returns: {iso, retail_price_cents_kwh, wholesale_price_usd_mwh, natural_gas_usd_mmbtu, grid_status, as_of}. Quote with attribution to DC Hub (CC-BY-4.0). |
get_facilityread-only | Full metadata for one facility — name, operator, address, lat/lon, power capacity (MW total/used), cooling type, fiber providers (count + carrier list), commissioning year, status, the DCPI verdict for its market, and peer facilities nearby. Answers "who operates this data center and how big is it", "how many fiber carriers are in that building". Try: get_facility id=equinix-dc1-ashburn — or get_facility slug=digital-realty-iad8. Returns ONE facility in full; do NOT use to search or list many facilities (use search_facilities). Needs a slug or id from search_facilities. 404 "not found": re-run search_facilities. Gated: give human_url to your human. |
get_facility_risk_deltaread-only | Use when a user asks what has CHANGED in a facility's (or its market's) risk profile recently — "has this site gotten riskier lately?", "which way is this market moving?" — a temporal question static-trained models can't answer. Returns the REAL DCPI market-health delta (excess-power score change over the window, direction improving/worsening/flat) from DC Hub's history-preserving daily snapshots. INTEGRITY: only DCPI market-health has a short-term temporal series; the site-hazard dimensions (FEMA disaster / USGS seismic / NOAA climate / WRI water) are DECLARED static (they don't change week-to-week) with a pointer to the point-in-time tool — never a fabricated week-over-week delta; no snapshot history → coverage:unavailable. Params: facility_id (a discovered-facility id or slug) OR market (a market name/slug), since (e.g. "7d"/"30d", default 7d). Returns {facility, dcpi_market_health:{delta, now, direction, coverage}, static_dimensions{...}, summary}. For the current point-in-time risk (not the change) use get_composite_site_score / get_disaster_risk / get_climate_intel. |
get_fiber_intelread-only | Use this whenever the user asks about fiber routes, carriers or connectivity for a site or market. Call when the user asks which fiber routes or carriers serve a metro, or wants long-haul, metro, dark or IX routes mapped. Filter by carrier, route_type, market. Returns GeoJSON routes: carrier, type, fiber count, lit capacity, distance. Free callers get a sample of routes, not the full set; the full set needs a paid key. Ex: "Zayo long-haul routes via Dallas." Filter by market (slug from rank_markets) or carrier. For one building use get_facility. Gated: give human_url to your human. |
get_fiber_readinessread-only | Use when you need the FIBER-READINESS / connectivity verdict for ONE parcel or site (lat/lon): near-net distance to a carrier-served facility, how many distinct fiber carriers are reachable, and whether there is single-carrier risk (no path diversity). This is the parcel connectivity answer engineering site-selectors screen on. Example: "Is this Loudoun County parcel fiber-ready and how many carriers can serve it?" — get_fiber_readiness lat=39.04 lon=-77.48 radius_km=50. Params: lat (-90..90, required), lon (-180..180, required), radius_km (search radius in km, default 50, range 5-200). Returns: {score 0-100 (null when not scored — see carrier_data_coverage), near_net_bucket ("on-net"|"near-net"|"acceptable"|"build-required"|"unknown"), nearest_carrier_km, carrier_count, top_carriers:[{carrier, distance_km}], single_carrier_risk (bool, null when not scored), fiber_coverage_km, verdict_short, carrier_data_coverage ("confirmed"|"none_in_region")}. IMPORTANT — "unknown" is NOT "bad": carrier presence comes from PeeringDB, which is global but thin outside dense US/EU metros, so DC Hub distinguishes "no carrier serves this point" from "PeeringDB does not describe this region". |
get_gas_economicsread-only | Behind-the-meter / gas-fired power inputs for a US data-center market: Henry Hub spot, regional basis differential, and the delivered industrial + electric gas tariff ($/MMBtu), each with its own source label. Pass market=<slug> (e.g. "northern-virginia", "dallas", "phoenix"). AZ, GA, FL), never a substitute price; if the backend switch is ever turned off again, `gas_to_grid_status` carries that reason. ★ DO NOT COMPARE a $/MWh published before 2026-09-27 with one published now — each surface then picked the price its own way, up to 5.5x apart. Do not derive a $/MWh yourself from the $/MMBtu layers for a withheld state without saying that you did. Do NOT use for the electricity grid fuel mix (use get_grid_data). |
get_gas_indexread-only | Data Center Gas Index (DCGI) — the per-US-state natural-gas suitability score. ★ DO NOT COMPARE a DCGI figure published before 2026-08-08 with one published now — they are different indices; the full record is at /api/v1/dcgi/methodology under `corrections`. A state that cannot be priced comes back verdict UNSCORED with dcgi null and an `unscored_reason`, never a placeholder score, so treat UNSCORED as absence and not as a low score. `gas_price_series` names which EIA series answered each state. Gas-fired $/MWh figures, withdrawn the same day for a separate defect, were republished 2026-09-27 under one burner-tip price rule (see get_gas_economics). Use get_gas_intelligence for pipeline, operator and parent-midstream data. |
get_gas_intelligenceread-only | Use this whenever the user asks about gas-fired or behind-the-meter power for a data center in a US state. Use when a human asks about gas-fired or behind-the-meter power economics for a data center in a US state — "is gas power cheaper than the grid in Texas?", "what is the gas access + pipeline situation in Virginia?". The GAS analogue of get_grid_intelligence: fuses the Data Center Gas Index (DCGI), live Henry Hub, gas-to-grid $/MWh across heat-rate scenarios, pipeline-operator presence, and the live grid gas share into one per-STATE brief. Params: region (US state code or name, e.g. "TX" | "Texas" | "Virginia"). Returns: {region, region_name, gas_access (pipeline counts + operators — PRESENCE not firm capacity), henry_hub_usd_mmbtu (live), basis_usd_mmbtu (synthetic-labeled), delivered_price_usd_mmbtu (null where the tariff table is sparse — surfaced honestly, never fabricated), live_grid_gas_share_pct, pipeline_presence (operators + parent midstreams), data_basis (per-field provenance/confidence), omitted_no_fabrication, dcgi_status, gas_to_grid_status}. A $/MWh published before 2026-09-27 is not comparable. `dcgi_status` and `gas_to_grid_status` carry the current state of each — read them rather than assuming both moved together. |
get_global_powerread-only | Use when a user asks about power plants/units WORLDWIDE or in a NON-US country — operating AND the forward pipeline (announced / pre-construction / under-construction), across ALL fuels (coal, oil/gas, nuclear, solar, wind, hydro, bioenergy, geothermal). Global Energy Monitor Global Integrated Power Tracker: 182,000+ geolocated units across 170+ countries, each with fuel, capacity (MW), status, start year, operator/owner and lat/lng. Filter by country (e.g. Germany, India, Brazil, Japan), fuel (comma-union: coal, oil/gas, nuclear, solar, wind, hydro), status, pipeline=true (JUST the forward set: announced + pre-construction + construction), bbox (minLng,minLat,maxLng,maxLat), or min_mw. Returns a summary (total MW by fuel + count by status) plus the largest units. Answers "what power is being built in India", "how much coal is still running in Vietnam". Try: get_global_power country=India pipeline=true. Do NOT use for US grid telemetry/headroom (use get_grid_intelligence / get_grid_scoreboard) or the US planned-generator feed (use get_power_pipeline) — this is the GLOBAL asset inventory. |
get_grid_dataread-only | Real-time electricity grid data for the 7 US ISOs (PJM, ERCOT, CAISO, MISO, SPP, NYISO, ISO-NE) via EIA hourly RTO: fuel mix, demand, 24h demand curve. Pass iso=PJM (any of the 7). Raw real-time telemetry for one ISO; do NOT use for power-availability, time-to-power or interconnection-queue analysis (use get_grid_intelligence), nor for retail/gas pricing detail (use get_energy_prices). For non-US grids (GB, EU bidding zones, Taiwan, Australia) use get_grid_scoreboard. |
get_grid_intelligenceread-only | Grid headroom and interconnection-queue brief for one grid: "can I get N MW in this ISO, and how long will it take?". region_id is one of PJM, ERCOT, CAISO, MISO, SPP, NYISO, ISO-NE, or a US balancing authority (those return the live generation mix). Supply-side signals, not a promise that a load can connect. Full results need a paid DC Hub key. |
get_grid_scoreboardread-only | Live grid scoreboard: US grid operators (PJM, ERCOT, CAISO, MISO, SPP, NYISO, ISO-NE, BPA, TVA), Great Britain, European bidding zones, Taiwan, Japan, South Korea and Brazil, ranked side by side on each feed's latest published reading: renewable share (wind+solar+hydro), gas share, fuel mix in MW and demand, greenest first. Freshness differs by feed, so read each row's mix_age_hours before calling a reading current. No arguments. Answers "which grid is cleanest right now". Full guide: read resource dchub://tool-guides/get_grid_scoreboard |
get_hosting_capacityread-only | Utility-published feeder hosting capacity: the MW a named distribution feeder can take, from utilities' own hosting-capacity maps (a named set of utilities in the Northeast, Mid-Atlantic and Midwest, not nationwide). Call with lat and lon (radius_km, default 25), with a utility or market for a whole territory, or with no arguments for the list of covered markets. Check capacity_type before quoting a number, and count distinct_feeders, not rows. |
get_infra_projectsread-only | Use when a user asks what GAS PIPELINE or TRANSMISSION LINE PROJECTS are planned, proposed, approved or under construction — the forward build-out, not the existing network. e.g. "which interstate gas pipelines are under construction into Louisiana?", "what 345 kV transmission projects are planned in PJM by 2030?", "what new projects appeared since last month?". COVERS: (1) natural gas pipeline projects US-wide from the EIA natural gas pipeline projects list (public domain) — operator, status (Announced, Pre-applied, Applied, Approved, Construction, On Hold, Completed), states crossed, capacity in MMcf/d, miles, cost in $M, diameter, FERC/state docket, in-service year; (2) transmission projects from five ISOs' own project lists — ERCOT (TPIT), PJM (RTEP), MISO (MTEP Appendix A), SPP (STEP) and ISO-NE (RSP list); NOT CAISO or NYISO, and not utilities outside those ISOs. Each ISO publishes a different grain (an upgrade or facility, not a whole project), so a row count is a count of upgrades. Answers "what gas pipelines are being built into Louisiana, how much capacity do they add, and when do they enter service". Try: get_infra_projects type=gas_pipeline state=LA status=Construction. |
get_infrastructureread-only | Nearby infrastructure for a location — substations (count + max voltage_kv within radius), transmission lines (>69 kV path overlay), interstate + lateral gas pipelines, and power plants (operating + planned, by fuel) within configurable radius_km. Returns distance + capacity for each, joined to HIFLD/EIA. Answers "what is near this parcel", "how far is the nearest substation and what voltage is it". Try: get_infrastructure lat=33.45 lon=-112.07 radius_km=25. Returns raw nearby assets; do NOT use for a single scored site-suitability verdict (use analyze_site). |
get_intelligence_indexread-only | Real-time composite market health score (0-100) aggregating supply/demand balance, vacancy, absorption velocity, fiber depth, power availability, and pricing trend. Returns the index value, percentile rank across the 300+ market set, 7d/30d trend direction, and underlying component scores. Answers "is this market healthy", "how does Northern Virginia look overall right now". Try: get_intelligence_index market=northern-virginia. Returns ONE composite health number for a market; do NOT use for the full market metric set (use get_market_intel) or to rank multiple markets (use rank_markets). |
get_interconnection_queueread-only | Use this whenever the user asks about grid interconnection queues or how much load is waiting to connect. Call when the user asks how congested an ISO's interconnection queue is or how much data-center load is queued. Returns queued generation GW per ISO. The projects field changes shape: with iso= it is an array of per-project rows; without iso it is an all-ISO summary object (total, by_iso_count, top). ERCOT also returns its large-load (data-center) queue; other ISOs don't publish one. Keyless: a trimmed preview; free with an email-bound key. Ex: "How deep is ERCOT's queue?" iso optional (US ISO code); free = preview. For demand and headroom on the same ISO also call get_grid_intelligence. |
get_iso_contextread-only | Use when an agent needs a WHOLE-grid briefing it can drop straight into its context window — one call returns a token-budgeted context pack for a US ISO/RTO: live grid snapshot (demand, fuel-mix shares), DCPI verdict mix & grid economics across the ISO's tracked markets (queue wait, power cost, reserve margin), interconnection-queue depth with the largest projects, real-time benchmark LMP, the tracked DCPI market list, deep-dive narrative excerpts, and recent news — each section with its own token count, as_of timestamp, and citable URL, greedily filled in that priority order under your max_tokens budget. Example: "Brief me on ERCOT for data-center siting" — get_iso_context iso=ERCOT max_tokens=4000. Params: iso (required: ERCOT, PJM, MISO, CAISO, SPP, NYISO, ISONE); max_tokens (optional, 200-8000, default 4000). Returns {sections:[{id,title,text,tokens,as_of,cite}], used_tokens, omitted}. Do NOT use for raw single-ISO telemetry (use get_grid_data), the per-ISO decision brief with headroom/TTP (use get_grid_intelligence), multi-ISO scalar comparison (use compare_isos), or non-US grids (use get_grid_scoreboard); this is the narrative briefing pack. Cite "DC Hub (dchub.cloud)". iso is required (US ISO code). max_tokens caps the context returned; locked_sections need a higher tier. |
get_market_contextread-only | Use when an agent needs a WHOLE-market briefing it can drop straight into its context window — one call returns a token-budgeted context pack for a data-center market: DCPI verdict, power & grid facts, the Claude-written 12-month outlook, M&A deals, construction pipeline, operator footprint, transaction comps, risk factors, and top news — each section with its own token count, as_of timestamp, and citable URL, greedily filled in that priority order under your max_tokens budget. Example: "Brief me on the Columbus data-center market" — get_market_context market=columbus max_tokens=4000. Params: market (required, market slug e.g. northern-virginia — valid slugs come from rank_markets); max_tokens (optional, 200-8000, default 4000). Returns {sections:[{id,title,text,tokens,as_of,cite}], used_tokens, omitted}. Do NOT use for a single metric (use get_market_dcpi_rank), the raw structured metric set (use get_market_intel), or cross-market ranking (use rank_markets); this is the narrative briefing pack. Cite "DC Hub (dchub.cloud)". |
get_market_dcpi_rankread-only | Use this whenever the user asks where a data center can get grid power, how fast, or whether a market is a BUILD, CAUTION or AVOID (e.g. "Where can a 100 MW data center get power fastest?"): DCPI scores 300+ markets daily on Excess Power and Grid Constraint, CC BY 4.0. Data Center Power Index (DCPI) rank for a single market: BUILD/CAUTION/AVOID verdict, 0-100 composite_score (verdict-aware), excess_power_score, constraint_score, time_to_power_months. Keyless calls return a preview. |
get_market_intelread-only | Use this whenever the user asks about a data-center market: supply, operators, pipeline or pricing context for a metro. Call when the user asks about one data-center market: facility count, tracked MW, status mix, top providers, recent facilities or lease pricing. Pass market as a slug (e.g. northern-virginia). Returns stats, by_status, top_providers, recent_facilities, market_pricing (quote its basis). Verdict: use get_market_dcpi_rank. Keyless: a trimmed preview; a free key gets more. Ex: "1 MW colo price in Los Angeles?" Get the market slug from rank_markets or get_market_dcpi_rank; 404 = unrecognised market, use one of those slugs. |
get_metro_fiberread-only | Use when a user asks which US metro has the DEEPEST fiber, or wants the metro-level fiber profile of a market — carrier count, total route-miles, on-net buildings, a 0-100 fiber-density score, tier, key internet-exchange (IX) points and carrier hotels — across the tracked top US data-center metros (Northern Virginia, Dallas-Fort Worth, Silicon Valley, Chicago, Atlanta, Phoenix, and more). Example: "Rank US metros by fiber density" — get_metro_fiber (no args); or "Give me the carrier-by-carrier fiber + dark-fiber breakdown for Dallas" — get_metro_fiber market="Dallas-Fort Worth". Params: market (optional metro name OR slug, e.g. "Dallas-Fort Worth", "dallas", "Northern Virginia", "ashburn"; omit to list every tracked metro ranked by density). Returns: without market -> {markets:[{market, state, tier, fiber_density_score, total_carriers, total_route_miles, total_on_net_buildings}], total_markets, total_route_miles}; with market -> {market, summary:{fiber_density_score, total_carriers, total_route_miles, total_on_net_buildings, tier, key_ix_points, key_carrier_hotels}, carriers:[{carrier, route_miles_approx, on_net_buildings, fiber_type, services}]} including dark-fiber routes. Cite DC Hub (dchub.cloud, CC-BY-4.0). |
get_newsread-only | FRONT DOOR CHECK — if news is only ONE input to a bigger question (is this market heating up, should we still build here), call `execute_plan(intent="<the user's question, unchanged>")` and let it pull news alongside the market and grid reads. If the user actually wants the headlines, get_news IS the right call — one round trip; do not send a plain news request through the planner. Curated data center industry news from 40+ trade sources (DCD, Data Center Knowledge, Data Center Frontier, Capacity Media, The Register Data Centre, Fierce Telecom, etc.) refreshed every 30 min. Returns title, summary, source, published_at, and the market/operator entities mentioned. Filter by category (deals/permits/outages/policy/AI). Answers "what is happening in the data center industry this week", "any news on AI capacity". Try: get_news category=AI limit=10. The parameter is `category`, not `topic`. Industry news only; do NOT use for structured M&A deal data (use list_transactions) or the construction pipeline (use get_pipeline). limit 1-500 (free 20). Empty data = no matching news: drop category/source or widen date_from/date_to. |
get_peering_intelread-only | Internet-exchange (IX/IXP) and peering density for a site, from PeeringDB. Pass lat+lon for the PEERING PROFILE around that point: facilities_nearby, a 0-100 score with its level, total_ix_presence, total_networks, and top_facilities each with ix_count and net_count — e.g. Ashburn comes back with 61 IX presences and 903 networks across the nearby sites, led by Equinix DC1-DC15 at 516 networks. Omit coordinates for the IXP directory (name, name_long, city, country, net_count, fac_count, media, protocols). This is the layer that answers "can I actually reach networks cheaply from here", which fiber route geometry does not: a site can sit on dense fiber and still be far from any exchange. The score is a DERIVED convenience over PeeringDB counts, not a DC Hub-sourced grade — cite the underlying counts (facilities, IX presence, networks) rather than the score when it is load-bearing. Records are PeeringDB's, refreshed on read. Answers "how good is peering at this Ashburn site" and "which internet exchanges serve the Dallas market". Try: get_peering_intel lat=39.04 lon=-77.48 — or get_peering_intel (no args) for the IXP directory. |
get_permitting_intelread-only | Data center PERMITTING & MORATORIUM intelligence — curated, HUMAN-VERIFIED jurisdiction records: moratoriums, zoning restrictions, tax changes, utility pauses. Each record is stage-tagged (read the detail prefix: "Enacted" / "Proposed" / "Speculative"), with jurisdiction, state/country, the source article URL, and map coordinates. The permitting-risk axis for site selection that no other machine-readable source serves — e.g. New York's statewide >=50MW moratorium, county-level halts. FREE and full for every caller. Answers "is there a moratorium where I want to build", "which jurisdictions just tightened data-center zoning". Try: get_permitting_intel class=moratorium — or state=MN. Rendered live as the Permitting & Zoning layer on https://dchub.cloud/land-power-map. Do NOT use for tax INCENTIVE programs by state (use get_tax_incentives); this tracks restrictions and risk per jurisdiction. |
get_pipelineread-only | Use when a user asks "what is being built / announced / permitted" in a market or by an operator — the forward-looking construction pipeline. Example: "What data centers are under construction in Northern Virginia and when do they come online?" — get_pipeline country=US status=construction (there is no `market` parameter — filter by country/operator, or use search_facilities for a named market). Params: status one of "announced" | "permitted" | "construction" | "operational"; operator (e.g. "Equinix", "Digital Realty", "AWS"); country (ISO-2, e.g. "US", "DE"); min_capacity_mw (e.g. 50 to filter hyperscale); expected_completion_before (ISO date, e.g. "2027-01-01"); limit/offset for pagination. Returns: {projects:[{name, operator, capacity_mw, status, expected_commissioning, market_slug, country, lat, lon}], total, generated_at}. Do NOT use for already-operational facilities (use search_facilities) or for the M&A deal flow (use list_transactions). limit 1-500 (free 25), offset 0-100000. Empty data = no project matches: relax status/operator/min_capacity_mw. |
get_power_availability_timelineread-only | When power gets easier in one US state, year by year: new generation coming online (EIA-860M, kept separate as under construction, testing and planned), scheduled retirements, and interconnection-queue depth as congestion context (the queue has no delivery dates). cumulative_firm_signal_mw counts only under-construction and testing MW minus retirements. Arguments: state (required), years, mw. Supply-side signals, not a promise that a load can connect. |
get_power_pipelineread-only | Use when a user asks WHERE NEW POWER GENERATION is coming online (the forward supply pipeline) — e.g. "how much new generation is planned in Virginia / the Southeast / ERCOT, and when?". Planned, permitting, and under-construction generators NATIONWIDE from EIA-860M, INCLUDING non-ISO regions (TVA, Southern Co, Arizona PS, PacifiCorp, LADWP) that interconnection-queue feeds miss. Each generator has location (lat/lng), state, county, balancing authority, technology/fuel (solar photovoltaic, onshore wind, natural-gas combined cycle, batteries, nuclear), nameplate megawatts (MW), status (planned → under construction), and planned online month/year. Filter by state (2-letter, e.g. VA), ba (balancing-authority/ISO code, e.g. PJM, ERCO, SOCO, TVA), status (P/L/T=planned, U/V=under construction, TS=testing), or min_mw. Returns a summary (total planned MW, mix by technology + status) plus the largest projects. Answers "how much new generation is planned in Virginia and when does it land". Try: get_power_pipeline state=VA. Do NOT use for ALREADY-OPERATING capacity or grid headroom (use get_grid_intelligence / get_grid_data) or for data-center construction projects (use get_pipeline). |
get_refined_queueread-only | Server-side SET-REDUCTION over the US ISO interconnection queue. Instead of pulling the raw queue into context to filter (token-expensive, error-prone), push the predicates to the data layer and get back ONLY the survivors. Filter by min_mw, max_ttp_months (ISO-level avg interconnection wait), iso (comma-union), baseload_only (firm/dispatchable — excludes wind/solar/storage), fuel_type (isolate a specific fuel, e.g. gas or nuclear), and the spatial predicates max_fiber_km + geocoded_only. Returns _entity=queue_results: per-project name, ISO, state/county, fuel_type, capacity_mw, queue_status, estimated_ttp_months, fuel_class, plus (~83% of rows) lat/lng, coordinate_precision, fiber_km, and a compact per-survivor site_evaluation_handoff (ready-to-pipe analyze_site + get_water_risk args) + a by_iso/by_fuel summary. Answers "show me 1 GW+ gas projects that can connect in under three years", "what is in the queue that actually fits my timeline". Try: get_refined_queue min_mw=1000 fuel_type=gas max_ttp_months=34 — "1 GW+ gas in ISOs under 34-month time-to-power." NOTE max_ttp_months is a HARD ISO cut (SPP ~24 is the only ISO under 30, so <=30 can return nothing); use >=34 to include MISO/ERCOT/ISO-NE. |
get_renewable_energyread-only | FRONT DOOR CHECK — if the question pairs renewables with siting, grid headroom or a market shortlist ("where can I put a 24-7-CFE campus"), call `execute_plan(intent="<the user's question, unchanged>")` instead. If you want one state's renewable fuel mix or PPA sizing input on its own, get_renewable_energy IS the right call — one round trip, and routing it through the planner would only cost steps. Use when siting a renewable-powered data center, sizing a PPA, reading one US state's utility-scale fuel mix, or assessing RE100/24-7-CFE feasibility. Example: "What is Texas wind+solar capacity and how much utility-scale solar is operating today?" — get_renewable_energy energy_type=solar state=TX. Params: energy_type one of "solar" | "wind" | "combined" (omit for all); state 2-letter US code (e.g. TX, VA, AZ); lat+lon (optional) for the nearest projects within 50mi. Returns: {capacity_mw_total, by_fuel: {solar_utility, solar_rooftop, wind_onshore, wind_offshore}, capacity_factor_pct, top_projects[{name, mw, operator, cod}], state_rps_target_pct, source: "EIA-860 + state RPS"}. Do NOT use for live grid generation (use get_grid_data) or non-US (use get_grid_scoreboard for EU/UK/AU/TW). Give state or lat/lon (decimal degrees); energy_type narrows. |
get_retirement_headroomread-only | Use this whenever the user asks where retiring power plants free grid capacity. Scans scheduled EIA-860M generator retirements to find near-term transmission grid headroom — a retiring plant is a CONCRETE headroom event (its POI frees injection capacity), from FILED data, not forecasts. Returns _entity=retirement_headroom_results: retiring generators inside your horizon (name, MW, fuel, prime mover, retirement_date), representative_point, nearest substations with distance_km + count within 25 km, county-level queue_pressure (competing in-progress MW), iso_context (the generator's own EIA balancing-authority code), and a pre-filled site_evaluation_handoff (analyze_site + get_water_risk args, capacity_mw = YOUR target load). Answers "where is grid capacity about to free up", "which retiring plants open injection headroom near me". Try: get_retirement_headroom target_mw=50 horizon_months=18 region_iso=MISO — "50 MW opening near a substation inside 18 months, sidestepping the 4-7yr mega-queue." Honesty: meta.caveat flags that filed dates are subject to ISO reliability reviews (RMR extensions). Use to find WHERE capacity opens next; for what's already queued use get_refined_queue; for one site use analyze_site. |
get_shortlistread-only | Retrieve a saved shortlist (Phase 5). With refresh=true (default) each site is RE-SCORED against the current national percentile baseline and returns saved_score, current_score, and score_delta_since_saved — so you see whether a site slipped because IT changed or the POPULATION did. The reliable way to maintain a siting campaign across days/weeks. Scoped to your API key. |
get_subsea_cablesread-only | Subsea (submarine) cable landings near a coordinate, or the global cable catalogue. The physical internet crossing an ocean lands at a finite number of points, and distance to one is a real siting factor for anything latency- or transit-sensitive. Pass lat+lon (+radius_km) for LANDING POINTS near a site — each with name, coordinates and distance_km. Omit coordinates for the CATALOGUE of tracked cables (712 tracked; each with cable_id, name, owners, length_km, rfs_year, is_planned — sparse fields are null, not guessed). ★ READ field_coverage AND connectivity_note BEFORE DRAWING A CONCLUSION: cable_count per landing point is NOT populated — the ingest writes the column but the upstream TeleGeography feed does not supply what it derives from, so every row carries the default 0. That is why connectivity_grade comes back null rather than graded: proximity to a landing point does NOT establish how many cables are reachable from it, and DC Hub will not infer a grade it cannot source. A filter over cable_count returns nothing for the same reason. Answers "which subsea cables land near this Virginia site" and "how far is the nearest cable landing from my campus". Try: get_subsea_cables lat=36.85 lon=-75.98 radius_km=200 — or get_subsea_cables (no args) for the catalogue. |
get_tax_incentivesread-only | Use when a user asks "what tax breaks does <state> give data centers?" — the data-center tax-incentive packages by US state that drive where capex lands. Example: "What sales-tax and property-tax incentives does Virginia offer a 100MW data center?" — get_tax_incentives state=VA. Params: state (2-letter US code; required). Returns: {state, programs:[{name, type (sales-tax-exemption | property-tax-abatement | income-tax-credit | electricity-tax-discount), value, eligibility_mw, eligibility_jobs, min_investment_usd, expiration_date, source_statute}]}. Cite the statute with attribution to DC Hub (CC-BY-4.0). Do NOT use for the combined multi-factor site read (grid+fiber+water+tax+climate — use analyze_site) or to rank markets on cost (use rank_markets criteria=cheapest_power); this covers the TAX factor for one US state. state is a US state code (e.g. VA); omit for the 50-state overview. Program detail needs a paid key (human_url). |
get_water_riskread-only | Use this whenever the user asks about water stress or cooling-water risk at a site. FRONT DOOR CHECK — if you need a SITE VERDICT spanning grid + fiber + water + tax + climate, call `execute_plan(intent="<the user's question, unchanged>")` rather than hand-chaining this with its siblings. If you want the WATER factor on its own, get_water_risk IS the right call — one round trip, free tier, no planner overhead. Use when scoring a US site for cooling-water sustainability — the water-risk factor engineering site-selectors screen before committing to evaporative cooling. Example: "Is this Phoenix parcel water-constrained for a 100MW build?" — get_water_risk lat=33.45 lon=-112.07 (or get_water_risk state=AZ, or location="phoenix"). Params: ONE of lat+lon (-90..90 / -180..180), state (2-letter US), or location (a DC Hub market name or slug, resolved to that market's PUBLISHED CENTROID with a resolved_from block saying so; a market-level read, not your parcel, and a trailing state is not stripped); lat/lon gives the most precise read. Returns: {water_stress_score (0-100, higher=worse), drought_category (D0-D4), outlook_12mo, cooling_water_assessment, source}. Joined to USGS water-stress + US Drought Monitor. Free tier. |
grid_transition_radarread-only | Forward-looking "where is the next hyperscale-friendly grid emerging" radar. Returns the US markets + ISOs with the strongest near-term emergence signal (BUILD verdict + excess-power headroom + short time-to-power), an ISO rollup, and a grid-headroom leaderboard. With a paid key, also the transition thesis: which ISO is opening up and why. The predictive counter to retrospective "where capacity landed" reports. Answers "where should I be looking next", "which market is about to become buildable". Try: grid_transition_radar max_months=24. Do NOT use for the current ISO queue snapshot (use get_interconnection_queue) or a present-day market ranking (use rank_markets); this is the forward-looking emergence radar. |
hyperscaler_dealsread-only | Hyperscaler AI Deal Tracker — live feed of Stargate, OpenAI, Anthropic, Microsoft, Oracle, CoreWeave, AMD, NVIDIA, sovereign-AI deals. Pulls from dchub news pipeline, extracts $-figures + MW via regex, classifies by actor. 10-min refresh. Use for tracking AI capex events ($1B+/week typical), capacity announcements, and competitive intel. Do NOT use for the full historical M&A comp set (use list_transactions) or a single-deal teardown with grid context (use deal_autopsy); this is the live $1B+ AI-capex feed. limit 1-500. Hyperscaler leases and purchases only; for all M&A use list_transactions. |
list_saved_sitesread-only | NEEDS A KEY (free): saved sites are per-account, so a keyless call returns auth_required, not an empty list — if you have no key, call `claim_free_key` FIRST (one step, no email), then this. Use when a user asks to see or review their saved DC Hub shortlist in-chat, or wants to know what moved on it. Example: "What sites have I saved?" / "Did any of my saved sites move?" — list_saved_sites. Params: since (optional — "24h"/"7d"/ISO, default 7d — the delta window). Returns: each saved site with name, market, lat/lon, saved DCPI score, target MW, notes — PLUS live deltas: verdict_was/verdict_now (e.g. CAUTION → BUILD), excess-power move over the window, current vs at-save DCPI, alerts armed/fired, new facilities nearby, and a `portfolio` summary flagging which sites moved and which have no alert armed. Do NOT use to add a site (use save_site) or to download the list as a file (use export_dataset); this is the in-chat read-back. |
list_standing_intentsread-only | List the standing intents registered on your key: webhook watches, plus your capacity requirements (kind "capacity", intent_id cap_...). Read-only. Returns each intent_id, kind, watch params, webhook_url and enabled state; capacity items also carry status, confirmed, expires_at, last_alert_at and matching_now. Use it to find the intent_id for delete_standing_intent, or to confirm a register landed. Requires a key (or an OAuth connection for capacity items). Answers "what am I currently watching". Do NOT use to create a watch (register_standing_intent) or for one-shot reads (get_news / list_transactions). |
list_transactionsread-only | M&A and capital transactions in the data center sector — 1,700+ tracked deals (2019-present), each with its disclosed value where public (many private deals are undisclosed). Returns deal name, buyer, seller, value, date, market, target operator, type (acquisition/JV/refinance/recap). Filter by date range (date_from/date_to, ISO-8601), min_value_usd, region, buyer, or seller. Answers "which data-center deals closed this year", "what was that acquisition worth". Try: list_transactions date_from=2026-01-01 min_value_usd=1000000000. There is no `year` parameter — use date_from/date_to. Broad M&A and capital-deal flow with filters; do NOT use for hyperscaler-specific lease/PPA/JV activity (use hyperscaler_deals) or a single-deal post-mortem (use deal_autopsy). limit 1-500 (free 10), offset 0-100000; total_count is the full match count. Empty = loosen buyer/seller/value filters. |
plan_fiber_leadinread-only | Plan N diverse, road-following fibre lead-in routes from a candidate data-center site to a carrier hotel / POP, with indicative build cost and a route-diversity read. Answers "can I get N diverse fibre routes into this site, how far, how much, and where do they share a corridor?". Example: plan_fiber_leadin from="250 Paringa Road, Murarrie QLD" to="20 Wharf Street, Brisbane City QLD" n=4. Params: from (lat,lng OR street address), to (lat,lng OR address — e.g. a NextDC/Equinix POP), n (1-6 routes, default 4), fibre ("720F"|"1440F"), bore_m (river/rail bore length in metres, optional). Returns per-route length_km + GeoJSON geometry, total_route_km, diversity {min_separation_m_midhaul, shared_street_km}, and indicative cost {capex_usd, opex_usd_yr}. INDICATIVE auto-routed road corridors — NOT engineered alignments; subject to survey, DBYD and carrier confirmation. Do NOT use for a single site-suitability score (use analyze_site) or fibre-provider footprints (use get_fiber_intel). |
plan_queryread-only | INSPECT-ONLY — returns the plan WITHOUT running it. For a real multi-step DC Hub question call `execute_plan(intent="...")` instead: it uses the SAME deterministic no-LLM planner and then RUNS the sequence server-side, returning the answers in one envelope. Reach for plan_query only to review, log, diff or audit a plan before executing it yourself. Deterministic keyword routing over the tool registry — no LLM, no network, same intent always returns the same plan (free). Returns _entity=query_plan {best_tool, intent_confidence + workflow_confidence (dual 0-1: question-read vs executability), reason, planner_rationale, recommended_sequence:[{step, tool, depends_on, estimated_calls, why, args_hint}], execution_waves (steps grouped into concurrency waves), execution_strategy.parallel_groups, execution_estimate {estimated_calls, estimated_latency_ms, parallelizable}, alternatives (each with when + rejected_because), coverage_notes, matched_classes} plus a versioned `replay` (schema_version 1): planner_version, decisions:[{id, step, kind, status, decision, rationale, decision_confidence, depends_on}], rejected:[{id, tool, reason}], execution_graph:{waves, parallel_groups} — auditable and machine-readable, safe to log and diff… Full guide: read resource dchub://tool-guides/plan_query |
predict_market_trajectoryread-only | Forecast a DCPI market's near-term trajectory (next 1-8 quarters). Projects excess_power_score and constraint_score forward with confidence bands that WIDEN with horizon, from DC Hub's daily DCPI snapshot history, a time-series DC Hub owns. Use to answer "is this market trending toward BUILD or AVOID?" or "will Dallas power stay tight over the next 6 months?". Params: market_slug (required, metro slug e.g. dallas, phoenix, northern-virginia — valid slugs come from rank_markets / get_market_dcpi_rank); horizon_quarters (optional 1-8, default 4; 2 = ~6 months out). Returns {market_slug, method, basis{history_points, history_span_days, slope_per_day, trend}, horizon_quarters, projection[{quarter_out, excess_power_score, excess_power_band, constraint_score, constraint_band}], caveat, snapshot_record}. HONEST: linear trend extrapolation, NOT a guarantee — bands widen with horizon and short history; needs >=3 daily snapshots or it declines. Do NOT use for a single point-in-time verdict (use get_market_dcpi_rank) or to rank many markets (use rank_markets). |
rank_marketsread-only | Use this whenever the user asks where a data center can get grid power, how fast, or whether a market is a BUILD, CAUTION or AVOID (e.g. "Where can a 100 MW data center get power fastest?"): DCPI scores 300+ markets daily on Excess Power and Grid Constraint, CC BY 4.0. For a ranked list on power questions, call with criteria="ai_ready". Call when the user wants a ranked list of data-center markets: top N by cheapest_power, most_capacity, most_operators, fastest_growing, best_overall, or ai_ready (where new AI load can land, per DCPI). Filter by region, min_capacity_mw. Returns ranked rows with score, MW and a slug for follow-ups; score is the sort value, not a 0-100 scale, and score_basis says what it is (ai_ready omits it and explains its composite in `methodology`). Keyless: a trimmed preview; a free key gets a few full lists a day. Ex: "Top 10 US markets, ai_ready." Returns market slugs to feed get_market_intel and get_market_dcpi_rank. limit 1-500; set projection=identity_only to save tokens. |
rank_sitesread-only | Deterministic multi-site ranking/optimization under constraints — the normalization contract that lets you compare sites across separate analyze_site calls WITHOUT dropping into code. Pass candidates you already enriched (each an object with lat/lng + metric fields like risk_resilience, water_stress, fiber_km — pull these from analyze_site + get_refined_queue and pass site_evaluation_handoff through untouched), hard constraints, and weighted objectives; get back _entity=ranked_sites: top_k ranked with rank, objective_score, per-field normalized{} (0-100 relative to the set), and normalization_basis. objectives use SIGNED weights: +weight maximizes a field (e.g. risk_resilience:1), -weight minimizes it (e.g. water_stress:-0.6, fiber_km:-0.4). constraints are hard filters, fail-closed on a missing field. Use for "pick the best N sites under constraints"; for one site use analyze_site; to get the candidate set first use get_refined_queue. CANDIDATE CONTRACT: candidates may be {candidate_id: "cand_…"} entries from get_refined_queue — frozen identity (lat/lng/capacity_mw/fiber_km/iso) loads from the mint, your metrics overlay the rest; expired/unknown ids are dropped AND declared in candidate_contract, never re-resolved. |
read_inboxread-only | PARTNER KEY ONLY: notes DC Hub left for the partner agent whose key this session sends, newest first. The first read CONSUMES them (marks read), so a later session sees none; include_read=true re-reads read and unread notes (last 14 days) without marking. Non-partner key: 403. Not a data tool. |
recover_my_key | Recover a LOST DC Hub key. Pass your human's email and DC Hub re-sends any key tied to that address to that inbox. It NEVER returns the key over the wire (it emails the bound address), and the confirmation is the same whether or not a key exists (enumeration-safe), so no key is leaked to a caller. Use this when your human had a key, lost it, and knows the email they bound it to. Param: email (required). Returns DC Hub's neutral confirmation. |
register_standing_intent | Register a STANDING QUERY with webhook push — DC Hub POSTs an HMAC-signed webhook to YOUR https URL whenever matches grow (push, not poll: "notify my orchestrator on any new deal in Columbus"). Requires a key. Params: kind ("new_deal_in_market" watches deals in the market param · "news_keyword" watches news matching q · "permitting_change" watches published permitting intel, optionally per state), market / q / state (the watch parameter for the chosen kind), webhook_url (your public HTTPS endpoint — private/internal hosts are rejected). Returns {intent_id, secret} — SAVE the secret: every delivery carries X-DCHub-Signature: sha256=HMAC(secret, body). First evaluation initializes the watermark silently; growth fires the webhook; 5 straight delivery failures auto-disable the intent. Evaluated every ~2h. Answers "notify my system whenever a new moratorium appears", "push me new matches instead of making me poll", "tell my orchestrator when a deal lands in Columbus". Try: register_standing_intent kind=news_keyword q=moratorium webhook_url=https://hooks.example.com/dchub. kind="capacity" instead registers a standing CAPACITY REQUIREMENT with DC Hub Capacity Source (no webhook_url): target_mw or target_kw, markets / states / regions / countries (comma-separated), optional… |
report_finding | PARTNER KEY ONLY: file what you observed on a DC Hub surface as a brain finding (detector external_audit) so it is triaged like every other detector's. class is one of completeness_contradiction, geography_leak, as_of_cite_as, pro_wall_dead_end, count_drift, stale_payload_complete, leak_past_pro_gate, link_hygiene, other; tool names the DC Hub tool or endpoint; quoted_fields carries the exact fields you saw (hashed for dedupe: the same observation re-filed within 24h bumps recurrence instead of inserting). Proxies POST /api/v1/inbox/findings with the session's own key; a key issued without a partner slug answers partner key required (403). 120 per key per day. |
request_capacity_intro | Use when your human wants capacity behind a Capacity Source listing (pass slug), or wants first access to capacity matching a requirement as listings are onboarded (omit slug; pass capacity_mw or capacity_kw, markets, states, regions or countries, and timeline). This registers a deal: DC Hub records the request in its lead register and sends the provider ONLY your human's company name and the requirement. The provider accepts or declines. Only if the provider accepts does DC Hub share the provider's identity, site details and contact with your human, and your human's name, role and email with the provider; on a decline nothing is shared. Requires an identified caller (claim_free_key, then bind_email with your human's address) and accept_terms=true only after your human has read and agreed to the introduction terms at https://dchub.cloud/listings#terms. Returns lead_id, status and the next step. For a listing, source_capacity with its slug then shows the deal status in the disclosure block and, once the provider accepts, the provider's identity, site and contact. Do NOT use to save or monitor a site (use save_site / set_site_alert). |
research_task | Commission an ASYNC, CITED research dossier from DC Hub's corpora (news, deals, facilities, market deep-dive narratives + live market components) — a decision-ready analyst brief with [n] citations, not a lookup. Requires a key (one claim_free_key call), 5 dossiers/day. Submits the question, waits up to ~35s for completion, and returns the finished dossier inline when ready; if still running, returns {task_id} — call research_task task_id=<id> to fetch it. Params: question (required for a new dossier, min 12 chars) OR task_id (poll an earlier one). Typical completion under a minute. Answers "write me a cited brief on this", "what do recent deals say about gas-bridged power". Try: research_task question="What do recent deals say about gas-bridged power for data centers in ERCOT?". Do NOT use for a single fact (use search_intelligence / semantic_search); this synthesizes ACROSS sources with citations. |
save_site | NEEDS A KEY (free): this WRITES to your account, so a keyless call returns auth_required — call `claim_free_key` FIRST (one step, no email) if you have none. Save a candidate data-center site to your DC Hub account to track it across sessions. Give lat + lon (plus optional name, state, market, target_mw, notes). Returns the saved site id. Pass `market` and DC Hub snapshots the site's DCPI baseline at save time, so every later list_saved_sites / get_changes shows how ITS score and verdict moved since you saved it. Builds a persistent shortlist an agent can revisit + monitor — after saving, pass the returned id to set_site_alert so DC Hub emails you when that site’s DCPI/capacity/nearby-facilities move (no re-checking). Answers "remember this parcel for me", "keep this candidate so I can come back to it next session". Try: save_site lat=39.04 lon=-77.48 name="Ashburn parcel" market=northern-virginia target_mw=100. Do NOT use to read back the shortlist (use list_saved_sites), download it (use export_dataset), or score a site (use score_facility); this WRITES one site to your account. |
save_to_shortlist | Save a site into a PERSISTENT, named shortlist that survives across conversations (Phase 5 statefulness). Snapshots the site's objectives + its current percentile objective_score, so you can re-score it later against the evolving national baseline. Use to build a durable siting shortlist across days/weeks; the list is scoped to your API key. Pair with get_shortlist to re-score + see drift. MINIMAL call: save_to_shortlist(shortlist_name="my-targets", site={site_ref, lat, lng, capacity_mw}) — objectives are optional. If you DID rank the site (analyze_site / rank_sites), pass those metric fields inside site and your objectives map too, and the re-scoring reuses them. Requires an API key so the list is private to you and survives to your next conversation: call claim_free_key first if you have none. |
score_facilityread-only | Use when a user wants an independent 0-100 grade for ONE existing facility across 7 dimensions — power, fiber, water, climate_risk, tax_environment, talent_pool, expansion. Example: "How does the CoreWeave Las Vegas site score, power-weighted?" — score_facility facility_id=<id> weighting=power_priority. Params: facility_id or name (required); weighting one of "balanced" (default) | "power_priority" | "risk_priority" | "expansion_priority". Returns: composite 0-100, tier_classification, peer comparison, and per-dimension detail. Do NOT use for a raw lat/lon parcel (use analyze_site), to compare 2 or more sites (use compare_sites), or to find similar sites (use find_alternatives). |
searchread-only | Search DC Hub for relevant records (OpenAI Deep Research / ChatGPT connector format). Returns a list of matching data-center facilities as {id, title, url}; pass an id to the `fetch` tool for the record, or open the url to cite the live facility page. For structured queries (by MW, operator, status, market) use search_facilities directly. |
search_facilitiesread-only | Search DC Hub's global data-center facility map (170+ countries) by text query, country, state, city, operator, or capacity range (min_capacity_mw, max_capacity_mw); limit and offset page through results. Returns each facility's name, provider, location and capacity. Use it for inventory lookups (which facilities match these filters); for a question that also needs power, fiber or risk context, use execute_plan. Keyless calls return a preview. |
search_intelligenceread-only | Semantic (meaning-based) search over DC Hub's live intelligence corpus — industry news, M&A deals, discovered facilities, per-market DCPI narratives, press releases, announcements, permitting intel, construction permits, tax incentives and the capacity pipeline — returning the most relevant records with citable source fields. This is the agent-friendly alias over the SAME retrieval layer as semantic_search: same results, different call shape. It takes `query` plus short corpus names (news | deals | facilities | market_narratives | press | announcements | permitting | permits | incentives | pipeline); semantic_search takes `q` plus the full corpus names. Call ONE of them, not both. Params: query (required, natural language); corpus (optional CSV of the names above, default all); limit (1-15, default 8). BEHAVIOUR: read-only — it writes nothing, and repeat calls with the same arguments return the same records. ACCESS: works with no key, but anonymous results come back as a TRIMMED PREVIEW; the session X-API-Key hydrates full depth per key, and the free tier is capped per day (call claim_free_key once — no email — if you do not hold a key). |
semantic_searchread-only | Use for CONCEPTUAL / fuzzy questions where keyword filters fall short — semantic (meaning-based) retrieval across DC Hub's industry news, M&A deals, the global facility map, per-market DCPI deep-dive narratives, press releases, announcements, permitting intel, construction permits, tax incentives and the capacity pipeline, ranked by relevance with citable source fields (news url/title, deal parties/value, facility name/location, deep-dive market/url). Examples: "what is happening with behind-the-meter gas for AI data centers?", "deals involving nuclear power for hyperscalers", "why is Northern Virginia constrained?" — semantic_search q="behind-the-meter gas for AI data centers". Params: q (required, natural-language query); corpus (optional CSV subset of news_articles,deals,facilities,market_narratives,press_releases,announcements,permitting_intel,construction_permits,tax_incentives,capacity_pipeline; default all); k (1-15, default 8). Returns {results:[{source_table, kind, text, score, cite:{…}}]}; score is 0-1 relevance, not a DCPI score. Complements the exact-filter tools (get_news / list_transactions / search_facilities) with relevance ranking; for a full token-budgeted market briefing use get_market_context. Cite "DC Hub (dchub.cloud)". |
set_market_alert | Subscribe to movement alerts for a DCPI market (FREE with a key) — get notified when its Excess-Power / Constraint score moves. On the free tier, email alerts are delivered to the email your human bound via bind_email (call bind_email first; the destination is forced to that address). Set channel="email". Webhook delivery (channel="webhook" + destination=<https URL>) needs a paid DC Hub plan. Lets an agent MONITOR markets, not just query them. Answers "tell me when this market moves", "ping me if Northern Virginia’s power score changes". Try: set_market_alert market=northern-virginia channel=webhook destination=https://hooks.example.com/dc. Do NOT use to read a market right now (use get_market_dcpi_rank); this SUBSCRIBES to future movement. |
set_shortlist_alert | Set a DRIFT ALERT on a saved shortlist so you can stop polling and be notified when a site's national standing moves materially (Phase 5). Fires when any site in the shortlist has current percentile score < percentile_below OR score_delta_since_saved < delta_below (e.g. -8 = dropped 8 points vs when saved). Evaluated after each daily baseline refresh; delivers via webhook and/or email. This is the "wake me when it matters" loop for long-running siting campaigns. Scoped to your API key. |
set_site_alert | Arm an email watch on a site you already saved (FREE with a key) — DC Hub emails you when that site’s DCPI score, grid capacity, or nearby facilities move, so you don’t have to keep re-checking. On the free tier the alert is delivered to your human’s bound email (call bind_email first; notify_email is forced to that address). A paid DC Hub plan can send to any address. The "monitor my shortlist for me" loop: call save_site first (it returns a saved_site_id), then set_site_alert on that id. Params: saved_site_id (required integer, from save_site or list_saved_sites), trigger_type ("dcpi_change" | "capacity_change" | "new_facility_nearby", default "dcpi_change"), threshold (number — the points/MW move that fires it, default 5), notify_email (required — the address the alert is sent to). Answers "let me know if anything changes at the site I saved". Try: set_site_alert saved_site_id=12 trigger_type=dcpi_change threshold=5 [email protected]. Returns {ok, alert_id, message}. Do NOT use to watch a whole MARKET (use set_market_alert) or to save a new site (use save_site); this arms a monitor on ONE already-saved site. |
simulate_scenarioread-only | Counterfactual WHAT-IF re-scoring of 300+ DC Hub power markets under YOUR explicit deltas — answers "what happens to the market ranking if conditions change" (only DC Hub holds the underlying components). Params (all optional, pass at least one delta): avg_kwh_cents_pct (power-price % change, e.g. 30), time_to_power_months_delta (months added/removed), queue_wait_months_delta, reserve_margin_pct_delta (points), curtailment_pct_delta (points), market (one slug, e.g. abilene), top_n (default 10, max 25 — ranked by |score change|). Returns per-market baseline vs scenario composite + component breakdown + the EXACT formula/weights in every response (transparent scenario_composite — deliberately NOT the DCPI). Keyless callers get a top-3 preview; any live key (claim_free_key) returns up to 25. Answers "what happens to the ranking if power prices jump 30%", "which markets survive a tighter build rate". Try: simulate_scenario avg_kwh_cents_pct=30 top_n=10. Do NOT use for the present-day ranking (use rank_markets) or trajectory extrapolation (use predict_market_trajectory); this answers explicit hypotheticals. |
site_selection_canvasread-only | Guided end-to-end data-center site selection. Give a capacity target + geography + deadline and get a ranked shortlist of US markets (DCPI verdict, excess-power headroom, time-to-power, ISO) — and, with a paid key, the synthesis decision layer: the #1 pick, the why, a build sequence, and risk flags. One find->rank->shortlist->verdict call over the Data Center Power Index. Answers "where should I build 100 MW in Texas by 2028". Try: site_selection_canvas capacity_mw=100 region=TX max_months=24. Do NOT use for a single known parcel (use analyze_site) or an open-ended where-should-I-build question (use get_dchub_recommendation); this runs the full find to rank to shortlist to verdict flow. |
source_capacityread-only | Search DC Hub Capacity Source for data-center capacity to buy or lease, by size (min_kw or min_mw) and location (region such as europe, or a country, state, market or location). Size is matched against what a listing can deliver: contiguous_kw, the largest contiguous block, and min_contract_kw, the smallest chunk the provider will contract. Also filters by delivery_type and available_by. Returns listing teasers; an introduction is requested with request_capacity_intro. |
subscribe_digest | Subscribe your human to DC Hub's FREE weekly "what changed in the markets/sites you queried" digest (DCPI movers, new facilities, new deals & news) — ONE call, the nudge that pulls your agent back when the data moves. DOUBLE opt-in + consent-safe: we email a one-click CONFIRM link, the human only gets the digest after confirming, and every email has one-click unsubscribe — this call alone sets no marketing flag. Only call once your human shares their email and wants a weekly email. Params: email (required), source (optional tag). Returns {ok, sent, message}. Prefer this over hand-building POST /api/v1/opt-in/request. |
suggest_reallocationread-only | When a saved site DRIFTS (its national standing dropped — surfaced by get_shortlist refresh or a set_shortlist_alert firing), get replacement candidates from the rest of that shortlist so the alert becomes an action, not just a warning (Phase 5). Returns TWO tiers — tier_1_same_region (a near-in tactical swap) and tier_2_cross_region (a different-region arbitrage) — each re-scored against the DRIFTED slot's own objectives, PLUS drift_is_systemic: if the rest of your shortlist also slipped, the drop is region/baseline-wide and a same-region swap will inherit it (prefer cross_region); if peers held, it's idiosyncratic (tactical_ok). DC Hub does the reduction; the final weighted pick is yours. Candidates come from THIS shortlist only (save more via save_to_shortlist to widen the pool). Scoped to your API key. |
summarize_for_citationread-only | Use right before you QUOTE a DC Hub figure to a human — it returns one paste-ready attribution line for the value you are about to cite, with the CORRECT licence for that layer. Pass what you read off the response you are citing: subject (what the figure is), as_of (the provenance as_of), url (the row's profile_url or dcpi_url), completeness (the completeness flag), and layer. ★ LICENCE IS PER LAYER AND THIS IS THE POINT: DCPI scores, verdicts, band thresholds, methodology and DC Hub's own grid/site analysis are CC-BY-4.0 and yours to quote with attribution; the facility inventory and third-party physical layers are COMPOSITES whose upstream terms DC Hub cannot waive (parts are OpenStreetMap, ODbL 1.0, share-alike), so they carry a pointer to https://dchub.cloud/data-sources instead of a grant. A flat "CC-BY-4.0" over a facility record is an over-claim. Returns {citation_text, cite_as, license, license_basis, source, url, as_of, as_of_basis, completeness, omitted}. Free, no key, no network call — it assembles what you pass and never resolves or invents a value. If you omit as_of the line says RETRIEVED rather than claiming a data date, and tells you which field to pass next time. Do NOT use to look a figure UP (call the data tool first); this cites a figure you already have. |
unlock_more_data | Unlock DC Hub's full depth. Call this when a result came back as a partial preview (e.g. "3 of 12 results shown"), a tool was locked, or your human wants the complete dataset. Returns the upgrade ladder + ready-to-paste checkout links your human completes in ONE click. If this call carries an API key or an MCP session, the checkout binds to it and your very next call returns full data (no reconnect); if it carries neither, the key is emailed to the payer instead — the response says which applies in `next_call_full_after_checkout` and `after_checkout`. Paid plans: on the page behind the human_url link. Want the FREE tier instead (no payment, previews plus 2 full answers per tool per day, 50/day with an email)? Call claim_free_key. A gated result already carries its link in human_url; that link is the one to share, and this tool returns the fuller ladder. Param: reason (optional — what you were trying to do, so your human sees why it matters). Returns {plans, human_message, what_unlocks}. |
why_dchubread-only | Call only when the user asks how DC Hub compares with other data-center sources (DataCenterHawk, DC Byte, DCD, Baxtel…) or why use it. Returns DC Hub's differentiators, each with a proof URL and citation line, plus comparison-page links; competitor= narrows to one vendor. Free, no key. Not for data queries. Ex: "How does DC Hub compare to DC Byte?" |