Skip to main content
Glama

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

Search Facilities

search_facilities
Read-onlyIdempotent

FRONT DOOR CHECK — if the ask is "find MW in " or otherwise wants power / fiber / water / verdict context ATTACHED to the hits, call execute_plan(intent="<the user's question, unchanged>") instead of hand-chaining this with three more tools. If the ask is a plain inventory lookup — which facilities match these filters — search_facilities IS the right call and costs one round trip; the planner would add steps and latency for nothing. Search 20,700+ global data center facilities across 170+ countries — by location (country/state/market), capacity (MW), operator, fiber connectivity, status (operational/under-construction/planned), or DCPI verdict. Returns name, provider, lat/lon, power_mw, fiber count, market_slug, status. Answers "which data centers are in Virginia", "who has capacity in this country". Try: search_facilities country=US state=VA min_capacity_mw=10. Note: status is RETURNED but is not a filter — there is no status or min_mw parameter; to filter by construction stage use get_pipeline. Use this to find EXISTING facilities; do NOT use for the forward-looking construction pipeline (use get_pipeline) or for the full profile of one facility (use get_facility).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoCity name to filter facilities, e.g. Ashburn, Dallas
tierNoUptime Institute tier filter (1-4)
limitNoMax results to return (1-500; default varies by tool)
queryNoFree-text search over facility name/operator/location (mapped to the backend `q` param), e.g. "hyperscale Ashburn"
stateNoUS state abbreviation or region, e.g. VA, TX
offsetNoPagination offset, 0-based (skip this many results)
countryNoISO 3166-1 alpha-2 country code, e.g. US, GB, SG
operatorNoOperator/provider company name, e.g. Equinix, Digital Realty
max_capacity_mwNoMaximum power capacity filter in megawatts (MW)
min_capacity_mwNoMinimum power capacity filter in megawatts (MW)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoFacility rows matching the filters
noteNoServing note (e.g. how many rows the full tier returns)
tierNoTier the response was served at
countNoRows returned in THIS response (null on some gated tiers)
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.
successNotrue when the search executed
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.
total_matchingNoTotal rows matching the filter across the dataset (null when withheld by tier)
full_results_availableNofalse when the row set was trimmed for your tier
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
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds genuinely useful behavioral context: status is returned but not filterable, there is no `status` or `min_mw` parameter, and this tool costs one round trip versus a planner chain. It stops short of 5 because it doesn't address pagination or result limits, but schema covers that.

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 long but every sentence carries decision-relevant information, and the most important routing guidance is front-loaded in the 'FRONT DOOR CHECK'. It uses clearly labeled sections for returns, examples, notes, and exclusions, making the dense content scannable with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the return-field list is bonus rather than required. The description fully covers routing, scope, example invocation, exclusions, and the critical status-filter caveat, which is enough for an agent to select and call the tool correctly. The only real gap is the unsupported 'by market' filter claim, since the schema has no market parameter.

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. The description adds value by giving a concrete invocation example ('search_facilities country=US state=VA min_capacity_mw=10') and warning against using non-existent parameters like `status` and `min_mw`. The 'by market' phrase is slightly misleading because no market parameter exists, but the example compensates for that ambiguity.

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 the core action explicitly: 'Search 20,700+ global data center facilities' and answers inventory questions like 'which data centers are in Virginia'. It differentiates itself from sibling tools by naming get_pipeline and get_facility as alternatives for different needs, so an agent can tell exactly what this tool is for.

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 'FRONT DOOR CHECK' gives an explicit decision rule: asks that want power/fiber/water/verdict context should go to execute_plan, while plain inventory lookups should use this tool. It also explicitly says do NOT use it for the construction pipeline (use get_pipeline) or full facility profiles (use get_facility), leaving no ambiguity.

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

Try in Browser

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.