get_peering_intel
Internet-exchange (IX/IXP) and peering density for a site, from PeeringDB. Pass lat+lon for the PEERING PROFILE around that point: facilities_nearby, a 0-100 score with its level, total_ix_presence, total_networks, and top_facilities each with ix_count and net_count — e.g. Ashburn comes back with...
This record as markdown: /tools/cloud-dchub-mcp-server/get-peering-intel.md
What get_peering_intel does on Mcp Server
AI agents call get_peering_intel to retrieve information from Mcp Server without modifying anything. It is typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
lat | number | — | Latitude of the site, e.g. 39.04 — with lon, returns the peering profile around it; omit both for the IXP directory |
lng | number | — | Alias for lon — either name works |
lon | number | — | Longitude of the site, e.g. -77.48 |
limit | integer | — | Max results to return (1-500; default varies by tool) |
latitude | number | — | Alias for lat — either name works |
longitude | number | — | Alias for lon — either name works |
Parameters from the server's own tool schema.
Why get_peering_intel is rated Low
Tool queries public peering infrastructure data with no side effects or state changes.
From the tool's definition retrieves peering density, IX presence, networks from PeeringDB; no modifications
Attacks that exploit this kind of access
The rule that runs get_peering_intel safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Mcp Server, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For get_peering_intel, this is the rule to start with:
get_peering_intel is read-only, so it stays allowed. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Mcp Server, apply this rule, and every get_peering_intel call is checked against it from then on.
Questions about get_peering_intel
Internet-exchange (IX/IXP) and peering density for a site, from PeeringDB. Pass lat+lon for the PEERING PROFILE around that point: facilities_nearby, a 0-100 score with its level, total_ix_presence, total_networks, and top_facilities each with ix_count and net_count — e.g. Ashburn comes back with 61 IX presences and 903 networks across the nearby sites, led by Equinix DC1-DC15 at 516 networks. Omit coordinates for the IXP directory (name, name_long, city, country, net_count, fac_count, media, protocols, policy/tech contacts). This is the layer that answers "can I actually reach networks cheaply from here", which fiber route geometry does not: a site can sit on dense fiber and still be far from any exchange. The score is a DERIVED convenience over PeeringDB counts, not a DC Hub-sourced grade — cite the underlying counts (facilities, IX presence, networks) rather than the score when it is load-bearing. Records are PeeringDB's, refreshed on read. Answers "how good is peering at this Ashburn site" and "which internet exchanges serve the Dallas market". Try: get_peering_intel lat=39.04 lon=-77.48 — or get_peering_intel (no args) for the IXP directory. Do NOT use for fiber route geometry (get_fiber_intel), near-net carrier distance at a parcel (get_fiber_readiness), metro fiber depth (get_metro_fiber), or subsea landings (get_subsea_cables). It is categorised as a Read tool in the Mcp Server MCP Server, which means it retrieves data without modifying state.
get_peering_intel accepts 6 parameters: lat, lng, lon, limit, latitude, longitude. The full parameter table on this page comes from the server's own tool schema.
Register the Mcp Server MCP server in PolicyLayer and add a rule for get_peering_intel: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Mcp Server. Nothing to install.
get_peering_intel is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the get_peering_intel rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for get_peering_intel. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
get_peering_intel is provided by the Mcp Server MCP server (https://dchub.cloud/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Mcp Server, and thousands of servers like it.
This server
Across the catalogue