Coroid en tant que serveur MCP

Coroid expose un serveur Model Context Protocol (MCP) distant. Un assistant ou un agent externe, comme Hermes, Codex, Claude Code ou Cursor, peut l'utiliser pour travailler avec Coroid via le même registre d'outils gouvernés que celui utilisé par l'assistant de chat.

Configurez sous Paramètres → Connexions → Coroid MCP server, ce qui couvre Aperçu, Configuration du client, Jeton d'accès, Approbations et Politiques d'automatisation.

Le point de terminaison#

Le serveur MCP s'exécute sur le passerelle API, à cette adresse :

https://api.coroid.ai/mcp

Le protocole de transport est le HTTP streamable sans état. Authentifiez-vous avec OAuth ou un jeton d'accès personnel.

Ce qui est activé#

Coroid active les fonctionnalités MCP par étapes, pour toutes les organisations en même temps.

Tant qu'une fonctionnalité n'est pas activée, les clients ne voient pas ses outils et Coroid rejette les appels destinés à ceux-ci. Le reste de cette page décrit l'ensemble complet.

Connecter un client#

Utilisez OAuth si votre client le prend en charge. Vous approuvez la connexion dans votre navigateur et pouvez la révoquer à tout moment. Les jetons d'accès expirent après 15 minutes et les jetons de rafraîchissement après 30 jours ; chaque rafraîchissement remplace le jeton de rafraîchissement.

Le client demande des scopes lorsqu'il se connecte. Avant de les approuver, vous voyez les scopes et choisissez si le client peut accéder à tous les projets ou seulement à certains. Un client qui ne demande aucun scope n'a qu'un accès en lecture ; demandez donc les scopes dont vous avez besoin, comme le fait l'exemple de Codex.

Hermes#

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

Avec un jeton d'accès à la place :

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

Donnez le jeton à Hermes lorsqu'il en fait la demande. Conservez-le dans le magasin de données d'identification d'Hermes plutôt que dans son fichier de configuration.

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

Avec un jeton d'accès à la place :

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

Exécutez la première commande dans votre terminal. Ensuite, tapez la seconde dans Claude Code, sélectionnez coroid et connectez-vous dans votre navigateur.

Avec un jeton d'accès à la place :

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#

Ajoutez Coroid à ~/.cursor/mcp.json, ou à .cursor/mcp.json dans un dépôt pour partager la configuration avec toutes les personnes qui y travaillent :

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

Cursor se connecte via OAuth : approuvez la connexion dans votre navigateur lorsqu'il vous le demande. Vérifiez les scopes sur cet écran, car une connexion sans scopes d'écriture ne permet que la lecture.

Avec un jeton d'accès à la place :

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

Définissez COROID_MCP_TOKEN dans l'environnement à partir duquel Cursor démarre. Un .cursor/mcp.json dans un dépôt est commité avec lui ; placez donc la variable deux, jamais le jeton.

Autres clients#

Tout client prenant en charge les serveurs MCP distants via HTTP streamable peut se connecter. Coroid publie les métadonnées OAuth pour le point de terminaison et prend en charge l'enregistrement dynamique de clients avec PKCE. Un client sans OAuth peut envoyer un jeton d'accès en tant que jeton porteur dans cet en-tête : Authorization.

Avant qu'un agent ne modifie quoi que ce soit, demandez-lui de lister les outils de Coroid et de lire cette ressource : coroid://context. Elle indique sous quel nom l'agent agit, avec quels scopes et projets.

Jeton d'accès#

Les jetons sont créés et gérés sous Jeton d'accès. Comme toute autre donnée d'identification, ils sont affichés une fois et ne sont jamais renvoyés par la suite.

Émettez un jeton par client plutôt que de partager le même. La révocation de l'accès d'un seul client devient alors une action isolée plutôt qu'une panne pour tout le monde.

Un jeton agit au nom de la personne qui l'a créé, et seule une personne connectée au portail peut en créer un. Chaque jeton possède ses propres scopes, expire après 30, 90 ou 365 jours, et concerne tous les projets ou uniquement ceux que vous sélectionnez. Un propriétaire peut également attacher une politique d'automatisation. Tous les jetons commencent par le même préfixe : cmp_pat_.

