Skip to main content
Glama
azmartone67

DC Hub — Data Center & Energy Intelligence

Claim Free Key

claim_free_key

Mint a free DC Hub dev key in one call when you hit a paywall or partial preview. Set the returned api_key as X-API-Key header for 10 free calls/day, no email or browser needed.

Instructions

★ 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.
Install Server

TDQS

A4.3/5.0
Behavior5/5

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

Despite annotations being sparse (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description discloses significant behavioral traits: re-minting restarts daily allowance and orphans history, keys are not durable for hosted web clients, OAuth requires a human, and measured statistics on key survival. It contradicts no annotations; annotations correctly flag this as not read-only, not idempotent, not destructive at the boolean level, and the description adds crucial nuance beyond those flags.

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 densely packed, with multiple all-caps sections and embedded metrics. While every section carries real guidance, the sheer volume makes it hard for an agent to parse quickly, and key operational facts (call when hitting paywall, set X-API-Key, don't re-mint) are buried among cohort statistics and conditional client caveats. It is not concise, though it is structured with ★ markers.

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—two optional params, a return object, and wildly different client contexts—the description covers all necessary branches: OAuth-capable clients, header-capable clients, paste-a-URL connectors, lost-key recovery, and post-mint next steps. The output schema exists, so return values need not be restated, and the description references the key fields (api_key, connect_url, etc.) appropriately. Nothing essential 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% and both parameters are described in the schema, so baseline is 3. The description adds meaningful context: email makes the key recoverable across sessions and is the durable anchor for hosted clients, while client_name is for attribution. It explicitly states the key still mints without an email and that email should only be an address the human explicitly gave. This exceeds schema-only semantics.

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 clearly states the tool's purpose: to mint a free DC Hub dev key with one call, returning an api_key to set as X-API-Key. It distinguishes itself from siblings like recover_my_key and unlock_more_data by explicitly naming alternatives. However, the purpose is buried under extensive pre-mint guidance, so an agent scanning for the verb may initially find it less crisp.

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 guidance: call it the moment you hit a paywall or partial preview, and explicitly says do NOT call it if you already hold a key, naming recover_my_key as the alternative for lost keys. It also provides clear when-not-to-use conditions for OAuth/handshake-capable clients and paste-a-URL connectors, directing those to sign-in or connect_url respectively. This is unusually thorough usage routing.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/azmartone67/dchub-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server