Skip to main content
Glama
azmartone67

DC Hub — Data Center & Energy Intelligence

Market Intelligence

get_market_intel
Read-onlyIdempotent

Retrieve detailed market intelligence for any data-center metro: vacancy, pricing, supply pipeline, operators, and YoY growth.

Instructions

Use when a user asks about ONE data-center market — vacancy, capacity pricing, supply pipeline, dominant operators, YoY growth — across any of 300+ markets. Example: "What is Northern Virginia's vacancy rate, $/MW-day pricing, and current DCPI verdict?" — get_market_intel market=northern-virginia. Params: market is the market_slug (e.g. "northern-virginia", "dallas", "phoenix", "frankfurt", "tokyo", "singapore"). Returns: {market, country, capacity_mw_total, capacity_mw_under_construction, vacancy_pct, absorption_mw_ttm, price_per_mw_day_usd, yoy_growth_pct, dominant_operators[], dcpi_verdict (BUILD/CAUTION/AVOID), composite_score, last_updated}. Do NOT use to rank multiple markets (use rank_markets) or for a single facility (use get_facility).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
marketNoMarket slug (metro), e.g. northern-virginia, dallas, frankfurt, singapore — valid slugs come from rank_markets / get_market_dcpi_rank
metricNoOptional single metric to focus on, e.g. vacancy, pricing, absorption, pipeline
periodNoOptional time window for the metric, e.g. ttm, 12mo, ytd
compare_toNoOptional second market slug to compare against, e.g. dallas

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
quotaNoCaller quota state (remaining calls, tier) when available.
statsNoHeadline market stats
_gatedNotrue when parts of the payload were withheld by tier
marketNoThe market identity block
_entityNoPayload class discriminator (e.g. facility|market|iso_grid|queue_results|deal|report|response) — branch on this before parsing the rest.
successNotrue when the market lookup succeeded
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.
by_statusNoFacility counts keyed by status (Operational, Under Construction, Planned, Announced, active)
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.
related_intelNoRAG-grounded related intelligence passages (cited)
top_providersNoDominant operators, largest first
recent_facilitiesNoRecently added / discovered facilities in the market
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.
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description doesn't need to restate safety. It adds value by describing the return shape, including the DCPI verdict enum (BUILD/CAUTION/AVOID) and the last_updated field, giving the agent concrete expectations without contradicting annotations.

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

Conciseness5/5

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

The description is well-structured with a clear usage trigger, an example, parameter explanation, return fields, and explicit exclusions. Every sentence contributes to the agent's understanding without redundancy or filler, making it both concise and information-dense.

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?

The tool has 4 optional params, rich annotations, and an output schema. The description covers when to use it, what it returns, examples, and exclusions, leaving no critical gaps. It is fully self-contained for a read-only market intelligence query tool.

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 input schema has 100% description coverage, providing a baseline of 3. The description goes further by explaining that 'market' is a market_slug with concrete examples ('northern-virginia', 'dallas', etc.) and by referencing where valid slugs come from (via the schema note). This added example-based semantics justifies a 4.

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?

The description states a specific verb and resource: 'Use when a user asks about ONE data-center market' covering vacancy, pricing, pipeline, operators, and growth. It explicitly distinguishes from siblings by saying 'Do NOT use to rank multiple markets (use rank_markets) or for a single facility (use get_facility)', making the purpose unambiguous.

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 clearly states when to use the tool ('Use when a user asks about ONE data-center market') and provides exclusions with alternative tool names ('Do NOT use to rank multiple markets (use rank_markets) or for a single facility (use get_facility)'). This is explicit and actionable.

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

Install Server

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