Conservez un jeton dans l'environnement de votre client ou dans son magasin de données d'identification. Ne le placez jamais dans un dépôt ou dans une invite de commande.

Scopes et rôles#

Un scope définit ce qu'une connexion peut faire. Votre rôle dans l'organisation fixe la limite : un outil nécessite à la fois son scope et au moins son rôle. Coroid vérifie votre rôle actuel à chaque appel, afin qu'une connexion ne conserve jamais des droits que vous avez perdus.

Seul un administrateur ou un propriétaire peut accorder un périmètre dont le rôle le plus bas est Administrateur. Seul un propriétaire peut accorder un périmètre dont le rôle le plus bas est Propriétaire.

Une connexion limitée à certains projets ne peut pas accéder à quoi que ce soit dans d'autres projets, même via l'identifiant d'une tâche, d'un plan, d'un sprint, d'un rapport ou d'une version. Elle ne peut pas non plus utiliser les outils à l'échelle de l'organisation, comme ceux-ci : list_plans, get_capacity_dashboard.

Outils#

Votre client n'affiche que les outils activés et autorisés par vos périmètres et rôles. La colonne d'approbation indique ce qui se passe lors de l'appel à un outil :

Lecture#

Ces outils nécessitent le rôle de Réviseur et ce périmètre : mcp.read. Aucun d'entre eux n'a besoin d'approbation.

Pour en savoir plus sur les outils de publication, consultez Versions via MCP.

Règles Anti-slop de votre éditeur#

Les deux outils Anti-slop permettent à l'agent personnel d'un développeur de conformer son travail aux normes du Contrôle qualité appliquées à chaque pull request, avant même que l'pull request n'existe.

• anti_slop_rules renvoie la politique Anti-slop publiée du projet : les règles et celles qui bloquent, les règles personnalisées, les règles mises en quarantaine, les nouvelles dépendances que Coroid peut rechercher dans les registres publics, ainsi qu'un extrait pour AGENTS.md qui énonce les mêmes règles pour un agent local. Collez l'extrait dans AGENTS.md, ou dans une règle dans .cursor/rules pour Cursor.
• anti_slop_scan analyse une branche, une balise ou une validation que Coroid a synchronisée avec une base, la branche par défaut sauf indication contraire. Il ne fait qu'une lecture : il ne modifie aucun fichier, n'exécute aucune commande, n'installe rien et n'appelle aucun modèle. Il est limité à 5 appels par minute.

Une analyse est une prévisualisation. Le Contrôle qualité vérifie toujours l'pull request, et c'est son verdict qui compte. Consultez Vérifications Anti-slop.

Créer et modifier des tâches#

Ces outils nécessitent le rôle Membre et ce périmètre : mcp.work.write.

Le travail créé via MCP ne passe pas par la phase de qualification. Une demande de la taille d'un plan envoyée à l'outil de tâches devient un plan brouillon au lieu d'une tâche. Les plans créés via MCP démarrent sous forme de brouillons.

Exécuter le travail#

Ces outils nécessitent le rôle Membre et ce périmètre : mcp.execute.

Livraison#

Ces outils nécessitent le rôle Membre et ce périmètre : mcp.delivery. Les versions ont leur propre section ci-dessous.

Administration#

Ces outils modifient la configuration de l'organisation et de ses projets.

Paramètres de l'organisation#

Un agent tel que Hermes peut configurer une organisation à partir de captures d'écran, de fichiers ou d'une description. Il lit le format de paramétrage de Coroid, écrit les données dans un bundle, prévisualise ce dernier puis l'applique. Ces outils nécessitent le rôle de Propriétaire et cet étendue : mcp.organization.admin.

Un bundle contient des placeholders à la place des valeurs de secrets, et Coroid rejette un bundle qui inclut un secret. Voir Exporter et importer les paramètres.

Versions via MCP#

Les outils de version sont les mêmes que ceux utilisés par l'assistant de chat et passent par la même API de version que le portail :

