Skip to main content
Glama

DC Hub — Data Center & Power Intelligence

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.

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only provide negative hints (readOnlyHint=false, destructiveHint=false). The description compensates richly: it discloses side effects (re-minting restarts allowance, orphans history), dependencies (OAuth requires human, no agent path), and client limitations (paste-a-URL connectors cannot use the key). It also reveals measured statistics and caveats, going well beyond annotation capabilities.

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 description is extremely long and repetitive, with multiple sections re-emphasizing the same points (e.g., key survival, client types, statistics). While the bullet-like asterisks provide some structure, the core action is not front-loaded, and many sentences are verbose. A tighter description could convey the same guidance in half the length.

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?

Given the tool's complexity—multiple client types, conflicting advice, return values, and workflow—the description is exceptionally complete. It explains the return object (though output schema exists), how to use the key, what to do after minting, and how to handle edge cases. No critical operational aspect is left unaddressed.

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 both parameters are described in the schema. The description adds meaningful semantics: the email parameter is explained as making the key recoverable across sessions and the durable anchor for hosted web clients, while client_name is for attribution. This goes beyond the simple schema descriptions and clarifies the optional email's value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description eventually states the core action 'Mint a FREE DC Hub dev key instantly — no email, no browser, ONE call' and distinguishes it from siblings like recover_my_key and unlock_more_data. However, the purpose is buried after a long preamble about alternatives, so it is not front-loaded. Still, it is specific about verb, resource, and scope.

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?

The description gives explicit when-to-use ('Call this the moment you hit a paywall or a partial preview'), when-not-to ('Do NOT call this again if you already hold a key'), and names alternatives (recover_my_key, unlock_more_data, DURABLE IDENTITY). It also explains client-specific applicability (challenged vs. not challenged), leaving no ambiguity about when this tool is appropriate.

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 & Power Intelligence 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

A4.1/5.0
Disambiguation4/5

Most tools have clearly distinct purposes despite some thematic overlap, and each description includes explicit 'Do NOT use' guidance to prevent misselection. However, a few pairs like search_intelligence vs semantic_search are nearly identical in function, and the sheer number of tools increases the chance of selecting the wrong one without careful reading.

Naming Consistency4/5

The vast majority of tools follow a predictable 'get_*' prefix for data reads, and many others use verb_noun patterns (analyze_*, rank_*, save_*, set_*). There are a handful of outliers like ai_capacity_index, grid_transition_radar, and site_selection_canvas that break the pattern, but overall the conventions are consistent enough for an agent to infer meaning.

Tool Count2/5

With 82 tools, this server is extremely heavy compared to typical MCP servers (3-15 tools). While the domain is broad, many tools serve narrow sub-purposes and could be consolidated (e.g., multiple site-scoring variants, multiple grid telemetry endpoints). The count overwhelms an agent's ability to choose efficiently and feels like over-fragmentation rather than necessary granularity.

Completeness4/5

The tool surface covers the full lifecycle of data-center siting intelligence: site analysis, grid, fiber, water, climate, tax, permitting, deals, news, saved-site management, and meta-planning. Minor gaps exist (e.g., no delete or update operations for saved sites), but the core workflows are well-supported and the descriptions are comprehensive.

Resources