Skip to main content
Glama
azmartone67

DC Hub — Data Center & Energy Intelligence

Get Subsea Cables

get_subsea_cables
Read-onlyIdempotent

Locate the nearest subsea cable landing by coordinates with distance in km, or list all tracked cables globally for connectivity siting.

Instructions

Subsea (submarine) cable landings near a coordinate, or the global cable catalogue. The physical internet crossing an ocean lands at a finite number of points, and distance to one is a real siting factor for anything latency- or transit-sensitive. Pass lat+lon (+radius_km) for LANDING POINTS near a site — each with name, coordinates and distance_km. Omit coordinates for the CATALOGUE of tracked cables (712 tracked; each with cable_id, name, owners, length_km, rfs_year, is_planned — sparse fields are null, not guessed). ★ READ field_coverage AND connectivity_note BEFORE DRAWING A CONCLUSION: cable_count per landing point is NOT populated — the ingest writes the column but the upstream TeleGeography feed does not supply what it derives from, so every row carries the default 0. That is why connectivity_grade comes back null rather than graded: proximity to a landing point does NOT establish how many cables are reachable from it, and DC Hub will not infer a grade it cannot source. A filter over cable_count returns nothing for the same reason. Treat 0 as UNKNOWN, never as "no cables". Answers "which subsea cables land near this Virginia site" and "how far is the nearest cable landing from my campus". Try: get_subsea_cables lat=36.85 lon=-75.98 radius_km=200 — or get_subsea_cables (no args) for the catalogue. Do NOT use for terrestrial fiber routes (get_fiber_intel), a parcel fiber verdict (get_fiber_readiness), metro fiber depth (get_metro_fiber), or internet-exchange / peering density (get_peering_intel).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNoLatitude of the site, e.g. 36.85 — with lon, returns landing points near it; omit both for the cable catalogue
lngNoAlias for lon — either name works
lonNoLongitude of the site, e.g. -75.98
limitNoMax results to return (1-500; default varies by tool)
latitudeNoAlias for lat — either name works
longitudeNoAlias for lon — either name works
radius_kmNoSearch radius in km around lat/lon for landing points (default 200)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.
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.
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.

  1. Addedv2.12.10

TDQS

A5/5.0
Behavior5/5

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

The description goes beyond the read-only annotation by disclosing data caveats: cable_count is not populated (defaults to 0), connectivity_grade comes back null, and 0 should be treated as UNKNOWN. It explains the upstream feed limitation and warns about filtering on cable_count, providing critical behavioral transparency.

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 essential information: the two modes, output fields, data caveats, example calls, and exclusions. There is no filler; the warning about cable_count is purposeful and not redundant. The structure is front-loaded with the core function and ends with clear non-use cases.

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 provides complete context: output characteristics for both modes, data quality caveats, example values, and a clear boundary against 4 sibling tools. An agent can confidently decide when to call this tool and what to expect from the results, even without an explicit output schema.

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?

All 7 parameters have descriptions in the schema, and the description adds extra context: aliases (lng/lon, latitude/lat, longitude/lon), the default radius of 200 km, and the conditional use of coordinates vs. catalogue. Schema coverage is 100%, and the description enriches meaning beyond the schema.

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 two distinct modes (landing points near a coordinate, or the global cable catalogue) and explicitly distinguishes this tool from sibling tools like get_fiber_intel, get_fiber_readiness, get_metro_fiber, and get_peering_intel, making its 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 gives explicit when-to-use guidance with example questions ('which subsea cables land near this Virginia site') and a concrete invocation example. It also states what NOT to use it for, naming the specific sibling tools and their purposes.

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

Deploy Server

Other Tools