Skip to main content
Glama
azmartone67

DC Hub: Data Center, Power Grid & Energy Intelligence

Get Subsea Cables

get_subsea_cables
Read-onlyIdempotent

Locate subsea cable landing points near a latitude/longitude with distances, or retrieve the tracked cable catalogue with owners and ready-for-service year for siting analysis.

Instructions

Use this when the user asks about subsea (submarine) cable landings near a site, or the 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. 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.

Input 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

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv2.12.45
    • changedOutput schema / additionalProperties
      Previous value: -{}New value: +true
    • removedOutput schema / description
      Removed value: -"DC Hub envelope: tool data fields ride at the top level beside these keys."
    • removedOutput schema / properties / _entity
      Removed value: -{
      -  "description": "Payload class (facility|market|iso_grid|queue_results|deal|report|response); branch on it.",
      -  "type": "string"
      -}
    • removedOutput schema / properties / _front_door
      Removed value: -{
      -  "additionalProperties": {},
      -  "description": "First-tool hint: plan_query(intent) returns the ordered plan.",
      -  "properties": {},
      -  "type": "object"
      -}
    • removedOutput schema / properties / _return_loop
      Removed value: -{
      -  "additionalProperties": {},
      -  "description": "Next-session delta call (get_changes).",
      -  "properties": {},
      -  "type": "object"
      -}
    • removedOutput schema / properties / citation
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "additionalProperties": {},
      -      "properties": {},
      -      "type": "object"
      -    },
      -    {
      -      "type": "string"
      -    }
      -  ],
      -  "description": "How to attribute DC Hub: {source, url, license, cite_as, retrieved_at}, or the attribution line as a string."
      -}
    • removedOutput schema / properties / provenance
      Removed value: -{
      -  "additionalProperties": {},
      -  "description": "Source, method, as_of, verification_counts, license, cite_as; quote it when citing.",
      -  "properties": {},
      -  "type": "object"
      -}
    • removedOutput schema / properties / quota
      Removed value: -{
      -  "additionalProperties": {},
      -  "description": "Caller quota state (remaining calls, tier).",
      -  "properties": {},
      -  "type": "object"
      -}
    • removedOutput schema / properties / site_evaluation_handoff
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "items": {
      -        "additionalProperties": {},
      -        "properties": {},
      -        "type": "object"
      -      },
      -      "type": "array"
      -    },
      -    {
      -      "additionalProperties": {},
      -      "properties": {},
      -      "type": "object"
      -    }
      -  ],
      -  "description": "Follow-up calls [{tool, parameters, why}] when the payload carries coordinates."
      -}
  2. Changed8 schema fields changedv2.12.43
    • changedOutput schema / description
      Previous value: -"DC Hub envelope: structuredContent mirrors the JSON payload in content[0].text — tool-specific data fields ride at the top level alongside these envelope keys."New value: +"DC Hub envelope: tool data fields ride at the top level beside these keys."
    • changedOutput schema / properties / _entity / description
      Previous value: -"Payload class discriminator (e.g. facility|market|iso_grid|queue_results|deal|report|response) — branch on this before parsing the rest."New value: +"Payload class (facility|market|iso_grid|queue_results|deal|report|response); branch on it."
    • changedOutput schema / properties / _front_door / description
      Previous value: -"In-band front-door hint (first workflow-entry tool of a session): call plan_query(intent) first for the ordered multi-step plan."New value: +"First-tool hint: plan_query(intent) returns the ordered plan."
    • changedOutput schema / properties / _return_loop / description
      Previous value: -"Suggested next-session delta call (get_changes since=24h) so you pull only what changed."New value: +"Next-session delta call (get_changes)."
    • changedOutput schema / properties / citation / description
      Previous value: -"Machine-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."New value: +"How to attribute DC Hub: {source, url, license, cite_as, retrieved_at}, or the attribution line as a string."
    • changedOutput schema / properties / provenance / description
      Previous value: -"Collection-level provenance block: {source, method, as_of, verification_counts, cite_url_template, license, cite_as}. Quote the verification level when citing."New value: +"Source, method, as_of, verification_counts, license, cite_as; quote it when citing."
    • changedOutput schema / properties / quota / description
      Previous value: -"Caller quota state (remaining calls, tier) when available."New value: +"Caller quota state (remaining calls, tier)."
    • changedOutput schema / properties / site_evaluation_handoff / description
      Previous value: -"Pre-built follow-up calls (analyze_site / get_water_risk args) when the payload carries coordinates — an array of {tool, parameters, why} entries."New value: +"Follow-up calls [{tool, parameters, why}] when the payload carries coordinates."
  3. Addedv2.12.10

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, so the description only needs to add beyond them, and it does: cable_count is always 0 due to an upstream feed gap, connectivity_grade is null by design, and DC Hub will not infer a grade. That prevents a serious downstream misreading of the returned data.

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?

Front-loaded with the trigger and both modes, but the ★ caveat paragraph is dense and the emphasis styling plus a trailing example sentence make it longer than necessary for an experienced caller, even though every piece does carry information.

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?

Output schema exists, yet the description still covers the non-obvious parts an agent cannot get from the schema - the null/default field behavior and the reason grades are absent. Nothing needed to call it correctly or interpret results is missing.

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% and alias parameters are documented there, so the baseline is 3; the description adds real value by tying lat+lon+radius_km to a specific return shape and stating that omitting coordinates switches to catalogue mode, which the schema does not convey.

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 two specific modes with concrete resources: LANDING POINTS near a site (name, coordinates, distance_km) and the CATALOGUE of tracked cables (712, with field list). An agent can distinguish this from neighbors like get_fiber_intel or get_metro_fiber without opening a schema.

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 trigger ('use this when the user asks about subsea cable landings near a site, or the cable catalogue'), explicit mode selection rule ('Pass lat+lon (+radius_km)... Omit coordinates for the CATALOGUE'), and two worked example calls.

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