DC Hub — Data Center & Energy Intelligence

Save To Shortlist

save_to_shortlist

Save a site to a persistent, named shortlist for later re-scoring against the evolving national baseline across conversations.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`site`	Yes	Site object. MINIMAL form is enough: {site_ref, lat, lng, capacity_mw}. Richer is better — add any analyze_site metric fields (risk_resilience, fiber_connectivity, water score…) and those become what gets re-scored later.
`notes`	No	Optional free-text note, e.g. "strong fiber, acceptable water"
`objectives`	No	OPTIONAL {field: signedWeight} map (+maximize/-minimize) if this site was ranked under explicit objectives — stored so re-scoring reuses the same criteria. Omit it and DC Hub weights the site's own metric fields equally.
`shortlist_name`	Yes	Name of the shortlist, e.g. "Q3-2026-1GW-targets" — created if new. REQUIRED.

Output Schema

TableJSON Schema

Name	Required	Description
`quota`	No	Caller quota state (remaining calls, tier) when available.
`_entity`	No	Payload class discriminator (e.g. facility\|market\|iso_grid\|queue_results\|deal\|report\|response) — branch on this before parsing the rest.
`citation`	No	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.
`provenance`	No	Collection-level provenance block: {source, method, as_of, verification_counts, cite_url_template, license, cite_as}. Quote the verification level when citing.
`_front_door`	No	In-band front-door hint (first workflow-entry tool of a session): call plan_query(intent) first for the ordered multi-step plan.
`_return_loop`	No	Suggested next-session delta call (get_changes since=24h) so you pull only what changed.
`site_evaluation_handoff`	No	Pre-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.

Changed2 schema fields changedAug 30, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedOutput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

Changed5 schema fields changedv2.3.20Aug 14, 2026

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"
```

Changed4 schema fields changedv2.3.14Jul 30, 2026

changedInput schema / properties / objectives / description

Previous value: -"The {field: signedWeight} objectives this site was ranked under (+maximize/-minimize) — stored so re-scoring uses the same criteria"New value: +"OPTIONAL {field: signedWeight} map (+maximize/-minimize) if this site was ranked under explicit objectives — stored so re-scoring reuses the same criteria. Omit it and DC Hub weights the site's own metric fields equally."

changedInput schema / properties / shortlist_name / description

Previous value: -"Name of the shortlist, e.g. \"Q3-2026-1GW-targets\" — created if new"New value: +"Name of the shortlist, e.g. \"Q3-2026-1GW-targets\" — created if new. REQUIRED."

changedInput schema / properties / site / description

Previous value: -"Site object: {site_ref?, lat, lng, capacity_mw, <metric fields from analyze_site>} — the metrics are what get re-scored later"New value: +"Site object. MINIMAL form is enough: {site_ref, lat, lng, capacity_mw}. Richer is better — add any analyze_site metric fields (risk_resilience, fiber_connectivity, water score…) and those become what gets re-scored later."

changedInput schema / required

Previous value: -[
-  "site",
-  "objectives"
-]New value: +[
+  "shortlist_name",
+  "site"
+]

Changed1 schema field changedv2.3.12Jul 28, 2026

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"
+}

Addedv2.3.8Jul 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description discloses key behaviors beyond annotations: persistence across conversations, API-key privacy/scoping, snapshotting objectives and percentile score, optional reuse of ranked metrics, and the prerequisite of claim_free_key. None of this is present in the sparse annotations, and it directly informs correct invocation.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: purpose, behavioral guarantees, usage scenario, pairing, minimal call, optional enrichment, and auth prerequisite. The most important statefulness concept is front-loaded and the details flow logically.

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

Completeness5/5

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

For a stateful mutation tool with 4 parameters, an output schema, and minimal annotations, the description covers everything an agent needs to call it correctly: persistence, auth, required fields, optional fields, example call, and post-save workflow with get_shortlist. No significant gap remains.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds substantial value: it gives a MINIMAL call example with site={site_ref, lat, lng, capacity_mw}, explains that objectives are optional and what happens if omitted, and clarifies how richer metric fields get reused during re-scoring. This is far beyond the baseline schema descriptions.

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 opens with a specific verb and resource: 'Save a site into a PERSISTENT, named shortlist that survives across conversations.' It clearly distinguishes itself from plain saves by emphasizing persistence, API-key scoping, and re-scoring behavior, and it names get_shortlist as the complementary tool.

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

Usage Guidelines4/5

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

It gives clear usage context: 'Use to build a durable siting shortlist across days/weeks' and explains the list is scoped to the API key. It also tells the agent to pair with get_shortlist for re-scoring, but it does not explicitly discuss when not to use it versus alternatives like save_site.

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

Deploy Server