MCP verbinden: Claude, Claude Code, Cursor und andere Clients einrichten

Diese Clients melden sich über OAuth an. Du brauchst keinen Zugriffsschlüssel.

1. Öffne in Claude Einstellungen → Connectors → Custom Connector hinzufügen.
2. Trage als Server-URL <Instanz-Adresse>/api/mcp ein.
3. Claude leitet dich zum Login weiter, danach öffnet sich die Bestätigungsseite von Project Manager.
4. Prüfe den Zugriff (siehe nächster Schritt) und klicke auf Erlauben. Mit Verweigern brichst du ab.
5. Teste die Verbindung mit der Frage „Zu welchen Organisationen habe ich Zugriff?“ – Claude ruft list_organizations auf.

Die Bestätigungsseite zeigt, was der Client darf, und lässt dich den Zugriff im Bereich Einstellungen eingrenzen. Sie legt im Hintergrund einen widerrufbaren Zugriffsschlüssel an; der Token selbst wird dir nicht angezeigt.

Zugriff auf

Standardmäßig die aktuell aktive Organisation mit deiner Rolle. Der Zugang ist dann an diese Organisation gebunden.

Für alle Organisationen, denen ich angehöre

Macht den Zugang kontoweit. Die Organisation wird dann pro Anfrage angegeben (Header oder Argument organization). Ohne aktive Organisation ist diese Option fest gesetzt.

Zugriffsrechte: Nur Lesen

Erlaubt Tools mit Scope read (Daten lesen und auflisten).

Zugriffsrechte: Lesen und Schreiben

Zusätzlich Tools mit Scope write (Einträge erstellen und bearbeiten).

Zugriffsrechte: Lesen, Schreiben, Löschen

Voller Zugriff, zusätzlich Tools mit Scope delete. Voreingestellt, wenn der Client keinen engeren Scope anfragt.

Stattdessen einen API Key verwenden

Alternative für Clients ohne Sitzung im Browser: Du trägst einen bestehenden Zugriffsschlüssel (mk_…) ein und autorisierst damit.

Diese Clients lesen einen Bearer-Token aus einer Konfigurationsdatei. Erstelle dafür im Konto unter Integrationen einen MCP-Zugriffsschlüssel (der vollständige Schlüssel wird nur einmal angezeigt) und trage ihn in die MCP-Konfiguration ein.

type

http

url

<Instanz-Adresse>/api/mcp

headers → Authorization

Bearer <DEIN_SCHLÜSSEL> – der Schlüssel beginnt mit mk_.

headers → X-Organization-Slug (nur kontoweit)

Slug der Organisation, die der Schlüssel ansprechen soll.

1. Öffne Konto → Integrationen und erstelle einen Schlüssel für MCP/KI-Werkzeuge; vergib einen Namen, wähle das Zugriffslevel und entscheide über „Account-wide“.
2. Kopiere den Schlüssel sofort – er lässt sich nicht erneut anzeigen.
3. Trage Serveradresse und Header in die MCP-Konfiguration deines Clients ein (die Einrichtungshilfe /mcp/setup zeigt ein vollständiges Beispiel als JSON mit mcpServers → project-manager).
4. Starte den Client neu und teste mit einer lesenden Anfrage.

Ein Zugang ist entweder an eine Organisation gebunden oder kontoweit. Bei kontoweiten Zugängen bestimmst du die Organisation über einen der folgenden Wege.

Organisationsgebunden

Der Zugang gilt nur für die Organisation, die beim Erstellen aktiv war. Er funktioniert nur, solange diese Organisation in der Webapp deine aktive Organisation ist.

Kontoweit + Header

X-Organization-Id, X-Organization-Slug oder X-Organization-Name legen die Organisation fest (in dieser Reihenfolge ausgewertet). Rolle und Module werden aus deiner Mitgliedschaft in dieser Organisation abgeleitet.

Kontoweit ohne Header

Alle Tools werden gelistet und erhalten den zusätzlichen Parameter organization (Name, Slug oder ID). Ohne Angabe kommt ein Fehler; list_organizations funktioniert ohne Organisation.

Nicht Mitglied

Wird eine Organisation angegeben, in der du nicht Mitglied bist, lehnt der Server ab.

Alle Zugänge – auch die über die Bestätigungsseite angelegten (Name „Claude — connected <Datum>“) – erscheinen im Konto unter Integrationen mit Name, Präfix, Rechten und letzter Verwendung. MCP-Schlüssel und WebDAV-Schlüssel sind getrennte Arten und nicht austauschbar.

1. Öffne Konto → Integrationen und wähle den Schlüsselbereich für MCP/KI-Werkzeuge.
2. Erkenne den Zugang an Name und letzter Verwendung.
3. Widerrufe ihn. Ab sofort werden Anfragen mit diesem Schlüssel und alle mit ihm ausgestellten OAuth-Tokens abgelehnt.
4. Erstelle bei Bedarf einen neuen Zugang mit engeren Rechten.

Wer einen eigenen Client baut, findet die Metadaten unter den Standardpfaden. Der Ablauf ist OAuth 2.0 mit Authorization-Code und PKCE (nur S256); Clients registrieren sich dynamisch (RFC 7591).

/.well-known/oauth-authorization-server

Metadaten des Autorisierungsservers: Endpunkte für Autorisierung, Token und Registrierung; unterstützt werden response_type code, die Grants authorization_code und refresh_token, PKCE S256 und Token-Endpunkt-Authentifizierung none.

/.well-known/oauth-protected-resource

Metadaten der geschützten Ressource (<Instanz-Adresse>/api/mcp) und Verweis auf den Autorisierungsserver. Ein 401 des MCP-Endpunkts verweist per WWW-Authenticate darauf.

/api/mcp/oauth/register

Dynamische Client-Registrierung; vergibt eine client_id (dyn_…). Mindestens eine redirect_uri muss erlaubt sein.

/api/mcp/oauth/authorize und /token

Autorisierung und Tokenausgabe. Der Autorisierungscode gilt 5 Minuten, das Zugriffstoken 1 Stunde, das Erneuerungstoken 365 Tage und wird bei jeder Erneuerung neu ausgestellt.

Erlaubte Redirect-URIs

Loopback-Adressen (localhost, 127.0.0.1, ::1) mit beliebigem Port sowie Adressen, die der Betreiber der Instanz ausdrücklich freigegeben hat. Andere Adressen werden abgelehnt.

Direkte Schlüssel

Alternativ akzeptiert /api/mcp jeden MCP-Schlüssel mit Präfix mk_ als Bearer-Token.