The Testbed Becomes Part of the Conversation: Dynamic Inventory in pyATS MCP

The testbed has always been one of the most important pieces of a pyATS workflow. It tells the automation which devices exist, how to reach them, which operating systems they run and where to resolve their credentials. Get that foundation right and a tremendous amount becomes possible.

Now the pyATS MCP server can build that foundation during the conversation.

An agent can discover an inventory, build a testbed in server memory, inspect it and activate it. The existing pyATS tools can then use that inventory. A hand-maintained testbed.yaml is no longer a prerequisite for every workflow.

That is a remarkably useful connection: the system that knows your devices can become the starting point for the system that interacts with them.

This is part one of a two-part series. Here, I want to focus on the upstream pyATS MCP project itself. Part two explains how we brought it into NetClaw, including the installer, source composition and the additional operating boundaries.

Build the inventory around the question

Imagine a maintenance window for one site. The source of truth has the current device list. A controller has another view. Your lab contains the devices you want to use for rehearsal. The first useful question is which of those records belong in this particular operation.

A dynamic testbed makes that selection an explicit step. You can build a candidate for a site, a particular inventory or a reviewed set of records. Give it a meaningful name, inspect the mapped devices and decide when it should become active.

The value grows when inventories change frequently. A lab can be recreated. A project can gain another router. An operational query can narrow from a whole environment to a small set of devices. The testbed can be assembled from the information relevant to that moment, with its source and scope still understood.

Static files remain useful for stable, deliberately maintained environments. Dynamic construction adds another way to prepare the same automation foundation.

What the upstream project provides

At the revision used for this work, 4a3c1e3, pyATS MCP exposes 34 tools, including eight dynamic-testbed tools. The source includes native readers for Itential Inventory Manager, NetBox, Nautobot and Catalyst Center, alongside generic REST and structured inline/file inputs. The builder supports CSV, JSON, YAML and XML with declarative field mapping. The upstream implementation and guide describe those contracts.

The workflow has a small, understandable vocabulary:

Tool	Role in the workflow
pyats_testbed_sources	Inspect the available source configuration and active selection
pyats_testbed_source_inventories	Discover Itential inventories
pyats_testbed_build	Map source records into a candidate, with preview options
pyats_testbed_validate	Check the pyATS schema and credential references; optionally probe reachability
pyats_testbed_activate	Select the inventory used by subsequent operations
pyats_testbed_list	Inspect the server's candidate registry
pyats_testbed_get	Inspect a particular candidate
pyats_testbed_delete	Remove a candidate from the registry

The mapping step is essential. One source calls an address managementIpAddress; another puts it inside a primary-address object. Platform labels also differ. The builder translates those records into the device and connection structure pyATS expects. That is where inventory data becomes an automation input.

The existing tools gain a new starting point

The especially exciting part is what happens after activation. The server's shared testbed loader supplies the selected inventory to the existing operational tools. The implementation is visible in the upstream server.

A dynamically selected device can become the target of an existing show-command workflow. Genie learning and comparison can use the selected testbed. Declarative tests and fleet operations can start from that same inventory. Configuration tools also retain their own controls and approval obligations.

The practical opportunity is substantial. An agent can help move from an inventory question to a concrete, reviewable device selection, then use tools that already understand network platforms. The selection itself becomes something the operator can inspect and discuss before any connection is attempted.

For example, a workflow might ask: “Prepare a candidate from this lab inventory, show the devices and connection facts, and validate its structure. Stop before connecting.” A later, separately authorized request can use that selection for a real read operation.

Understand what each result proves

A valid testbed proves that the inventory has an acceptable structure. It does not prove that a device is reachable, that a credential works or that a command will succeed. Those observations require their own checks. The distinction gives the operator useful stopping points.

Credential references such as %ENV{PYATS_DEVICE_PASSWORD} let the server resolve a secret from its own environment. Operators still need to configure source credentials, device credentials and access boundaries correctly. The upstream source includes file/host restrictions and command protections; a deployment should review the actual behavior of its chosen revision and client.

The dynamic registry is also process-local. Restarting the server loses that selection. HTTP transport mode does not turn it into a durable inventory database. Subprocess-based workflows may materialize private temporary testbed files when a tool requires a filesystem path. These details are documented in the builder and matter when designing a repeatable workflow.

Why I am excited about this

Network engineers already spend enormous effort keeping useful information in inventory systems, lab platforms and controllers. Dynamic testbeds give that information another practical purpose: preparing the exact device set for an automation task.

MCP gives an agent a discoverable interface to those operations. pyATS supplies the network automation foundation. The operator can see the candidate and decide what happens next. Together, those pieces make the distance between a useful question and a prepared workflow much shorter.

Start with the pyATS MCP repository, read its dynamic-testbed guide and try a small reviewed inventory. Then continue to part two: bringing dynamic testbeds into NetClaw, where the source selection spans an entire collection of integrations.