Ein MCP-Servereintrag ist ein kleines Stück JSON mit einem unnachgiebigen Fehlermodus: Ist ein Schlüssel falsch, gibt es keine Meldung — der Server erscheint schlicht nicht. Jeder Transport will eine andere Form: Ein lokaler braucht einen Befehl samt Argumenten, ein entfernter eine URL und meist einen Header, und beides zu mischen ergibt eine Datei, die vollständig aussieht und nichts tut. Dieser Builder fragt nur nach den Feldern des gewählten Transports, warnt, wenn ein Feld des anderen ausgefüllt ist, und markiert wohl den häufigsten Fehler der Praxis: ein echtes Zugangstoken in einer Datei, die im Repository landet. Er gibt sowohl die Konfigurationsdatei als auch den entsprechenden Einzeiler aus.
Funktionen
Nur die Felder, die der gewählte Transport nutzt
Warnt, wenn ein Feld des anderen Transports gefüllt ist
Markiert ein echt wirkendes Geheimnis in der Datei, nicht aber einen Platzhalter
Warnt bei unverschlüsseltem HTTP zu einem entfernten Host, schweigt bei localhost
Erkennt Argumente, die im Befehlsfeld stecken
Umgebungsvariablen und Header als bearbeitbare Paare
Gibt Projektdatei und Desktop-Konfiguration aus
Der entsprechende Befehl, korrekt gequotet
So verwendest du MCP-Server-Konfiguration
Benennen Sie den Server — so werden seine Werkzeuge eingeordnet
Wählen Sie den genutzten Transport
Füllen Sie Befehl und Argumente oder URL und Header aus
Kopieren Sie das JSON in Ihre Konfiguration oder führen Sie den Befehl aus
Beispiel
Eingabe
"command": "npx -y some-server"
Ausgabe
Warning: looked up as a single executable with that name
Das erste Wort ist der Befehl; alles Weitere ist ein Argument.
Häufige Fehler & Fehlerbehebung
Der Server erscheint nie. — Meist eine falsche Form: ein stdio-Eintrag mit url oder ein entfernter mit command. Beides wird hier markiert, denn keines erzeugt für sich einen Fehler.
Der Befehl wird nicht gefunden. — Argumente gehören getrennt. Setzen Sie npx in das Befehlsfeld und den Rest in die Argumentliste: Ein Befehl mit Leerzeichen wird als eine einzige ausführbare Datei gesucht.
Bei mir läuft es, bei anderen nicht. — Meist ein absoluter Pfad Ihrer Maschine in den Argumenten oder ein Zugangsdatum aus Ihrer Umgebung, das sonst niemand hat.
Ich habe ein Token in der Konfigurationsdatei. — Verweisen Sie auf eine Umgebungsvariable. Ein echt wirkendes Geheimnis wird hier markiert, denn Konfigurationsdateien werden versioniert.
Häufig gestellte Fragen
Welchen Transport soll ich nehmen?
stdio für alles Lokale — der Client startet es als Prozess und spricht über dessen Standardein- und -ausgabe. HTTP für einen entfernten Server. SSE existiert vor allem für Server, die vor HTTP geschrieben wurden.
Wo liegt die Konfigurationsdatei?
Eine Projektdatei liegt im Repository, damit das Team dieselben Server hat; die Desktop-App hat eine eigene Konfiguration für Server, die Sie überall wollen. Beide Formen werden ausgegeben und der Pfad angezeigt.
Wie halte ich ein Token aus der Datei?
Schreiben Sie einen Verweis auf eine Umgebungsvariable statt des Werts. Die Prüfung sieht, ob der Wert wie ein echtes Zugangsdatum oder wie ein Platzhalter aussieht, und beanstandet nur Ersteres.
Datei oder Befehl?
Beide tun dasselbe. Die Datei ist besser, wenn sie mit dem Projekt versioniert werden soll; der Befehl ist schneller zum Ausprobieren. Beide entstehen aus denselben Feldern.
Warum ist der Servername wichtig?
Er ist der Schlüssel des Eintrags und der Namensraum seiner Werkzeuge, also können zwei Server ihn nicht teilen, und Umbenennen ändert, wie seine Werkzeuge überall referenziert werden.
Verwandte Tools
MCP-Tool-Schema — Definieren Sie ein Tool und erhalten Sie das JSON Schema, Strict-Modus geprüft.
Tool-Schema-Prüfer — Fügen Sie eine Definition ein und sehen Sie, warum sie abgelehnt wird.
Hooks-Builder — Bauen Sie settings.json-Hooks und finden Sie Matcher, die nie auslösen.