ROOTBEER MCP Server

Experimental — and we want your input. This is a first release of an MCP interface to ROOTBEER's routing diagnostics. The tools, their output shapes, and the guidance text may change as we learn how people actually use them. If you try it, please tell us what worked, what didn't, and what you'd want next: rootbeer@internet2.edu

ROOTBEER's MCP server lets an AI assistant — Claude, ChatGPT, or anything else that speaks the Model Context Protocol — ask ROOTBEER the same questions a network engineer would, in plain language: "Why is Internet2 rejecting one of our prefixes?", "Does anything under our /16 have RPKI problems?", "Who's prepending, and does it matter?"

It exposes the analysis behind the RE Topology Report's AS Report, built from Internet2's own BGP route data — every route Internet2 receives from its peers, including the ones its policy rejects, which is the part you can't see from a public looking glass.

It also exposes the RPKI-ROA Planner: for a prefix you hold, every route and route object the planner can find for it, which of them today's ROAs already cover, and the ROAs that would cover the rest — plus a what-if check of ROAs you're about to publish.

At a glance

The tools

Routing advice

as_routing_advice(asn)

Everything Internet2 sees that originates from or transits a given AS, with each prefix classified and annotated. Ask about your own AS, an upstream, or a downstream customer.

prefix_routing_advice(prefix)

Everything announced under a covering prefix (the prefix itself plus every more-specific), regardless of who announces it. Ask about a /16 you hold, or a /8 you're curious about.

What comes back

Both routing-advice tools return the same structure. For each prefix:

• Status — rejected (Internet2's policy dropped at least one path), at_risk (accepted, but with warnings worth a look), or clean.

• Issues, each with a short plain-text summary and a suggested fix:

  Issue	Meaning
  rpki_invalid / rpki_none	Covering ROA fails validation / no ROA published
  irr_conflict / irr_none	IRR route object contradicts the origin / none exists
  tier1	Path crosses a commercial tier‑1 carrier (Internet2 rejects these)
  private_asn	An RFC 6996 private ASN appears in the path
  too_long	Longer than Internet2 accepts (/27 IPv4, /49 IPv6)
  policy_filter_likely	Rejected, but none of the above explain it — usually a per‑customer prefix filter
  lpp_path / lpp_comm	Local Preference Probe results suggest path‑length or commodity routing wins over R&E
  leaked	More‑specifics visible in the commodity DFZ but not the R&E table
  not_in_re	A covering prefix the same origin announces to the commodity Internet has address space with no accepted R&E route (a /16 in commodity with only a /17 in R&E reads 50%); only reported for origins with at least one accepted route in the answer — possibly intended, worth confirming. Prefixes the origin announces to commodity only, with nothing in R&E under them, read 100% and appear only in the report-level list
  prepend	AS‑path prepending (×2 or more)
  unregistered	Outside current RIR delegated stats

• Paths — the full AS paths Internet2 saw, with accept/reject verdict, prepend runs, and the Internet2 router that heard each one.

• RPKI, IRR, and LPP detail — the covering ROAs and route objects actually matched, and the probe counts behind an LPP classification.

• Not in R&E — the report-level not_in_re list names every commodity-announced prefix with address space no accepted R&E route reaches — covering aggregates with only part of their space in R&E, and prefixes announced to commodity only — with the share of its addresses affected (pct) and how many accepted R&E prefixes sit under it (re_prefixes, 0 for a commodity-only prefix); each affected R&E prefix repeats the aggregates over it as not_in_re / not_in_re_pct. not_in_re_truncated is true when the commodity-only part of the list was capped (the topology map shows them all).

• topology_url — a deep link into the interactive RE Topology Report, a Sankey map of the same routes. Your assistant should offer this to you; it's the fastest way to see what the tool is describing.

Very large answers (more than 2,000 distinct prefixes) come back as a count plus the topology link rather than the full list — the map handles that scale better than a chat window.

RPKI-ROA planning

The other two tools are the RPKI-ROA Planner with the clicking taken out. The web page shows a table of every route and route object it can find for your prefix, lets you untick rows or filter them by age, and lists the ROAs needed for what's left; its "Test ROA data" panel checks a ROA set you're considering against the same table. Each tool does one of those jobs in a single call.

roa_plan(prefix, max_days_old?, origin_asns?, exclude_origin_asns?)

Everything the planner finds at or below prefix — which must be /8 or longer (IPv4) or /16 or longer (IPv6), and public address space:

Each candidate's rov_status is how RPKI validators judge that (prefix, origin) today, against the validated ROAs ROOTBEER holds: valid, invalid (a covering ROA exists but doesn't authorize this origin or this prefix length), not_found (no covering ROA) or unknown (the validator couldn't be reached — such candidates are counted as needing a ROA, and a warning says so).

needed_roas is what would make every selected candidate that isn't already valid, valid — in both forms the web page offers:

• multi_prefix — one ROA per origin AS listing its prefixes. This is the form the planner recommends. RFC 9455 (BCP 238) favours one prefix per ROA to keep each ROA's meaning unambiguous, but multi-prefix ROAs are equally standards-compliant and keep the number of ROA objects, repository churn and validator load down for networks with many prefixes.
• single_prefix — the same prefixes, one ROA each.

maxLength equals the prefix length in both; the planner never widens it.

The optional arguments are the web page's selection controls: max_days_old deselects routing-history and IRR candidates not seen or modified within that many days (the page's "Days Old" filter); origin_asns keeps only those origins; exclude_origin_asns drops them. Deselected candidates stay in the answer with selected: false, so the assistant can show you what it left out and why.

