Netdryrun
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| dry_runA | The primary tool: dry-run a network change. Deploys the containerlab lab of netdryrun.yml at |
| start_runA | The asynchronous dry_run, for clients that give up on a long tool call: returns at once with a |
| get_resultA | The result of a run started with start_run. While status is running there is no verdict: wait poll_after_s seconds and call again (a dry run takes about 60-120 s). Once it has finished, the result is exactly dry_run's, with its run_id: act on |
| run_checksA | Run the checks in netdryrun.yml at |
| record_baselineA | 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. |
| validateA | Validate netdryrun.yml at |
| check_typesB | List supported check types and their keys, to read netdryrun.yml or help a human write it. Starts no lab. 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
dry_run and start_run perform the same operation (sync vs async) and get_result is tightly coupled to start_run, but the descriptions make the relationship and polling flow explicit. run_checks could be mistaken for dry_run, yet its description clearly states it reuses an already-running lab without deploy/destroy. Boundaries are mostly distinct with only this intended pairing overlap.
Six of seven names follow a verb_noun pattern (dry_run, start_run, get_result, run_checks, record_baseline, check_types). 'validate' is a bare verb, a minor deviation, but the overall convention is predictable and readable.
Seven tools is well-scoped for a dry-run validation server: a synchronous path, an asynchronous path with polling, a re-check tool, baseline generation, and two lightweight metadata/introspection tools. Each earns its place.
Core lifecycle (validate, dry_run, async run + poll, run_checks, record_baseline, check_types) is covered, but the keep_lab=true flow explicitly tells the agent to 'destroy the lab' afterward and there is no destroy_lab or list_runs tool to do so. That is a notable dead end in a workflow the descriptions actively encourage.