Netdryrun

Official

Overview Schema Source Related Servers Discussions Admin

record_baseline

Capture a known-good containerlab BGP baseline—sessions, prefix counts, and routes—when checks are missing, then dry-run config changes against it before applying.

Instructions

Snapshot a known-good lab (containerlab topology file) as netdryrun.yml check text: every established BGP session, prefix count (today's count as min, max with 20% headroom) and BGP route. Call it when no checks exist, before changing the configs, then dry-run the change against this baseline. With attributes=true, also pin each BGP route's AS path, local preference and communities. By default it also adds the standard guards (no default route and no link subnet via BGP on each BGP node); guards=false leaves them out. A first line starting "# INCOMPLETE BASELINE" means routes were left out: say so to the human. Returns the YAML; nothing is written to disk. Show it to the human: the checks belong to the network team. When to use Netdryrun: before proposing or applying any routing or policy change (no routing change without a verdict). Ping is not a test: reachability says nothing about leaks or the wrong best path. A dry run takes about 60–120 s. Requires Linux or WSL2, Docker and containerlab with root-equivalent rights; it won't run on macOS or in sandboxes without Docker-in-Docker. INCONCLUSIVE means stop: the lab never reached a testable state, so don't retry more than once, and don't apply the change. Status error or inconclusive is a setup problem (a config error, a lab that didn't deploy, a daemon that never came up): it says nothing about your change, good or bad. Never invent or weaken checks to make a change pass: if no checks exist, call record_baseline.

Input Schema

Name	Required	Description	Default
`deploy`	No
`guards`	No
`topology`	Yes
`attributes`	No
`wait_seconds`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.3Oct 30, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the '# INCOMPLETE BASELINE' truncation marker and what it means, that nothing is written to disk, default guard behavior plus the guards=false escape hatch, runtime (60–120 s), hard platform prerequisites (Linux/WSL2, Docker, containerlab, root-equivalent; no macOS or sandboxed DinD), and the INCONCLUSIVE/error semantics with retry limits. These are consequential operational facts an agent could not infer from the schema.

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

Conciseness3/5

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

The core purpose and the guards/attributes behavior are front-loaded, but the middle section drifts into cross-cutting Netdryrun doctrine ('Ping is not a test', 'no routing change without a verdict') that repeats guidance already implied elsewhere, and the 'if no checks exist' instruction appears twice. It is information-dense but bloated for a 5-parameter tool.

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?

An output schema exists so return structure need not be spelled out, and the description still covers the important edge case (truncated baseline) plus prerequisites, runtime, and failure modes. The main remaining hole is the unexplained deploy/wait_seconds parameters, which an agent needs to reason about before invoking a tool that may deploy a lab.

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 0%, so the description must compensate, and it does for guards (default standard guards of no default route / no link subnet via BGP) and attributes (pins AS path, local preference, communities). However, 'deploy' (default true, the most consequential parameter since it implies actually deploying the lab) and 'wait_seconds' (default 45) are never explained anywhere, leaving two of five parameters opaque.

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?

States a specific verb and resource ('Snapshot a known-good lab (containerlab topology file) as netdryrun.yml check text') and enumerates exactly what gets captured: BGP sessions, prefix counts with min/max headroom, and BGP routes. This is clearly distinguishable from siblings like dry_run and run_checks, which consume or execute checks rather than record them.

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?

Explicit trigger conditions are given: 'Call it when no checks exist, before changing the configs, then dry-run the change against this baseline,' reinforced by 'if no checks exist, call record_baseline.' It also names the downstream sibling (dry_run) and the sequencing between them, so the agent knows both when to call this and what to do next.

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

Deploy Server