net-mcp

Bgp Route Lookup

bgp_route_lookup

Retrieve current BGP routes for any IP prefix from global tables, returning origin AS, AS path, communities, and peer data. Filter by RIPE RIS collector for regional perspective.

Instructions

Look up current BGP routes for a prefix from global routing tables.

Returns BGP route entries including origin AS, AS path, communities, and peer information. Optionally filter by a specific RIPE RIS collector to get a regional perspective (e.g. RRC06 for Tokyo, RRC15 for Sao Paulo).

Source order: RIPEstat looking glass, then Cloudflare Radar (if a token is configured), then bgproutes.io (if a key is configured), then the bgp.tools full table only if RIPEstat itself failed. At most 20 routes are returned; total reports how many were observed. Use ris_collectors first to pick a collector ID for a regional view.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`prefix`	Yes	IP prefix in CIDR notation (e.g. '1.1.1.0/24')
`collector`	No	RIPE RIS collector ID to filter by (e.g. 'RRC00', 'RRC06'). Use ris_collectors to see available collectors and their locations. None queries all collectors.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Set when an upstream lookup failed; other fields may be empty or partial.
`total`	Yes	Total routes observed, even if the list is truncated
`prefix`	Yes	Prefix that was queried
`routes`	Yes	Observed routes (capped; see total)
`source`	Yes	Which data source produced this result

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 22, 2026

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the source fallback order, config-dependent sources, the 20-route limit, and the `total` field. It does not mention rate limits or error behavior, but it is substantially transparent for a lookup tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place: purpose, return fields, regional filtering, source order, limits, and a workflow tip. It is front-loaded with the core operation and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return-value details are already handled. The description covers source selection, fallback behavior, collector workflow, and result limits. Minor operational details like failure modes or authentication setup are absent, but the tool is otherwise complete for a 2-parameter lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both `prefix` and `collector`. The description adds useful examples and clarifies 'None queries all collectors', but this is marginal value beyond the structured schema.

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?

The description opens with 'Look up current BGP routes for a prefix' – a specific verb, resource, and scope. It also enumerates returned data (origin AS, AS path, communities, peer information), and the 'current' qualifier helps distinguish it from sibling tools like bgp_historical_lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a concrete workflow for regional perspective: 'Use ris_collectors first to pick a collector ID' and explains collector examples like RRC06 for Tokyo. It does not explicitly contrast with alternative siblings such as bgp_historical_lookup or mrt_search, so when-not-to-use guidance is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.