
Oxidized MCP
io.github.mhajderPublished by GitHub account mhajderv0.2.2Updated Nov 7, 2026
MCP server for Oxidized network device configuration backups
Overview
MCP server that lets an assistant browse, search, diff and back up network device configurations stored in Oxidized via its oxidized-web API.
- What you can do
- List, find and inspect devices with backup status and health statistics
- Read the latest configuration of a device, paged by lines
- Search all stored configurations by regex or literal text with context
- Browse version history, read past versions and diff them as unified diffs
- Queue an immediate backup or reload the node list (hidden in read-only mode)
- When to use it
- Useful when you keep network device configs in Oxidized and want an assistant to answer questions about inventory, backup health, configuration contents or recent changes, or to trigger a backup without opening the web UI.
- Requirements
- Python 3.11-3.15 (run with uvx or pip) or the Docker image; a reachable Oxidized instance with oxidized-web enabled, set via OXIDIZED_URL. Optional HTTP Basic auth via OXIDIZED_USERNAME and OXIDIZED_PASSWORD. Version history and diffs need the git or gitcrypt output. HTTP transports can use MCP_HTTP_BEARER_TOKEN.
Installation
In SourceWeft
- Open Oxidized MCP in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
Oxidized MCP Server
Let AI agents search, compare and back up network device configs stored in Oxidized
Oxidized MCP Server is a Python-based Model Context Protocol (MCP) server that gives AI assistants access to Oxidized, the network device configuration backup tool. It talks to the oxidized-web REST API to list devices, check backup health, read and search device configurations, browse and diff configuration history, and queue backups. It supports read-only mode, tag-based tool filtering, and bearer token authentication for HTTP transports.
✨ Features
Core Features
- List and filter managed devices by group, model and last backup status
- Find devices by partial name, full name (
group/name) or IP address - Summarise backup health: failures, devices never backed up and stale backups
- Read the latest backed-up configuration of any device, paged for large configs
- Search all configurations for a regular expression or literal text, with matching lines and context
Configuration History
- List the stored configuration versions of a device (git output)
- Read a device's configuration as it was at any version (full oid or short prefix)
- Diff two versions, or just see the most recent change, as a unified diff
Operations
- Queue an immediate backup of a device, optionally with a commit message and author
- Reload the node list from its source (router.db, SQL, HTTP, ...)
- Read-only mode hides every operation for safe monitoring
Advanced Capabilities
- Node vars (often device credentials) are redacted in tool output by default
- HTTP Basic auth for oxidized-web behind a reverse proxy
- Rate limiting, SSL/TLS verification and configurable timeouts
- Tag-based tool filtering and an optional tool-search transform
- Bearer token authentication for HTTP transports
🚀 Installation
Prerequisites
- Python 3.11 to 3.15
- A running Oxidized instance with oxidized-web enabled
- For version history and diffs: the Oxidized
git(orgitcrypt) output
Quick Install from PyPI
The easiest way to get started is to install from PyPI:
Remember to configure the environment variables for your Oxidized instance before running the server:
For more details, visit: https://pypi.org/project/oxidized-mcp/
Install from Source
- Clone the repository:
- Install dependencies:
- Configure environment variables:
- Run the server:
Development Setup
For development with additional tools:
🔧 Configuration
Environment Variables
Sentry Error Tracking & Monitoring (Optional)
The server optionally supports Sentry for error tracking, performance monitoring, and debugging. Sentry integration is completely optional and only initialized if configured.
Installation
To enable Sentry monitoring, install the optional dependency:
Configuration
Enable Sentry by setting the SENTRY_DSN environment variable in your .env file:
Features
When enabled, Sentry automatically captures:
- Exceptions & Errors: All unhandled exceptions with full context
- Performance Metrics: Request/response times and traces
- MCP Integration: Detailed MCP server activity and interactions
- Logs & Breadcrumbs: Application logs and event trails for debugging
- Context Data: Environment, client info, and request parameters
Getting a Sentry DSN
- Create a free account at sentry.io
- Create a new Python project
- Copy your DSN from the project settings
- Set it in your
.envfile
Disabling Sentry
Sentry is completely optional. If you don't set SENTRY_DSN, the server will run normally without any Sentry integration, and no monitoring data will be collected.
🧰 Available Tools
Node Tools
list_nodes: List devices with optional filters (group, model, last run status, name/IP substring) and paging; group/model are filtered by Oxidized itself (/nodes/<group|model>/<value>.json), so large inventories are not transferred in fullget_node: Get a single device's details and last backup run (accepts name or IP)find_nodes: Find devices by partial name, full name or IP, exact matches firstget_backup_stats: Backup health summary - counts per status, group and model, success rate, failed / never backed up / stale devices; optionally for a single group or model
Configuration Tools
get_node_config: Get the latest backed-up configuration of a device (by name or IP), paged by lines (offset/max_lines)search_configs: Search all configurations for a regex or literal text; returns matching lines with line numbers and optional context
Version History Tools
Require the Oxidized git or gitcrypt output.
list_node_versions: List stored configuration versions (oid, date, author, message), newest firstget_node_version: Get the configuration at a given version (full oid or unique prefix), paged by linesdiff_node_versions: Unified diff between two versions; defaults to the most recent change
Operation Tools
Hidden when READ_ONLY_MODE=true.
trigger_node_backup: Queue an immediate backup of a device, optionally recording a commit message and authorreload_nodes: Reload the whole node list from its source (a per-node reload is deliberately not offered: oxidized-web's/reload?node=Xreplaces the entire in-memory node list with the matching nodes)
🔒 Security & Safety Features
Read-Only Mode
The server supports a read-only mode that disables all write operations for safe monitoring:
When enabled, only tools tagged read-only are exposed: trigger_node_backup and reload_nodes are hidden, while every node, configuration and history tool stays available.
Tag-Based Tool Filtering
You can disable specific categories of tools by setting disabled tags:
Available tags include:
node- Node listing and lookup tools (and the backup/reload operations)stats- Backup health statisticsconfig- Configuration read toolssearch- Configuration search and node search toolsversion- Version history toolsdiff- Version diff toolbackup- Backup trigger operationreload- Node list reload operationread-only- Every tool that does not change Oxidized state
Rate Limiting
The server supports rate limiting to control API usage and prevent abuse. If enabled, requests are limited per client using a sliding window algorithm.
Enable rate limiting by setting the following environment variables in your .env file:
If RATE_LIMIT_ENABLED is set to true, the server will apply rate limiting middleware. Adjust RATE_LIMIT_MAX_REQUESTS and RATE_LIMIT_WINDOW_MINUTES as needed for your environment. Both must be at least 1 when rate limiting is on; while it is off they are not read.
Tool Search for Large Toolsets
FastMCP tool search can reduce prompt size for servers with many tools.
When enabled, list_tools returns two synthetic tools:
search_tools: Finds matching tools and returns their full schemascall_tool: Executes any discovered tool by name
Enable it with:
bm25 supports natural language queries, while regex uses a regex
pattern input for deterministic matching.
With tool search enabled, any other TOOL_SEARCH_STRATEGY value stops the
server at startup, and TOOL_SEARCH_MAX_RESULTS must be at least 1.
Tool search respects existing visibility controls (read-only mode and disabled tags).
SSL/TLS Configuration
The server supports SSL certificate verification and custom timeout settings:
Upstream Authentication
oxidized-web has no authentication of its own and is usually published behind a reverse proxy with HTTP Basic auth. Set both variables to send Basic auth with every request:
Node Vars Redaction
Node vars from the Oxidized source (router.db, SQL, HTTP) often contain per-device credentials, and oxidized-web returns them unredacted from /nodes.json. The server replaces every var value with <redacted> (keeping the keys) unless you opt out:
Transport Configuration
The server supports multiple transport protocols for different deployment scenarios:
STDIO Transport (Default)
The default transport uses standard input/output for communication. This is ideal for local usage and integration with tools that communicate via stdin/stdout:
HTTP SSE Transport (Server-Sent Events)
For network-based deployments, you can use HTTP with Server-Sent Events. This allows the MCP server to be accessed over HTTP with real-time streaming:
When using SSE transport with a bearer token, clients must include the token in their requests:
HTTP Streamable Transport
The HTTP Streamable transport provides HTTP-based communication with request/response streaming. This is ideal for web integrations and tools that need HTTP endpoints:
When using streamable transport with a bearer token:
Note: The HTTP transport requires proper JSON-RPC formatting with jsonrpc and id fields. The server may also require session initialization for some operations.
Health Endpoint
Both HTTP transports (sse and http) serve GET /health, which answers 200 ok
when the server is handling requests. It needs no bearer token and does not
contact Oxidized, so an Oxidized outage does not mark the MCP server unhealthy.
The Docker image's HEALTHCHECK uses it:
📝 Oxidized Notes
- Version history (
list_node_versions,get_node_version,diff_node_versions) needs thegitorgitcryptoutput. With thefileoutput Oxidized reports no versions. - Groups: node names should be unique. Tools accept an optional
groupto disambiguate;get_node_configand the history tools look the group up automatically when it is omitted (with the git output'ssingle_repothe group is part of the stored path, so it is required by oxidized-web). Nodes without a group are shown as groupdefault, and passingdefaultback is treated as "no group".search_configsfilters groups the same way aslist_nodes(exact match).trigger_node_backuptakes no group because Oxidized queues backups by node name or IP only. - Filtering large inventories:
groupandmodelinlist_nodes/get_backup_statsare filtered by Oxidized itself. The group must match exactly (case-sensitive, as shown bylist_nodes), so a misspelt group returns nothing instead of downloading the whole inventory. Built-in model names are case-insensitive (iosand theIOSXEalias are sent asIOS, from a catalog of Oxidized's models); custom models must be spelled exactly. Neither filter ever falls back to downloading the whole inventory. - Search runs in two steps: oxidized-web's
conf_searchfinds matching devices (it reads every configuration server-side, so it can be slow on large installations), then only those configurations are fetched to extract matching lines.max_nodescaps the fetches; nodes that were never backed up (whose placeholder text can match) are skipped without counting. The server-side step usesOXIDIZED_SEARCH_TIMEOUT(default 300 s) instead ofOXIDIZED_TIMEOUT. Patterns run as Ruby regexps on the server and Python regexps locally, line by line, so stick to common syntax. - Backups are asynchronous:
trigger_node_backupmoves the device to the head of the queue. Checkget_nodefor the result. - Errors: oxidized-web answers unknown node names with HTTP 500. When it runs with
RACK_ENV=productionthe reason is hidden, so a 500 on a node route is reported with a hint that it may be an unknown node name.
🐳 Using Docker
A Docker image is available on GitHub Packages for easy deployment.
The image defaults to the HTTP Streamable transport on port 8000 (http://localhost:8000/mcp).
🤝 Contributing
Contributions are welcome. See CONTRIBUTING.md for the dev setup, checks and commit message format, and use the issue templates for bugs and feature requests.
Found a security problem? Please report it privately as described in SECURITY.md.
📜 License
MIT License - see LICENSE for details.
Source: README.md at commit b36bd7b
Tools
0Version history
4- v0.2.2LatestNov 7, 2026
- v0.2.1Oct 23, 2026
- v0.2.0Oct 19, 2026
- v0.1.0Sep 27, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts