Using rConfig with NetBox, Grafana, PagerDuty and other MCP servers

Using rConfig with NetBox, Grafana, PagerDuty and other MCP servers

An agent connected to one MCP server can answer questions about one tool. Connect it to rConfig, your source of truth and your monitoring at the same time, and it can answer the questions engineers actually ask: “the core switch alarmed at 02:10, did anyone change it?” This page covers how to set that up so the answers are reliable.

Who answers what

Give each server one job. The agent picks tools far more accurately when their scopes don’t overlap.

Nautobot, Infrahub, LibreNMS and ServiceNow have MCP servers too, from their vendors or the community. The same rules apply: one job each, read-only where possible.

Configuring several servers

Every client in the compatibility table supports several servers in one file. A Claude Code project file, as an example, with rConfig and NetBox:

{
  "mcpServers": {
    "rconfig": {
      "type": "http",
      "url": "https://rconfig.example.net/mcp",
      "headers": { "Authorization": "Bearer ${RCONFIG_MCP_TOKEN}" }
    },
    "netbox": {
      "command": "<launch command from the NetBox MCP server README>",
      "env": {
        "NETBOX_URL": "https://netbox.example.net/",
        "NETBOX_TOKEN": "${NETBOX_TOKEN}"
      }
    }
  }
}

Name the rConfig server rconfig. Its tools have generic names (get_devices, get_device), and clients tell servers apart by prefixing the server key. In Claude Code, for example, the tool becomes mcp__rconfig__get_devices, which keeps it distinct from another server’s device tool and lets you write permission rules for it.

Joining records across tools

The agent has to match a device in one tool to the same device in another. Match on names or IP addresses, never on IDs: rConfig’s device ID 42 and NetBox’s device ID 42 are unrelated.

If rConfig imports its inventory from NetBox, Nautobot, Infrahub, Zabbix or another source through Device Sync, names already match and the join is exact. Without Device Sync, expect naming drift (DUB-CORE-01 against dub-core-01.example.net) and tell the agent how your names map.

When sources disagree

Each tool tells the truth about something different:

• rConfig reports what was configured at the last successful backup. Every device record carries last_config_at; ask the agent to quote it.
• NetBox (or Nautobot, Infrahub) reports what was planned.
• Monitoring reports what is happening now.

So a disagreement is information, not an error. A VLAN in NetBox but not in the config is either unbuilt or removed; a config change after the last backup won’t show in rConfig until the next one. Ask the agent to report both values and the timestamps, and to say which tool each fact came from. The NetBox playbook works through this in detail.

Keeping cost and context under control

Every connected server adds its tool definitions to the model’s context on every turn, and every tool result is billed as input. Device configs are large. A few habits keep a multi-server agent fast:

• Search before fetching. search_configs returns only matching lines (up to 20 per config). get_latest_config returns the whole file. Ask for lines first and full configs only for the devices that matter.
• Diff instead of comparing. get_config_diff returns only the changed hunks between two versions.
• Filter early. get_devices takes name, vendor, group and tag filters and pages at 50. Filtering by group or tag beats listing everything.
• Name the command you want. Without a filter, get_latest_config returns the newest stored output for the device, whichever command produced it. It takes a command filter, so “get the running config for core-sw-01” returns the running config even on a device that also collects show version. Each result’s command field shows which output you got.
• Turn off servers a task doesn’t need. Most clients can disable a server per session or limit which of its tools load.

Access and trust

• Least privilege per server. Use read-only tokens everywhere: an rConfig user limited to the devices in scope, a NetBox token without write permissions, a PagerDuty user in a restricted role.
• All results end up in one model. Configs from rConfig, logs from Grafana and incident notes from PagerDuty all go to the agent’s model provider. The strictest data rule among your tools applies to the whole agent.
• Treat tool results as data, not instructions. Interface descriptions, banners and ticket text are free text written by people. An agent that follows instructions found inside a config is a risk, which is one more reason to keep every server read-only.

Write the routing down once

Agents follow standing instructions better than repeated prompts. Put a short brief in the place your client reads every session (a CLAUDE.md or AGENTS.md file, Cursor rules, or Copilot instructions):

## Network tools
- rConfig: stored device configs, config history and diffs, compliance results.
  Always quote last_config_at when citing a config.
- NetBox: intended state (devices, interfaces, IPs, VLANs). Treat as the plan, not the network.
- Grafana and Zabbix: current health and alerts.
- Match devices across tools by hostname. Never by ID.
- All tools are read-only. Propose changes as text; never claim a change was made.

The rConfig Skill gives the agent the rConfig half of this brief for you.

Related reference

• Connect an AI agent over MCP
• Device Sync overview
• NetBox Device Sync
• Roles