Coroid als MCP-Server

Coroid stellt einen Remote-Model-Context-Protocol-(MCP-)Server bereit. Ein externer Assistent oder Agent – etwa Hermes, Codex, Claude Code oder Cursor – kann ihn nutzen, um mit Coroid über dasselbe verwaltete Tool-Register wie der Chat-Assistent zu arbeiten.

Konfigurieren Sie unter Einstellungen → Verbindungen → Coroid MCP-Server, was folgendes abdeckt Übersicht, Client-Einrichtung, Zugriffstoken, Freigaben und Automatisierungsrichtlinien.

Der Endpunkt#

Der MCP-Server läuft auf dem API-Gateway unter dieser Adresse:

https://api.coroid.ai/mcp

Der Transport erfolgt über stateless Streamable HTTP. Authentifizieren Sie sich mit OAuth oder einem persönlichen Zugriffstoken.

Was ist aktiviert?#

Coroid aktiviert die MCP-Funktionen schrittweise – jeweils für alle Organisationen gleichzeitig.

Solange eine Funktion nicht aktiviert ist, sehen Clients ihre Tools nicht und Coroid lehnt Aufrufe dafür ab. Der Rest dieser Seite beschreibt das vollständige Set.

Einen Client verbinden#

Nutzen Sie OAuth, wenn Ihr Client es unterstützt. Sie genehmigen die Verbindung in Ihrem Browser und können sie jederzeit widerrufen. Zugriffstoken sind 15 Minuten gültig, Refresh-Token 30 Tage – jedes Refresh ersetzt das vorherige Refresh-Token.

Der Client fordert bei der Verbindung Bereiche an. Vor der Genehmigung sehen Sie die Bereiche und entscheiden, ob der Client auf alle Projekte oder nur auf einige zugreifen darf. Ein Client ohne angeforderte Bereiche erhält nur Lesezugriff – fordern Sie daher die benötigten Bereiche an, wie im Codex-Beispiel gezeigt.

Hermes#

hermes mcp add coroid --url https://api.coroid.ai/mcp --auth oauth
hermes mcp login coroid
hermes mcp test coroid

Alternativ mit einem Zugriffstoken:

hermes mcp add coroid --url https://api.coroid.ai/mcp --auth header

Geben Sie Hermes das Token, wenn es danach fragt. Speichern Sie es im Credential-Speicher von Hermes – nicht in seiner Konfigurationsdatei.

Codex#

codex mcp add coroid --url https://api.coroid.ai/mcp
codex mcp login coroid --scopes mcp.read,mcp.work.write,mcp.execute,mcp.delivery

Alternativ mit einem Zugriffstoken:

export COROID_MCP_TOKEN="cmp_pat_…"
codex mcp add coroid --url https://api.coroid.ai/mcp --bearer-token-env-var COROID_MCP_TOKEN

Claude Code#

claude mcp add --transport http --scope user coroid https://api.coroid.ai/mcp
/mcp

Führen Sie den ersten Befehl in Ihrem Terminal aus. Geben Sie dann den zweiten in Claude Code ein, wählen Sie coroid und melden Sie sich im Browser an.

Alternativ mit einem Zugriffstoken:

export COROID_MCP_TOKEN="cmp_pat_…"
claude mcp add --transport http --scope user --header "Authorization: Bearer $COROID_MCP_TOKEN" coroid https://api.coroid.ai/mcp

Cursor#

Fügen Sie Coroid zu ~/.cursor/mcp.json, oder zu .cursor/mcp.json in einem Repository hinzu, um die Einrichtung mit allen Mitarbeitern zu teilen:

{
  "mcpServers": {
    "coroid": {
      "url": "https://api.coroid.ai/mcp"
    }
  }
}

Cursor meldet sich mit OAuth an: Genehmigen Sie die Verbindung im Browser, wenn danach gefragt wird. Überprüfen Sie die Bereiche auf diesem Bildschirm – eine Verbindung ohne Schreibberechtigungen ermöglicht nur das Lesen.

Alternativ mit einem Zugriffstoken:

{
  "mcpServers": {
    "coroid": {
      "url": "https://api.coroid.ai/mcp",
      "headers": {
        "Authorization": "Bearer ${env:COROID_MCP_TOKEN}"
      }
    }
  }
}

Legen Sie COROID_MCP_TOKEN in der Umgebung fest, aus der Cursor gestartet wird. Ein .cursor/mcp.json in einem Repository wird damit committet – platzieren Sie die Variable dort, niemals das Token.

Andere Clients#

Jeder Client, der Remote-MCP-Server über Streamable HTTP unterstützt, kann sich verbinden. Coroid veröffentlicht die OAuth-Metadaten für den Endpunkt und unterstützt die dynamische Client-Registrierung mit PKCE. Ein Client ohne OAuth kann ein Zugriffstoken als Bearer-Token in diesem Header senden: Authorization.

Bevor ein Agent etwas ändert, lassen Sie ihn die Tools von Coroid auflisten und diese Ressource lesen: coroid://context. Dort wird angezeigt, als wer der Agent agiert, mit welchen Bereichen und Projekten.

Zugriffstoken#

Token werden unter Zugriffstokenerstellt und verwaltet. Wie jede andere Anmeldeinformation werden sie nur einmal angezeigt und danach nie wieder ausgegeben.

Erstellen Sie pro Client ein eigenes Token – so lässt sich der Zugriff eines einzelnen Clients widerrufen, ohne dass alle betroffen sind.

Ein Token wirkt als die Person, die es erstellt hat; nur eine im Portal angemeldete Person kann eines erstellen. Jedes Token hat eigene Bereiche, läuft nach 30, 90 oder 365 Tagen ab und gilt für alle Projekte oder nur für die ausgewählten. Ein Owner kann auch eine Automatisierungsrichtlinie zuweisen. Alle Token beginnen mit demselben Präfix: cmp_pat_.

Speichern Sie ein Token in der Umgebung oder im Credential-Speicher Ihres Clients. Legen Sie es niemals in ein Repository oder in eine Eingabeaufforderung.

Bereiche und Rollen#

Ein Bereich bestimmt, was eine Verbindung tun darf. Ihre Rolle in der Organisation setzt die Grenze: Ein Tool benötigt sowohl seinen Bereich als auch mindestens seine Rolle. Coroid prüft bei jedem Aufruf Ihre aktuelle Rolle – eine Verbindung behält niemals Rechte, die Sie verloren haben.

Nur ein Administrator oder Inhaber kann einen Bereich mit der niedrigsten Rolle „Administrator“ zuweisen. Nur ein Inhaber kann einen Bereich mit der niedrigsten Rolle „Inhaber“ zuweisen.

Eine Verbindung, die auf bestimmte Projekte beschränkt ist, kann nicht auf Inhalte anderer Projekte zugreifen – selbst über die ID eines Tasks, einer Planung, eines Sprints, eines Berichts oder eines Releases. Sie kann auch keine organisationweiten Tools nutzen, wie zum Beispiel diese: list_plans, get_capacity_dashboard.

Tools#

Ihr Client zeigt nur die aktivierten Tools an, die für Ihre Bereiche und Rollen zugänglich sind. Die Spalte „Freigabe“ gibt an, was beim Aufruf eines Tools geschieht:

Lesen#

Diese Tools erfordern die Rolle „Rezension“ und diesen Bereich: mcp.read. Keines davon benötigt eine Freigabe.

Informationen zu den Release-Tools finden Sie unter Releases über MCP.

Anti-Slop-Regeln aus Ihrem Editor#

Die beiden Anti-Slop-Tools sorgen dafür, dass der Agent des Entwicklers seine Arbeit an die Standards der Qualitätskontrolle hält – und zwar bereits vor der Erstellung des pull request.

