MCP und API-Schlüssel

Setup hat einen MCP-Server. Ein KI-Agent wie Claude Code oder Cursor kann damit tun, was du im Dashboard tust: ein Projekt ansehen, einen Test starten, die Logs lesen, die App behalten oder entfernen. Der Agent meldet sich mit einem API-Schlüssel an, den du erstellst, und kann nur, was du selbst auch könntest.

Für Agenten gelten dieselbe Sandbox und dieselben Regeln wie für Menschen. Sie sehen nie die Zugangsdaten deiner verbundenen Konten und müssen fragen, bevor sie etwas löschen. Behandle einen API-Schlüssel wie ein Passwort: Wer ihn hat, kann Apps in seinen Workspaces starten, stoppen und löschen.

Anmelden statt Schlüssel

Die meisten MCP Hosts melden sich selbst bei Setup an, dann brauchst du gar keinen Schlüssel. Füge den Server mit seiner Adresse hinzu, zum Beispiel https://setup.run/api/mcp. Beim Verbinden öffnet der Host Setup in deinem Browser. Melde dich an und beantworte Darf … Setup verwenden?:

• Arbeitsbereich: dein persönlicher Arbeitsbereich oder eine Organisation. Die anderen sieht die App nie.
• Was sie darf: Ansehen (nur lesen), Ansehen und Apps betreiben oder Auch den Arbeitsbereich verwalten (so weit deine eigene Rolle reicht). Wer nur zusehen darf, kann nur Ansehen erlauben.

Wähle Erlauben, dann ist der Host verbunden. Setup zeigt den Namen der App nur als den Namen, den sie sich selbst gibt, und sagt dir, ob es geprüft hat, woher die App kommt. Erlaube nur Apps, die du gerade selbst verbindest.

Der Host bekommt Zugangsdaten, die 15 Minuten gelten und sich selbst erneuern; du kopierst nichts von Hand. Deine Verbindungen stehen unter Mein Konto, Verbundene Apps (/dashboard/account/connected-apps). Trennen beendet den Zugriff einer App sofort.

API-Schlüssel erstellen

1. Öffne im Dashboard Entwickler: /dashboard/developers, oder /dashboard/<workspace>/developers innerhalb eines Workspaces. Du findest die Seite in der Seitenleiste der Detailansicht. In der einfachen Ansicht kommst du über Details anzeigen hin (siehe Einfache Ansicht und Detailansicht).
2. Wähl Schlüssel erstellen.
3. Füll das Formular aus:
   • Name, damit du deine Schlüssel später auseinanderhältst, zum Beispiel „Claude Code auf meinem Laptop“.
   • Workspace: Alle meine Workspaces oder Nur ein bestimmter Workspace.
   • Läuft ab: in 30 Tagen, in 90 Tagen (Standard), in einem Jahr oder nie.
4. Wähl noch einmal Schlüssel erstellen. Setup zeigt den Schlüssel genau einmal unter Kopiere deinen neuen Schlüssel, zusammen mit einem fertigen Befehl für Claude Code. Kopiere ihn und wähl dann Ich habe ihn kopiert.

Setup speichert nur einen Hash des Schlüssels und kann ihn nicht noch einmal anzeigen. Hast du ihn verloren, widerruf ihn und erstell einen neuen. Jeder Schlüssel beginnt mit setup_, damit Secret-Scanner ihn erkennen.

Was ein Schlüssel darf

Außer der Wahl des Workspaces gibt es keine Berechtigungen pro Schlüssel. Ein Schlüssel:

• hat deine Rechte, mit deiner Rolle in jedem Workspace,
• gilt mit Alle meine Workspaces in deinem persönlichen Workspace und in jeder Organisation, in der du Mitglied bist,
• sieht und ändert mit Nur einem Workspace nichts außerhalb davon und funktioniert nicht mehr, sobald du diese Organisation verlässt,
• hat nie globale Admin-Rechte, auch wenn dein Konto sie hat,
• kann keine Schlüssel erstellen, auflisten oder widerrufen und kommt nicht an Admin-, Abrechnungs- oder Kontoeinstellungen.

Einen Schlüssel widerrufen

Die Liste auf Entwickler zeigt zu jedem Schlüssel Name, Workspace, wann er erstellt und zuletzt genutzt wurde und wann er abläuft. Zum Widerrufen wählst du den Button daneben und dann Schlüssel widerrufen. Agenten und Skripte mit diesem Schlüssel hören sofort auf zu funktionieren. Rückgängig machen lässt sich das nicht.

Einen MCP-Client verbinden

Der Server liegt unter /api/mcp deiner Setup-Instanz, zum Beispiel https://setup.run/api/mcp. Der Bereich Agenten verbinden auf Entwickler zeigt die folgenden Snippets mit der richtigen Adresse.

Claude Code

Exportiere deinen Schlüssel als SETUP_API_KEY und führ dann aus:

claude mcp add --transport http setup https://setup.run/api/mcp \
  --header "Authorization: Bearer $SETUP_API_KEY"

Cursor

Trag das in .cursor/mcp.json eines Projekts ein, oder in ~/.cursor/mcp.json für alle Projekte, und ersetze <SETUP_API_KEY> durch deinen Schlüssel:

