DC Hub

Request Capacity Intro

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).

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Your human's full name. Nothing is sent without it; use only what they gave you, never invent it
`role`	No	Your human's role or title
`slug`	No	The listing to register a deal for: its slug or id from source_capacity. Omit to register a standing requirement for upcoming listings instead
`notes`	No	Anything else the provider should know about the requirement. It travels with the requirement, so leave out anything that identifies your human
`states`	No	Comma-separated US states of interest, e.g. "TX, AZ"
`company`	No	Your human's company. Nothing is sent without it
`markets`	No	Comma-separated markets of interest, e.g. "Dallas, Phoenix"
`message`	No	A short note from your human for the provider. The deal registration itself carries only the company name and the requirement
`regions`	No	Comma-separated regions of interest from north_america, latin_america, europe, asia_pacific and middle_east_africa (aliases emea, apac, latam, americas), e.g. "europe, apac"
`timeline`	No	When the capacity is needed, e.g. a quarter and year
`use_case`	No	What the capacity is for, e.g. "AI inference"
`countries`	No	Comma-separated countries of interest, e.g. "Germany, Netherlands"
`capacity_kw`	No	Capacity needed, in kW (capacity_mw is the same requirement in MW)
`capacity_mw`	No	Capacity needed, in MW
`accept_terms`	No	Set true ONLY after your human has read and agreed to the introduction terms at https://dchub.cloud/listings#terms. Unless it is exactly true, nothing is sent
`terms_version`	No	The terms version your human agreed to, e.g. program.terms.version from source_capacity. Omit to send the version currently published

Output Schema

TableJSON Schema

Name	Required	Description
`quota`	No	Caller quota state (remaining calls, tier).
`_entity`	No	Payload class (facility\|market\|iso_grid\|queue_results\|deal\|report\|response); branch on it.
`citation`	No	How to attribute DC Hub: {source, url, license, cite_as, retrieved_at}, or the attribution line as a string.
`provenance`	No	Source, method, as_of, verification_counts, license, cite_as; quote it when citing.
`_front_door`	No	First-tool hint: plan_query(intent) returns the ordered plan.
`_return_loop`	No	Next-session delta call (get_changes).
`site_evaluation_handoff`	No	Follow-up calls [{tool, parameters, why}] when the payload carries coordinates.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 9, 2026
RemovedSep 29, 2026

Changed6 schema fields changedSep 16, 2026

addedInput schema / properties / capacity_kw

Added value: +{
+  "description": "Capacity needed, in kW (capacity_mw is the same requirement in MW)",
+  "type": "number"
+}

addedInput schema / properties / countries

Added value: +{
+  "description": "Comma-separated countries of interest, e.g. \"Germany, Netherlands\"",
+  "type": "string"
+}

changedInput schema / properties / message / description

Previous value: -"A short note from your human to the operator"New value: +"A short note from your human for the provider. The deal registration itself carries only the company name and the requirement"

changedInput schema / properties / notes / description

Previous value: -"Anything else the operator should know about the requirement"New value: +"Anything else the provider should know about the requirement. It travels with the requirement, so leave out anything that identifies your human"

addedInput schema / properties / regions

Added value: +{
+  "description": "Comma-separated regions of interest from north_america, latin_america, europe, asia_pacific and middle_east_africa (aliases emea, apac, latam, americas), e.g. \"europe, apac\"",
+  "type": "string"
+}

changedInput schema / properties / slug / description

Previous value: -"The listing to request an introduction for: its slug or id from source_capacity. Omit to register a standing requirement for upcoming listings instead"New value: +"The listing to register a deal for: its slug or id from source_capacity. Omit to register a standing requirement for upcoming listings instead"

AddedSep 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond annotations: discloses exactly what data is shared with the provider and when (company name and requirement only; identity/site/contact and human's name/role/email only on acceptance; nothing on decline), plus auth and terms requirements. Annotations cover non-mutation; the description carries the disclosure/auth semantics that annotations cannot.

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?

Front-loaded with 'Use when...' and organized by mode, prerequisites, disclosure behavior, and returns. Dense but long; nearly every sentence carries routing, privacy, or prerequisite information, though it could be tightened slightly.

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?

A 16-parameter, no-required-parameter tool with an output schema is fully served: the description explains mode selection, prerequisite call chain, consent gating, disclosure outcomes, and the follow-up sibling. Return values are noted briefly even though an output schema exists.

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 mode-selection semantics that the schema alone leaves implicit: slug is for a listing and its omission switches to standing-requirement mode, and capacity_mw/capacity_kw express the same requirement. That is genuine added meaning.

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+resource (register a capacity intro/deal) and clearly distinguishes two operating modes: pass a slug for a listing vs omit it for a standing requirement. An agent can tell exactly what the tool does 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 Guidelines5/5

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

Explicit when-to-use conditions for both modes, prerequisites (claim_free_key, then bind_email, accept_terms=true after reading terms), named alternative for the listing follow-up (source_capacity), and an explicit exclusion ('Do NOT use to save or monitor a site (use save_site / set_site_alert)').

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

All DC Hub tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.