• anti_slop_rules liefert die veröffentlichte Anti-Slop-Richtlinie des Projekts: die Regeln und welche davon blockieren, benutzerdefinierte Regeln, quarantänierte Regeln, welche neuen Abhängigkeiten Coroid aus öffentlichen Registries abrufen darf, sowie ein Snippet für AGENTS.md das dieselben Regeln für einen lokalen Agenten angibt. Fügen Sie das Snippet in AGENTS.md, oder in eine Regel in .cursor/rules für Cursor ein.
• anti_slop_scan prüft einen Branch, Tag oder Commit, den Coroid synchronisiert hat – gegen den Basis-Branch, sofern nicht ein anderer angegeben ist. Es liest nur: Es ändert keine Dateien, führt keine Befehle aus, installiert nichts und ruft kein Modell auf. Die Anzahl der Aufrufe ist auf 5 pro Minute begrenzt.

Eine Scan-Aktion ist eine Vorschau. Die Qualitätskontrolle prüft weiterhin den pull request – ihr Urteil zählt. Weitere Informationen finden Sie unter Anti-Slop-Prüfungen.

Arbeit erstellen und ändern#

Diese Tools erfordern die Rolle „Mitglied“ und diesen Bereich: mcp.work.write.

Über MCP erstellte Arbeit durchläuft keine Qualifizierungsphase. Eine planungsgroße Anfrage an das Task-Tool wird zu einem Entwurf einer Planung statt zu einem Task. Über MCP erstellte Pläne beginnen als Entwürfe.

Arbeit ausführen#

Diese Tools erfordern die Rolle „Mitglied“ und diesen Bereich: mcp.execute.

Lieferung#

Diese Tools erfordern die Rolle „Mitglied“ und diesen Bereich: mcp.delivery. Releases haben ihren eigenen Abschnitt weiter unten.

Verwaltung#

Diese Tools bestimmen die Einrichtung der Organisation und ihrer Projekte.

Organisationseinstellungen#

Ein Agent wie Hermes kann eine Organisation anhand von Screenshots, Dateien oder einer Beschreibung konfigurieren. Er liest das Einstellungsformat von Coroid, schreibt die gewonnenen Daten in ein Bundle, zeigt das Bundle vor und wendet es anschließend an. Diese Tools benötigen die Rolle Inhaber sowie diesen Bereich: mcp.organization.admin.

Ein Bundle enthält Platzhalter statt Geheimdatenwerten, und Coroid lehnt ein Bundle ab, das Geheimdaten enthält. Siehe Einstellungen exportieren und importieren.

Releases über MCP#

Die Release-Tools sind dieselben, die der Chat-Assistent nutzt, und sie durchlaufen denselben Release API wie das Portal:

create_release akzeptiert eine vollständige Commit-SHA, eine kurze SHA eines kürzlich gemachten Commits oder latest, und überlässt die Version der Versionsquelle des Projekts, sofern Sie keine eigene angeben. get_release gibt pro Umgebung die Prüfungen, die letzte Bereitstellung, die vom Pipeline-System gemeldete Version und an, ob Coroid die laufende Version verifiziert hat. Ein Token, das auf bestimmte Projekte beschränkt ist, kann keine Releases in anderen Projekten erreichen. Der Release API wendet außerdem seine eigenen Freigaberegeln an, sodass eine über MCP erfolgte Freigabe genauso zählt wie eine im Portal.

list_release_pull_requests gibt die offenen Pull Requests eines Projekts in der von Coroid vorgeschlagenen Reihenfolge zurück – inklusive des Grundes für eventuelle Ausnahmen. bundle_release_pull_requests erstellt daraus eine Release: einen Release-Branch mit den in der vorgegebenen Reihenfolge zusammengeführten Pull Requests und einen Release-Pull-Request. Es wird ein Branch gepusht und ein pull request geöffnet, weshalb immer eine menschliche Entscheidung erforderlich ist. Auslassen Sie prNumbers zur Nutzung der Auswahl von Coroid.

Freigaben und Automatisierungsrichtlinien#

Freigaben ist eine Warteschlange mit Aktionen, die auf eine menschliche Entscheidung warten. Automatisierungsrichtlinien bestimmt, was in diese Warteschlange aufgenommen werden soll.

