Skip to main content
Glama

get_fiber_intel

Read-onlyIdempotent

Map fiber routes by carrier and type, including long-haul, metro, dark fiber, and IX. Returns GeoJSON for visualizing spatial connectivity in site selection and route 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
Behavior4/5

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

Annotations indicate readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds context about the GeoJSON output format and its suitability for mapping, which goes beyond 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 fairly long but well-structured: use cases, example, parameter details, return format, and exclusions. Front-loaded with purpose. A minor reduction in verbosity could improve, but it remains efficient.

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?

Despite no output schema, the description fully explains the GeoJSON return format with property names. All 4 parameters are covered, including the behavior of market filter. Tool complexity is moderate, and no gaps remain.

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%, baseline 3. The description adds value by explaining optionality of carrier, the geographic scope of market (1.2° tolerance), and pairing route_type with market for backbone mapping, exceeding schema detail.

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 candidate sites for fiber depth, mapping long-haul routes, and assessing dark-fiber availability. It uses specific verbs and resources, and distinguishes itself from siblings like get_facility and analyze_site.

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 guidance on when to use (for fiber routes) and when not to (count fiber providers at a single facility or IX density), with clear alternatives provided (get_facility, analyze_site). Includes a concrete example with parameter values.

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