peering-mcp

An MCP server that lets an AI agent look up how the internet is actually wired together — which networks connect to each other, at which internet exchanges and facilities, under what peering policy, and who a given address range is registered to.

Five read-only tools over two public sources: PeeringDB for interconnection, and the regional internet registries over RDAP for registration. Upstream responses are validated and shaped, free text is stripped of structure before it reaches a model, requests are rate limited to what PeeringDB asks for, and answers are cached on disk between runs. Every response is held to a byte budget.

Install it with uvx peering-mcp. A personal project, MIT licensed.

Why this exists

The internet is roughly eighty thousand independent networks that agree to carry each other's traffic. Which networks connect to which, where they meet, and on what terms is public, free and well structured — published through stable APIs by PeeringDB and the regional internet registries.

None of it is reachable by an AI agent. Ask a coding assistant which internet exchanges a given carrier is present at and it will answer from memory: fluent, confident, and often wrong. It has no way to check, so it does not check.

This server is that way to check.

What it does

find_common_presence is the tool that motivated the project. Working out where two or more networks could interconnect means looking each one up, listing everywhere it is present, and intersecting the results by hand. That is about an hour and a dozen browser tabs. It should be one question.

It takes two to five AS numbers and answers in four requests, whatever the number of networks. Shared exchanges come back widest bottleneck first — ordered by the smallest capacity any one network has there, because that is what a connection between them would be limited by.

It also returns how many locations each network has on its own, so an empty answer is explainable: either the networks genuinely do not overlap, or one of them has no records at all, which is a very different thing.

find_at_exchange asks it the other way round: who is already at DE-CIX Frankfurt, and which of them will peer with anyone. It takes an exchange name or its PeeringDB id, optionally keeps only the networks stating one peering policy, and returns them largest capacity first. A name matching several exchanges — ten of them are called LINX, on four continents — comes back as candidates to choose between, never a guess at which one was meant.

lookup_registration is the one tool here that does not read PeeringDB. It asks the registry that made the allocation — RIPE NCC, ARIN, APNIC, LACNIC or AFRINIC — and answers with the holder, the allocation date, the range the registration actually covers, and where to report abuse. Which registry to ask is itself a lookup, resolved from IANA's own bootstrap files rather than through a third-party redirector, so the answer can say who it came from.

Ask about one address and you get the block it sits in: 8.8.8.8 is answered with 8.8.8.0 - 8.8.8.255, registered to Google LLC. A range no registry is responsible for, such as 240.0.0.0/8, is answered without a request leaving the machine.

What an answer looks like

Every tool returns the same envelope, so a model learns one shape rather than five. Asking lookup_network for AS3320 returns this — the whole response, 854 bytes on the wire, against a 42-field upstream record:

{
  "status": "ok",
  "data": {
    "network": {
      "asn": 3320,
      "name": "Deutsche Telekom",
      "long_name": "Deutsche Telekom AG",
      "website": "https://wholesale.telekom.com",
      "network_type": "NSP",
      "traffic_estimate": "50-100Tbps",
      "scope": "Global",
      "traffic_ratio": "Mostly Inbound",
      "ipv4_prefixes": 150000,
      "ipv6_prefixes": 40000,
      "exchange_count": 7,
      "facility_count": 53,
      "policy": {
        "general": "Restrictive",
        "locations": "Required - International",
        "ratio_required": true,
        "contract_required": "Required",
        "url": null
      },
      "irr_as_set": "AS3320:AS-DTAG AS3320:AS-DTAG-V6",
      "looking_glass": "https://lg.telekom.com"
    },
    "candidates": []
  },
  "note": "PeeringDB records are maintained by the networks themselves. Treat a missing field as unrecorded, not as evidence it is untrue.",
  "provenance": {
    "source": "peeringdb",
    "fetched_at": "2026-09-14T16:44:53.916085Z",
    "record_updated": "2026-08-31T13:30:19Z",
    "from_cache": false
  }
}

