Skip to main content
Glama
azmartone67

DC Hub — Data Center & Energy Intelligence

by azmartone67
OverviewSchemaRelated ServersScoreDiscussions(1)
JavaScript
Remote

Grid Intelligence

get_grid_intelligence
Read-onlyIdempotent

Answer whether a specific ISO or balancing authority can supply N MW of power and estimate time-to-power. Returns grid constraint, queue-wait, curtailment, and reserve-margin metrics.

Instructions

Use when a user asks "can I get N MW of power in and how long will it take?" — the flagship grid-headroom + interconnection-queue brief for one ISO. Example: "How much excess power does PJM have right now and what is the time-to-power for a 200MW load?" — get_grid_intelligence region_id="PJM". Params: region_id (aliases iso/region accepted) — one of the 7 US ISOs ("PJM" | "ERCOT" | "CAISO" | "MISO" | "SPP" | "NYISO" | "ISO-NE") OR a US EIA balancing authority (40+ now live, e.g. Atlanta/SOCO, Carolinas/DUK, Florida/FPL, Phoenix/AZPS, Las Vegas/NEVP, Portland/PGE, Seattle/SCL, LA/LDWP, Quincy/GCPD, Denver/PSCO, Tennessee/TVA — note: balancing authorities return live generation mix; demand, headroom, interconnection-queue and DCPI scores remain ISO-level for the 7 ISOs). You may instead pass market="Ashburn" (or a metro slug like "northern-virginia") to name a MARKET rather than a grid code: it is resolved to the ISO for that market through the published DCPI market row, and the reply carries a resolved_from block naming what it resolved to — the figures then describe the ISO, which is larger than the market you named. Returns: {iso, iso_name, demand_mw, generation_mix_pct{NG,COL,NUC,WND,SUN,WAT,…}, renewable_share_pct, gas_share_pct, constraint_score (0-100 DCPI), excess_power_score (0-100 DCPI), avg_time_to_power_months, avg_queue_wait_months, curtailment_pct, reserve_margin_pct, retail_price_cents_kwh, queue_depth_gw, data_center_share_pct, stranded_capacity_mw, grid_emergencies_30d, build_rate_pct, last_updated}. ★avg_time_to_power_months and avg_queue_wait_months are DIFFERENT measurements and are not interchangeable: time-to-power is the DCPI per-market estimate averaged over the ISO, while queue-wait is a proxy derived from live interconnection-queue DEPTH (12 + 0.6 months per GW, clipped 12-66) and is the one that saturates on the deepest queues. Quote whichever you mean by name. Do NOT use to compare 2+ ISOs side-by-side (use compare_isos) or for the global greenest-first ranking (use get_grid_scoreboard).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
isoNoAlias for region_id — the ISO/RTO or balancing-authority code
marketNoMarket NAME or metro slug instead of a grid code, e.g. "Ashburn", "northern-virginia", "dallas". Resolved to its ISO through the published DCPI market row before the brief is built; the answer carries a resolved_from block naming what it resolved to. Not an alias for region_id — "Ashburn" is not a grid code.
regionNoAlias for region_id — the ISO/RTO or balancing-authority code
region_idNoGrid region (required): one of the 7 US ISOs (PJM, ERCOT, CAISO, MISO, SPP, NYISO, ISO-NE), an EIA balancing-authority code (e.g. SOCO, DUK, AZPS, TVA), or the PJM Dominion zone region_id="PJM-DOM" for live Ashburn / Northern Virginia zone load + real-time LMP (the world's #1 DC market, invisible in EIA)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
quotaNoCaller quota state (remaining calls, tier) when available.
_entityNoPayload class discriminator (e.g. facility|market|iso_grid|queue_results|deal|report|response) — branch on this before parsing the rest.
citationNoMachine-readable citation: how to attribute DC Hub (dchub.cloud) for this payload. Normally an OBJECT {source, url, license, cite_as, retrieved_at}; a bare string is accepted and carries the attribution line itself.
provenanceNoCollection-level provenance block: {source, method, as_of, verification_counts, cite_url_template, license, cite_as}. Quote the verification level when citing.
_front_doorNoIn-band front-door hint (first workflow-entry tool of a session): call plan_query(intent) first for the ordered multi-step plan.
_return_loopNoSuggested next-session delta call (get_changes since=24h) so you pull only what changed.
site_evaluation_handoffNoPre-built follow-up calls (analyze_site / get_water_risk args) when the payload carries coordinates — an array of {tool, parameters, why} entries.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • addedInput schema / properties / market
      Added value: +{
+  "description": "Market NAME or metro slug instead of a grid code, e.g. \"Ashburn\", \"northern-virginia\", \"dallas\". Resolved to its ISO through the published DCPI market row before the brief is built; the answer carries a resolved_from block naming what it resolved to. Not an alias for region_id — \"Ashburn\" is not a grid code.",
+  "type": "string"
+}
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  2. Changed5 schema fields changedv2.3.20
    • removedOutput schema / properties / citation / additionalProperties
      Removed value: -{}
    • addedOutput schema / properties / citation / anyOf
      Added value: +[
+  {
+    "additionalProperties": {},
+    "properties": {},
+    "type": "object"
+  },
+  {
+    "type": "string"
+  }
+]
    • changedOutput schema / properties / citation / description
      Previous value: -"Machine-readable citation: how to attribute DC Hub (dchub.cloud) for this payload."New value: +"Machine-readable citation: how to attribute DC Hub (dchub.cloud) for this payload. Normally an OBJECT {source, url, license, cite_as, retrieved_at}; a bare string is accepted and carries the attribution line itself."
    • removedOutput schema / properties / citation / properties
      Removed value: -{}
    • removedOutput schema / properties / citation / type
      Removed value: -"object"
  3. Changed1 schema field changedv2.3.12
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "description": "DC Hub envelope: structuredContent mirrors the JSON payload in content[0].text — tool-specific data fields ride at the top level alongside these envelope keys.",
+  "properties": {
+    "_entity": {
+      "description": "Payload class discriminator (e.g. facility|market|iso_grid|queue_results|deal|report|response) — branch on this before parsing the rest.",
+      "type": "string"
+    },
+    "_front_door": {
+      "additionalProperties": {},
+      "description": "In-band front-door hint (first workflow-entry tool of a session): call plan_query(intent) first for the ordered multi-step plan.",
+      "properties": {},
+      "type": "object"
+    },
+    "_return_loop": {
+      "additionalProperties": {},
+      "description": "Suggested next-session delta call (get_changes since=24h) so you pull only what changed.",
+      "properties": {},
+      "type": "object"
+    },
+    "citation": {
+      "additionalProperties": {},
+      "description": "Machine-readable citation: how to attribute DC Hub (dchub.cloud) for this payload.",
+      "properties": {},
+      "type": "object"
+    },
+    "provenance": {
+      "additionalProperties": {},
+      "description": "Collection-level provenance block: {source, method, as_of, verification_counts, cite_url_template, license, cite_as}. Quote the verification level when citing.",
+      "properties": {},
+      "type": "object"
+    },
+    "quota": {
+      "additionalProperties": {},
+      "description": "Caller quota state (remaining calls, tier) when available.",
+      "properties": {},
+      "type": "object"
+    },
+    "site_evaluation_handoff": {
+      "anyOf": [
+        {
+          "items": {
+            "additionalProperties": {},
+            "properties": {},
+            "type": "object"
+          },
+          "type": "array"
+        },
+        {
+          "additionalProperties": {},
+          "properties": {},
+          "type": "object"
+        }
+      ],
+      "description": "Pre-built follow-up calls (analyze_site / get_water_risk args) when the payload carries coordinates — an array of {tool, parameters, why} entries."
+    }
+  },
+  "type": "object"
+}
  4. Changed1 schema field changedv2.3.7
    • changedInput schema / properties / region_id / description
      Previous value: -"Grid region (required): one of the 7 US ISOs (PJM, ERCOT, CAISO, MISO, SPP, NYISO, ISO-NE) or an EIA balancing-authority code, e.g. SOCO, DUK, AZPS, TVA"New value: +"Grid region (required): one of the 7 US ISOs (PJM, ERCOT, CAISO, MISO, SPP, NYISO, ISO-NE), an EIA balancing-authority code (e.g. SOCO, DUK, AZPS, TVA), or the PJM Dominion zone region_id=\"PJM-DOM\" for live Ashburn / Northern Virginia zone load + real-time LMP (the world's #1 DC market, invisible in EIA)"
  5. Changed3 schema fields changedv2.3.6
    • addedInput schema / properties / iso / description
      Added value: +"Alias for region_id — the ISO/RTO or balancing-authority code"
    • addedInput schema / properties / region / description
      Added value: +"Alias for region_id — the ISO/RTO or balancing-authority code"
    • addedInput schema / properties / region_id / description
      Added value: +"Grid region (required): one of the 7 US ISOs (PJM, ERCOT, CAISO, MISO, SPP, NYISO, ISO-NE) or an EIA balancing-authority code, e.g. SOCO, DUK, AZPS, TVA"
  6. First observedv2.1.19

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations carry the safety profile (readOnlyHint, idempotentHint, destructiveHint all safe), so the bar is lower and the description earns full credit for context beyond them. It discloses three critical behavioral traits: market names resolve to their ISO via the DCPI row with a resolved_from block, balancing authorities return only live generation mix while other metrics stay ISO-level, and the two time metrics are non-interchangeable with the queue-wait derivation formula (12 + 0.6 months/GW, clipped 12-66). These are exactly the traps that would corrupt an agent's output. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Information-dense but long (roughly 280 words). It is front-loaded with the trigger use case and example, and every clause earns its place — the alias list, BA caveat, metric warning, and sibling routing are all high-value. The return-field enumeration is partially redundant with the output schema, but it anchors the essential time-to-power vs queue-wait warning, so the length is largely justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity tool (4 params, three input modes, a counterintuitive resolution quirk, and a metric disambiguation), the description covers the critical decision points: valid inputs, market resolution behavior, BA data-scope limits, metric non-interchangeability, and when-not-to-use. Gaps are minor: no error behavior for invalid regions, and the schema's '0 required params' label sits awkwardly against the description's implication that a region or market is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real value beyond the schema: it groups iso/region/region_id as aliases, enumerates the full 7-ISO valid set plus 40+ balancing-authority examples, documents the special PJM-DOM zone for Ashburn, and clarifies that market is not an alias but a name resolved to a larger ISO. The only reason it isn't a 5 is that the schema already covers much of the same ground.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource+scope: 'the flagship grid-headroom + interconnection-queue brief for one ISO', anchored to a concrete trigger question ('can I get N MW of power in <ISO> and how long will it take?') and a worked example call. It distinguishes itself from siblings by name ('Do NOT use to compare 2+ ISOs side-by-side (use compare_isos) or for the global greenest-first ranking (use get_grid_scoreboard)').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use guidance is given as a verbatim user-intent trigger, and explicit when-not-to-use exclusions name the exact sibling alternatives (compare_isos, get_grid_scoreboard). The market-vs-ISO edge case is also covered with a warning that the figures describe the ISO, which is larger than the market named — leaving no ambiguity about interpretation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/azmartone67/dchub-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server