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.
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 below.
| Option | Fits when | Writes | Key limit | Verification |
|---|---|---|---|---|
| nbox | Reads first; writes only behind an explicit plan/apply step, with caller identity (OIDC) on the write path | Opt-in and narrow: status, description, tags, IP/prefix/range reservation | Deliberately small write surface; self-declared pre-1.0 | Docs review |
| NetBox Labs Platform MCP Server | On NetBox Cloud, with governed agent writes reviewed in branches | Yes, from the Starter plan; individually or in bulk, through isolated branches a human merges | NetBox Cloud only — no self-hosted or firewalled instances today | Docs review |
| NetBox MCP Enhanced | Writes against a self-hosted NetBox, with named tools per object family | Yes — more than fifty named write tools plus three generic ones, straight to the live instance | No license declared; no caller authentication documented for the HTTP transport | Docs review |
| NetBox MCP Server | Experimenting, or read-only access with the smallest possible surface | No — read-only by design | No writes, no GraphQL; the HTTP transport is unauthenticated unless MCP_AUTH_TOKEN is set | Docs review |
| netbox-mcp-rw | Generic CRUD including bulk, as a local subprocess of one client | Yes — nine generic tools including bulk, straight to the live instance | One subprocess per client; unchanged since September 2025, validation and tests open on the roadmap | Docs review |
| ToolMesh + netbox.dadl our project | Self-hosted NetBox alongside other systems, behind one governance layer | Yes — every tool carries an access class (read/write/dangerous/admin) that policies can gate | A standing service to operate; no /api/plugins/ (NetBox Branching), no GraphQL, no bulk writes | Hands-on tested |
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.
A Rust binary that is a terminal UI, a CLI and an MCP server at once. The MCP side is read-first: eleven read tools plus every object as an nbox:// resource, with two opt-in write tools behind a plan/apply step. The only community option with OIDC and a per-user vault on its HTTP write path. Self-declared pre-1.0.
The managed first-party server, in Public Preview on NetBox Cloud since June 2026. Nearly 100 tools covering reads, writes, bulk operations, IPAM allocation, cable tracing, GraphQL, config rendering and scripts, plus other NetBox Labs products. It is the only option here that routes agent writes through isolated branches a human reviews and merges, and the only one with dynamic model discovery that picks up installed plugins. Nothing to install; NetBox Cloud only.
A write-enabled derivative of the NetBox Labs OSS server: its four read tools plus more than fifty named write tools for sites, tenants, tags, VLANs, IPAM, DCIM, circuits and virtualization, and three generic create/update/delete tools. Ships a Docker Compose path and HTTP transport for web clients. The README states plainly that plugin object types are not supported. No license is declared.
The open source first-party server and, by adoption, the reference implementation: 213 stars and 94 forks, last pushed the day before this survey. Deliberately small -- four read tools over 127 core object types, no writes, no GraphQL -- and the project states that keeping it small is the point, with forking under Apache 2.0 as a supported path. The only option here with a signed, provenance-carrying container image.
Nine generic tools -- get, get-by-id, create, update, delete, the three bulk variants and changelogs -- that work against any NetBox object type rather than one tool per type. The most-starred community option with writes. The README calls it production ready while the roadmap still lists input validation, tests and async support as open. Created and last pushed on the same day in September 2025.
Not a NetBox-specific server but a self-hosted gateway reading a declarative YAML description of the NetBox REST API -- 608 tools, 98% of the API surface, the broadest coverage in this list. Governance (per-tool and per-user authorization, server-side credentials, output policies, audit) comes from the gateway rather than the connector. Two gaps follow from the static description: no dynamic plugin discovery, and no access to /api/plugins/ endpoints, which rules out driving NetBox Branching.
Our project — see the disclosure below
Rows are the ten dimensions; columns are the options. The table scrolls horizontally. Superscript numbers link to the source 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 and we will fix the data file.
| Dimension | nbox | NetBox Labs Platform MCP Server | NetBox MCP Enhanced | NetBox MCP Server | netbox-mcp-rw | ToolMesh + netbox.dadl our project |
|---|---|---|---|---|---|---|
| Maintainer type | Community -- single maintainer 1 | First party -- NetBox Labs, commercial 2 | Community -- single maintainer 3 | First party -- NetBox Labs, open source 4 | Community -- single maintainer 5 | Vendor -- Dunkel Cloud GmbH (publisher of this page) 7 |
| License | Apache-2.0 or MIT (dual) 1 | Proprietary (managed service) 2 | None declared 3 | Apache-2.0 4 | Apache-2.0 5 | Apache-2.0 (gateway and DADL registry) 7 |
| Runtime & install | Rust static binary; cargo, Homebrew, GHCR image, signed release archives 1 | None -- managed endpoint 2 | Python; uv or pip, plus a Docker Compose path 3 | Python 3; uv or pip, or the published Docker image 4 | Python 3.13+; git clone plus uv or pip 5 | Single Go binary; the DADL is one YAML file referenced from backends.yaml 8 |
| Last code activity | 12 Aug 2026 1 | Not applicable -- no public repository 2 | 19 Jul 2026 3 | 14 Aug 2026; latest release v1.2.1 (17 Jun 2026) 9 | 14 Sep 2025 -- created and last pushed the same day 5 | netbox.dadl last reviewed 15 Aug 2026 8 |
| Public adoption signal | 7 stars, 1 fork 1 | Not published 2 | 5 stars, 1 fork 3 | 213 stars, 94 forks 4 | 16 stars, 7 forks 5 | 5 stars, 0 forks (gateway repository) 7 |
| Maturity (self-declared) | "pre-1.0" 1 | Public Preview -- fully functional, no SLA 2 | No claim made 3 | Versioned releases since v1.0.0 (Oct 2025) 9 | "Production Ready"; the roadmap lists validation, tests and async as open 5 | Gateway is pre-1.0; the NetBox DADL is live-verified 7 |
| Tools / actions | 11 read tools plus 2 opt-in write tools 1 | "nearly 100 tools" -- vendor figure, not independently counted 10 | 4 read tools plus 50+ write tools and 3 generic write tools 3 | 4 tools -- get_objects, get_object_by_id, get_changelogs, search_objects 11 | 9 generic tools covering CRUD, the three bulk variants and changelogs 5 | 608 tools -- 608 of ~620 REST endpoints (98%) 6 |
| Read / write / delete | Read-only by default; writes are opt-in and narrow (status, description, tags, IP/prefix/range reservation) 1 | Read, write and delete, individually or in bulk; writes require a Starter plan or above 2 | Read, write and delete 3 | Read only -- by design, no write tools exist 4 | Read, write and delete, including bulk 5 | Read, write and delete; every tool carries an access class (248 read, 207 write, 114 dangerous, 39 admin) 8 |
| Core object coverage | Lookup-shaped: devices, IPs, prefixes, VLANs, sites, racks, rack groups, circuits, virtual circuits and more 1 | Discovered dynamically at startup -- every object type the instance exposes 2 | Explicitly defined and limited to core objects, per the README 3 | 127 core object types across dcim, ipam, circuits, virtualization, tenancy, vpn, wireless, extras, users and core 12 | README lists DCIM, IPAM, circuits and virtualization; the generic tools accept any type name 5 | DCIM, IPAM, virtualization, tenancy, circuits, wireless, VPN, extras, users and core, each declared endpoint by endpoint 8 |
| Plugin object types | Not documented 1 | Yes -- discovered dynamically at startup, so the tool surface grows with the instance 2 | No -- the README states plugin object types will not work 3 | Optional -- ENABLE_PLUGIN_DISCOVERY queries core/object-types at startup (NetBox 4.2+); off by default 4 | No -- plugin support is listed on the roadmap as open 5 | No -- /api/plugins/ endpoints are explicitly out of scope for a general DADL 8 |
| GraphQL, scripts, config rendering, cable tracing | Cable paths are rendered in detail views; GraphQL, scripts and config rendering are not documented 1 | All four -- GraphQL from Starter, cable tracing, config rendering and script execution from Professional 2 | Not documented 3 | None -- GraphQL and dynamic model discovery are stated as deliberately out of scope 4 | Not documented 5 | Scripts (+run), config templates (+render), cable trace and paths actions, rack elevation; GraphQL is not covered 8 |
| Next-available allocation (IP, prefix, VLAN, ASN) | Yes -- next-ip and next-prefix read-only, plus ip/prefix/ip-range reserve as writes 1 | Yes -- available prefixes, IPs, VLANs and ASNs, from Professional 2 | Not documented 3 | Not applicable -- read only 4 | Not documented 5 | Yes -- available-prefixes, available-ips, available-vlans and available-asns are declared 8 |
| Method towards NetBox | NetBox API token from config.toml or an env var 1 | NetBox v2 token (nbt_) as a Bearer header on the endpoint 2 | NETBOX_TOKEN via environment or Docker Compose 3 | NETBOX_TOKEN via CLI argument, environment variable or .env file 4 | NETBOX_TOKEN via environment variable 5 | Bearer token, injected server-side from the gateway's credential store at call time 13 |
| Where the secret lives | config.toml (0600 on Unix, redacted in config show) or an env var; no OS keyring 1 | In the client configuration -- the token is sent as a header on every connection 2 | On the host running the server 3 | On the machine running the server -- client config, environment or .env 4 | On the client machine, in the LLM client configuration or the environment 5 | Server-side in the gateway's credential store; not passed to the client or the model 13 |
| Who may call the server | stdio is a local subprocess; the HTTP transport supports OIDC with a per-user vault for writes 1 | Anyone with a valid NetBox token; the agent acts with that token's RBAC permissions 2 | Not documented -- no caller authentication is described for the HTTP transport 3 | Optional MCP_AUTH_TOKEN bearer on the HTTP transport; unauthenticated when unset, which the README flags explicitly 4 | Not applicable -- local subprocess of one client 5 | Authenticated gateway users with a per-user identity 14 |
| Least privilege | Through the NetBox token; read-only by default and writes require an explicit flag plus confirmation 1 | NetBox RBAC per token, plus tier-enforced tool registration and an optional per-connection read-only flag 2 | Through the NetBox token's permissions; the README recommends read-only tokens for read use 3 | Through the NetBox token; the README asks for a read-only token 4 | Through the NetBox token's permissions 5 | NetBox token permissions plus per-tool, per-user authorization in the gateway 14 |
| Deployment mode | Local subprocess (stdio) or a loopback HTTP service 1 | SaaS -- runs as part of your NetBox Cloud infrastructure 2 | Local subprocess or a self-hosted HTTP service via Docker Compose 3 | Local subprocess or a self-hosted HTTP service (container or Python) 4 | Local subprocess on the client machine 5 | Self-hosted gateway (binary or container) 7 |
| Data path | Client to nbox to NetBox; no third party 1 | Client to NetBox Cloud; the server is part of the NetBox instance, so no separate vendor hop 2 | Client to local or self-hosted server to NetBox; no third party 3 | Client to local or self-hosted server to NetBox; no third party 4 | Client to local server to NetBox; no third party 5 | Client to your gateway to NetBox; no third party 7 |
| Works with a firewalled self-hosted NetBox | Yes -- runs wherever you run it 1 | No -- NetBox Cloud only; NetBox Enterprise support is stated as planned for later this year 2 | Yes -- runs inside your network 3 | Yes -- explicitly stated to work against private NetBox instances 4 | Yes -- runs on the operator's machine 5 | Yes -- the gateway runs inside your network 7 |
| NetBox versions | Version-aware -- capability preflight via status, with features gated on NetBox 4.5+ and 4.6+ 1 | Not applicable -- the managed instance is the version 2 | Not documented 3 | Core types work broadly; plugin discovery requires NetBox 4.2+, with an endpoint fallback for NetBox < 4.4 4 | Not documented 5 | Targets NetBox v4.x; individual endpoints are annotated with the version that introduced them (4.1, 4.2, 4.3, 4.5+) 8 |
| Edition / hosting dependency | None -- any reachable NetBox 1 | NetBox Cloud subscription; capabilities are mapped to Free, Starter, Professional and Premium tiers 2 | None -- any reachable NetBox 3 | None -- any reachable NetBox 4 | None -- any reachable NetBox 5 | None -- any reachable NetBox; the instance URL is set in backends.yaml 8 |
| Tool allow/deny | Coarse -- writes are enabled or not, via --local-writes or --allow-writes plus an nbox:write caller scope 1 | Yes -- mode=discrete|code|both and read_only per connection, plus tier-enforced tool registration 2 | Not documented 3 | Not applicable -- four read tools, nothing to gate 4 | Not documented 5 | Yes -- per-tool, per-user policies over four access classes 14 |
| Read-only mode | Default -- writes require an explicit flag 1 | ?read_only=true per connection, or locked instance-wide on request to support 2 | Not documented -- use a read-only NetBox token 3 | Inherent -- no write tools exist 4 | Not documented -- use a read-only NetBox token 5 | Via authorization policy and/or a read-only NetBox token 14 |
| Audit trail in the connector | Not documented; writes accept an optional --message that lands in the NetBox changelog 1 | Every call is attributed to the human whose token authorized the agent; NetBox's own changelog applies 10 | Not documented -- NetBox's own changelog still applies 3 | Not documented -- NetBox's own changelog still applies 4 | Not documented; the README points at NetBox's built-in changelog 5 | Structured log per call, attributed to user and caller, on a fail-closed pipeline 7 |
| DLP / redaction of responses | Not documented 1 | Not documented 2 | Not documented 3 | Not documented 4 | Not documented 5 | Output Gate -- JS policies before and after execution, with redaction 15 |
| Distribution & pinning | crates.io, Homebrew tap, GHCR multi-arch image and release archives with SHA256SUMS 1 | Vendor-operated; no artifact to pin 2 | git clone; no published package or signed release 3 | Tagged releases plus multi-arch Docker Hub images signed with cosign (keyless, GitHub OIDC) and carrying SLSA build provenance 4 | git clone; no published package or signed release 5 | Tagged releases and container images; the NetBox description is a versioned YAML file in a public registry 8 |
| Dependency surface | One static Rust binary, no runtime; optional features can be compiled out 1 | Opaque -- vendor-operated 2 | Python plus its dependency tree 3 | Python plus fastmcp, httpx, pydantic and starlette 11 | Python 3.13+ plus FastMCP 5 | One static Go binary; adding NetBox introduces no further runtime dependency, only a YAML file 7 |
| Defence against prompt injection | Not documented 1 | No classifier documented; exposure is bounded by RBAC, read-only mode, branching and a sandboxed Code Mode instead 10 | Not documented 3 | Not documented 4 | Not documented 5 | No classifier ships; response text can be screened in an Output Gate post-policy, but none does so by default 15 |
| Transport | stdio, plus an optional loopback HTTP transport with OIDC 1 | MCP over streamable HTTP 2 | stdio (default) and HTTP 3 | stdio (default) and HTTP, endpoint /mcp on port 8000 4 | stdio -- the only transport documented 5 | Streamable HTTP; stdio when the gateway runs locally as a single-user subprocess 16 |
| Remote / multi-user capable | Yes over HTTP -- OIDC callers with a per-user vault for writes 1 | Yes -- each caller brings their own NetBox token and RBAC identity 2 | Reachable over HTTP, but all callers share the server's single NetBox token 3 | Reachable over HTTP with one shared bearer; all callers share the server's single NetBox token 4 | No -- one subprocess per client 5 | Yes -- multi-user with per-user authorization 14 |
| Catalog cost in context | 13 tools -- small; the README claims a ~9 ms cold start as one static binary 1 | Nearly 100 tools in discrete mode; Code Mode replaces them with three tools, for which the vendor claims 85% less context overhead 2 | Roughly 60 tools loaded up front 3 | 4 tools -- negligible, though the get_objects description embeds the full list of 127 object types 11 | 9 tools -- negligible 5 | 608 tools, but Code Mode replaces the catalog with two meta-tools, keeping the loaded context near-flat 17 |
| Discovery | Static tool list 1 | Dynamic model discovery at startup; Code Mode adds a schema-exploration tool and a discovery-refresh tool 2 | Static tool list 3 | Static tool list; optional plugin type discovery extends the type registry, not the tool list 4 | Static tool list 5 | Progressive, ranked tool discovery 17 |
| Response size control | --fields, -o plain|json|csv, and a ~30 s per-profile read cache 1 | Not documented at field level; Code Mode aggregates in the sandbox so raw responses need not enter context 2 | Inherited from the upstream read tools 3 | fields and brief parameters, limit default 5 and max 100, plus filter validation that rejects __in and multi-hop lookups 11 | Not documented 5 | Offset pagination with max 20 pages and a 500-item response cap declared in the DADL, plus ?brief and ?fields hints per tool 8 |
| Branching / review before merge | No -- writes land directly on the live instance 1 | Yes -- agents work in isolated branches, propose diffs and merge only through human review; change request workflows and NetBox Validation pre-change analysis are wired into the same connection (Professional+) 10 | No -- writes land directly on the live instance 3 | Not applicable -- read only 4 | No -- writes land directly on the live instance 5 | No -- NetBox Branching is a plugin served under /api/plugins/branching/, and those endpoints are explicitly out of scope for netbox.dadl, so branches cannot be driven through the gateway today 18 |
| Dry-run / confirmation before a write | Yes -- --dry-run, or --allow-writes plus an explicit --confirm; the MCP side splits this into plan_write and apply_write 1 | Branch diffs act as the review step; the docs additionally recommend enabling tool approval prompts in the MCP client 2 | Not documented 3 | Not applicable -- read only 4 | Not documented; the README warns to test in a development environment first and to use bulk operations carefully 5 | Human-in-the-loop is available as a gateway policy; 114 tools are classed dangerous and 39 admin, which a policy can gate on 8 |
| Bulk operations | Narrow -- ip reserve --count N posts one list body atomically; nothing broader 1 | Yes -- create, modify and delete objects individually or in bulk (Starter+) 2 | Not documented as a separate capability 3 | Not applicable -- read only 4 | Yes -- dedicated bulk create, update and delete tools 5 | No -- bulk PUT/PATCH/DELETE on collections is explicitly not covered; per-object operations in Code Mode are the stated alternative 8 |
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.A gateway reading a static description reaches none of these. If your use case depends on one of them, pick accordingly.
A gateway earns its keep when NetBox is not the only system in the picture:
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.
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. 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.
Yes — two, and they barely overlap. The open source NetBox MCP Server (Apache-2.0) is deliberately small: four read tools over 127 core object types, no writes, no GraphQL, and by adoption it is the reference implementation. The Platform MCP Server is a managed NetBox Cloud service in Public Preview since June 2026: nearly 100 tools (the vendor's figure) covering reads, writes, bulk operations, GraphQL, config rendering and scripts, with agent writes routed through isolated branches. Only the first has a public repository — a GitHub search surfaces it, not the managed service.
It depends on the option. The NetBox Labs OSS server is read-only by design — no write tools exist. nbox is read-only by default, with two opt-in write tools that are deliberately narrow and split into plan and apply. NetBox MCP Enhanced adds more than fifty named write tools plus three generic ones to the OSS server's four read tools. netbox-mcp-rw exposes generic create, update and delete including bulk variants. The Platform MCP Server writes from the Starter plan upward, individually or in bulk. ToolMesh + netbox.dadl declares write and delete tools across the API, each classed read, write, dangerous or admin so a policy can gate them.
Only the Platform MCP Server. It works in isolated branches, proposes diffs, and merges only through human review, with change request workflows and NetBox Validation pre-change analysis on the same connection. NetBox Branching is a plugin whose REST API lives under /api/plugins/branching/, and netbox.dadl explicitly excludes plugin endpoints — so branches cannot be driven through our gateway today. The remaining write-capable options write directly to the live instance; nbox's plan/apply step is a confirmation gate, not an isolated branch.
nbox reads the API token from a config.toml (0600 on Unix, redacted in config show) or an environment variable. NetBox MCP Enhanced and the NetBox Labs OSS server take it from the environment of the machine running the server; netbox-mcp-rw reads it from the LLM client's configuration or environment on the client machine. The Platform MCP Server takes a NetBox v2 token as a header on every connection, so the secret sits in each caller's client configuration and the agent acts under that token's RBAC permissions. ToolMesh keeps the token server-side in the gateway's credential store and injects it at call time, so it never appears in a client configuration.
Five of the six do, because you run them yourself inside your network. The exception is the Platform MCP Server: it is part of NetBox Cloud and works only there, with NetBox Enterprise support stated as planned for later this year.
Only through the two NetBox Labs servers. The Platform MCP Server discovers every object type the instance exposes at startup, plugins included. The OSS server has optional plugin discovery (ENABLE_PLUGIN_DISCOVERY, NetBox 4.2+, off by default), which extends its type registry. NetBox MCP Enhanced states plainly that plugin object types will not work, netbox-mcp-rw lists plugin support as an open roadmap item, and netbox.dadl excludes /api/plugins/ endpoints as out of scope for a general description.
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.
Found under the same search terms, but not comparable options under the inclusion criterion — each with the reason:
Disclosure. This page is published by Dunkel Cloud GmbH, 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. 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.