{
  "mcpServers": {
    "setup": {
      "url": "https://setup.run/api/mcp",
      "headers": { "Authorization": "Bearer <SETUP_API_KEY>" }
    }
  }
}

Andere Clients

Der Server spricht Streamable HTTP ohne Sessions: Jede Anfrage wird für sich bearbeitet. Schick den Schlüssel als Authorization: Bearer setup_... oder im Header x-api-key. Session-Cookies nimmt dieser Endpunkt nicht an.

curl https://setup.run/api/mcp \
  -H "Authorization: Bearer $SETUP_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Ohne Schlüssel und ohne Anmeldung kommt 401 mit dem Code apiKey.missing und einem Header WWW-Authenticate, der Hosts sagt, wo sie sich anmelden. Ein ungültiger, abgelaufener oder widerrufener Schlüssel bekommt 401 mit apiKey.invalid. Ist ein Schlüssel auf einen Workspace beschränkt, in dem du nicht mehr Mitglied bist, kommt 403 mit apiKey.workspaceUnavailable.

Tools

Tools mit organizationId nehmen den Workspace des Schlüssels, wenn du es weglässt, bei einem Schlüssel ohne Workspace deinen persönlichen.

Ein typischer Ablauf: analyze, der Person die reviewUrl zeigen, einen Test per deploy starten, get_deployment und get_logs bis die App läuft, dann deployment_action mit promote zum Behalten, oder destroy. Ist kein Runner online, wartet die App in der Warteschlange, und get_deployment sagt das.

Rezepte mit externen Diensten

Braucht ein Rezept externe Dienste (siehe Rezepte), lässt es sich erst deployen, wenn die Person entschieden hat, wie jeder eingerichtet wird. Bis dahin schlägt deploy mit deployment.needsRequirements fehl. Der Agent ruft explain_requirements auf, erklärt die Möglichkeiten und schickt die Person zur Seite des Rezepts unter reviewUrl. Soll Setup die Ressourcen anlegen, verbindet die Person zuerst über den Link aus connect_service ein Konto und bestätigt danach auf der Seite der App den Plan mit seinen Kosten. Zugangsdaten laufen nie über den Agenten. Mehr unter Integrationen und verbundene Konten.

Was ein Agent kann und was nicht

Ein Agent kann alles, was die Tools oben abdecken, in den Workspaces, die sein Schlüssel erlaubt. Neben dem, was kein Schlüssel darf (siehe oben), kann er nicht:

• Zugangsdaten verbundener Konten eintragen oder lesen, denn connect_service liefert nur einen Link,
• außerhalb seines Workspaces handeln, wenn der Schlüssel auf einen beschränkt ist,
• etwas außerhalb der Sandbox ausführen: Seine Apps bekommen dieselben Rezeptregeln und dieselbe Runner-Härtung wie deine (siehe Sicherheit),
• eine App löschen, eine Sicherung wiederherstellen oder einen Rest entfernen, ohne confirm: true zu übergeben.

Sicherheitsregeln

• Text von Dritten ist markiert. READMEs, Projektbeschreibungen, Befunde, Rezept-Notizen, Logs, Runner-Fehler und Check-Ausgaben kommen in einem eigenen Block zurück. Er beginnt mit UNTRUSTED DATA from ... und steht zwischen Markern, die bei jeder Antwort zufällig sind, damit der Text seinen Block nicht selbst schließen kann. Die Anweisungen des Servers sagen Agenten, diesen Text als Daten zu behandeln und nie Anweisungen darin zu folgen.
• Destruktive Tools sind markiert. deployment_action und remove_leftover tragen den MCP-destructiveHint. Clients, die ihn beachten, fragen dich vor jedem Aufruf, auch bei einem einfachen start oder stop.
• Löschen braucht eine Bestätigung. Setup lehnt destroy, restore und remove_leftover ab, solange der Agent nicht confirm: true übergibt, weil sie Daten löschen oder ersetzen. Der Server sagt Agenten, dass sie dich vorher fragen sollen.
• Keine Zugangsdaten über Agenten. Konten verbindest du im Dashboard. Tools nehmen nie Schlüssel von Anbietern an und geben nie welche zurück.
• Schlüssel klein halten. Beschränk einen Schlüssel auf einen Workspace, gib ihm ein Ablaufdatum und widerruf ihn, sobald der Agent ihn nicht mehr braucht.

Limits

Fehler von Tools kommen als Text zurück, etwa Setup API error 400 (deployment.invalidInputs): Missing: ADMIN_EMAIL, mit denselben Codes wie die REST-API.

Die REST-API

Derselbe Schlüssel funktioniert auf den Plattform-Routen von Setup, etwa /api/analyses, /api/projects, /api/deployments, /api/runners und /api/integrations. Die MCP-Tools rufen intern genau diese Routen auf, Validierung, Workspace-Regeln und Rate-Limits sind also dieselben. Schlüssel unter /api/api-keys verwalten geht nur mit einer angemeldeten Session im Browser. Ein mitgeschickter Schlüssel muss gültig sein: Ein widerrufener Schlüssel bekommt 401, auch wenn zusätzlich ein Session-Cookie dabei ist.

Die einzelnen REST-Routen beschreibt diese Seite nicht.