NetBox MCP and rConfig: compare intended state with running configs

NetBox MCP and rConfig: compare intended state with running configs

NetBox says interface Gi1/0/12 on dub-acc-07 is a trunk carrying VLANs 10 and 20, described “AP-Floor2”. The switch may say something else. Finding those gaps has always meant scripts that parse vendor configs and query the NetBox API. With the NetBox MCP server and rConfig’s MCP server in the same agent, you describe the comparison in plain language and the agent does the reading.

Best for: source-of-truth hygiene, pre-migration audits, checking a site after a project hands over. Tools: rConfig, NetBox (or Nautobot, or Infrahub). rConfig tools used: get_devices, get_latest_config, search_configs, get_config_history.

How it flows

flowchart LR
    A["Agent"] -- "devices, interfaces,<br/>IPs, VLANs for one site" --> N["NetBox MCP<br/>(intended)"]
    A -- "stored config<br/>per device" --> R["rConfig MCP<br/>(configured)"]
    A --> D["Mismatch report<br/>with evidence from both"]
    A -. "who changed last?" .-> N
    A -. "who changed last?" .-> R

The NetBox Labs server is read-only and exposes generic object queries (get_objects, get_object_by_id) plus NetBox’s change log (get_changelogs). rConfig supplies the stored configs. Neither side can change anything.

What can be compared

Compare things that appear in both places. A config doesn’t record rack positions or circuit IDs, and NetBox doesn’t record ACL entries.

Example session

Work one site or one device role at a time. It keeps the agent’s context small and the report readable.

Compare NetBox with rConfig for every access switch at site DUB. From NetBox: each device’s interfaces (enabled, description, mode, VLANs) and IP addresses. From rConfig: the latest running config for the same devices. Check the command field and make sure you’re reading a running config, not show version output. Match devices by hostname. Report only mismatches, as a table: device, interface, attribute, NetBox value, config value. Quote last_config_at for each device.

What a well-briefed agent does:

1. Lists the site’s access switches in NetBox, then finds each one in rConfig with get_devices by name. If rConfig’s inventory is synced from NetBox through Device Sync, the names match exactly.
2. Reads intended state for each device from NetBox: interfaces, IP addresses, VLANs.
3. Reads the stored running config for each device from rConfig with get_latest_config, passing a command filter such as running.
4. Compares attribute by attribute and drops everything that matches.

An illustrative report:

Device      Interface   Attribute     NetBox            Config               Backup
dub-acc-07  Gi1/0/12    trunk VLANs   10,20             10,20,30             today 03:00
dub-acc-07  Gi1/0/31    enabled       true              shutdown             today 03:00
dub-acc-09  Gi1/0/4     description   AP-Floor2         AP-Floor3            today 03:00
dub-acc-11  (device)    exists        planned           no rConfig backup    -

Deciding which side to fix

A mismatch says the two disagree, not which is wrong. Both tools keep history, so ask the agent to find out which moved last:

For each mismatch, check NetBox’s change log for that object and rConfig’s config history for that device. Say which side changed most recently and when.

• The config changed last (rConfig history shows the edit): someone changed the network without updating NetBox. Either record it in NetBox or revert it through your change process.
• NetBox changed last (change log shows the edit): the plan moved and the network hasn’t caught up. That is pending work, not drift.
• Neither changed recently: a long-standing gap. Usually NetBox was populated from an old export and never reconciled.

Limits to know

• The model reads configs, it doesn’t parse them. A language model is good at reading a config but can miss an interface in a 3,000-line file. Spot-check its findings on a device or two before acting on the report, and keep sites small.
• Stored config, not live state. rConfig shows the config at the last backup. Quote last_config_at; a change after it won’t appear yet.
• Cost grows with config size. Each get_latest_config call returns a whole config. For an estate-wide check of one attribute (for example, “which switches define VLAN 30?”), use search_configs instead of fetching every file.
• One running config per device. If a device collects several commands, make sure the agent compares the running config. Naming it in the prompt is enough, because get_latest_config can filter by command.

Variations

• Nautobot or Infrahub. Swap in their MCP servers. rConfig’s Nautobot and Infrahub Device Sync keep the hostnames aligned.
• Pre-migration audit. Before replacing a site’s switches, run the comparison so the new configs are generated from a NetBox that matches reality.
• After a project hands over. Compare the site against NetBox the day the project team leaves, while they can still answer questions.

Related reference

• Connect an AI agent over MCP
• NetBox Device Sync
• Device Sync overview
• Config search