vencord-mcp

코딩 에이전트가 플러그인 작성자처럼 실행 중인 Discord 클라이언트를 읽을 수 있게 해주는 MCP 서버입니다: 스토어, 웹팩 모듈, 패치, React props, 그리고 게이트웨이 트래픽 자체까지 읽을 수 있습니다.

--remote-debugging-port로 시작된 모든 Chromium과 통신하므로, Vencord나 Equicord가 주입된 Discord에서 작동하며, 대부분의 기능은 축소된 웹팩 번들이 있는 모든 Electron 앱에서도 작동합니다.

존재 이유

이미 별도로 존재하던 두 가지 기능이 있었지만, 각각 단독으로는 유용하지 않았습니다.

여러 범용 Electron 및 Chrome DevTools MCP 서버가 있습니다. 스크린샷을 찍고, 콘솔을 읽고, JavaScript를 평가하지만, 웹팩, Flux 스토어, Vencord 패치에 대해서는 아무것도 모르기 때문에, 이를 사용하는 에이전트는 매 세션마다 동일한 보일러플레이트를 다시 발견하는 데 예산을 소모합니다.

반면, Vencord Companion은 정확히 필요한 것을 알고 있습니다: 웹팩 find가 고유한지, 패치의 match가 컴파일되는지 등입니다. 하지만 이는 VSCode 확장 프로그램으로, 편집기에서 읽는 사람을 위해 만들어졌습니다.

이 둘을 연결하는 것은 없었습니다. 이것이 그 역할을 합니다.

Related MCP server: instagit

변경 사항

플러그인을 작성하는 일반적인 루프는 다음과 같습니다: devtools를 열고, 축소된 번들을 뒤지고, 정규식을 작성하고 기도하고, 컴파일하고, Discord를 재시작하고, 결과를 확인합니다. 각 실수는 재시작을 필요로 합니다.

이 도구들을 사용하면 루프가 몇 초 만에 종료되며, 더 중요한 것은 에이전트가 추측을 멈춘다는 점입니다. test_patch는 아무것도 빌드되기 전에 "이 패치가 실제로 실행될까?"라는 질문에 답합니다. capture_websocket는 인터페이스가 암시하는 대신 서버가 실제로 보낸 것을 보여줍니다. react_props는 UI가 숫자만 표시하는 실패의 이름을 복구합니다.

설치

npm install

MCP 클라이언트에 등록하세요. 대부분의 클라이언트는 다음과 같은 구성 블록을 사용합니다:

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

CLI를 제공하는 클라이언트는 일반적으로 mcp add vencord -- node /absolute/path/to/vencord-mcp/src/index.js와 같은 한 줄 명령어로 동일한 작업을 수행합니다.

그런 다음 디버거를 연 상태로 Discord를 시작하세요:

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

포트는 localhost에서만 수신하지만, 디버거이므로 접근 가능한 모든 것이 세션을 읽을 수 있습니다. 작업이 끝나면 Discord를 정상적으로 닫고 다시 여세요.

도구

달리 명시되지 않는 한 읽기 전용입니다.

모든 도구는 port(기본값 9223)와 둘 이상의 페이지 대상이 열려 있을 때 선택적 urlHint를 사용합니다.

설치할 가치가 있는 세 가지

**test_patch**는 Vencord가 시작 시 실행하는 것과 동일한 검사를 실제로 실행 중인 빌드에 대해 수행합니다. 모듈과 일치하지 않는 find는 패치가 조용히 실행되지 않음을 의미하고, 여러 개와 일치하는 find는 Vencord가 모두 패치함을 의미합니다. 둘 다 플러그인이 다른 것처럼 보이는 방식으로 오작동할 때까지 보이지 않습니다.

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

**patch_status**는 test_patch가 할 수 없는 질문에 답합니다: 실제로 실행되었는지 여부입니다. Vencord는 모듈이 로드되면 보류 목록에서 패치를 제거하므로, 여전히 나열된 것은 일치하지 않은 것입니다. 이것이 가장 많은 시간을 소모하는 실패입니다. 플러그인이 로드되고, 오류를 보고하지 않으며, 조용히 아무것도 하지 않기 때문입니다. all로 선언된 패치는 설계상 영구히 나열되며, 손상된 것으로 읽히지 않도록 별도로 보고됩니다.

**capture_websocket**는 Discord의 음성 opcode를 이름으로 디코딩합니다: IDENTIFY, READY, SESSION_DESCRIPTION, VIDEO, MEDIA_SINK_WANTS. 이를 읽는 것은 "비디오가 나타나지 않았다"와 "서버가 ssrc 267을 제공했고, 클라이언트가 최대 품질로 요청했지만 패킷이 도착하지 않았다"의 차이이며, 이는 다른 수정이 필요한 다른 버그입니다.

한 가지 주의사항: Network 도메인은 생성되는 것을 본 소켓만 기록합니다. 캡처가 시작될 때 이미 열려 있던 연결은 (socket opened before capture)로 보고됩니다. 프레임은 여전히 디코딩됩니다(내용이 프로토콜을 식별하기 때문), 하지만 URL은 알 수 없습니다. URL을 얻으려면 창 중에 클라이언트를 다시 연결하게 하세요.

참고 사항

Discord는 eval을 차단하는 엄격한 CSP를 제공합니다. 여기의 모든 평가는 allowUnsafeEvalBlockedByCSP를 설정하는데, 이는 디버거가 어쨌든 실행할 수 있는 문서화된 방법입니다. 이것이 없으면 모든 호출이 도움이 되지 않는 EvalError로 실패합니다.

각 도구 호출은 자체 디버거 세션을 열고 종료합니다. 호출 간에 하나를 열어두면 동기화가 깨질 상태만 생성됩니다.

테스트

node test/smoke.js

실제 프로토콜을 통해 stdio로 실제 서버와 통신합니다: 초기화, 도구 나열, 그런 다음 9223 포트에서 Discord가 실행 중이면 라이브 경로를 실행합니다. 시작하는 서버가 응답하는 서버와 같지는 않습니다.

라이선스

GPL-3.0-or-later, Vencord와 동일합니다.