Cursor MCP setup for rConfig: real network configs while you write automation

Cursor MCP setup for rConfig: real network configs while you write automation

Cursor’s agent can call rConfig’s MCP server over Streamable HTTP with a bearer token, so it reads real device configs while it writes your code. That changes automation work: a template, parser or playbook gets built against what’s actually on the devices, not against a guess or a stale sample.

Best for: network automation developers, template and parser work, checking a script’s assumptions against the estate.

Connect

Add rConfig to ~/.cursor/mcp.json (all your projects) or .cursor/mcp.json (one project). Cursor expands ${env:NAME}, so the token can stay out of the file:

{
  "mcpServers": {
    "rconfig": {
      "url": "https://<your-rconfig-server>/mcp",
      "headers": { "Authorization": "Bearer ${env:RCONFIG_MCP_TOKEN}" }
    }
  }
}

The MCP server page is the reference for these settings.

Check it: open Cursor’s MCP settings. rconfig shows a green status and lists its eight tools.

Add the rConfig Skill

Download the rConfig Skill and add SKILL.md to the project’s Cursor rules. It tells the agent which tool to use for what, and to check which command a config came from.

Tool approvals

Cursor asks before its agent runs an MCP tool unless you’ve allowed that tool to run automatically. Every rConfig tool is read-only, so letting them run without a prompt is low risk. Keep prompts on for any servers in the same project that can write.

Things to ask

Cursor is at its best when the answer is code in your repository.

• Template from reality: “Read the latest running configs of the three DUB access switches from rConfig. Write a Jinja2 template that reproduces their interface sections, and list every line that differs between them.”
• Parser tests with real input: “Get the running config of lon-fw-01 from rConfig and add it as a fixture for tests/test_acl_parser.py. Then write tests for the three ACLs it contains.”
• Check assumptions: “My script assumes every device in the Core group is Cisco and has a Loopback0. Check that against rConfig and list the exceptions.”

Configs from rConfig arrive with secrets obfuscated, so a fixture built this way doesn’t leak passwords. Review it anyway before committing: hostnames and addresses may still be sensitive.

Quirks worth knowing

• Which config you get: unless a command is named, get_latest_config returns the newest stored output for the device, whatever the command. Ask for the running config explicitly; the agent passes that to the tool’s command filter.
• Large configs use context: for a question about one setting across many devices, ask the agent to search (search_configs) rather than open every config.
• Certificates: with an internal CA, Cursor’s runtime has to trust it, or the connection fails without a clear TLS error.

Related reference

• Connect an AI agent over MCP
• Download the rConfig Skill
• AI-friendly REST API docs: for scripts that call rConfig’s API directly
• Which AI agents can connect to rConfig?