Also in the answer: a planner_url that opens the same table in the web planner; ddos_mitigation_asns plus a caveat when a DDoS scrubbing provider's AS (such as Radware, AS198949) is among the origins — the provider announces your routes during a mitigation event, often via your regional network, and may need ROAs the planner can't see; warnings when an upstream source failed (the table is then partial); caveats, which always include why incorrect or incomplete ROAs break connectivity; and disclaimer, the planner's terms (below).

roa_plan_test(prefix, roa_asn, roas)

The web page's "Test ROA data": give it the origin AS and the prefixes of a ROA set you're considering — each as "prefix" or "prefix, maxLength", e.g. "192.0.2.0/23, 24" — and every candidate the planner finds for prefix comes back with three verdicts: existing_rov_status (today's ROAs), proposed_rov_status (your ROAs on their own, what the web page shows) and after_publishing (both together — a route that's valid under either stays valid). Each covered route names the proposed ROA that decided it and links into the ROA Visualizer, which walks through the match step by step. The summary counts newly_valid routes and invalid_after_publishing ones — routes your ROAs would cover without authorizing, which networks doing route origin validation would drop. Run it before publishing what roa_plan recommends, or any alternative you have in mind.

Both planning answers cap their lists (1,000 candidates, 500 single-prefix ROAs) and say so with candidates_truncated / needed_roas_truncated; the counts in summary are always complete, and the web planner shows everything.

The risk, and the disclaimer

The web planner makes you acknowledge a disclaimer before it shows a single row, because publishing a ROA changes how your whole prefix is judged. Today, with no covering ROA, validators treat your routes as unknown and networks carry them. Once any ROA covers a prefix, every announcement under it that no ROA authorizes — another origin AS, a more-specific beyond maxLength, a route the planner never saw — becomes RPKI-invalid and is dropped by networks that filter on it. An incomplete ROA set can therefore take down routes that work today. Confirm every origin AS and prefix length your network legitimately announces, including during failover and DDoS mitigation, and check the final set with roa_plan_test before publishing.

The MCP tools can't make you click, so they return the planner's terms on every answer as disclaimer, and the server's instructions tell your assistant to relay them. In substance:

This service is provided by Internet2 on an "as is" and "as available" basis, without any warranties, express or implied, including but not limited to warranties of accuracy, completeness, merchantability, or fitness for a particular purpose. The information and recommendations produced by this tool are intended for informational purposes only. You are solely responsible for verifying the accuracy, completeness and suitability of any RPKI Route Origin Authorizations (ROAs) you create or modify based on this output. Incorrect or incomplete ROAs can result in partial or complete loss of connectivity for your organization's networks. Internet2 accepts no liability for any direct, indirect, incidental, or consequential damages arising from the use of, or reliance upon, this service. By using this tool, you acknowledge and agree to these terms.

Connecting

Claude (claude.ai or the desktop app)

Settings → Connectors → Add custom connector. Name it ROOTBEER, paste https://rootbeer.internet2.edu/mcp, and save. No OAuth or API key is required. (Custom connectors are available on paid plans; Free plans allow one.)

Claude Code

claude mcp add --transport http rootbeer https://rootbeer.internet2.edu/mcp

ChatGPT

Custom MCP servers are added under Settings → Connectors with Developer Mode enabled; availability depends on your plan and the exact menu moves between releases. Use the same URL, https://rootbeer.internet2.edu/mcp, with no authentication.

Anything else

Any MCP client that supports the streamable-HTTP transport can connect to the endpoint directly. From Python, for example, with the official SDK (pip install mcp):

import asyncio
from mcp import Client

async def main():
    async with Client("https://rootbeer.internet2.edu/mcp") as client:
        result = await client.call_tool("as_routing_advice", {"asn": 3})
        print(result.structured_content["summary"])

