A
AIops-tools/Firewall-AIops
Governed AI-ops for OPNsense + pfSense firewalls — gateway/rule/traffic RCA, guarded rule/alias writes, with audit/budget/undo (preview)
SECURITY.md ✓
View on GitHub ↗Link checked 2026-11-12 · HTTP 200 · opens the vendor's own site
Install & config
- Copy the command above
- Paste it as one entry under
mcpServersinclaude_desktop_config.json— local servers take command + args (example: clients) - Restart your client
Client config (built from the install command this repo gives)
{
"mcpServers": {
"aiops-tools-firewall-aiops": {
"command": "uv",
"args": ["tool", "install", "firewall-aiops"]
}
}
}Parsed from the README we fetched on 2026-10-26; we have not executed it.
command/args come from the install command the repository states. When it is ambiguous, the project README wins.
VS Code (.vscode/mcp.json - the key is servers)
{
"servers": {
"aiops-tools-firewall-aiops": {
"command": "uv",
"args": ["tool", "install", "firewall-aiops"]
}
}
}Same server, but VS Code keeps it under <code>servers</code>.
Claude Code (command line)
claude mcp add --transport stdio aiops-tools-firewall-aiops -- uv tool install firewall-aiops
Claude Code does not read a config file; add the server with this command.
Key names differ by client: Clients & CLI
- Star count
- 2 ★ · AIops-tools/Firewall-AIops · read from the GitHub search API · (checked 2026-11-13 20:00:50)
- Source
- collected from the punkpeye/awesome-mcp-servers list · type: MCP server
- Harvest history
- first seen 2026-10-23 · last seen 2026-11-14 · seen 26× · listed by 23 sources
- Score
- score 2,300 · 2 ★ · 23 sources · mcp
- Install
uv tool install firewall-aiops
FAQ (answers come from our records)
How do I install it?
The repository provides this install command:
uv tool install firewall-aiops. It comes from the repository itself; we cannot guarantee it runs as-is in your client.Who is it for?
We filed it under these tags: MCP 服务. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository
AIops-tools/Firewall-AIops；first catalogued 2026-10-23；last seen 2026-11-14。There is no official certification or quality rating here — we record sources and dates only.# Firewall AIops
以下摘录自该仓库的 README（片段） · 在 GitHub 读完整 README →
Governed, audited AI-ops for OPNsense and pfSense firewalls — for AI agents (via MCP) and humans (via CLI).
> Disclaimer: Community-maintained open-source project. Not affiliated with, endorsed by, or sponsored by the OPNsense project, Deciso, Netgate, or the pfSense project. OPNsense, pfSense and Netgate are trademarks of their respective owners. MIT licensed.
firewall-aiops speaks to two firewall platforms behind one MCP server — OPNsense
(REST API under /api/..., API key+secret via HTTP Basic auth) and pfSense
(REST API v2 under /api/v2/... from the pfSense-pkg-RESTAPI package, API key via
an X-API-Key header) — with the same tools working on both. Each target in the
config names its own platform; a name-keyed platform registry selects the API shape
(auth + resource paths), so an agent never has to know which firewall it is talking to.
Every tool runs through a built-in governance harness (vendored, zero external
dependency): audit log, token/call budget with runaway circuit-breaker, descriptive
risk-tier labelling, undo-token recording, and prompt-injection sanitisation.
## Why this exists
One server, both firewalls — OPNsense and pfSense in a mixed estate, spoken to
through identical tool names. Adding a third firewall later is a new platform
descriptor, not a rewrite.
Read the whole firewall — firmware/health, interfaces & gateways, filter rules
(with hit counts and state table), NAT (port-forward / outbound / 1:1), aliases,
VPN (WireGuard / OpenVPN / IPsec), DHCP leases & reservations, and the firewall log.
Flagship RCA analyses — transparent heuristics that show their numbers, never a
black-box verdict: gatewayhealthrca (WAN loss/latency/down → cause + action),
rulehitandshadowanalysis (never-hit + shadowed/redundant rules), and
blockedtrafficrca (top blocked sources/ports → scan / brute-force / probe).
Governed writes — toggle a rule, add/remove an alias entry (reversible,
undo-recorded from the fetched before-state), flush states, restart a service, and
the "make it live" commit (applychanges / reconfigure) and reboot at
risk=high with a dry-run preview. Every write, reversible or not, lands an
audit row.
## What this tool does, and does not, decide
It delivers firewall operations — reads and writes — accurately and efficiently,
and records every one of them. It does not decide whether a write is allowed
to happen. That is the agent's judgement, or the permission of the account you
connect it with: give the OPNsense/pfSense API user a read-only role, and the
writes fail at the server — the place that actually owns the permission.
So there is no read-only switch, no policy file, no approval gate to configure.
The one thing the tool guarantees is that nothing is silent: every call, over
MCP and over the CLI alike, lands an audit row in ~/.firewall-aiops/audit.db,
and reversible writes still capture their before-state and record an inverse
where one exists.
> Each tool declares a risklevel, matched to its [READ]/[WRITE]
> documentation tag, and carried into the audit row as a descriptive tier — so a
> reviewer can see at a glance that a row was a high-risk write. It is a label,
> not a gate.
Running a smaller / local model? See
> Disclaimer: Community-maintained open-source project. Not affiliated with, endorsed by, or sponsored by the OPNsense project, Deciso, Netgate, or the pfSense project. OPNsense, pfSense and Netgate are trademarks of their respective owners. MIT licensed.
firewall-aiops speaks to two firewall platforms behind one MCP server — OPNsense
(REST API under /api/..., API key+secret via HTTP Basic auth) and pfSense
(REST API v2 under /api/v2/... from the pfSense-pkg-RESTAPI package, API key via
an X-API-Key header) — with the same tools working on both. Each target in the
config names its own platform; a name-keyed platform registry selects the API shape
(auth + resource paths), so an agent never has to know which firewall it is talking to.
Every tool runs through a built-in governance harness (vendored, zero external
dependency): audit log, token/call budget with runaway circuit-breaker, descriptive
risk-tier labelling, undo-token recording, and prompt-injection sanitisation.
## Why this exists
One server, both firewalls — OPNsense and pfSense in a mixed estate, spoken to
through identical tool names. Adding a third firewall later is a new platform
descriptor, not a rewrite.
Read the whole firewall — firmware/health, interfaces & gateways, filter rules
(with hit counts and state table), NAT (port-forward / outbound / 1:1), aliases,
VPN (WireGuard / OpenVPN / IPsec), DHCP leases & reservations, and the firewall log.
Flagship RCA analyses — transparent heuristics that show their numbers, never a
black-box verdict: gatewayhealthrca (WAN loss/latency/down → cause + action),
rulehitandshadowanalysis (never-hit + shadowed/redundant rules), and
blockedtrafficrca (top blocked sources/ports → scan / brute-force / probe).
Governed writes — toggle a rule, add/remove an alias entry (reversible,
undo-recorded from the fetched before-state), flush states, restart a service, and
the "make it live" commit (applychanges / reconfigure) and reboot at
risk=high with a dry-run preview. Every write, reversible or not, lands an
audit row.
## What this tool does, and does not, decide
It delivers firewall operations — reads and writes — accurately and efficiently,
and records every one of them. It does not decide whether a write is allowed
to happen. That is the agent's judgement, or the permission of the account you
connect it with: give the OPNsense/pfSense API user a read-only role, and the
writes fail at the server — the place that actually owns the permission.
So there is no read-only switch, no policy file, no approval gate to configure.
The one thing the tool guarantees is that nothing is silent: every call, over
MCP and over the CLI alike, lands an audit row in ~/.firewall-aiops/audit.db,
and reversible writes still capture their before-state and record an inverse
where one exists.
> Each tool declares a risklevel, matched to its [READ]/[WRITE]
> documentation tag, and carried into the audit row as a descriptive tier — so a
> reviewer can see at a glance that a row was a high-risk write. It is a label,
> not a gate.
Running a smaller / local model? See
Listed badge (optional)
Copy this line into the README if you want the listing mark. Optional, and it does not affect being listed.
[](https://anclum.com/en/s/aiops-tools-firewall-aiops/)
- Source
- awesome · https://github.com/AIops-tools/Firewall-AIops
- Browse by field
- MCP servers
- Traction
- 2 ★
- Listed by
- 23 independent sources
- added
- today
- Security policy
- the repository has
SECURITY.mdat its root (we checked that the file exists, not what it says)
More like this
Filed under
Every tag opens the full list for that filter. Counts are the live catalogue figures.