vencord-mcp

Ein MCP-Server, der es einem Coding-Agenten ermöglicht, einen laufenden Discord-Client so zu lesen, wie ein Plugin-Autor ihn liest: Stores, Webpack-Module, Patches, React-Props und den Gateway-Datenverkehr selbst.

Er kommuniziert mit jedem Chromium, das mit --remote-debugging-port gestartet wurde, funktioniert also mit Discord, in das Vencord oder Equicord injiziert wurde, und das meiste funktioniert mit jeder Electron-App mit einem minimierten Webpack-Bundle.

Warum es das gibt

Zwei Hälften davon existierten bereits getrennt, und keine war für sich allein nützlich.

Es gibt mehrere generische Electron- und Chrome-DevTools-MCP-Server. Sie machen Screenshots, lesen die Konsole und führen JavaScript aus, kennen aber nichts von Webpack, Flux-Stores oder Vencord-Patches, sodass ein Agent, der sie verwendet, sein Budget damit verschwendet, jedes Mal dieselben Boilerplates neu zu entdecken.

Auf der anderen Seite weiß Vencord Companion genau die richtigen Dinge: ob ein Webpack-Find eindeutig ist, ob ein Match eines Patches kompiliert. Aber es ist eine VSCode-Erweiterung, die für einen Menschen gebaut wurde, der sie in einem Editor liest.

Nichts verband die beiden. Dies tut es.

Related MCP server: instagit

Was es ändert

Die normale Schleife zum Schreiben eines Plugins ist: Devtools öffnen, durch ein minimiertes Bundle jagen, einen Regex schreiben und hoffen, kompilieren, Discord neu starten, herausfinden. Jeder Fehler kostet einen Neustart.

Mit diesen Werkzeugen schließt sich die Schleife in Sekunden, und was noch wichtiger ist: Der Agent hört auf zu raten. test_patch beantwortet "Würde dieser Patch tatsächlich ausgeführt werden?" bevor etwas gebaut wird. capture_websocket zeigt, was der Server wirklich gesendet hat, statt was die Schnittstelle implizierte. react_props findet den Namen eines Fehlers, dessen UI nur eine Zahl anzeigt.

Installieren

npm install

Registrieren Sie es bei Ihrem MCP-Client. Die meisten akzeptieren einen Konfigurationsblock wie diesen:

{
  "mcpServers": {
    "vencord": {
      "command": "node",
      "args": ["/absolute/path/to/vencord-mcp/src/index.js"]
    }
  }
}

Clients, die eine CLI mitbringen, haben normalerweise einen Einzeiler für dasselbe, etwa mcp add vencord -- node /absolute/path/to/vencord-mcp/src/index.js.

Starten Sie dann Discord mit geöffnetem Debugger:

Discord.exe --remote-debugging-port=9223

Der Port hört nur auf localhost, aber es ist ein Debugger: Alles, was ihn erreichen kann, kann Ihre Sitzung lesen. Schließen und öffnen Sie Discord normal, wenn Sie fertig sind.

Werkzeuge

Nur lesend, sofern nicht anders gekennzeichnet.

Jedes Werkzeug akzeptiert port (Standard 9223) und ein optionales urlHint für den Fall, dass mehr als ein Seitenziel geöffnet ist.

Die drei, die die Installation lohnen

test_patch führt dieselbe Prüfung aus, die Vencord beim Start ausführt, gegen den tatsächlich laufenden Build. Ein Find, der kein Modul trifft, bedeutet, dass der Patch stillschweigend nie ausgeführt wird, und ein Find, der mehrere trifft, bedeutet, dass Vencord sie alle patcht. Beides ist unsichtbar, bis sich das Plugin auf eine Weise falsch verhält, die wie etwas anderes aussieht.

test_patch(find: '"2026-08-video-guard"', match: 'variations:\\{.{0,120}?\\}\\}', replace: 'variations:{}')
-> "find is unique and match hits exactly once"

patch_status beantwortet die Frage, die test_patch nicht beantworten kann: Wurde es tatsächlich ausgeführt? Vencord entfernt einen Patch aus seiner Liste der ausstehenden Patches, sobald sein Modul geladen wird. Alles, was noch gelistet ist, hat also nie getroffen. Das ist der Fehler, der die meiste Zeit kostet, weil das Plugin lädt, keinen Fehler meldet und leise nichts tut. Patches, die als all deklariert sind, bleiben aus Designgründen für immer gelistet und werden separat gemeldet, damit sie nicht als defekt gelesen werden.

capture_websocket dekodiert Discords Sprach-Opcodes namentlich: IDENTIFY, READY, SESSION_DESCRIPTION, VIDEO, MEDIA_SINK_WANTS. Sie zu lesen ist der Unterschied zwischen "Das Video ist nicht erschienen" und "Der Server hat ssrc 267 angeboten, der Client hat es in voller Qualität angefordert, und es folgten keine Pakete", was unterschiedliche Fehler mit unterschiedlichen Korrekturen sind.

Ein Hinweis: Die Network-Domain zeichnet nur Sockets auf, deren Erstellung sie gesehen hat. Eine Verbindung, die bereits offen war, als die Aufnahme begann, wird als (socket opened before capture) gemeldet – die Frames werden trotzdem dekodiert, weil ihr Inhalt das Protokoll identifiziert, aber die URL ist unbekannt. Lassen Sie den Client während des Fensters neu verbinden, um sie zu erhalten.

Hinweise

Discord liefert eine strenge CSP aus, die eval blockiert. Jede Auswertung hier setzt allowUnsafeEvalBlockedByCSP, was der dokumentierte Weg ist, damit ein Debugger trotzdem läuft; ohne dies schlägt jeder Aufruf mit einem nicht hilfreichen EvalError fehl.

Jeder Werkzeugaufruf öffnet eine eigene Debugger-Sitzung und beendet sie. Eine zwischen den Aufrufen offen zu halten, würde nur Zustand schaffen, der aus dem Takt geraten kann.

Tests

node test/smoke.js

Es spricht das echte Protokoll mit dem echten Server über stdio: initialisieren, die Werkzeuge auflisten, dann den Live-Pfad gegen einen Discord auf Port 9223 ausführen, falls einer läuft. Ein Server, der startet, ist nicht dasselbe wie ein Server, der antwortet.

Lizenz

GPL-3.0-or-later, entsprechend Vencord.