Es gibt zwei MCP-Server für NetBox von NetBox Labs selbst, dazu vier weitere von außerhalb des Unternehmens — und sie unterscheiden sich weit stärker, als der gemeinsame Name vermuten lässt. Der quelloffene ist rein lesend mit vier Tools; der gemanagte ist ein NetBox-Cloud-Dienst mit knapp hundert, und er ist die einzige Option, die Agenten-Writes durch einen Branch führt, den ein Mensch mergen muss. Diese Seite listet, was es mit Stand 15. August 2026 gibt, was jede Option abdeckt, wo die Credentials liegen und was passiert, wenn ein Agent schreibt.
Diese Seite stellt alle sechs MCP-Optionen, die wir finden konnten, über zehn Dimensionen nebeneinander. Wir stellen eine davon selbst her — deshalb sind die Regeln unten wichtig: keine Scores, keine Sterne, kein Ranking. Jede Zelle nennt eine Tatsache und verlinkt den Beleg.
Die eigentliche Wahl ist nicht die Toolzahl, sondern der Zuschnitt des Zugangs: ein kleiner NetBox-spezifischer Agenten-Connector, NetBox Clouds integrierter agentischer Change-Workflow — oder eine Governance-Schicht über NetBox und weitere Systeme. Mit Stand 15. August 2026 sieht das Feld so aus — sechs MCP-Optionen, dazu sieben benachbarte Projekte, die unter denselben Suchbegriffen auftauchen, aber keine vergleichbaren Optionen sind. Jede Aussage in der Tabelle fasst belegte Zellen der Vergleichsmatrix unten zusammen.
| Option | Geeignet, wenn | Schreiben | Wichtigste Grenze | Prüfstatus |
|---|---|---|---|---|
| nbox | Lesen zuerst; Schreiben nur hinter einem expliziten Plan/Apply-Schritt, mit Aufrufer-Identität (OIDC) auf dem Schreibpfad | Opt-in und eng: Status, Beschreibung, Tags, IP-/Prefix-/Range-Reservierung | Bewusst schmale Schreibfläche; Selbstauskunft pre-1.0 | Doku-Review |
| NetBox Labs Platform MCP Server | Auf NetBox Cloud, mit kontrollierten Agenten-Writes und Branch-Review | Ja, ab Starter; einzeln oder in Bulk, über isolierte Branches, die ein Mensch merged | Nur NetBox Cloud — heute keine self-hosted oder abgeschotteten Instanzen | Doku-Review |
| NetBox MCP Enhanced | Schreiben gegen ein self-hosted NetBox, mit benannten Tools je Objektfamilie | Ja — über fünfzig benannte Schreib-Tools plus drei generische, direkt auf die Live-Instanz | Keine Lizenz angegeben; keine Aufrufer-Authentifizierung für den HTTP-Transport dokumentiert | Doku-Review |
| NetBox MCP Server | Experimentieren, oder rein lesender Zugriff mit kleinstmöglicher Fläche | Nein — konstruktionsbedingt nur lesend | Kein Schreiben, kein GraphQL; der HTTP-Transport ist ohne MCP_AUTH_TOKEN unauthentifiziert | Doku-Review |
| netbox-mcp-rw | Generisches CRUD inklusive Bulk, als lokaler Subprozess eines Clients | Ja — neun generische Tools inklusive Bulk, direkt auf die Live-Instanz | Ein Subprozess je Client; seit September 2025 unverändert, Validierung und Tests laut Roadmap offen | Doku-Review |
| ToolMesh + netbox.dadl unser Projekt | Self-hosted NetBox neben weiteren Systemen, hinter einer gemeinsamen Governance-Schicht | Ja — jedes Tool trägt eine Zugriffsklasse (read/write/dangerous/admin), auf die Policies gaten können | Ein stehender Dienst, den man betreibt; kein /api/plugins/ (NetBox Branching), kein GraphQL, keine Bulk-Writes | Live geprüft |
Was sie trennt. Die Abdeckung reicht von 4 Tools bis 608. Nur die beiden NetBox-Labs-Server entdecken Plugin-Objekttypen zur Laufzeit. Nur drei der sechs geben Aufrufern eine eigene Identität — die übrigen arbeiten über ein einzelnes NetBox-Token, und der HTTP-Transport des OSS-Servers ist unauthentifiziert, solange MCP_AUTH_TOKEN nicht gesetzt ist, was sein README offen sagt. Bei der Schreibsicherheit ist die Spreizung am größten: Drei Optionen schreiben direkt auf die laufende Instanz, nbox teilt Writes in Plan und Apply, und nur der Platform-Server isoliert sie in einem Branch mit einem Diff, das ein Mensch freigibt.
Ein Rust-Binary, das zugleich Terminal-UI, CLI und MCP-Server ist. Die MCP-Seite ist read-first: elf Lese-Tools plus jedes Objekt als nbox://-Ressource, dazu zwei opt-in-Schreib-Tools hinter einem Plan/Apply-Schritt. Die einzige Community-Option mit OIDC und Per-User-Vault auf dem HTTP-Schreibpfad. Selbstauskunft: pre-1.0.
Der gehostete First-Party-Server, seit Juni 2026 in Public Preview auf NetBox Cloud. Knapp 100 Tools für Lesen, Schreiben, Bulk-Operationen, IPAM-Vergabe, Cable Tracing, GraphQL, Config-Rendering und Scripts, dazu weitere NetBox-Labs-Produkte. Die einzige Option hier, die Agenten-Writes über isolierte Branches führt, die ein Mensch prüft und merged, und die einzige mit dynamischer Modell-Discovery samt installierter Plugins. Keine Installation; nur NetBox Cloud.
Eine schreibfähige Ableitung des NetBox-Labs-OSS-Servers: dessen vier Lese-Tools plus über fünfzig benannte Schreib-Tools für Sites, Tenants, Tags, VLANs, IPAM, DCIM, Circuits und Virtualisierung, dazu drei generische create/update/delete-Tools. Bringt einen Docker-Compose-Weg und HTTP-Transport für Web-Clients mit. Das README sagt ausdrücklich, dass Plugin-Objekttypen nicht unterstützt werden. Es ist keine Lizenz angegeben.
Der quelloffene First-Party-Server und nach Verbreitung die Referenzimplementierung: 213 Sterne, 94 Forks, letzter Push am Tag vor dieser Erhebung. Bewusst klein -- vier Lese-Tools über 127 Kern-Objekttypen, kein Schreiben, kein GraphQL -- und das Projekt erklärt diese Kleinheit zum Zweck, mit dem Fork unter Apache 2.0 als vorgesehenem Weg. Die einzige Option hier mit signiertem Container-Image samt Provenance.
Neun generische Tools -- get, get-by-id, create, update, delete, die drei Bulk-Varianten und Changelogs -- die gegen jeden NetBox-Objekttyp arbeiten statt ein Tool je Typ. Die meistgesternte Community-Option mit Schreibzugriff. Das README nennt sie „production ready", während die Roadmap Eingabevalidierung, Tests und Async-Support noch als offen führt. Angelegt und zuletzt gepusht am selben Tag im September 2025.
Kein NetBox-spezifischer Server, sondern ein selbst gehostetes Gateway, das eine deklarative YAML-Beschreibung der NetBox-REST-API liest -- 608 Tools, 98% der API-Fläche, die breiteste Abdeckung in dieser Liste. Governance (Autorisierung je Tool und Nutzer, serverseitige Credentials, Output-Policies, Audit) kommt vom Gateway, nicht vom Connector. Aus der statischen Beschreibung folgen zwei Lücken: keine dynamische Plugin-Discovery und kein Zugriff auf /api/plugins/-Endpunkte, womit NetBox Branching nicht ansteuerbar ist.
Unser Projekt — siehe Offenlegung unten
Zeilen sind die zehn Dimensionen, Spalten die Optionen. Die Tabelle scrollt horizontal. Hochgestellte Zahlen verlinken den Beleg zur jeweiligen Zelle.
„Nicht dokumentiert“ heißt: Die von uns geprüften Quellen sagen dazu nichts — nicht, dass die Funktion fehlt. Wer eines dieser Projekte pflegt und einen Fehler findet, eröffnet ein Issue — wir korrigieren die Datendatei.
Die Zellwerte stehen derzeit auf Englisch; die deutsche Fassung folgt nach dem Maintainer-Review, damit Korrekturen nur einmal einfließen.
| Dimension | nbox | NetBox Labs Platform MCP Server | NetBox MCP Enhanced | NetBox MCP Server | netbox-mcp-rw | ToolMesh + netbox.dadl unser Projekt |
|---|---|---|---|---|---|---|
| Maintainer-Typ | 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 |
| Lizenz | 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 & Installation | 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 |
| Letzte Code-Aktivität | 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 |
| Öffentliches Adoptionssignal | 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 |
| Reifegrad (Selbstauskunft) | "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 / Aktionen | 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 |
| Lesen / Schreiben / Löschen | 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 |
| Abdeckung der Kernobjekte | 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-Objekttypen | 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-Vergabe (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 |
| Verfahren gegenüber 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 |
| Wo das Secret liegt | 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 |
| Wer den Server aufrufen darf | 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 |
| Betriebsmodus | 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 |
| Datenpfad | 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 |
| Funktioniert mit abgeschottetem 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-Versionen | 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 |
| Editions-/Hosting-Abhängigkeit | 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-Modus | 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 im 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 von Antworten | 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-Fläche | 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 |
| Abwehr von 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-/mehrbenutzerfähig | 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 |
| Katalogkosten im Kontext | 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 |
| Steuerung der Antwortgröße | --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 vor dem 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 / Bestätigung vor dem Schreiben | 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-Operationen | 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 |
Ein Gateway, das eine statische Beschreibung der NetBox-REST-API liest, erreicht genau das, was diese Beschreibung deklariert — nicht weniger, strukturell aber auch nicht mehr. Vier Dinge liegen außerhalb unserer, und dort gewinnt ein eigens gebauter Server:
/api/plugins/-Endpunkte — dort liegt NetBox Branching tatsächlich. Die Branching-REST-API sitzt unter /api/plugins/branching/, und netbox.dadl schließt Plugin-Endpunkte ausdrücklich aus; Branch-basiertes Review von Agenten-Writes lässt sich über das Gateway heute also nicht fahren. Der Platform MCP Server hat Branching nativ verdrahtet.Ein Gateway, das eine statische Beschreibung liest, erreicht nichts davon. Wer einen dieser Fälle braucht, wählt entsprechend.
Ein Gateway rechnet sich, wenn NetBox nicht das einzige System im Bild ist:
Der ehrliche Trade-off: Ein Gateway ist ein stehender Dienst, den man betreiben, überwachen und verfügbar halten muss. Die schlankste Form der dedizierten Server ist ein Subprozess, den der LLM-Client startet — da ist gar nichts zu betreiben. Wer stattdessen einen von ihnen zentral über HTTP betreibt, betreibt ebenfalls eine Komponente; die Zahl gleicht sich an, und der Unterschied verschiebt sich auf das, was die Matrix oben zeigt: ein Dienst vor einem System mit einem geteilten NetBox-Token gegen ein Multi-User-Gateway vor mehreren. So oder so zahlt sich ein Gateway erst aus, wenn mehr als ein System dahinter hängt. Wer nur NetBox anbinden wird und lesende Zugriffe braucht, fährt mit dem quelloffenen First-Party-Server schlanker. Den gibt es, es sind vier Tools, und er kann über MCP kein einziges NetBox-Objekt verändern.
Der maschinenlesbare Coverage-Report für unsere Option — jedes Tool, seine Zugriffsklasse und welche Teile der NetBox-REST-API abgedeckt sind und welche nicht — steht unter dadl.ai/d/netbox. Er weist 608 Tools über 608 von rund 620 REST-Endpunkten aus (98%), jedes Tool in einer von vier Zugriffsklassen (248 read, 207 write, 114 dangerous, 39 admin), mit ausdrücklich benannten Lücken: Plugin-Endpunkte, GraphQL und Bulk-Writes auf Collections.
Ja — zwei, und sie überschneiden sich kaum. Der quelloffene NetBox MCP Server (Apache-2.0) ist bewusst klein: vier Lese-Tools über 127 Kern-Objekttypen, kein Schreiben, kein GraphQL, und nach Verbreitung die Referenzimplementierung. Der Platform MCP Server ist ein gemanagter NetBox-Cloud-Dienst in Public Preview seit Juni 2026: knapp 100 Tools (Angabe des Anbieters) für Lesen, Schreiben, Bulk-Operationen, GraphQL, Config-Rendering und Scripts, mit Agenten-Writes über isolierte Branches. Nur der erste hat ein öffentliches Repository — eine GitHub-Suche findet ihn, nicht den gemanagten Dienst.
Das hängt von der Option ab. Der OSS-Server von NetBox Labs ist bewusst nur lesend — es existieren keine Schreib-Tools. nbox ist standardmäßig nur lesend, mit zwei opt-in-Schreib-Tools, die bewusst eng sind und in Plan und Apply geteilt. NetBox MCP Enhanced ergänzt die vier Lese-Tools des OSS-Servers um über fünfzig benannte Schreib-Tools plus drei generische. netbox-mcp-rw bietet generisches Create, Update und Delete einschließlich Bulk-Varianten. Der Platform MCP Server schreibt ab dem Starter-Plan, einzeln oder in Bulk. ToolMesh + netbox.dadl deklariert Schreib- und Lösch-Tools über die API, jedes in der Klasse read, write, dangerous oder admin, sodass eine Policy sie gezielt freigeben oder sperren kann.
Nur der Platform MCP Server. Er arbeitet in isolierten Branches, schlägt Diffs vor und merged nur nach menschlichem Review, mit Change-Request-Workflows und Pre-Change-Analyse durch NetBox Validation auf derselben Verbindung. NetBox Branching ist ein Plugin, dessen REST-API unter /api/plugins/branching/ liegt, und netbox.dadl schließt Plugin-Endpunkte ausdrücklich aus — Branches lassen sich über unser Gateway heute also nicht ansteuern. Die übrigen schreibfähigen Optionen schreiben direkt auf die laufende Instanz; der Plan/Apply-Schritt von nbox ist eine Bestätigungsstufe, kein isolierter Branch.
nbox liest das API-Token aus einer config.toml (0600 unter Unix, in config show geschwärzt) oder einer Umgebungsvariable. NetBox MCP Enhanced und der OSS-Server von NetBox Labs nehmen es aus der Umgebung des Rechners, auf dem der Server läuft; netbox-mcp-rw liest es aus der Konfiguration des LLM-Clients oder der Umgebung auf der Client-Maschine. Der Platform MCP Server nimmt ein NetBox-v2-Token als Header auf jeder Verbindung — das Secret steht also in der Client-Konfiguration jedes Aufrufers, und der Agent agiert unter den RBAC-Rechten dieses Tokens. ToolMesh hält das Token serverseitig im Credential-Store des Gateways und injiziert es zur Aufrufzeit, sodass es nie in einer Client-Konfiguration auftaucht.
Fünf der sechs ja, weil man sie selbst im eigenen Netz betreibt. Die Ausnahme ist der Platform MCP Server: Er ist Teil von NetBox Cloud und funktioniert nur dort; Unterstützung für NetBox Enterprise ist laut Anbieter für später in diesem Jahr geplant.
Nur über die beiden NetBox-Labs-Server. Der Platform MCP Server entdeckt beim Start jeden Objekttyp, den die Instanz exponiert, Plugins eingeschlossen. Der OSS-Server hat optionale Plugin-Discovery (ENABLE_PLUGIN_DISCOVERY, NetBox 4.2+, standardmäßig aus), die sein Typ-Register erweitert. NetBox MCP Enhanced sagt klar, dass Plugin-Objekttypen nicht funktionieren, netbox-mcp-rw führt Plugin-Unterstützung als offenen Roadmap-Punkt, und netbox.dadl schließt /api/plugins/-Endpunkte als außerhalb des Umfangs einer generellen Beschreibung aus.
Ab hier Referenzteil — die benachbarten Projekte, Methodik und Offenlegung, Changelog und Belege. Für die Entscheidung oben braucht es nichts davon; hier steht die Evidenz.
Unter denselben Suchbegriffen gefunden, aber nach dem Aufnahmekriterium keine vergleichbaren Optionen — jeweils mit Begründung:
Offenlegung. Diese Seite wird von der Dunkel Cloud GmbH herausgegeben, die ToolMesh herstellt — eine der sechs gelisteten Optionen. Wir haben ein offensichtliches Interesse daran, wie das aussieht. Die Gegenmaßnahmen sind strukturell: Die Optionen stehen alphabetisch nach Anzeigename, unser eigener Eintrag eingeschlossen; jede Zelle trägt einen Beleg-Link; keine Zelle enthält Score oder Ranking; und die beiden „Wann…“-Abschnitte oben benennen die Fälle, in denen unsere Option das falsche Werkzeug ist.
Aufnahmekriterium. Eine GitHub-Suche nach „netbox mcp“, „netbox mcp server“ und „netbox model context protocol“ ergab am 15. August 2026 46 Repositories; der gemanagte Platform MCP Server hat kein öffentliches Repository und kam über die begleitende Anbieterrecherche hinzu. Gelistet wird eine Option, wenn alle drei Punkte zutreffen: eine öffentlich erreichbare Quelle oder Produktseite; als benutzbarer Server präsentiert statt als Demo, Kursartefakt oder persönlicher Fork ohne eigene Substanz; und Dokumentation, die mindestens die Steckbrief-Dimension füllt. Sechs Optionen erfüllten alle drei Punkte — fünf öffentliche Repositories plus der gemanagte Platform MCP Server. Sieben Projekte sind als benachbart dokumentiert, der Rest sind Forks, Kursartefakte und Ein-Tages-Experimente ohne README oder Lizenz.
Wie die Fakten erhoben wurden. Aus dem jeweils eigenen Repository, README, der Dokumentation und — wo zitiert — dem Quellcode, gelesen am 15. August 2026. Repository-Metadaten — Lizenz, letzter Commit, Sterne und Forks — stammen vom selben Tag aus der GitHub-API. Wo ein Projekt etwas nicht angibt, steht „nicht dokumentiert“ statt einer Vermutung. Bei gehosteten Produkten heißt das: die Plattform-Dokumentation, nicht nur eine Produktseite — die Fähigkeiten des Platform MCP Servers sind über die NetBox-Cloud-Dokumentation und den Launch-Post des Anbieters dokumentiert, beide sind als Beleg angegeben. Registry-Aggregatoren dienten nur dem Auffinden von Kandidaten, nie als Beleg.
Prüftiefe. Die fünf Optionen, die wir nicht selbst pflegen, sind Doku- und Quellcode-Review, nicht Testergebnis — gelesen, nicht gestartet. Die Prüfstatus-Spalte der Entscheidungs-Tabelle weist das je Option aus, und Anbieterangaben, die wir nicht selbst nachzählen können, werden als solche zitiert. Unser eigener Eintrag ist die Ausnahme: Das netbox.dadl dahinter ist live-verifiziert, seine Zeile wurde am 15. August 2026 zuletzt geprüft. Die Maintainer aller gelisteten Projekte wurden mit der Veröffentlichung dieser Seite benachrichtigt; wenn ein Doku-Review etwas falsch wiedergibt, landen ihre Korrekturen in der Datendatei.
Korrekturen und Ergänzungen. Die Matrix lebt als eine YAML-Datei im Repository dieser Website; das Website-Repository selbst ist privat, Korrekturen laufen deshalb als Issue im öffentlichen ToolMesh-Repository. Eine Tatsache korrigieren oder eine übersehene Option ergänzen: ein Issue genügt. An die Maintainer: Wenn wir euer Projekt falsch dargestellt haben, ist das ein Bug, und wir beheben ihn.