Coroid als MCP-Server

Coroid stellt einen Remote-Model-Context-Protocol-(MCP-)Server bereit. Externe Assistenten oder Agenten wie Hermes, Codex oder Claude Code können ihn nutzen, um mit Coroid über dasselbe verwaltete Tool-Register wie der Chat-Assistent zu arbeiten.

Konfigurieren Sie die Einstellungen unter Einstellungen → Verbindungen → Coroid MCP-Server, womit folgende Bereiche abgedeckt werden: Ü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

Als Übertragungsprotokoll wird stateless Streamable HTTP genutzt. Die Authentifizierung erfolgt via OAuth oder einem persönlichen Zugriffstoken.

Was aktiviert ist#

Coroid aktiviert die MCP-Funktionen schrittweise – und zwar für jede Organisation gleichzeitig.

Solange eine Funktion nicht aktiviert ist, können Clients ihre Tools nicht sehen 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 dies unterstützt. Sie genehmigen die Verbindung in Ihrem Browser und können sie jederzeit widerrufen. Zugriffstoken sind 15 Minuten gültig, die Aktualisierungstoken 30 Tage – bei jeder Aktualisierung wird das Refresh-Token ersetzt.

Der Client fordert beim Verbinden Bereiche an. Vor der Genehmigung sehen Sie die Bereiche und entscheiden, ob der Client auf alle Projekte oder nur auf bestimmte zugreifen darf. Ein Client ohne angeforderte Bereiche erhält nur Lesezugriff – fordern Sie daher nur die benötigten Bereiche an, wie im Beispiel mit Codex 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 aus 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

Andere Clients#

Jeder Client, der externe 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 Änderungen vornimmt, bitten Sie ihn, die Tools von Coroid aufzulisten und diese Ressource zu lesen: coroid://context. Dort wird angezeigt, als wer der Agent agiert, welche Bereiche und Projekte ihm zugewiesen sind.

Zugriffstoken#

Die Token werden unter Zugriffstokenerstellt und verwaltet. Wie bei allen anderen Anmeldeinformationen werden sie nur einmal angezeigt und danach nicht mehr ausgegeben.

Erstellen Sie pro Client ein eigenes Token. So lässt sich der Zugriff eines einzelnen Clients widerrufen, ohne dass dies zu einem Ausfall für alle anderen führt.

Ein Token wirkt als die Person, die es erstellt hat – und nur eine im Portal angemeldete Person kann ein solches Token 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 Inhaber kann auch eine Automatisierungsrichtlinie zuweisen. Alle Token beginnen mit demselben Präfix: cmp_pat_.

Speichern Sie das Token im Umfeld Ihres Clients oder im Anmeldeinformationenspeicher. Geben Sie es niemals in einem Repository oder Prompt an.

Bereiche und Rollen#

Ein Bereich definiert die zulässigen Aktionen einer Verbindung. Ihre Rolle in der Organisation bestimmt die Grenzen: Ein Tool benötigt sowohl den entsprechenden Bereich als auch mindestens die passende Rolle. Coroid prüft bei jedem Aufruf Ihre aktuelle Rolle, sodass eine Verbindung niemals über verlorene Berechtigungen verfügt.

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 auf bestimmte Projekte beschränkte Verbindung kann nicht auf Inhalte anderer Projekte zugreifen – selbst über die ID einer Aufgabe, eines Plans, Sprints, Berichts oder Release. Sie kann auch keine organisationsweiten Tools nutzen, wie zum Beispiel: list_plans, get_capacity_dashboard.

Tools#

Ihr Client zeigt nur die Tools an, die aktiviert sind und für die Ihre Bereiche sowie Rolle die Berechtigung gewähren. Die Spalte 'Freigabe' gibt an, was beim Aufruf eines Tools geschieht:

Lesen#

Diese Tools erfordern die Rolle 'Rezensent' sowie diesen Bereich: mcp.read. Keines davon benötigt eine Freigabe.

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

Arbeit erstellen und ändern#

Für diese Tools ist die Rolle Mitglied sowie der Bereich erforderlich: mcp.work.write.

Über MCP erstellte Arbeit durchläuft keinen Qualifizierungsprozess. Eine an das Aufgaben-Tool gesendete Anfrage mit Plan-Größe wird stattdessen zu einem Entwurfsplan und nicht zu einer Aufgabe. Über MCP erstellte Pläne beginnen als Entwürfe.

Laufende Arbeit#

Für diese Tools ist die Rolle Mitglied sowie der Bereich erforderlich: mcp.execute.

Lieferung#

