Skip to main content
Glama

Register Standing Intent (webhook push)

register_standing_intent

Use this when the user wants a webhook when data center deals change: 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). 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…

Input 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

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • removedOutput schema / properties / _entity
      Removed value: -{
      -  "type": "string"
      -}
    • removedOutput schema / properties / _front_door
      Removed value: -{
      -  "type": "object"
      -}
    • removedOutput schema / properties / _return_loop
      Removed value: -{
      -  "type": "object"
      -}
    • removedOutput schema / properties / citation
      Removed value: -{}
    • removedOutput schema / properties / provenance
      Removed value: -{
      -  "type": "object"
      -}
    • removedOutput schema / properties / quota
      Removed value: -{
      -  "type": "object"
      -}
    • removedOutput schema / properties / site_evaluation_handoff
      Removed value: -{}
  2. Changed19 schema fields changed
    • changedOutput schema / additionalProperties
      Previous value: -{}New value: +true
    • removedOutput schema / description
      Removed value: -"DC Hub envelope: tool data fields ride at the top level beside these keys."
    • removedOutput schema / properties / _entity / description
      Removed value: -"Payload class (facility|market|iso_grid|queue_results|deal|report|response); branch on it."
    • removedOutput schema / properties / _front_door / additionalProperties
      Removed value: -{}
    • removedOutput schema / properties / _front_door / description
      Removed value: -"First-tool hint: plan_query(intent) returns the ordered plan."
    • removedOutput schema / properties / _front_door / properties
      Removed value: -{}
    • removedOutput schema / properties / _return_loop / additionalProperties
      Removed value: -{}
    • removedOutput schema / properties / _return_loop / description
      Removed value: -"Next-session delta call (get_changes)."
    • removedOutput schema / properties / _return_loop / properties
      Removed value: -{}
    • removedOutput schema / properties / citation / anyOf
      Removed value: -[
      -  {
      -    "additionalProperties": {},
      -    "properties": {},
      -    "type": "object"
      -  },
      -  {
      -    "type": "string"
      -  }
      -]
    • removedOutput schema / properties / citation / description
      Removed value: -"How to attribute DC Hub: {source, url, license, cite_as, retrieved_at}, or the attribution line as a string."
    • removedOutput schema / properties / provenance / additionalProperties
      Removed value: -{}
    • removedOutput schema / properties / provenance / description
      Removed value: -"Source, method, as_of, verification_counts, license, cite_as; quote it when citing."
    • removedOutput schema / properties / provenance / properties
      Removed value: -{}
    • removedOutput schema / properties / quota / additionalProperties
      Removed value: -{}
    • removedOutput schema / properties / quota / description
      Removed value: -"Caller quota state (remaining calls, tier)."
    • removedOutput schema / properties / quota / properties
      Removed value: -{}
    • removedOutput schema / properties / site_evaluation_handoff / anyOf
      Removed value: -[
      -  {
      -    "items": {
      -      "additionalProperties": {},
      -      "properties": {},
      -      "type": "object"
      -    },
      -    "type": "array"
      -  },
      -  {
      -    "additionalProperties": {},
      -    "properties": {},
      -    "type": "object"
      -  }
      -]
    • removedOutput schema / properties / site_evaluation_handoff / description
      Removed value: -"Follow-up calls [{tool, parameters, why}] when the payload carries coordinates."
  3. Added
  4. Removed
  5. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations declare the safety profile (readOnly=false, idempotent=false, openWorld=true), and the description adds substantial context beyond them: a key is required, deliveries are HMAC-signed with a documented X-DCHub-Signature header, private/internal hosts are rejected, and the caller must persist the returned secret. That is exactly the extra operational detail annotations cannot convey.

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

Conciseness3/5

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

The purpose and return contract are front-loaded, but the description is overlong, repeats example intents, and is visibly truncated ("optional…"), leaving the capacity branch described in fragments. Sentences mostly earn their place but the size and the cut-off hurt.

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 22-parameter tool with only one required param and an existing output schema, the description covers purpose, mechanics, auth/key requirement, and the {intent_id, secret} return well. The truncated capacity branch means some sub-mode parameters are described only through the schema, but nothing critical is missing for the primary webhook path.

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 the baseline is 3, but the description goes further by mapping kind values to their watch parameter (new_deal_in_market→market, news_keyword→q, permitting_change→state) and by stating the webhook_url validation rule (public HTTPS only) that the schema does not express.

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 specific verb and resource (register a standing query with webhook push) and immediately distinguishes it from poll-based siblings ("push, not poll") and from list_standing_intent/delete_standing_intent. An agent can tell what it does and which sibling it is not without opening the schema.

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?

Opens with an explicit trigger ("Use this when the user wants a webhook when data center deals change") and gives concrete user phrasings that map to it. It also flags the capacity variant and that webhook_url is required for every kind except capacity, but does not explicitly say when NOT to use this in favor of poll-based siblings like set_market_alert.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.