
NetBox MCP
io.github.mhajder由 GitHub 帳號 mhajder 發布v0.3.0更新於 Nov 7, 2026
MCP server for NetBox DCIM/IPAM with read-only and dry-run modes
概覽
本機 MCP 伺服器,讓助理以結構化方式讀寫 NetBox DCIM/IPAM 執行個體,並提供唯讀與試跑保護。
- 可以做什麼
- 列出、篩選、搜尋並讀取任何 NetBox 物件類型(含外掛類型),查看變更記錄與伺服器狀態
- 執行唯讀 GraphQL 查詢,並在寫入前檢視物件類型的可寫欄位與可選值
- 尋找空閒 IP、前綴、VLAN 與 ASN,追蹤線纜路徑,算繪裝置設定,計算前綴使用率並尋找機櫃空間
- 單筆或批次建立、更新、刪除物件,分配下一個空閒資源,連接線纜並執行自訂指令碼
- 可選擇將變更暫存到 netbox-branching 分支而非主分支
- 適用情境
- 適合助理需要回答網路資產問題或在 NetBox 中進行受控變更的情境,例如稽核裝置與 IP 空間、規劃分配,或準備供人工審核的變更。唯讀或試跑模式便於在開放寫入前先做探索性使用。
- 執行需求
- 本機 Python 3.11 至 3.15 執行環境(以 uvx 或 pip 執行)或 Docker 映像;可連線的 NetBox 4.2 或更新版本;NETBOX_URL 以及具備所需權限的 NetBox API 權杖(NETBOX_TOKEN)。選用設定涵蓋 SSL 驗證、逾時、限流、外掛探索、分支、HTTP 傳輸與 Sentry。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 NetBox MCP,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。
其他 MCP 客戶端
參照 儲存庫 中的啟動說明。
README
NetBox MCP Server
Give AI agents structured access to NetBox, your network source of truth
NetBox MCP Server is a Python-based Model Context Protocol (MCP) server that gives AI assistants structured access to NetBox - the source of truth for network infrastructure (DCIM and IPAM). A small set of generic tools covers all 139 core object types of NetBox 4.7 (and plugin types, if enabled), plus specialised tools for search, change logs, GraphQL, free IP/prefix/VLAN allocation, prefix utilization, free rack space, cable tracing and connecting, config rendering, custom scripts and (optionally) netbox-branching. Writes can be hidden entirely (read-only mode) or simulated (dry-run mode).
✨ Features
Core Features
- Query any NetBox object type with filtering, ordering and pagination through one tool
- Keep responses small with
fields,omitandbrief- the tools steer the model to use them - Search many object types at once, with explicit reporting of failed and truncated types
- Read the change log (who changed what, when) and NetBox status/version/plugins
- Run read-only GraphQL queries for nested data in one round trip
- List free IPs, prefixes, VLANs and ASNs; trace cable paths; render device configs
- Compute prefix utilization (as the NetBox UI shows it) and find racks with room for a device
Management Operations
- Create, update and delete any object type, singly or in bulk (NetBox runs a bulk write as one transaction)
- Allocate the next free IP, prefix, VLAN or ASN atomically
- Connect ports with a cable, naming them by device and port name
- Run NetBox custom scripts (changes rolled back unless
commitis set) - Optionally stage changes in a netbox-branching branch instead of main
- Describe an object type's writable fields and choices before writing
Advanced Capabilities
- Read-only mode hides every write tool; dry-run mode turns every write into a preview
- NetBox v2 (
Bearer nbt_...) and legacy v1 (Token ...) API tokens - Plugin object type discovery (e.g.
netbox_dns.zone) - Filter validation that rejects filters NetBox would silently ignore (
__in, multi-hop lookups) - Retries on 429/5xx without ever replaying a create after a server error
- Tag-based tool filtering, optional tool-search transform, rate limiting and response size limit
- Bearer token authentication for HTTP transport
- Multiple transport options (STDIO, SSE, HTTP)
- Optional Sentry integration for error tracking
🚀 Installation
Prerequisites
- Python 3.11 to 3.15
- A NetBox instance, version 4.2 or newer. Features added later (
omit, v2 tokens,/api/authentication-check/) are used when the server detects them - A NetBox API token with the permissions you want the assistant to have. The token is the real security boundary: a read-only token cannot write, whatever this server's settings are
Quick Install from PyPI
The easiest way to get started is to install from PyPI:
Remember to configure the environment variables for your NetBox instance before running the server:
Install from Source
- Clone the repository:
- Install dependencies:
- Configure environment variables:
- Run the server:
Using Docker
A Docker image is available on GitHub Packages for easy deployment.
Development Setup
For development with additional tools:
🔧 Configuration
Environment Variables
🧰 Available Tools
Object types are named app.model, as NetBox itself names them (dcim.device, ipam.prefix, virtualization.virtualmachine). API paths such as dcim/devices are accepted too. With branching enabled, every tool that reads or writes objects also takes an optional branch argument.
Objects (read)
Specialised (read)
Write
Tool Tags
Every tool is tagged netbox plus a group tag, which DISABLED_TAGS can switch off: objects, search, changelog, status, graphql, ipam, dcim, config, branching, scripts, write and delete. Read tools also carry read-only.
🔒 Security & Safety Features
Read-Only Mode
Read-only mode hides every write tool - the client only sees the 13 read tools (14 with branching enabled):
Dry-Run Mode
Dry-run mode keeps the write tools visible, but none of them changes NetBox. Each one resolves and validates its target, then returns the request it would have sent, flagged "dry_run": true. Updates and deletes also fetch the current object, so the preview shows the values that would change and exactly what would be deleted:
READ_ONLY_MODE takes precedence: when both are set, write tools are hidden.
NetBox Branching
With the netbox-branching plugin, changes can be staged in a branch and reviewed before they are merged into main. Branching support is off by default, so a NetBox without the plugin gets no branch tools and no branch argument. Enable it with:
This adds netbox_list_branches and netbox_create_branch, and a branch argument (a branch name or its schema ID) to every other tool. To send every call to one branch by default:
Setting NETBOX_BRANCH without NETBOX_BRANCHING_ENABLED=true is a configuration error: the server refuses to start rather than silently writing to main.
Branch names are resolved to the schema ID that the X-NetBox-Branch header needs. Merging, syncing and reverting are deliberately not exposed as tools - they belong in a human review step.
Plugin Discovery
The first time a call names an unknown type (or netbox_list_object_types runs), the server reads /api/core/object-types/ and adds every plugin model with a REST endpoint (for example netbox_dns.zone). Plugin types never shadow core types. If discovery fails, the core types keep working.
Tag-Based Tool Filtering
You can disable specific categories of tools by setting disabled tags. For example, allow creates and updates but never deletes:
Response Size Limit
Large NetBox objects add up quickly. RESPONSE_MAX_SIZE truncates any tool response above the given number of bytes:
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.
Tool search respects existing visibility controls (read-only mode and disabled tags).
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.
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.
SSL/TLS Configuration
The server supports SSL certificate verification and custom timeout settings:
Certificates are verified against the operating system trust store, so a NetBox behind an internal CA works as soon as that CA is trusted by the OS. SSL_CERT_FILE or SSL_CERT_DIR take precedence when set.
Transport Configuration
The server supports multiple transport mechanisms for the MCP protocol:
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:
Per-user NetBox tokens
By default every client shares the server's NETBOX_TOKEN, so NetBox sees one user. With NETBOX_TOKEN_PASSTHROUGH=true, each client sends its own NetBox API token instead. NetBox applies that user's permissions and the changelog records the real user:
- Requests without a token, or with a token NetBox rejects, get HTTP 401. If NetBox cannot be reached to check a token within 10 seconds (or
NETBOX_TIMEOUT, if lower), the request gets HTTP 503 withRetry-After, so clients retry instead of logging in again. The 503 passes on NetBox's ownRetry-Afterwhen NetBox sends one. Accepted tokens are cached for 60 seconds. After that, the token is still accepted right away for up to 10 minutes while the server re-checks it with NetBox in the background, so a known user never waits on a check, even during a NetBox outage. A revoked token is dropped once its re-check comes back; until then it only reaches tools that don't call NetBox (such as the tool list), because NetBox refuses the token on every call that does. Rejected tokens are cached for 30 seconds, so a token just created in NetBox may be refused for up to 30 seconds if it was tried before it existed. At most 8 token checks reach NetBox at once; requests with a token the server hasn't seen yet wait for a free slot, and get HTTP 503 if the wait exceeds the check timeout. - v2 (
nbt_...) and legacy v1 tokens both work; the server sends each to NetBox with the right scheme. NETBOX_TOKENis ignored. Only thehttpandssetransports are supported, and the server refuses to start ifMCP_HTTP_BEARER_TOKENis set too, since both use theAuthorizationheader.- With
RATE_LIMIT_ENABLED=true, each NetBox user gets their own rate-limit window (each token on NetBox before 4.5), so the limit no longer caps the server's total load on NetBox. - With
NETBOX_PLUGIN_DISCOVERY=true, plugin types found with any user's token are added to one shared list.rediscoverreplaces that list with what the calling user can see, which drops uninstalled plugins; another user's call that names a type only they can see rediscovers it with their token. - Clients send their NetBox tokens to this server, so put it behind HTTPS.
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 NetBox, so a NetBox outage does not mark the MCP server unhealthy.
The Docker image's HEALTHCHECK uses it:
For more information on FastMCP transports, see the FastMCP documentation.
🤝 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.
來源:README.md,提交 3240808
工具
0版本歷史
4- v0.3.0最新Nov 7, 2026
- v0.2.1Oct 23, 2026
- v0.2.0Oct 19, 2026
- v0.1.0Sep 27, 2026
評分
已滿足適用檢查項的 50%
該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。
- 近 30 天內可連通25 分
請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。
- 已宣告認證方式10 分
請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。
- 已列出工具15 分
請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。
- 描述必需15 分
- 圖示10 分
- 文件15 分
- 授權條款10 分