Skip to main content
Glama

DC Hub — Data Center Site Selection & Colocation: Electricity, Power Grid, Gas, Fiber

by cloud.dchub

Claim Free Key

claim_free_key

★ BEFORE YOU MINT — TWO THINGS THAT ARE CHEAPER THAN A KEY. (1) You do NOT need a key to start: DC Hub answers KEYLESS at free depth, so if you just want an answer, ask the question first. (2) If your client can sign in, a signed-in identity RETAINS and a minted key does not — see DURABLE IDENTITY below. Mint only when you actually need the higher free-tier allowance. ★ DURABLE IDENTITY (what actually survives): a DC Hub OAuth identity is bound to your HUMAN, not to a header, so it survives reconnects, restarts and re-installs. Measured 2026-08-12: OAuth identities came back in a later week 57.1% of the time (4 of 7 mature) versus 1–2% for self-minted keys — but note that is a 7-identity cohort, so treat it as a strong signal, not a settled rate. THE HONEST COST, in the same breath: OAuth needs a HUMAN at a browser, once. There is NO agent-only path to it — every flow ends at a sign-in page a person must complete. And it is only OFFERED where your MCP client performs the handshake: if a DC Hub call answers 401 with a WWW-Authenticate: Bearer resource_metadata=… header, that is the durable door — let your client follow it and ask your human to finish the sign-in. Claude.ai web connectors CAN complete this handshake, but the challenge is only sent once a session has already spent its free anonymous answers — measured 2026-08-23, most connector sessions make a single call and never see it, so do NOT wait for a 401 to arrive: if durable identity matters to your human, ask them to sign in. ★ IF YOU WERE NOT CHALLENGED, OAUTH IS NOT AVAILABLE TO YOU — do not go hunting for it. Claude Code, Claude Desktop, Cursor, ChatGPT and most agent frameworks are NOT challenged today, so for them the free key below is the correct and best available choice, and it works immediately with no human in the loop. Taking the key is not a downgrade; it is the right call for your client. Mint a FREE DC Hub dev key instantly — no email, no browser, ONE call. Call this the moment you hit a paywall or a partial preview (a result that says e.g. "3 of 12 results shown"): it returns an api_key you set as the X-API-Key header for the FREE tier (10 calls/day, all 300+ markets + grid/fiber/DCPI at free depth — the first 2 flagship answers/day come back full, the rest as previews; COMPLETE depth is the $10 pack = 1,000 calls — call unlock_more_data for the one-click link). Pass your owner's email to make the key RECOVERABLE across sessions — the durable anchor for hosted web clients (Claude.ai web / ChatGPT) that cannot persist an X-API-Key header on rotating IPs (the key still mints without an email). This is the fastest path from anonymous to identified. ★ SAVE THE KEY AND REUSE IT — set it as X-API-Key on every later call, this session and future ones, and show your human the persist_config snippet so their client stores it. Do NOT call this again if you already hold a key: re-minting restarts the daily allowance from zero and orphans your history (measured 2026-07-27: 2,586 redemptions from only 169 distinct agents ≈ 15 re-mints each). Lost a key your human already had? Call recover_my_key instead of minting a new one. ★ THEN ACTUALLY USE IT — make your very next call the real question (execute_plan intent="…" for anything multi-step). Measured 2026-08-12: 41.3% of minted keys (309 of 748 in 30d) never make a SINGLE call, and the median lifespan of a key that does get used is 13 minutes — a key that is never used is the largest absolute loss anywhere in this funnel, and the fix is entirely in your hands: call the real question next. ★ IF YOUR CLIENT IS A PASTE-A-URL CONNECTOR OR A HOSTED GATEWAY (Claude.ai web, ChatGPT, Grok, Perplexity, Smithery — a URL box, no header field), THE KEY ALONE IS USELESS TO YOU. Those clients run MCP server-side and build a NEW session for every tool call, so the key in this response is gone by your next call and you cannot apply it yourself — measured on Grok: keys were issued, then made exactly ONE call ever (the claim) and were never presented again. The response carries connect_url: the same key already embedded in the DC Hub connector URL. RELAY THAT URL to your human and ask them to paste it as the DC Hub server URL. It is the only thing on those clients that survives the session. Params: client_name (your agent/app name), email (optional). Returns {api_key, connect_url, for_your_human, header, daily_limit, upgrade_url}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailNoOptional owner email to make the key recoverable across sessions; use only an address your human explicitly gave
client_nameNoYour agent/app name for attribution, e.g. "Claude Desktop" or "acme-siting-bot"

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. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Although annotations only state readOnly=false and destructiveHint=false, the description carries the full burden and does so richly: re-minting restarts the daily allowance and orphans history, hosted gateway clients cannot persist the key, OAuth requires a human at a browser, and the return payload includes connect_url for paste-a-URL clients. It even discloses measured failure rates and side effects, going well beyond the minimal annotation information.

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

