Damira + NetBox + pyATS + Ansible

Use Damira in Claude Code or Cursor with the NetBox, Ansible Automation Platform, pyATS and Terraform MCP servers you already run. Intent from your source of truth, a validated change, and a check-mode hand-off, with advisor mode enforced.

Damira works with your automation stack. It doesn't replace it or host it. If you already run NetBox or Nautobot, Ansible Automation Platform (AAP), pyATS or Terraform, connect their MCP servers to Claude Code or Cursor. Damira reads the intended state from your source of truth, has your AI write the change, validates it locally, and hands it to your own tools in check mode. You apply it.

Damira ships none of these servers and holds none of their credentials. They run under your accounts, with your permissions.

What you get

Your server	Damira uses it for	What stays with you
NetBox / Nautobot	Intended state: devices, interfaces, VLANs, prefixes, config context	Editing the source of truth
Ansible Automation Platform	Launching the validated playbook as a job in check mode, with diff	The live run
pyATS / Genie	Before and after snapshots of the features the change touches, and their diff	Approving each device call
Terraform	Provider and module documentation lookups	Plan review and apply, from your pipeline

The source-of-truth-change skill chains them: intent, then a generated playbook, Terraform or Python, then damira validate, then the hand-off to whichever servers you have.

Setup

1. Connect your servers

Add the MCP servers you use to your AI tool the way their maintainers document. Keep the product in each server's name (netbox, aap, pyats, terraform): Damira's advisor-mode check recognizes the servers by name in Claude Code.

Project servers go in .mcp.json at the root of your workspace; tokens come from your environment, not the file.

{
  "mcpServers": {
    "netbox": {
      "command": "<your NetBox MCP server command>",
      "env": { "NETBOX_URL": "https://netbox.example.net", "NETBOX_TOKEN": "${NETBOX_TOKEN}" }
    },
    "aap": { "type": "http", "url": "https://aap.example.net/mcp" },
    "pyats": { "command": "<your pyATS MCP server command>" },
    "terraform": { "command": "docker", "args": ["run", "-i", "--rm", "hashicorp/terraform-mcp-server"] }
  }
}

2. Run `damira init`

Run the init skill (or damira init) in the workspace. It finds the servers above in .mcp.json, ~/.claude.json, .cursor/mcp.json and ~/.cursor/mcp.json and writes an Automation capabilities section to CLAUDE.md or AGENTS.md. The section lists server names and what each one unlocks. It never copies URLs, environment variables or tokens. Add --no-detect to skip it.

## Automation capabilities
- ~~source-of-truth: netbox: intended state (devices, interfaces, VLANs, prefixes) as the input to a change
- ~~automation: aap: launch the validated playbook as a job in check mode (job_type=check) for a diff; ...
- ~~testing: pyats: pyATS/Genie pre/post snapshots and diffs, each device call approved by the engineer; ...

3. Prepare AAP for check-mode launches

AAP ignores a launch setting unless the job template asks for it. On the job templates you want Damira to use, turn on Prompt on launch for Job type, Show changes (diff mode) and Limit. Without the job type prompt, Damira won't launch the template, because a check-mode request would be ignored.

Example session

Add VLAN 120 (VOICE) to the access ports tagged "voice" on the Chicago access
switches, from NetBox.

Intent. Your AI queries NetBox for active access switches at the Chicago site and the interfaces tagged voice, and shows a table of devices, interfaces and the intended VLAN with their NetBox IDs. You confirm.
Change. It writes a playbook with the cisco.ios resource modules, using the NetBox platform for ansible_network_os.
Validate. damira validate runs yamllint, ansible-playbook --syntax-check and ansible-lint locally and fixes what they find, for up to three rounds.
Pre-change snapshot. pyATS learns vlan and interface on the first switch. You approve the device call.
Check-mode job. Once you've committed the playbook to the project AAP syncs, your AI launches the job template with job_type=check, diff on, limited to one switch, and summarizes the diff.
Hand-back. You get the NetBox IDs, the files, the validate result, the diff, the launch settings for the live run, and the rollback. It offers to draft the change request for your ITSM tool.

You run the live job. Afterwards, ask for the post-change snapshot and your AI diffs it against the pre-change one.

Guardrails

Advisor mode is the default, and the plugin's device gate enforces it on these servers. The gate doesn't rely on the prompt.

Call	Advisor mode	Guided or lab mode
AAP job launch with `job_type=check`	You're asked to approve	You're asked to approve
AAP job launch in run mode, or a workflow launch	You're asked to approve (blocked in strict mode)	You're asked to approve
AAP lookups (templates, jobs, output)	Allowed	Allowed
pyATS call that reaches a device	You're asked to approve (blocked in strict mode)	You're asked to approve
pyATS configuration push	Blocked	You're asked to approve
Terraform run, apply or workspace change	Blocked	You're asked to approve
Terraform registry and docs lookups	Allowed	Allowed
NetBox reads and any other MCP server	Not touched by the gate	Not touched by the gate

A tool the gate doesn't recognize on one of these servers is sent to you to approve.

Limits. In Claude Code the gate recognizes a server by the name you gave it, so keep aap, ansible, pyats or terraform in the name. Servers added as claude.ai connectors appear under generated names that the gate can't recognize; add these servers to .mcp.json instead. The gate checks the launch request, not AAP's response, and can't see whether a template prompts for job type, so it asks before every launch, check mode included. Server names are matched in any case (AAP works as well as aap).

Terraform

The Terraform server is used for documentation only. Your AI writes the HCL, damira validate runs fmt, init without a backend and validate, and you run terraform plan locally or in CI. Applying happens in your pipeline.

Install: plugin setup for Claude Code and Cursor
Security: advisor mode, redaction and what Damira receives
Documents: MOPs and change controls from the same session
Automation & Generators: write and validate Terraform, automation scripts, pipelines and tests with no external server — for when you don't have (or don't want to wire in) NetBox, AAP, pyATS or Terraform MCP servers

Damira + NetBox + pyATS + Ansible

On this page