asyncio.run(main())

Example

Once connected, just ask. Real exchange, lightly condensed:

You: What routing problems does AS 3 have in the Internet2 R&E network?

Assistant: AS 3 (MIT-GATEWAYS) announces 40 prefixes into Internet2 — 32 IPv4 and 8 IPv6 — and all 40 are accepted. None are rejected, but all 40 are flagged at risk for the same two reasons:

• No ROA published for any of them, so RPKI validators can't confirm MIT as the origin. Fix: create ROAs for each prefix and origin AS in the ARIN portal.
• AS-path prepending (×3) on their announcements, which only influences networks that route on path length. Fix: prefer local-preference-based traffic engineering.

You can explore these routes visually here: https://rootbeer.internet2.edu/re-topology-report/#asn=3

Or by address space:

You: Is there anything wrong with the prefixes under 18.0.0.0/8?

Assistant: Internet2 sees 245 prefixes under 18.0.0.0/8, all IPv4. None are rejected; 178 are at risk and 67 are clean. The at-risk ones are almost all missing ROAs … (continues with the breakdown and the topology link.)

Follow-up questions work the way you'd expect — "which of those are IPv6?", "show me just the rejected ones", "what would fix the RPKI issue?" — because the assistant already holds the full structured result.

And ROA planning (illustrative — the numbers are made up):

You: Which ROAs are we still missing for 198.51.100.0/22?

Assistant: The planner finds 9 candidate routes under 198.51.100.0/22. Seven are originated by AS64496 (your AS) and are already covered by valid ROAs. Two need attention:

• 198.51.102.0/24 from AS64496 — announced today (in Internet2's RouteViews view) but no ROA covers it. One ROA for AS64496 with 198.51.102.0/24, maxLength 24, fixes that.
• 198.51.103.0/24 from AS64511 — a route object in RADB, last modified 5 years ago, from an AS I don't see in your current announcements. I'd confirm whether that's a former provider before creating a ROA for it.

The full table is here: https://rootbeer.internet2.edu/roa-planner/prefix/198.51.100.0%2F22

You: We only ever announce the /22 as /24s. What if we publish one ROA for 198.51.100.0/22 with maxLength 24 instead?

Assistant: Tested against the same candidates: all eight AS64496 routes would be valid, including the uncovered /24. The AS64511 route object would become invalid after publishing — the new ROA covers 198.51.103.0/24 but only authorizes AS64496 — so if AS64511 ever announces it, validating networks will drop that route. …

Things to know

• It's Internet2's view, not the global table. An AS or prefix that doesn't appear here isn't necessarily unrouted — it just isn't visible in Internet2's R&E topology.
• LPP findings are inferences. The Local Preference Probe reads routing preference from where probe responses come back, not from anyone's router configuration. Treat lpp_path / lpp_comm as a prompt to check, not a verdict; for anycast prefixes it isn't evaluated at all.
• The first question about a network can be slow. Registered-holder lookups for prefixes ROOTBEER hasn't seen recently go to RIPE/ARIN live; a large AS can take several seconds the first time and is fast after that.
• ROA planning queries live sources. RIPEstat, ARIN's RDAP and the IRR are asked when you are, paced to be polite to them. The first call for a prefix can take up to a minute (the tool gives up at two), and the result is cached for ten minutes, so a retry after a timeout is usually instant.
• Candidates are candidates. The planner assumes anything seen in the last five years, visible now, or registered in the IRR might need a ROA. It's deliberately inclusive — read days_old and the origin ASes before accepting a recommendation, and use the filters to drop what you know is stale or foreign.
• The planner is an aid, not an authority. Incorrect or incomplete ROAs can cause partial or complete loss of connectivity, and you are solely responsible for what you publish (see the disclaimer above). Verify every ROA against your own records before creating or changing it, and if a DDoS scrubbing service protects your network, confirm with them which ROAs the mitigation setup requires.
• It's read-only and unauthenticated. The server never accepts data, only questions; rate limiting bounds how many.

Activity monitor

Everything the server does is visible at https://rootbeer.internet2.edu/mcp-activity — a live feed of recent tool calls (tool, argument, outcome, duration) and running totals since the last restart. It records what was asked and how long it took, not who asked: no IP addresses or client identities are stored.

We're watching it to understand how the tools get used, and it's public so you can too.

What we'd like to hear

• Did the assistant pick the right tool and interpret the results correctly?
• Which questions did you want to ask that these tools couldn't answer?
• Is the advice text useful as written, or too generic / too Internet2-specific?
• What other ROOTBEER data (ASPA planning, IRR, traceroute, anycast) would be worth exposing this way?

Send thoughts to rootbeer@internet2.edu