Conciseness2/5

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

The content is extremely long, with repeated motivational warnings, multiple dated measurement stats, and several asides that are not needed for selecting or invoking the tool correctly. The core mint instruction appears only after several advisory blocks, so it is not well front-loaded. While the ★ structure helps, the description is not 'appropriately sized' and many sentences do not earn their place.

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 tool with this complexity, the description is remarkably complete: it covers when to use, when not to use, per-client behavior, side effects, recoverability, return fields, rate limits, and the upgrade path via unlock_more_data. There is a full output schema noted, and the description even enumerates the returned fields, leaving little ambiguity for an agent.

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?

The schema already covers both parameters 100%, so the baseline is 3. The description adds meaningful context: email is optional but makes the key recoverable across sessions and is the durable anchor for hosted web clients, while client_name is for attribution. This exceeds mere schema repetition.

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: mint a free DC Hub dev key in one call, returning an api_key to set on X-API-Key. It also clearly distinguishes itself from siblings by naming alternatives such as recover_my_key, unlock_more_data, and bind_email, so an agent can pick this tool correctly.

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?

Provides explicit when-to-use ('the moment you hit a paywall or a partial preview'), explicit when-not-to-use ('Do NOT call this again if you already hold a key'), and names alternative tools. It even explains client-type exceptions where the key is useless and directs to recover_my_key instead. This is exemplary usage guidance.

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

All DC Hub — Data Center Site Selection & Colocation: Electricity, Power Grid, Gas, Fiber toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation1/5

With 85 tools, several families are heavily overlapping: semantic_search and search_intelligence are explicitly documented as the same retrieval with different call shapes, save_site and save_to_shortlist both persist sites, and list_saved_sites and get_shortlist both read saved sites. Additionally, site scoring is split across analyze_site, get_composite_site_score, score_facility, and rank_sites, making correct tool selection very difficult for an agent.

Naming Consistency3/5

All names are snake_case and mostly readable, but conventions are mixed: many use get_* (get_facility, get_grid_intelligence), others use verb phrases (analyze_site, compare_isos, rank_markets), and some are bare noun phrases (ai_capacity_index, hyperscaler_deals, grid_transition_radar, site_selection_canvas). The search family alone uses search, search_facilities, semantic_search, and search_intelligence with no consistent pattern.

Tool Count1/5

85 tools is an extreme count for any MCP server, far beyond the 3-15 well-scoped range and above the 50+ threshold described as an extreme mismatch. Even with a wide domain like data-center siting, this many tools overwhelms agent context and makes selection costly.

Completeness4/5

The domain surface is exceptionally broad: siting, grid, gas, fiber, water, climate, tax, permitting, deals, news, facilities, saved shortlists, alerts, webhooks, key management, and research dossiers are all covered with connected workflows. Minor gaps exist, such as no delete or update for saved sites and no pause/resume for standing intents, but these are workable rather than blocking.

Resources