# MCP Server für NetBox: die Optionen im Vergleich
> Alle auffindbaren MCP-Optionen für NetBox nebeneinander — nbox, NetBox Labs Platform MCP Server, NetBox MCP Enhanced, NetBox MCP Server, netbox-mcp-rw und ToolMesh + netbox.dadl. Abdeckung, Auth, Credential-Standort, Governance und Schreibsicherheit, jeweils mit Belegen.
Canonical: https://www.toolmesh.io/de/mcp/netbox/
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.
## Entscheidung auf einen Blick
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](#vergleichsmatrix) unten zusammen.
**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.
## Die Optionen
## Vergleichsmatrix
Zeilen sind die zehn Dimensionen, Spalten die Optionen. Die Tabelle scrollt horizontal. Hochgestellte Zahlen verlinken den [Beleg](#belege) 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](https://github.com/DunkelCloud/ToolMesh/issues) — wir korrigieren die Datendatei.
:::caution[Zwei Dinge, bevor Sie die Tabelle lesen]
**Nur unser eigener Eintrag ist durch einen Lauf gegen ein echtes NetBox gedeckt.** Die fünf anderen Zeilen sind eine Auswertung der jeweils eigenen Dokumentation und des Quellcodes mit Stand 15. August 2026 — siehe [Methodik](#methodik-und-offenlegung). Das netbox.dadl hinter unserer Zeile ist live-verifiziert und wurde am selben Tag zuletzt geprüft.
**Toolzahlen sind kein Maß für Funktionsumfang.** Die Projekte schneiden die API unterschiedlich granular in Tools, „608 gegen 4“ sagt für sich genommen also wenig. Vergleichbar ist die Endpunkt-Abdeckung — wie viel der NetBox-REST-API eine Option tatsächlich erreicht, gemessen am selben Nenner für alle. Unsere veröffentlichen wir (608 von rund 620 Endpunkten, 98%); die übrigen veröffentlichen ihre nicht, ihre Endpunkt-Abdeckung bleibt hier also unbeziffert. Die „nearly 100 tools“ des Platform MCP Servers sind die Angabe des Anbieters, die wir ohne NetBox-Cloud-Instanz nicht unabhängig nachzählen konnten.
:::
*Die Zellwerte stehen derzeit auf Englisch; die deutsche Fassung folgt nach dem Maintainer-Review, damit Korrekturen nur einmal einfließen.*
## Wann ein dedizierter NetBox-Server die bessere Wahl ist
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.
- **Dynamische Modell-Discovery.** Eine statische Beschreibung kann beim Start nicht bemerken, welche Plugins eine Instanz installiert hat. Der Platform MCP Server entdeckt jeden Objekttyp, den die Instanz exponiert; der OSS-Server kann Plugin-Objekttypen auf NetBox 4.2+ optional entdecken.
- **GraphQL.** netbox.dadl deckt nur die REST-API ab. Der Platform MCP Server bietet GraphQL-Abfragen ab dem Starter-Tier.
- **Bulk-Operationen auf Collections.** Bulk-PUT/PATCH/DELETE auf Collections ist in netbox.dadl ausdrücklich nicht abgedeckt — Einzelobjekt-Aufrufe im Code Mode sind die benannte Alternative. Der Platform MCP Server und netbox-mcp-rw bringen beide dedizierte Bulk-Tools mit.
Ein Gateway, das eine statische Beschreibung liest, erreicht nichts davon. Wer einen dieser Fälle braucht, wählt entsprechend.
## Wann ein Gateway die bessere Wahl ist
Ein Gateway rechnet sich, wenn NetBox nicht das einzige System im Bild ist:
- **Fragen über Systemgrenzen hinweg.** „Welche Hosts sind in Checkmk kritisch, und wem gehören sie laut NetBox?“ ist ein Agenten-Zug gegen einen Endpunkt statt zweier Connectoren, die einander nicht sehen. Die öffentliche [DADL-Registry](https://www.dadl.ai) führt Stand August 2026 30 APIs mit über 4.000 Tools — das zweite System ist also oft schon beschrieben.
- **Ein Ort für Credentials.** Das NetBox-Token liegt serverseitig und wird zur Aufrufzeit injiziert, statt in der Client-Konfiguration jedes Operators zu stehen.
- **Ein Autorisierungsmodell und ein Audit-Trail** über alle angebundenen Systeme statt Konventionen je Connector.
- **Kontext-Ökonomie im Großen.** 608 NetBox-Tools sind viel Schema für ein Modell; ein Katalog, der flach bleibt, zählt umso mehr, je mehr Systeme dazukommen. Das ist allerdings nicht unser Alleinstellungsmerkmal — der Code Mode des Platform MCP Servers löst dasselbe Problem für NetBox Cloud.
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.
## Coverage-Report
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](https://www.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.
## Häufige Fragen
{faqs.map(({ q, a }) => (
<>
{q}
{a}
))}
---
*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.*
## Benachbarte Projekte, die hier nicht als Option gelistet sind
Unter denselben Suchbegriffen gefunden, aber nach dem [Aufnahmekriterium](#methodik-und-offenlegung) keine vergleichbaren Optionen — jeweils mit Begründung:
## Methodik und Offenlegung
**Offenlegung.** Diese Seite wird von der [Dunkel Cloud GmbH](https://www.dunkel.cloud) 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](https://github.com/DunkelCloud/ToolMesh/issues). 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.
## Changelog
## Belege