Für diese Tools ist die Rolle Mitglied sowie der Bereich erforderlich: mcp.delivery. Die 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 aus, schreibt die gewonnenen Daten in ein Bundle, zeigt dieses vor und wendet es anschließend an. Für diese Vorgänge ist die Rolle des Inhabers sowie dieser Bereich erforderlich: mcp.organization.admin.

Ein Paket enthält Platzhalter statt geheimer Werte, und Coroid lehnt ein Paket ab, das ein Geheimnis enthält. Siehe Einstellungen exportieren und importieren.

Releases über MCP#

Die Release-Tools entsprechen denen des Chat-Assistenten und 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 angibt. get_release gibt pro Umgebung die Prüfungen, die letzte Deployment-Aktion, die von der Pipeline gemeldete Version sowie an, ob Coroid die laufende Version verifiziert hat. Ein auf bestimmte Projekte begrenztes Token kann nicht auf Releases in anderen Projekten zugreifen. Die Release-API wendet weiterhin ihre eigenen Freigaberegeln an; eine über MCP erfolgte Freigabe zählt daher genauso wie eine im Portal erteilte Freigabe.

list_release_pull_requests Der Befehl gibt die offenen Pull Requests eines Projekts in der von Coroid vorgeschlagenen Reihenfolge zurück und nennt außerdem die Gründe für eventuell ausgelassene Einträge. bundle_release_pull_requests Daraus wird ein Release erstellt: Ein Release-Branch mit den in der richtigen Reihenfolge zusammengeführten Pull Requests sowie ein Release-Pull-Request. Dabei wird ein Branch gepusht und ein pull request geöffnet – somit erfolgt stets eine manuelle Prüfung. Auslassen Sie dies. prNumbers So nutzen Sie die Auswahl von Coroid.

Freigaben und Automatisierungsrichtlinien#

Freigaben bilden eine Warteschlange mit Aktionen, die auf eine menschliche Entscheidung warten. Automatisierungsrichtlinien bestimmen, welche Aktionen in diese Warteschlange aufgenommen werden.

Dies ist die entscheidende Steuerung: Ein externer Client, der in Ihrem Namen agiert, 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 ein unbeaufsichtigtes System weitergeben.

Wenn eine Anfrage einer Freigabe bedarf, erhält der Client eine Freigabe-ID sowie einen Link – nicht jedoch das Ergebnis. Der Inhaber oder Administrator prüft das genutzte Tool sowie die übergebenen Argumente und stimmt der Anfrage anschließend zu oder lehnt sie ab. Bei Zustimmung wird die Anfrage exakt so ausgeführt, wie sie gestellt wurde; eine nachträgliche Änderung durch den Client ist nicht möglich. Eine Anfrage, die innerhalb von 10 Minuten nicht freigegeben wird, verfällt.

Eine Automatisierungsrichtlinie erlaubt einem Zugriffstoken, Tools mit dem Tag „Policy“ ohne vorherige Freigabe auszuführen. Nur Inhaber können solche Richtlinien erstellen und sie mit Zugriffstoken verknüpfen. 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. Zudem kann eine Richtlinie ein Ablaufdatum haben. Das Widerrufen einer Richtlinie führt zum Entzug aller damit verknüpften Zugriffstoken. Tools mit dem Tag „Always“ fallen niemals unter eine solche Richtlinie.

Eine OAuth-Verbindung kann keine Richtlinie übernehmen. Über OAuth müssen alle Tools mit dem Tag „Policy“ einer Freigabe zugeführt werden.

Wiederholungen, Operationen und Ressourcen#

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

Eine Änderung liefert außerdem eine Operation, die den Status sowie das Ergebnis festhält. Diese vier Tools stehen für jede Verbindung zur Verfügung:

Der Server stellt außerdem folgende Ressourcen bereit:

Außerdem stehen drei Prompts 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 ist streng geregelt, und die Ausnahmen sind beabsichtigt. Folgende Funktionen werden nicht bereitgestellt:

• eine Shell
• Git-Zugriff
• das Dateisystem
• rohen Datenbankzugriff
• beliebigen internen HTTP-Anfragen
• Coroid's eigene ausgehende MCP-Verwaltungstools

Sie erhalten die Möglichkeit, Arbeit zu verwalten – Aufgaben, Pläne, Projekte und Releases erstellen und überprüfen – es handelt sich dabei 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#

Steuern Sie Coroid direkt aus Ihrem gewohnten Arbeitsumfeld – einem Editor, Assistenten oder internem Tool – ohne den Umstieg auf das Portal. So können Sie beispielsweise Aufgaben über das Terminal erstellen oder einen Assistenten bitten, den aktuellen Blockierungsstatus zu prüfen – alles als lokale Aktion.

Verwandt#

• So starten Sie die Arbeit
• Einstellungen exportieren und importieren
• Externe MCP-Server
• Chat-Assistent
• Provenienz