Skip to main content
Glama
azmartone67

DC Hub — Data Center & Energy Intelligence

Fiber Intelligence

get_fiber_intel
Read-onlyIdempotent

Map fiber routes by carrier and route type to score site fiber depth and assess dark-fiber availability for data-center planning.

Instructions

Use when scoring a candidate site for fiber depth, mapping long-haul routes between metros, or assessing dark-fiber availability for a hyperscale build. Example: "Show all Zayo long-haul fiber routes through Northern Virginia I can put on a Leaflet map." — get_fiber_intel carrier=Zayo route_type=longhaul. Params: carrier one of "Zayo" | "Lumen" | "Cogent" | "Crown Castle" | "Windstream" | "GTT" | "Uniti" | "FiberLight" | "Segra" | "Arcadian Infracom" (omit for all carriers); route_type one of "metro" | "longhaul" | "dark" | "ix"; market a metro name or slug (e.g. "dallas", "ashburn", "northern-virginia") to return ONLY routes touching that metro (either endpoint near it) — pairs well with route_type=longhaul to map a metro's long-haul backbones. Returns: GeoJSON FeatureCollection {features:[{geometry, properties:{carrier, route_type, fiber_count, lit_capacity_gbps, capacity, distance_miles, distance_km}}]} ready to drop into Leaflet/Mapbox. Do NOT use to count fiber providers at a single facility (use get_facility) or for IX interconnection-density scores (use analyze_site).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
marketNoMetro name or slug (e.g. "dallas", "ashburn", "northern-virginia") — returns only routes touching that metro (either endpoint within ~1.2°). Great with route_type=longhaul.
carrierNoFiber carrier to filter on, e.g. Zayo, Lumen, Cogent, "Crown Castle", Windstream, GTT, Uniti; omit for all carriers
route_typeNoRoute class: "metro", "longhaul", "dark", or "ix"
include_sourcesNoInclude upstream data-source/provenance metadata in the response

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNo"FeatureCollection" — the payload is GeoJSON, ready for Leaflet/Mapbox
quotaNoCaller quota state (remaining calls, tier) when available.
totalNoTotal routes matching the filter (null when withheld by tier)
_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.
featuresNoFiber route features
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.
Behavior4/5

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

Annotations already cover readOnly/idempotent/destructive safety. The description adds valuable behavioral context: returns GeoJSON FeatureCollection ready for Leaflet/Mapbox, market filtering only touches routes near the metro endpoint, and pairs well with route_type=longhaul. It does not contradict annotations.

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

Conciseness4/5

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

The description is well-structured with clear sections (use case, example, params, return format, exclusions). It is longer than average but every sentence adds value; no fluff. The front-loading of the use case is effective.

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 description is fully self-contained: usage scenarios, parameter details with enum values, example, output format, and exclusions with alternatives. With full schema coverage and annotations, there is no critical missing context.

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

Parameters5/5

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

Even though schema coverage is 100%, the description adds substantial value beyond the schema: it enumerates valid carrier values and route_type values, gives example market slugs, and explains how market pairs with longhaul. This is critical for correct invocation.

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 states the tool's purpose: 'scoring a candidate site for fiber depth, mapping long-haul routes between metros, or assessing dark-fiber availability.' It uses a specific verb and resource ('get_fiber_intel') and distinguishes from siblings by explicitly saying what NOT to use it for (facility-level provider counts or IX density).

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?

Explicit usage guidance is provided: 'Use when...' and 'Do NOT use...' with alternative tools named (get_facility, analyze_site). A concrete example query is given to illustrate invocation. This fully covers when and when not to use the tool.

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