Dies ist die entscheidende Steuerung. Ein externer Client, der im Auftrag handelt, sollte routinemäßige Aufgaben frei ausführen können, während für wichtige Aktionen stets eine menschliche Zustimmung erforderlich ist. Legen Sie die Richtlinien fest, bevor Sie ein Token an etwas weitergeben, das unbeaufsichtigt läuft.

Wenn ein Aufruf einer Freigabe bedarf, erhält der Client eine Freigabe-ID und einen Link – nicht jedoch das Ergebnis. Ein Inhaber oder Administrator prüft das genaue Tool und die übergebenen Argumente, bevor er den Aufruf freigibt oder ablehnt. Bei einer Freigabe wird der Aufruf exakt so ausgeführt, wie er gestellt wurde, und der Client kann ihn danach nicht mehr ändern. Ein Aufruf, der innerhalb von 10 Minuten nicht freigegeben wird, verfällt.

Eine Automatisierungsrichtlinie erlaubt einem Zugriffstoken, Tools mit dem Kennzeichen Policy ohne vorherige Freigabe auszuführen. Nur Inhaber können Richtlinien erstellen und sie an Tokens zuweisen. Eine Richtlinie benennt die genauen Tools, kann auf bestimmte Projekte beschränkt werden und begrenzt die Anzahl der pro Stunde, pro Tag und gleichzeitig ausführbaren Aufrufe. Sie kann auch ein Ablaufdatum haben. Das Zurückziehen einer Richtlinie hebt die Zuweisung zu allen damit verbundenen Tokens auf. Tools mit dem Kennzeichen Immer fallen niemals unter eine solche Richtlinie.

Eine OAuth-Verbindung kann keine Richtlinie enthalten. Über OAuth muss jedes Tool mit dem Kennzeichen Policy auf eine Freigabe warten.

Neuzuordnungen, Operationen und Ressourcen#

Jedes Tool, das Änderungen vornimmt, erfordert diesen Parameter: idempotencyKey. Verwenden Sie für jede neue Aktion einen neuen Schlüssel und bei einer Wiederholung denselben Schlüssel. Coroid gibt dann das erste Ergebnis zurück, anstatt die Aktion zweimal auszuführen. Ein wiederverwendeter Schlüssel mit anderen Argumenten wird abgelehnt.

Eine Änderung liefert außerdem eine Operation, die ihren Status und das Ergebnis festhält. Diese vier Tools funktionieren für jede Verbindung:

Der Server stellt außerdem diese Ressourcen bereit:

Es stehen außerdem drei Eingabeaufforderungen zur Verfügung: create_and_run_task, investigate_failure, prepare_release.

Jedes Tool hat Grenzen pro Minute, pro Stunde und pro Tag. Ein Aufruf, der diese Grenzen überschreitet, schlägt fehl und gibt an, wie lange bis zur nächsten Wiederholung gewartet werden muss.

Was absichtlich nicht zur Verfügung gestellt wird#

Das Tool-Register wird gesteuert, und die Ausschlüsse sind beabsichtigt. Folgendes wird nicht bereitgestellt:

• Eine Shell
• Git-Zugriff
• Das Dateisystem
• Roher Datenbankzugriff
• Beliebiger interner HTTP-Zugriff
• Die eigenen ausgehenden MCP-Verwaltungstools von Coroid

Sie erhalten die Möglichkeit, Arbeit zu verwalten – Aufgaben, Pläne, Projekte und Releases erstellen und überprüfen – es handelt sich nicht um eine Umgebung für die Remote-Ausführung. Ein MCP-Client kann Coroid nicht zur Ausführung beliebiger Befehle nutzen.

Wofür es geeignet ist#

Coroid direkt aus Ihrem bestehenden Arbeitsumfeld heraus steuern – sei es ein Editor, ein Assistent oder ein internes Tool – ohne das Portal wechseln zu müssen. Eine Aufgabe direkt über das Terminal erstellen oder einen Assistenten bitten, den Blockierungsstatus zu prüfen, wird so zu einer lokalen Aktion.

Verwandte Inhalte#

• Möglichkeiten, mit der Arbeit zu beginnen
• Einstellungen exportieren und importieren
• Externe MCP-Server
• Chat-Assistent
• Provenienz