The status field is the first thing to read, and ok means one thing only: the answer is in data. A name matching several networks returns ambiguous with the candidates to choose between, never a guess at which one was meant. An AS number that is not listed returns not_found, with a note saying a network can route traffic without being registered.

Three more, from the tools that do the work

Real responses, trimmed where marked. Nothing here is illustrative: each is what the tool returned on 2026-09-19.

"Where could Deutsche Telekom and Hurricane Electric peer with each other?" — one call to find_common_presence with [3320, 6939], four upstream requests:

{
  "status": "ok",
  "data": {
    "networks": [
      { "asn": 3320, "name": "Deutsche Telekom", "exchanges": 7, "facilities": 53 },
      { "asn": 6939, "name": "Hurricane Electric", "exchanges": 335, "facilities": 342 }
    ],
    "exchanges": {
      "items": [
        {
          "name": "NL-ix",
          "city": "Amsterdam, Rotterdam, Brussels, Luxembourg, Frankfurt,…",
          "country": "NL",
          "networks": [
            { "asn": 3320, "speed_mbps": 220000, "ports": 2, "route_server": false },
            { "asn": 6939, "speed_mbps": 400000, "ports": 1, "route_server": true }
          ]
        },
        {
          "name": "DE-CIX Frankfurt",
          "city": "Frankfurt",
          "country": "DE",
          "networks": [
            { "asn": 3320, "speed_mbps": 110000, "ports": 1, "route_server": false },
            { "asn": 6939, "speed_mbps": 800000, "ports": 1, "route_server": true }
          ]
        }
      ],
      "total": 6,
      "truncated": false
    }
  }
}

Six shared exchanges, widest bottleneck first: NL-ix leads because the narrower of the two networks has 220 Gbps there, not because anyone has more in total. The per-network totals underneath are what make an empty answer readable — Deutsche Telekom records 7 exchanges in all, so "no overlap" would mean something different from Hurricane Electric's 335.

"Who is already at DE-CIX Frankfurt, and would they peer with anyone?" — find_at_exchange with policy: "Open":

{
  "status": "ok",
  "data": {
    "exchange": { "exchange_id": 31, "name": "DE-CIX Frankfurt", "city": "Frankfurt", "country": "DE", "networks_recorded": 1020 },
    "networks": {
      "items": [
        { "asn": 24940, "name": "Hetzner Online", "speed_mbps": 2800000, "ports": 3, "route_server": true, "policy": "Open" },
        { "asn": 20940, "name": "Akamai Technologies", "speed_mbps": 2100000, "ports": 4, "route_server": true, "policy": "Open" }
      ],
      "total": 649,
      "truncated": true
    }
  },
  "note": "Participation is self-reported by each network in PeeringDB; a network missing here is unrecorded, not absent. Showing the 2 largest of the 649 networks (of 1020 here) stating policy Open; raise limit for more, at most 200."
}

649 of the 1,020 networks there state an open policy. The filter applies to the exchange rather than to the page, so that is a count of the exchange — not "the open ones among the largest fifty".

"Who is 8.8.8.8 registered to, and where do I report abuse?" — lookup_registration, which reads the registry rather than PeeringDB:

{
  "status": "ok",
  "data": {
    "target": "8.8.8.8",
    "kind": "address",
    "registry": "ARIN",
    "handle": "NET-8-8-8-0-2",
    "holder": "Google LLC",
    "covers": "8.8.8.0 - 8.8.8.255",
    "allocation_type": "DIRECT ALLOCATION",
    "registered": "2023-12-28T17:24:33-05:00",
    "abuse": { "name": "Abuse", "email": "network-abuse@google.com" }
  },
  "note": "Registry data: it says who an allocation was made to, which is not always who operates the resource today.",
  "provenance": { "source": "rdap", "record_updated": "2023-12-28T17:24:56-05:00", "from_cache": true }
}

The question was about one address and the answer covers the block it sits in, which is what covers is for.

How it works