Skip to main content
Glama
azmartone67

DC Hub Intelligence

by azmartone67
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Remote

Register Standing Intent (webhook push)

register_standing_intent

Register a standing query that pushes HMAC-signed webhook alerts when new deals, news keywords, or permitting changes match; capacity requirements can be emailed.

Instructions

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 available_by (YYYY-MM or YYYY-MM-DD), delivery_type, min_chunk_kw, max_sites (1-6), use_case, notes, plus your human's name and company and accept_terms=true only after they agreed to https://dchub.cloud/listings#terms. Needs a key with your human's email bound (claim_free_key, then bind_email) or an OAuth connection. Returns intent_id cap_; DC Hub emails a confirmation link, then emails matching listings at most once a day. Do NOT use for one-shot reads (get_news / list_transactions), a one-off capacity search (source_capacity) or email alerts on a market (set_market_alert).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFor news_keyword: the keyword/phrase to watch in title+summary, e.g. moratorium
kindYesWatch kind: "new_deal_in_market" | "news_keyword" | "permitting_change" | "capacity" (a Capacity Source requirement, emailed, no webhook)
nameNoFor capacity: your human's full name, exactly as given; never invent it
roleNoFor capacity: your human's role or title
notesNoFor capacity: anything else about the requirement; leave out anything that identifies your human
stateNoFor permitting_change: optional US state filter, e.g. MN
marketNoFor new_deal_in_market: the market/region substring to watch, e.g. columbus
statesNoFor capacity: comma-separated US states, e.g. "TX, AZ"
companyNoFor capacity: your human's company
marketsNoFor capacity: comma-separated markets, e.g. "Dallas, Phoenix"
regionsNoFor capacity: comma-separated regions from north_america, latin_america, europe, asia_pacific, middle_east_africa (aliases emea, apac, latam, americas)
use_caseNoFor capacity: what the capacity is for, e.g. "AI inference"
countriesNoFor capacity: comma-separated countries, e.g. "Germany, Netherlands"
max_sitesNoFor capacity: how many sites the requirement may be split across, 1-6
target_kwNoFor capacity: capacity needed, in kW (or target_mw, not both)
target_mwNoFor capacity: capacity needed, in MW (or target_kw, not both)
webhook_urlNoYour public HTTPS webhook endpoint (required for every kind except capacity)
accept_termsNoFor capacity: true ONLY after your human read and agreed to https://dchub.cloud/listings#terms; otherwise nothing is sent
available_byNoFor capacity: needed by this date, YYYY-MM or YYYY-MM-DD
min_chunk_kwNoFor capacity: the smallest block worth taking, in kW
delivery_typeNoFor capacity: land, powered_shell, turnkey or colocation
terms_versionNoFor capacity: the terms version your human agreed to; omit to send the version currently published

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.

  1. Changed20 schema fields changedv2.12.21
    • addedInput schema / properties / accept_terms
      Added value: +{
+  "description": "For capacity: true ONLY after your human read and agreed to https://dchub.cloud/listings#terms; otherwise nothing is sent",
+  "type": "boolean"
+}
    • addedInput schema / properties / available_by
      Added value: +{
+  "description": "For capacity: needed by this date, YYYY-MM or YYYY-MM-DD",
+  "type": "string"
+}
    • addedInput schema / properties / company
      Added value: +{
+  "description": "For capacity: your human's company",
+  "type": "string"
+}
    • addedInput schema / properties / countries
      Added value: +{
+  "description": "For capacity: comma-separated countries, e.g. \"Germany, Netherlands\"",
+  "type": "string"
+}
    • addedInput schema / properties / delivery_type
      Added value: +{
+  "description": "For capacity: land, powered_shell, turnkey or colocation",
+  "enum": [
+    "land",
+    "powered_shell",
+    "turnkey",
+    "colocation"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / kind / description
      Previous value: -"Watch kind: \"new_deal_in_market\" | \"news_keyword\" | \"permitting_change\""New value: +"Watch kind: \"new_deal_in_market\" | \"news_keyword\" | \"permitting_change\" | \"capacity\" (a Capacity Source requirement, emailed, no webhook)"
    • addedInput schema / properties / markets
      Added value: +{
+  "description": "For capacity: comma-separated markets, e.g. \"Dallas, Phoenix\"",
+  "type": "string"
+}
    • addedInput schema / properties / max_sites
      Added value: +{
+  "description": "For capacity: how many sites the requirement may be split across, 1-6",
+  "type": "number"
+}
    • addedInput schema / properties / min_chunk_kw
      Added value: +{
+  "description": "For capacity: the smallest block worth taking, in kW",
+  "type": "number"
+}
    • addedInput schema / properties / name
      Added value: +{
+  "description": "For capacity: your human's full name, exactly as given; never invent it",
+  "type": "string"
+}
    • addedInput schema / properties / notes
      Added value: +{
+  "description": "For capacity: anything else about the requirement; leave out anything that identifies your human",
+  "type": "string"
+}
    • addedInput schema / properties / regions
      Added value: +{
+  "description": "For capacity: comma-separated regions from north_america, latin_america, europe, asia_pacific, middle_east_africa (aliases emea, apac, latam, americas)",
+  "type": "string"
+}
    • addedInput schema / properties / role
      Added value: +{
+  "description": "For capacity: your human's role or title",
+  "type": "string"
+}
    • addedInput schema / properties / states
      Added value: +{
+  "description": "For capacity: comma-separated US states, e.g. \"TX, AZ\"",
+  "type": "string"
+}
    • addedInput schema / properties / target_kw
      Added value: +{
+  "description": "For capacity: capacity needed, in kW (or target_mw, not both)",
+  "type": "number"
+}
    • addedInput schema / properties / target_mw
      Added value: +{
+  "description": "For capacity: capacity needed, in MW (or target_kw, not both)",
+  "type": "number"
+}
    • addedInput schema / properties / terms_version
      Added value: +{
+  "description": "For capacity: the terms version your human agreed to; omit to send the version currently published",
+  "type": "string"
+}
    • addedInput schema / properties / use_case
      Added value: +{
+  "description": "For capacity: what the capacity is for, e.g. \"AI inference\"",
+  "type": "string"
+}
    • changedInput schema / properties / webhook_url / description
      Previous value: -"Your public HTTPS webhook endpoint (required)"New value: +"Your public HTTPS webhook endpoint (required for every kind except capacity)"
    • changedInput schema / required
      Previous value: -[
-  "kind",
-  "webhook_url"
-]New value: +[
+  "kind"
+]
  2. Addedv2.12.10

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the mutation/open-world profile, and the description adds substantial context beyond them: HMAC signing scheme, embeddable secret that must be saved, silent first-evaluation watermark, auto-disable after 5 straight delivery failures, ~2h evaluation cadence, and rejection of private/internal webhook hosts. This is rich, decision-relevant behavioral detail.

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?

The core purpose and the push-vs-poll framing are front-loaded, and given two distinct modes (webhook intent and capacity requirement) across 22 params most content earns its place. It is dense and run-on with many parentheticals, but little is truly redundant.

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 22-param, dual-mode tool this covers the full register→sign→deliver→auto-disable lifecycle, the key/email prerequisite, and the capacity confirmation-email flow. An output schema exists, yet the description still notes the {intent_id, secret} return without over-explaining, so nothing an agent needs to call it correctly is missing.

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 meaning beyond the schema: it groups params by kind ('market / q / state — the watch parameter for the chosen kind'), explains the capacity-vs-webhook mode split, the claim_free_key→bind_email prerequisite, and the accept_terms gating. It roughly maps each field to its kind, which helps an agent avoid cross-mode errors.

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?

States a precise verb+resource (register a STANDING QUERY with webhook push) and immediately distinguishes the push model from polling ('push, not poll'). It also names the sibling alternatives it is not (get_news, list_transactions, source_capacity, set_market_alert), so an agent can route correctly without opening a schema.

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 is given via worked examples ('notify my orchestrator whenever a new moratorium appears', 'push me new matches instead of making me poll') and an explicit Do-NOT list naming the exact alternatives for one-shot reads, one-off capacity search, and market email alerts. Nothing is left to inference.

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

Deploy Server

Other Tools