Fourteen Ways to Build the Testbed: Dynamic Source Composition in NetClaw
One integration can tell you which devices exist. Another can explain the lab they belong to. A third can identify the snapshot or operational scope you care about. A network engineer brings those views together to decide what to investigate.
With NetClaw 1.14.0, those selected records can also become a dynamic pyATS testbed.
The new VS Code extension 1.4.0 and terminal installers let you choose Static or Dynamic inventory for each claw. Dynamic mode exposes fourteen source routes, and the managed MCP can compose reviewed source records into a candidate for the actual upstream pyATS builder. You inspect it, validate it and explicitly activate it in the session that will use it.
This is the next step from part one. The pyATS MCP project supplies the dynamic engine. NetClaw connects that engine to its existing integration catalog and installer experience, with a consistent review and validation path.
Think about a CML lab and NetBox together
Suppose you are preparing an investigation involving a CML lab and a set of devices documented in NetBox. You want a testbed containing only the relevant devices, with known management endpoints, explicit OS mappings and a clear account of where each record came from.
NetClaw's source integrations can gather the authorized, scoped records. A reviewed export can fill the same role when a suitable MCP reader is unavailable. Those inputs go into one bounded composition envelope. The normalizer checks the connection facts, source identity, freshness and completeness before passing the candidate to the upstream builder.
We exercised a combined CML + NetBox candidate through the real managed MCP and actual pyATS schema loader using synthetic source records. We also submitted a partial refresh and verified that it was rejected while the previous candidate remained active. That establishes the composition and preservation behavior; it does not claim access to a live CML or NetBox tenant.
The source boundary remains visible throughout. A CML console port cannot quietly become a management SSH port. A platform label must have an explicit supported mapping. Duplicate identities or conflicting endpoints stop composition. If two sources describe the same device inconsistently, the operator must resolve that conflict rather than receive an invented answer.
That is useful engineering: the candidate either carries enough evidence to proceed or gives us a concrete reason to improve the inputs.
Fourteen routes into the same workflow
The catalog covers twelve named products plus two reviewed export routes:
| Source group | Available choices | What the operator must establish |
|---|---|---|
| Inventory and sources of truth | Itential Inventory Manager, NetBox, Nautobot, OpsMill Infrahub | Exact inventory/schema, stable device identity, complete records and connection facts |
| Controllers and CMDB | Catalyst Center, ServiceNow | Authorized scope, supported reader or export and current management data |
| Labs | CML, containerlab, EVE-NG, GNS3 | Lab/project identity and independently observed management endpoints; consoles alone are insufficient |
| Assurance and network models | IP Fabric, Forward Networks | Concrete snapshot/network identity, capture time and an explicit projection into device records |
| Reviewed inputs | Structured records, REST exports | Trusted extraction, declared provenance, freshness and completeness |
These are composition routes, not fourteen claims of direct native fetching inside pyATS. Upstream has its own native source capabilities. NetClaw's managed path uses an existing authorized source MCP or reviewed export, then invokes upstream's inline builder with a fixed mapping. It does not expose arbitrary URL fetching or copy credentials from a static testbed.
The researched gaps are practical ones. ServiceNow requires a verified CMDB reader or an authorized Table API export. Infrahub schemas are installation-specific. Forward requires a known export contract rather than an assumed bulk-reader tool. Snapshot-backed systems must identify the actual snapshot used. The source guide records these requirements source by source.
Make it an installer choice
In the VS Code setup wizard, Testbed mode & sources opens native mode and source pickers. The selected choices appear in the plan review and survive saved-draft reload. Each claw owns its policy, so a mixed deployment can keep one member static and make another dynamic.
The terminal plan builder offers the same choice. Existing-runtime configuration through scripts/setup.sh --testbed-only supports Keep, Static and Dynamic with source selection. Setup writes the selected policy; it does not fetch an inventory or connect to a device merely because a source was selected.
Static remains the default for existing plans. Dynamic setup no longer manufactures an empty YAML file just to satisfy a static prerequisite. Existing inventory and credentials are preserved, and installing the extension does not silently upgrade an installed NetClaw runtime.
The installer gives this capability a place an operator can find, understand and revisit. You do not have to discover an undocumented environment switch halfway through a workflow.
Review, validate, activate, then operate
NetClaw exposes 35 managed tools: the 34 upstream tools plus netclaw_testbed_compose. The added composition tool accepts scoped records, produces an immutable candidate and returns a reviewable preview. Actual pyATS schema validation and resolution of the required credential references come before explicit activation.
The workflow is deliberately visible:
- Gather authorized source records or a reviewed export.
- Check scope, freshness, completeness and connection facts.
- Build the upstream candidate, review it and validate its schema and credential references.
- Explicitly activate it in the same persistent MCP process.
- Run separately authorized pyATS operations.
A candidate cannot be silently replaced under a previously reviewed name. An active candidate cannot be deleted. Activation is guarded while device work is in flight. Dynamic mode cannot quietly fall back to another static inventory after losing its selection.
Credential values remain in the selected installation's private environment; device records use references. Source-service credentials and device-login credentials are distinct. A valid inventory grants no permission to configure a device. Existing approval, baseline and verification requirements still govern operational changes.
Session lifetime is part of the design
Dynamic candidates belong to one owned MCP process. A persistent client can build, validate, activate and then use the candidate. Restarting requires rebuilding, revalidating and reactivating it.
The bounded pyats-testbed-session.py helper can preview and validate, or explicitly activate and list, within a single process. It then exits. Separate one-shot calls cannot share an in-memory registry.
The managed bridge also gives each process its own private task evidence directory and database. Previous evidence remains on disk, but a restarted bridge does not reconnect old task handles. Interrupted operations need investigation before any replay. The HUD's static testbed editor, collectors and Terminal Intent remain separate consumers; activating a pyATS candidate does not rebind them.
These boundaries make the operating model understandable. You can identify which candidate belongs to which session and which result has actually been established.
What we tested
Spec160 completed all 30 implementation tasks with a requirement-to-evidence record. The work includes 196 passing upstream tests, fifteen normalization/adversarial tests and six actual managed-MCP acceptance tests against a freshly installed isolated runtime. Every source choice has a representative synthetic fixture that reaches the real builder and schema validation path.
Real terminal prompts exercised both installer entry points. Native Mac acceptance in VS Code 1.145 Insiders exercised the fourteen-source picker, CML + NetBox selection, cancellation, save, reload and return to Static, with private file readback. Extension, HUD, setup and recovery suites also passed with their existing opt-in skips recorded.
Live source tenants, device reachability/login, Windows/WSL and stable/minimum-editor visual qualification remain unverified. Those are separate rows in the verification record, so the scope of each result is visible.
The opportunity is in the composition
What excites me most is how much existing work this connects. Your team already maintains inventories, builds labs and collects network models. NetClaw already exposes integrations and pyATS already provides a substantial automation toolkit. A dynamic, reviewed testbed lets those pieces participate in one concrete workflow.
An investigation can begin with a site, a lab or a snapshot and end with a precise device selection ready for the next authorized step. The operator can inspect its provenance and decide whether it is suitable. That is a powerful capability to put directly into a network engineer's everyday workspace.
Explore it: NetClaw 1.14.0 · VS Code extension · Dynamic-testbed guide · Upstream pyATS MCP.