net-mcp

Mrt Search

mrt_search

Find available historical BGP MRT files (RIB snapshots or update logs) for a time range and collector, returning URLs, sizes, and timestamps to prepare for BGP analysis.

Instructions

Find available MRT data files for a given time range and collector.

Use this to discover what historical BGP data is available before calling bgp_historical_lookup. Returns URLs, sizes, and timestamps for each MRT file.

RIB dumps (bview) are snapshots of the full routing table, taken every 8 hours at 00:00, 08:00, 16:00 UTC. Use these to see what the routing table looked like at a specific time.

Update files contain BGP announcements and withdrawals, archived every 5 minutes. Use these to see route changes during an incident.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`time_end`	Yes	End time in ISO 8601 format. For a RIB snapshot at a point in time, set end = start + 8 hours (RIB dumps are every 8h).
`collector`	No	RIPE RIS collector ID (e.g. 'rrc00'). Use ris_collectors to find the right one. Defaults to the configured collector (rrc00, global multihop).
`data_type`	No	'rib' for routing table snapshots (large, ~400MB, every 8h) or 'update' for BGP update messages (small, ~3MB, every 5min). Use 'rib' to see full routing state at a point in time. Use 'update' to see what changed during a time window.	rib
`time_start`	Yes	Start time in ISO 8601 format (e.g. '2026-03-22T00:00:00')

Output Schema

TableJSON Schema

Name	Required	Description
`tip`	No	Guidance on how to use these files
`error`	No	Set when an upstream lookup failed; other fields may be empty or partial.
`files`	Yes	Matching files (may be truncated; see total)
`total`	Yes	Total files in the window, even if the list is truncated
`collector`	Yes	Collector that was searched
`data_type`	Yes	'rib' or 'update'
`query_end`	Yes	End of the searched window
`query_start`	Yes	Start of the searched window

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 22, 2026

TDQS

A4.4/5.0

Behavior4/5

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It states the tool 'Returns URLs, sizes, and timestamps for each MRT file' and explains the nature of RIB dumps and update files, which covers the main behavioral surface. It does not explicitly say 'read-only' or mention potential response size or pagination, but 'Find available' strongly implies a non-mutating discovery operation.

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?

The description is well-structured: it leads with the purpose, then the relationship to bgp_historical_lookup, then the RIB/update explanation. It is slightly redundant with the input schema's parameter descriptions, especially for data_type, but every paragraph contributes useful behavioral or usage context. It is not bloated, though it could be tightened.

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?

Given the 100% schema coverage, the presence of an output schema, and the absence of nested objects, the description provides sufficient context to call the tool correctly. It explains the tool's role in a larger workflow, what it returns, how to choose between data types, and the temporal cadence of MRT files. Nothing an agent needs to decide whether to use this tool is missing.

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 baseline for this dimension is 3. The description reinforces the meaning of data_type and the RIB/update time cadence, but the schema already provides nearly identical detail (e.g., 'Use rib to see full routing state at a point in time'). The description adds some usage framing but does not introduce significant new parameter-level semantics beyond the 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 starts with a specific verb and resource: 'Find available MRT data files for a given time range and collector.' It further distinguishes itself from the sibling bgp_historical_lookup by explicitly saying this is the discovery step before that lookup, and it clarifies the two file types (RIB dumps vs update files). An agent can clearly tell what this tool does and how it differs from nearby tools.

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?

The description explicitly says to use this tool 'before calling bgp_historical_lookup' and provides concrete guidance for choosing between RIB dumps and update files: 'Use these to see what the routing table looked like at a specific time' and 'Use these to see route changes during an incident.' This gives clear when-to-use context and differentiates the internal modes.

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