DC Hub

Get Subsea Cables

get_subsea_cables

Read-onlyIdempotent

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

Name	Required	Description
`lat`	No	Latitude of the site, e.g. 36.85 — with lon, returns landing points near it; omit both for the cable catalogue
`lng`	No	Alias for lon — either name works
`lon`	No	Longitude of the site, e.g. -75.98
`limit`	No	Max results to return (1-500; default varies by tool)
`latitude`	No	Alias for lat — either name works
`longitude`	No	Alias for lon — either name works
`radius_km`	No	Search radius in km around lat/lon for landing points (default 200)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 19, 2026
- removedOutput schema / properties / _entity
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / _front_door
```
Removed value: -{
-  "type": "object"
-}
```
- removedOutput schema / properties / _return_loop
```
Removed value: -{
-  "type": "object"
-}
```
- removedOutput schema / properties / citation
```
Removed value: -{}
```
- removedOutput schema / properties / provenance
```
Removed value: -{
-  "type": "object"
-}
```
- removedOutput schema / properties / quota
```
Removed value: -{
-  "type": "object"
-}
```
- removedOutput schema / properties / site_evaluation_handoff
```
Removed value: -{}
```

Changed19 schema fields changedOct 18, 2026

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 / description

Removed value: -"Payload class (facility|market|iso_grid|queue_results|deal|report|response); branch on it."

removedOutput schema / properties / _front_door / additionalProperties
```
Removed value: -{}
```

removedOutput schema / properties / _front_door / description

Removed value: -"First-tool hint: plan_query(intent) returns the ordered plan."

removedOutput schema / properties / _front_door / properties
```
Removed value: -{}
```
removedOutput schema / properties / _return_loop / additionalProperties
```
Removed value: -{}
```
removedOutput schema / properties / _return_loop / description
```
Removed value: -"Next-session delta call (get_changes)."
```
removedOutput schema / properties / _return_loop / properties
```
Removed value: -{}
```

removedOutput schema / properties / citation / anyOf

Removed value: -[
-  {
-    "additionalProperties": {},
-    "properties": {},
-    "type": "object"
-  },
-  {
-    "type": "string"
-  }
-]

removedOutput schema / properties / citation / description

Removed value: -"How to attribute DC Hub: {source, url, license, cite_as, retrieved_at}, or the attribution line as a string."

removedOutput schema / properties / provenance / additionalProperties
```
Removed value: -{}
```

removedOutput schema / properties / provenance / description

Removed value: -"Source, method, as_of, verification_counts, license, cite_as; quote it when citing."

removedOutput schema / properties / provenance / properties
```
Removed value: -{}
```
removedOutput schema / properties / quota / additionalProperties
```
Removed value: -{}
```

removedOutput schema / properties / quota / description

Removed value: -"Caller quota state (remaining calls, tier)."

removedOutput schema / properties / quota / properties
```
Removed value: -{}
```

removedOutput schema / properties / site_evaluation_handoff / anyOf

Removed value: -[
-  {
-    "items": {
-      "additionalProperties": {},
-      "properties": {},
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "additionalProperties": {},
-    "properties": {},
-    "type": "object"
-  }
-]

removedOutput schema / properties / site_evaluation_handoff / description

Removed value: -"Follow-up calls [{tool, parameters, why}] when the payload carries coordinates."

AddedOct 9, 2026
RemovedSep 29, 2026
AddedSep 7, 2026

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.

All DC Hub tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.