Skip to main content
Glama

DC Hub — Data Center & Power Intelligence

by cloud.dchub

Hyperscaler Deal Tracker

hyperscaler_deals
Read-onlyIdempotent

Hyperscaler AI Deal Tracker — live feed of Stargate, OpenAI, Anthropic, Microsoft, Oracle, CoreWeave, AMD, NVIDIA, sovereign-AI deals. Pulls from dchub news pipeline, extracts $-figures + MW via regex, classifies by actor. 10-min refresh. Use for tracking AI capex events ($1B+/week typical), capacity announcements, and competitive intel. Do NOT use for the full historical M&A comp set (use list_transactions) or a single-deal teardown with grid context (use deal_autopsy); this is the live $1B+ AI-capex feed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of recent AI-capex deals to return (default 20)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dealsNoLive AI-capex deal feed entries, newest first
errorNoFeed error, if any (null on success)
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.
landingNoHuman landing page URL
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.
feed_nameNoFeed identity line
live_feedNoLive feed URL
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.
computed_atNoFeed computation timestamp (10-min refresh)
methodologyNoHow deals are extracted and classified
_return_loopNoSuggested next-session delta call (get_changes since=24h) so you pull only what changed.
result_countNoNumber of deals returned
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.1/5.0
Behavior4/5

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

The annotation already marks the tool as readOnly, idempotent, and non-destructive. The description adds useful behavioral context by mentioning it's a 'live feed' with a '10-min refresh' and describing the extraction process (regex, classification). It does not contradict the annotations, though it omits details like auth or rate limits.

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 excessively verbose, repeating the same information (deal types, source, refresh rate, usage guidance) multiple times. For example, the phrase 'Hyperscaler AI Deal Tracker' and the list of companies appear twice, and the usage note is duplicated with a trailing repetition. This could be condensed to a single concise paragraph without loss of meaning.

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?

Given the existence of an output schema (not shown but indicated), the description does not need to explain return values. It covers the tool's purpose, usage, and exclusions thoroughly. It also provides background on data sources (dchub news pipeline) and processing (regex, classification), making it sufficiently complete for an agent to decide when to use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'limit' is described in both the schema and the description, achieving 100% coverage. The description merely restates the schema's description without adding new meaning, so the baseline score of 3 is appropriate given high schema coverage.

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 clearly identifies the tool as a 'Hyperscaler AI Deal Tracker' that provides a live feed of specific deal types. It explicitly distinguishes itself from sibling tools by stating what it is not for and naming the alternatives (list_transactions, deal_autopsy). This gives a precise purpose.

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 provides explicit 'Use for' conditions (tracking AI capex events, capacity announcements, competitive intel) and explicit 'Do NOT use for' scenarios with references to alternative tools. This leaves no ambiguity about when to invoke this tool.

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