create_release accepte un identifiant de validation complet, un identifiant court d'une validation récente, ou latest, et laisse la version définie par la source de version du projet sauf si vous en spécifiez une. get_release rapporte, par environnement, les vérifications, la dernière déploiement, la version signalée par le pipeline et si Coroid a vérifié la version en cours d'exécution. Un jeton limité à certains projets ne peut pas accéder aux versions d'autres projets. La API de version applique néanmoins ses propres règles d'approbation, donc une approbation via MCP compte exactement comme une approbation dans le portail.

list_release_pull_requests renvoie les pull requests ouverts d'un projet dans l'ordre proposé par Coroid, avec la raison pour laquelle certaines seraient exclues. bundle_release_pull_requests crée une version à partir de celles-ci : une branche de version avec les pull requests fusionnées dans l'ordre et un pull request de version. Il pousse une branche et ouvre un pull request, il attend donc toujours l'intervention d'une personne. Exclure prNumbers pour utiliser la sélection de Coroid.

Approbations et politiques d'automatisation#

Approbations est une file d'attente d'actions en attente d'une intervention humaine. Politiques d'automatisation détermine ce qui doit figurer dans cette file d'attente.

C'est le contrôle essentiel. Un client externe agissant en votre nom doit pouvoir effectuer librement les tâches routinières et uniquement avec l'accord d'une personne pour les actions importantes. Définissez les politiques avant de confier un jeton à tout élément fonctionnant en autonomie.

Lorsqu'un appel nécessite une approbation, le client reçoit un identifiant d'approbation et un lien au lieu d'un résultat. Un propriétaire ou administrateur examine l'outil et les arguments exacts, puis approuve ou rejette l'appel. L'approbation exécute l'appel tel qu'il a été formulé, et le client ne peut pas le modifier ensuite. Un appel non approuvé dans les 10 minutes expire.

Une politique d'automatisation permet à un jeton d'accès d'exécuter les outils marqués Policy sans attendre d'approbation. Seuls les propriétaires créent des politiques et les associent aux jetons. Une politique nomme les outils exacts, peut être limitée à certains projets et fixe le nombre maximal d'appels par heure, par jour et simultanément. Elle peut également expirer. Révoquer une politique révoque tous les jetons associés. Les outils marqués Toujours ne sont jamais couverts par une politique.

Une connexion OAuth ne peut pas porter de politique. Via OAuth, tout outil marqué Policy attend une approbation.

Tentatives, opérations et ressources#

Chaque outil modifiant quelque chose requiert ce paramètre : idempotencyKey. Utilisez une nouvelle clé pour chaque nouvelle action et la même clé lors d'une nouvelle tentative. Coroid renverra alors le premier résultat au lieu d'agir deux fois. Une clé réutilisée avec des arguments différents sera refusée.

Une modification renvoie également une opération qui enregistre son statut et son résultat. Ces quatre outils fonctionnent pour toute connexion :

Le serveur fournit également ces ressources :

Il propose également trois invites : create_and_run_task, investigate_failure, prepare_release.

Chaque outil possède des limites par minute, par heure et par jour. Un appel dépassant ces limites échoue et indique le temps d'attente avant une nouvelle tentative.

Ce qui n'est pas exposé intentionnellement#

Le registre d'outils est géré et les exclusions sont volontaires. Il ne fournit aucun de ces éléments :

• un shell
• Accès Git
• le système de fichiers
• accès brut à la base de données
• HTTP interne arbitraire
• Les propres outils d'administration MCP sortants de Coroid

Vous pourrez désormais gérer le travail — créer et consulter les tâches, plans, projets et versions — ce n'est pas un environnement d'exécution à distance. Un client MCP ne peut pas utiliser Coroid pour exécuter des commandes arbitraires.

À quoi cela sert-il ?#

Utiliser Coroid depuis l'endroit où vous travaillez déjà — un éditeur, un assistant, un outil interne — sans avoir à basculer vers le portail. Créer une tâche depuis votre terminal ou demander à un assistant de vérifier ce qui est bloqué devient une action locale.

Articles associés#

• Comment commencer à travailler
• Exporter et importer les paramètres
• Serveurs MCP externes
• Assistant Chat
• Provenance