plane-mcp-server

Ein MCP-Server (Model Context Protocol) für selbst gehostetes Plane (Community Edition). Er stellt Claude 56 Tools für Projekte, Arbeitsaufgaben, Stati, Labels, Zyklen, Module, Kommentare, Aktivitätsverlauf, Links, Mitglieder und Intake-Triage bereit – genug, um aus einer lokalen Chat-Sitzung heraus als Projektmanager für alle Projekte in Ihrem Plane-Workspace zu fungieren.

Erstellt auf Basis der öffentlichen Plane-REST-API (/api/v1), dokumentiert unter developers.plane.so. Die Community Edition umfasst Projekte, Arbeitsaufgaben, Zyklen, Module, Intake und Stati/Labels – dieser Server beschränkt sich auf diesen Funktionsumfang. Epics, Initiativen, Teamspaces und Kunden sind reine Plane-Commercial/Cloud-Funktionen und wurden bewusst nicht aufgenommen.

Einrichtung

1. Plane-API-Schlüssel generieren

In Ihrer Plane-Instanz: Profileinstellungen → Persönliche Zugriffstoken → Persönliches Zugriffstoken hinzufügen.

2. Abhängigkeiten installieren und erstellen

cd plane-mcp-server
npm install
npm run build

3. Umgebungsvariablen konfigurieren

Kopieren Sie .env.example zu .env als Referenz, aber beachten Sie: MCP-Clients (Claude Desktop, Claude Code) übergeben Umgebungsvariablen direkt in ihrer Konfiguration, nicht über eine von diesem Prozess geladene .env-Datei.

4. Zum MCP-Client hinzufügen

Claude Code (claude mcp add oder .mcp.json bearbeiten):

{
  "mcpServers": {
    "plane": {
      "command": "node",
      "args": ["/absolute/path/to/plane-mcp-server/dist/index.js"],
      "env": {
        "PLANE_BASE_URL": "https://plane.mycompany.com",
        "PLANE_API_KEY": "plane_api_xxxxxxxxxxxxxxxxxxxx",
        "PLANE_WORKSPACE_SLUG": "acme"
      }
    }
  }
}

Claude Desktop (claude_desktop_config.json): derselbe mcpServers-Block wie oben.

Starten Sie den Client nach dem Bearbeiten der Konfiguration neu. Sie sollten sehen, dass sich der plane-Server mit 56 verfügbaren Tools verbindet.

Related MCP server: plane-selfhost-mcp

Was er kann

• Projekte – auflisten/abrufen/erstellen/aktualisieren/archivieren/löschen, wobei alle Projekte in einem Workspace gleichzeitig verwaltet werden.

• Arbeitsaufgaben (Issues) – vollständiges CRUD, Nachschlagen per UUID oder menschenlesbarer Kennung (ENG-123), Volltextsuche und erweiterte strukturierte Filtersuche (nach Status, Priorität, Bearbeiter, Labels).

• Stati & Labels – Workflow-Spalten und Tags jedes Projekts einsehen und verwalten.

• Zyklen (Sprints) – erstellen/aktualisieren/löschen, Arbeitsaufgaben zuweisen oder entfernen, Fortschrittszahlen für die Statusberichterstattung lesen.

• Module – gleicher Lebenszyklus wie Zyklen, für längerfristige Feature-Gruppierungen.

• Kommentare & Aktivität – Diskussionsfäden lesen/schreiben, das Auditprotokoll der Feldänderungen an einer Arbeitsaufgabe lesen.

• Links – PRs/Dokumente/Designs an eine Arbeitsaufgabe anhängen.

• Mitglieder – Namen/E-Mails von Personen in UUIDs auflösen, Projekte mit Personal besetzen, Rollen ändern.

• Intake – eingehende Anfragen triagieren (akzeptieren/ablehnen/auf später verschieben/duplizieren), bevor sie ins Backlog gelangen.

Jedes Listen-/Abruf-Tool akzeptiert response_format: "markdown" | "json" (standardmäßig Markdown, für die Lesbarkeit; json für die weitere programmatische Verwendung), und jedes Tool, das einen Workspace benötigt, verwendet standardmäßig PLANE_WORKSPACE_SLUG, falls konfiguriert, sodass die meisten Aufrufe nur eine project_id benötigen.

Nicht implementiert

Bewusst ausgelassen, um den Funktionsumfang fokussiert und CE-only zu halten: Datei-/Anhangs-Uploads, Seiten, Schätzungen, Zeiterfassung (Arbeitsprotokolle), benutzerdefinierte Arbeitsaufgabentypen/-eigenschaften und die rein kommerziellen Epics/Initiativen/Teamspaces/Kunden/IDP-Sync-APIs. Diese können später nach demselben Muster in src/tools/ hinzugefügt werden.

Eine typische Multi-Projekt-PM-Sitzung

1. plane_list_projects – alles im Workspace anzeigen.

2. plane_advanced_search_work_items im aktiven Projekt mit einem Prioritäts-/Statusfilter – herausfinden, was dringend ist. Es ist projektspezifisch, also einmal pro Projekt aufrufen, um den gesamten Workspace abzudecken.

3. plane_list_cycles im aktiven Projekt, dann plane_list_cycle_work_items – aktuellen Sprintstatus prüfen.

4. plane_update_work_item – Elemente zwischen Stati verschieben, neu zuweisen, neu priorisieren.

5. plane_add_work_item_comment – Statusnotizen hinterlassen.

6. plane_list_intake_issues + plane_update_intake_issue – die Triage-Warteschlange leeren.

Entwicklung

npm run dev     # tsx watch, runs src/index.ts directly
npm run build   # compile to dist/
npm start       # run compiled dist/index.js

Testen Sie mit dem MCP Inspector:

npx @modelcontextprotocol/inspector node dist/index.js

(Setzen Sie PLANE_BASE_URL / PLANE_API_KEY / PLANE_WORKSPACE_SLUG im Umgebungsbereich des Inspectors.)

Hinweise zur Endpunkt-Stabilität

Dieser Server wurde anhand der gehosteten API-Dokumentation von Plane (developers.plane.so) sowie des dokumentierten Self-Hosting-Verhaltens erstellt – selbst gehostete Instanzen teilen sich dieselbe /api/v1-Oberfläche, aber das genaue Verhalten kann je nach Plane-Version leicht variieren. Wenn ein weniger verbreitetes Tool (z. B. die Filtersyntax von plane_advanced_search_work_items) auf Ihrer Instanz einen 400/404-Fehler zurückgibt, bevorzugen Sie die einfacheren Tools plane_list_work_items / plane_list_states / plane_list_labels und filtern Sie clientseitig, oder prüfen Sie die API-Dokumentation Ihrer eigenen Instanz unter <your-plane-url>/api/, falls verfügbar.