Netdryrun

Official

Overview Schema Source Related Servers Discussions Admin

check_types

Lists supported verification checks and their configuration keys so you can read or author netdryrun.yml before a routing or policy dry run.

Instructions

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.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.3Oct 30, 2026

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description does disclose an important behavioral trait: 'Starts no lab.' But it then describes dry-run requirements, duration, and INCONCLUSIVE semantics that belong to a different tool, leaving the agent with a noisy and potentially misleading behavioral picture for this simple listing operation.

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

Conciseness2/5

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

The useful content is concentrated in the first two sentences and the final sentence about record_baseline. The middle passage about Docker, WSL2, 60–120 s runtimes, and INCONCLUSIVE states is largely irrelevant to check_types and bloats the definition.

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

Completeness3/5

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

For a zero-parameter listing tool with an output schema, the core purpose and safe/no-lab behavior are covered. However, the description does not cleanly isolate check_types from dry_run/start_run and may lead an agent to infer requirements that do not apply here.

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

Parameters4/5

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter detail, but none is needed because there is nothing to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence clearly states a specific verb and resource: list supported check types and their keys. It also distinguishes the tool from lab-starting operations with 'Starts no lab,' though it does not explicitly name the sibling tools it differs from.

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

Usage Guidelines3/5

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

It gives two concrete uses: reading netdryrun.yml or helping a human write it, and it names record_baseline when no checks exist. However, most of the usage guidance discusses when to use Netdryrun/dry runs generally rather than when to choose check_types over validate, run_checks, or dry_run.

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

Deploy Server