# MCP servers for NetBox: the options compared
> Every findable MCP option for NetBox side by side — nbox, NetBox Labs Platform MCP Server, NetBox MCP Enhanced, NetBox MCP Server, netbox-mcp-rw and ToolMesh + netbox.dadl. Coverage, auth, credential location, governance and write safety, each with sources.
Canonical: https://www.toolmesh.io/en/mcp/netbox/
There are **two MCP servers for NetBox from NetBox Labs itself**, plus four more from outside the company — and they differ far more than the shared name suggests. The open source one is read-only with four tools; the managed one is a NetBox Cloud service with nearly a hundred, and it is the only option that routes agent writes through a branch a human has to merge. This page lists what exists as of 15 August 2026, what each one covers, where your credentials sit, and what happens when an agent writes.
This page puts **all six MCP options we could find** for NetBox side by side across ten dimensions. We make one of them, which is why the sourcing rules below matter: no scores, no stars, no rankings — every cell states a fact and links to the evidence.
## Decision at a glance
The real choice is not the tool count but the shape of access: a small NetBox-specific agent connector, NetBox Cloud's integrated agentic change workflow, or one governance layer across NetBox and further systems. As of 15 August 2026 the field looks like this — **six MCP options**, plus seven adjacent projects that turn up under the same search terms but are not comparable options. Every claim in the table is a summary of sourced cells in the [comparison matrix](#comparison-matrix) below.
**What separates them.** Coverage runs from 4 tools to 608. Only the two NetBox Labs servers discover plugin object types at runtime. Only three of the six give callers their own identity — the rest work through a single NetBox token, and the OSS server's HTTP transport is unauthenticated unless you set MCP_AUTH_TOKEN, which its README says plainly. On write safety the spread is widest: three options write straight to the live instance, nbox splits writes into plan and apply, and only the Platform server isolates them in a branch with a diff a human approves.
## The options
## Comparison matrix
Rows are the ten dimensions; columns are the options. The table scrolls horizontally. Superscript numbers link to the [source](#sources) for that cell.
"Not documented" means the sources we checked do not state it — not that the feature is absent. If you maintain one of these projects and we got something wrong, [open an issue](https://github.com/DunkelCloud/ToolMesh/issues) and we will fix the data file.
:::caution[Two things to know before reading the table]
**Only our own entry is backed by a run against a live NetBox.** The other five rows are a reading of each project's own documentation and source code as of 15 August 2026 — see [methodology](#methodology-and-disclosure). The netbox.dadl behind our row is live-verified and was last reviewed on the same date.
**Tool counts are not a measure of capability.** The projects slice the API into tools at very different granularity, so "608 vs 4" says little on its own. The number that *is* comparable is endpoint coverage — how much of the NetBox REST API an option can actually reach, measured against the same denominator for everyone. We publish ours (608 of roughly 620 endpoints, 98%); none of the others publish theirs, so their endpoint coverage remains unquantified here. The Platform MCP Server's "nearly 100 tools" is the vendor's own figure, which we could not independently count without a NetBox Cloud instance.
:::
## When a dedicated NetBox server is the better choice
A gateway that reads a static description of the NetBox REST API reaches exactly what that description declares — no less, and structurally no more. Four things sit outside ours, and for those a purpose-built server wins:
- **`/api/plugins/` endpoints** — which is where NetBox Branching actually lives. The branching REST API sits under `/api/plugins/branching/`, and netbox.dadl explicitly excludes plugin endpoints, so branch-based review of agent writes cannot be driven through the gateway today. The Platform MCP Server has branching wired in natively.
- **Dynamic model discovery.** A static description cannot notice at startup which plugins an instance has installed. The Platform MCP Server discovers every object type the instance exposes; the OSS server can optionally discover plugin object types on NetBox 4.2+.
- **GraphQL.** netbox.dadl covers the REST API only. The Platform MCP Server offers GraphQL queries from the Starter tier.
- **Bulk collection operations.** Bulk PUT/PATCH/DELETE on collections is explicitly not covered in netbox.dadl — per-object calls in Code Mode are the stated alternative. The Platform MCP Server and netbox-mcp-rw both ship dedicated bulk tools.
A gateway reading a static description reaches none of these. If your use case depends on one of them, pick accordingly.
## When a gateway is the better choice
A gateway earns its keep when NetBox is not the only system in the picture:
- **Questions that span systems.** "Which hosts are critical in Checkmk, and who owns them in NetBox?" is one agent turn against one endpoint, instead of two connectors that cannot see each other. The public [DADL registry](https://www.dadl.ai) lists 30 APIs and over 4,000 tools as of August 2026, so the second system is often already described.
- **One place for credentials.** The NetBox token lives server-side and is injected at call time, rather than sitting in every operator's client configuration.
- **One authorization model and one audit trail** across every connected system, instead of per-connector conventions.
- **Context economy at scale.** 608 NetBox tools is a lot of schema for a model to carry; a catalog that stays flat matters more the more systems you connect. This one is not ours alone — the Platform MCP Server's Code Mode solves the same problem for NetBox Cloud.
The honest trade-off: a gateway is **a standing service** you have to run, monitor and keep available. The dedicated servers' leanest shape is a subprocess your LLM client launches — nothing to operate at all. Run one of them centrally over HTTP instead and you are operating a component too; the count evens out, and the difference shifts to what the matrix above shows: a service fronting one system on a shared NetBox token versus a multi-user gateway fronting several. Either way, a gateway only pays for itself once more than one system is behind it. If NetBox is the only thing you will ever connect, and reads are all you need, the first-party open source server is the leaner answer. It exists, it is four tools, and it cannot change a single NetBox object.
## Coverage report
The machine-readable coverage report for our option — every tool, its access class, and which parts of the NetBox REST API are and are not covered — is at **[dadl.ai/d/netbox](https://www.dadl.ai/d/netbox)**. It records 608 tools over 608 of roughly 620 REST endpoints (98%), each tool carrying one of four access classes (248 read, 207 write, 114 dangerous, 39 admin), with the uncovered areas named explicitly: plugin endpoints, GraphQL and bulk collection writes.
## Frequently asked questions
{faqs.map(({ q, a }) => (
<>
{q}
{a}
))}
---
*Reference from here on — the adjacent projects, the methodology and disclosure, the changelog and the sources. Nothing below is needed for the decision above; it is where the evidence lives.*
## Adjacent projects that are not listed as options
Found under the same search terms, but not comparable options under the [inclusion criterion](#methodology-and-disclosure) — each with the reason:
## Methodology and disclosure
**Disclosure.** This page is published by [Dunkel Cloud GmbH](https://www.dunkel.cloud), which makes ToolMesh — one of the six options listed. We have an obvious interest in how it looks. The countermeasures are structural: options are ordered alphabetically by display name, our own entry included; every cell carries a source link; no cell contains a score or a ranking; and the two "when to choose" sections above name the cases where our option is the wrong tool.
**Inclusion criterion.** A GitHub search for "netbox mcp", "netbox mcp server" and "netbox model context protocol" on 15 August 2026 returned 46 repositories; the managed Platform MCP Server has no public repository and entered through the accompanying vendor research. An option is listed when all three points hold: a publicly reachable source or product page; presented as a usable server rather than a demo, course artifact or personal fork without independent substance; and documentation sufficient to fill at least the profile dimension. Six options met all three — five public repositories plus the managed Platform MCP Server. Seven projects are documented as adjacent, and the rest are forks, course artifacts and one-day experiments without a README or license.
**How the facts were gathered.** Each option's own repository, README, documentation and — where cited — source code, read on 15 August 2026. Repository metadata — license, last commit, stars and forks — comes from the GitHub API on the same date. Where a project does not state something, the cell says "not documented" rather than guessing. For hosted products that means the platform documentation, not only a product page: the Platform MCP Server's capabilities are documented across the NetBox Cloud documentation and the vendor's launch post, and both are cited. Registry aggregators were used only to find candidates, never as evidence.
**Depth of verification.** The five options we do not maintain are documentation and source-code review, not test results — read, not run. The verification column in the decision table states this per option, and vendor figures we cannot count ourselves are quoted as such. Our own entry is the exception: the netbox.dadl behind it is live-verified, and its row was last reviewed on 15 August 2026. The maintainers of all listed projects were notified when this page went live; if a documentation review got something wrong, their corrections land in the data file.
**Corrections and additions.** The matrix lives as one YAML file in this site's repository; the site repository itself is private, so corrections travel as [issues on the public ToolMesh repository](https://github.com/DunkelCloud/ToolMesh/issues). Correcting a fact, or adding an option we missed, takes one issue. Maintainers: if we have misrepresented your project, that is a bug and we will fix it.
## Changelog
## Sources