MCP & jetons d'accès

Le serveur MCP Pierrr

Pierrr expose un serveur Model Context Protocol (MCP) distant. Vous y branchez un client IA pour piloter vos projets, déploiements, domaines et secrets en langage naturel. Les clients compatibles incluent notamment :

• Claude (Desktop ou web)
• ChatGPT
• Cursor
• Gemini, et tout autre client qui supporte un serveur MCP distant.

Se connecter en autorisant le client dans le navigateur

Avec un client qui le permet, vous n'avez aucun jeton à copier : indiquez seulement l'URL du serveur MCP. Le client ouvre une page Pierrr dans votre navigateur, où vous êtes déjà connecté, et vous y choisissez ce qu'il pourra faire.

Le déroulé :

1. Ajoutez le serveur MCP dans votre client avec l'URL ci-dessous, sans en-tête Authorization.
2. Le client ouvre la page d'autorisation de Pierrr. Connectez-vous si besoin : aucun mot de passe n'est redemandé si votre session est ouverte.
3. Vérifiez le nom de l'application, marqué « non vérifié » puisque c'est elle qui le déclare, et l'adresse à laquelle la réponse est envoyée. N'autorisez que ce que vous venez de lancer vous-même.
4. Choisissez l'organisation et les permissions, puis Autoriser. Les permissions sont plafonnées à votre rôle, et la révélation des valeurs de variables n'est jamais cochée d'office.
5. Le client reçoit un accès de courte durée qu'il renouvelle seul. Refuser le renvoie sans aucun accès.

Dans un fichier de configuration JSON, l'URL suffit :

{
  "mcpServers": {
    "pier": {
      "url": "https://api.pierrr.com/mcp"
    }
  }
}

Une autorisation vaut pour une seule organisation. Pour en piloter plusieurs depuis le même client, utilisez des jetons d'accès collés, décrits ci-dessous.

Applications connectées

Les clients autorisés depuis le navigateur apparaissent dans Paramètres, Jetons d'accès, section Applications connectées, avec leurs permissions et leur dernière utilisation. Le bouton Déconnecter coupe leur accès immédiatement : le client devra redemander une autorisation.

Si le même accès de renouvellement est présenté deux fois, Pierrr considère qu'il a fuité et coupe la connexion correspondante. Le client redemande alors une autorisation.

Créer un jeton d'accès personnel

L'autre façon de s'authentifier au serveur MCP est un jeton d'accès personnel (PAT) que vous créez dans le dashboard et collez dans la configuration du client. Ce jeton remplace votre mot de passe pour les accès programmatiques.

Pas à pas

1. Ouvrez le dashboard, puis Paramètres, puis Jetons d'accès (/settings/tokens).
2. Cliquez sur Nouveau jeton, donnez-lui un nom parlant (par exemple « Claude Desktop »), puis validez avec Créer le jeton.
3. Copiez le jeton affiché dans la fenêtre Jeton créé, conservez-le dans un endroit sûr, puis cliquez sur Terminé.
4. Collez-le dans la configuration de votre client IA (voir la section suivante).

Le jeton n'est affiché qu'une seule fois, à la création. Si vous le perdez, révoquez-le et créez-en un nouveau.

À la création, un jeton reçoit par défaut toutes les permissions de votre rôle, sauf la révélation des valeurs de variables. Décochez Accès complet pour choisir un sous-ensemble parmi 16 permissions : lire les projets, gérer les projets, gérer les conteneurs, lire les domaines, gérer les domaines, associer les domaines, lire les serveurs, redémarrer les serveurs, provisionner les serveurs, lire les déploiements, notifications, facturation, lire les dépôts, gérer l'organisation, gérer les membres, accéder aux bases de données.

La case Autoriser la révélation des valeurs de variables est décochée par défaut. Sans elle, un assistant branché avec ce jeton peut lister, créer ou modifier des variables, mais jamais lire une valeur en clair. Cochez-la seulement si vous en avez besoin.

Tout nouveau jeton expire. La date proposée est dans 90 jours ; vous pouvez en choisir une autre. Les jetons créés avant cette règle gardent leur date, ou l'absence de date : révoquez-les et recréez-les si vous voulez qu'ils expirent.

La liste des jetons indique pour chacun son état (Actif, Expiré, Révoqué), sa date de création, sa date d'expiration et sa dernière utilisation (ou Jamais utilisé).

La page affiche aussi l'URL de connexion MCP avec un bouton Copier : copiez-la de là plutôt que de la reconstruire.

Les permissions du jeton sont bornées à votre rôle dans l'organisation : un jeton ne peut jamais faire plus que ce que vous pouvez faire vous-même dans la console.

Un jeton peut aussi être restreint à un ou plusieurs projets de son organisation. Laissez tous les projets sélectionnés (le réglage par défaut) pour un jeton qui couvre toute l'organisation ; choisissez un sous-ensemble et il sera refusé sur tout autre projet, lectures comprises, partout où il est utilisé.

Brancher un client MCP

Renseignez ces trois informations dans la configuration MCP de votre client :

• URL : https://api.pierrr.com/mcp
• Transport : Streamable HTTP.
• En-tête : Authorization, valeur Bearer suivi d'un espace et de votre jeton d'accès. Inutile si votre client se connecte en l'autorisant dans le navigateur.

C'est l'URL du hub Pierrr hébergé, identique pour tous les clients. Si vous opérez votre propre instance Pierrr (self-hosted), utilisez l'API de votre domaine : https://api.votre-domaine.com/mcp.

Exemple de configuration

La plupart des clients acceptent un fichier de configuration JSON de cette forme :

{
  "mcpServers": {
    "pier": {
      "url": "https://api.pierrr.com/mcp",
      "headers": {
        "Authorization": "Bearer pier_pat_xxxxxxxxxxxxxxxx"
      }
    }
  }
}

Remplacez le jeton d'exemple par le vôtre (créé à l'étape précédente). L'URL est déjà celle de votre hub.

Plusieurs organisations

Un jeton d'accès unique autorise une seule organisation. Si vous en gérez plusieurs, listez plusieurs jetons d'accès personnels séparés par des virgules dans l'en-tête Authorization, un par organisation, tous créés par le même utilisateur :

{
  "mcpServers": {
    "pier": {
      "url": "https://api.pierrr.com/mcp",
      "headers": {
        "Authorization": "Bearer pier_pat_orgA_xxxxxxxx,pier_pat_orgB_yyyyyyyy"
      }
    }
  }
}

La fenêtre Nouveau jeton peut construire cela pour vous : activez Plusieurs organisations, choisissez celles que le connecteur doit couvrir et, pour chacune, tous ses projets ou seulement certains, puis Créer le jeton renvoie directement la valeur combinée déjà assemblée, avec la couverture de chaque organisation listée en dessous pour vérifier avant de copier.

Tous les jetons de la liste doivent vous appartenir. Dans le cas contraire, la connexion est refusée.

Avec un jeton multi-organisation, chaque appel d'outil doit préciser l'organisation ciblée en ajoutant l'un de ces arguments :

• organizationId : l'identifiant de l'organisation.
• organizationSlug : l'identifiant court de l'organisation (celui qui figure dans ses adresses), en alternative à l'identifiant.

Si un appel d'outil omet le sélecteur, ou désigne une organisation non couverte par le jeton, le serveur renvoie une erreur claire listant les organisations disponibles pour ce jeton, afin que votre client IA puisse vous demander d'en choisir une au lieu d'échouer silencieusement.

Capacités

Tout est limité à l'organisation du jeton et respecte vos permissions. Les capacités se répartissent en lectures et en actions.

Lecture

• Lister et inspecter vos projets et leurs conteneurs.
• Consulter l'historique, le détail et les logs des déploiements.
• Lister vos domaines personnalisés et leur statut.
• Lister vos serveurs (Pierrr Agent) et leur état.
• Lister les variables d'environnement, sans jamais leur valeur.
• Consulter votre usage et vos quotas de facturation.
• Lister les factures passées, paginées.
• Lister les notifications et consulter le nombre de non-lues.
• Lister les sauvegardes de données récentes et les exports de projet Pierrr.
• Lister les volumes d'un projet et leurs montages sur les conteneurs.
• Lister vos instances d'add-on Redis et leurs projets liés.
• Lister les groupes réseau d'un projet.
• Lister les conteneurs d'un projet et les dépôts qui leur sont liés, ou créer une application.
• Consulter l'historique des analyses de sécurité d'un projet et leurs résultats.
• Lister les membres de l'organisation et les invitations en attente.
• Consulter l'état de l'installation GitHub et lister les dépôts GitHub accessibles (les projets GitLab ne sont pas pilotables par MCP).
• Lister vos jetons d'accès personnels.

Lectures détaillées, par domaine

Tous les outils de cette liste sont des lectures : ils ne modifient rien, et votre client peut les autoriser sans vous demander. Entre parenthèses, la permission que le jeton doit porter.

• Projets et conteneurs, lecture (Lire les projets) : logs d'exécution récents d'un projet ou d'un seul conteneur, 500 lignes au plus, secrets reconnaissables masqués ; processeur et mémoire de la dernière heure avec le budget du projet ; limites de ressources d'un conteneur ; règle de mise à l'échelle automatique ; ports TCP publics ; extensions de base de données ; façon dont les variables d'environnement atteignent les conteneurs.
• Déploiements, lecture (Lire les déploiements et Lire les projets) : détail d'un déploiement, avec ses tentatives et leurs étapes.
• Avant un déploiement, lecture (Gérer les conteneurs) : derniers commits de la branche déployée, pour choisir une version précise ; vérification des variables qu'un conteneur recevra, par leur nom uniquement, jamais leur valeur.
• Sauvegardes et sécurité, lecture (Lire les projets) : planification des sauvegardes automatiques, planification des analyses de sécurité, détail d'une analyse.
• Serveurs, lecture (Lire les serveurs) : historique de santé d'un serveur, projets qu'il héberge, journal des commandes qu'il a reçues et de leur résultat.
• Organisation, lecture (Lire les projets) : vue d'ensemble (projets, conteneurs, domaines, serveurs) ; historique de santé quotidien de l'organisation ou d'un projet ; frameworks disponibles et modèles de Dockerfile fournis.
• Notifications, lecture (Notifications) : abonnements aux notifications de l'organisation.
• Facturation, lecture (Facturation) : offre et abonnement en cours, catalogue des offres, options disponibles et options actives, aperçu du coût d'un changement d'offre, instances de stockage objet et leurs projets, sans jamais leurs identifiants d'accès. Le paiement et le changement d'offre lui-même restent dans la console.
• Dépôts, lecture (Lire les dépôts) : branches d'un dépôt connecté, dossiers d'une branche, présence d'un Dockerfile et framework déclaré dans un dossier.
• Sites WordPress, lecture (Gérer les conteneurs) : sites de l'organisation, leur état d'installation, leur adresse, l'identifiant de connexion de l'administrateur et la dernière erreur.
• Migrations depuis un autre hébergeur, lecture (Gérer les projets) : migrations de l'organisation, leur état, leur analyse (variables par leur nom seulement, domaines, points à corriger) et leur rapport ; comptes que la connexion faite dans la console atteint chez l'autre hébergeur.

Actions

• Déclencher un déploiement.
• Redémarrer, démarrer, arrêter, builder ou supprimer une application.
• Démarrer ou arrêter toutes les applications d'un projet d'un coup (scale), ou régler le nombre de réplicas d'une application.
• Créer un domaine.
• Définir une variable d'environnement.
• Marquer une ou toutes les notifications comme lues.
• Lancer une sauvegarde de données pour un projet, ou en restaurer une sur son application.
• Créer un export de projet Pierrr.
• Monter ou démonter un volume sur une application.
• Lier ou délier un projet à une instance d'add-on Redis.
• Créer ou supprimer un groupe réseau.
• Créer un projet, le renommer, et y créer un conteneur.
• Sonder un domaine, le lier ou le délier d'un service, resynchroniser sa configuration.
• Modifier ou supprimer une variable, appliquer un bloc .env d'un coup, gérer les liaisons par conteneur, et révéler une valeur si le jeton y a été autorisé.
• Lancer une analyse de sécurité sur un projet.
• Inviter un membre dans l'organisation, ou renvoyer une invitation en attente.
• Resynchroniser la liste des dépôts accessibles via l'installation GitHub.
• Demander un instantané de santé à un serveur, ou vérifier si une mise à jour de l'agent est disponible.

Actions détaillées, par domaine

Chaque outil de cette liste modifie quelque chose. « modifie » : l'action se refait ou se corrige sans perte. « destructif » : elle supprime ou coupe quelque chose, et le serveur la refuse sans confirm: true. Entre parenthèses, la permission que le jeton doit porter, la même que pour l'action équivalente dans la console.

• Cycle de vie, modifie (Gérer les conteneurs) : annuler un déploiement en attente ou en cours ; redémarrer toutes les applications d'un projet ; réveiller un projet Free mis en veille après 30 jours sans activité ; builder une application depuis un commit précis plutôt que depuis le dernier de sa branche, ce qui permet aussi de revenir à une version antérieure.
• Mise à l'échelle automatique, modifie (Gérer les conteneurs) : créer, remplacer ou couper la règle d'une application ; ses réglages sont gardés quand elle est coupée.
• Projets et applications, modifie (Gérer les projets) : choisir où tourne un projet, sur Pierrr ou sur l'un de vos serveurs ; renommer une application ; changer ses limites et réservations de processeur et de mémoire ; changer ses réglages de build (branche, déploiement automatique, chemins, commandes, chemin de vérification de santé) ; ouvrir un port TCP public.
• Données et réseau, modifie (Gérer les projets) : donner à une application l'accès à la base de données, au cache ou au stockage objet du projet ; activer une extension de base de données ; modifier un groupe réseau (destructif : changer sa liste d'applications en retire celles qui n'y sont plus) ou réappliquer la configuration réseau sur le serveur ; planifier les sauvegardes automatiques et les analyses de sécurité.
• Stockage objet, modifie (Facturation) : lier un projet à l'une de vos instances de stockage objet.
• Serveurs, modifie (Provisionner les serveurs) : renommer un serveur.
• Sites WordPress, modifie (Gérer les projets) : créer un site dans un projet existant ou dans un projet à lui, sur Pierrr ou sur l'un de vos serveurs. Le mot de passe de l'administrateur n'est rendu qu'une fois, dans la réponse, comme dans la console.
• Migrations depuis un autre hébergeur, modifie (Gérer les projets) : choisir un compte et lister ses projets, analyser un projet, créer sur Pierrr les domaines de l'application importée et lier ceux qui pointent déjà ici, clore une migration importée.
• Projets, destructif (Gérer les projets) : supprimer un projet avec toutes ses applications, sa base de données et ses données ; fermer un port TCP ; changer la façon dont les variables atteignent les conteneurs, ce qui efface les liaisons faites conteneur par conteneur ; retirer à une application l'accès à la base de données, au cache ou au stockage objet ; désactiver une extension de base de données.
• Domaines, destructif (Gérer les domaines) : supprimer un domaine et toutes ses liaisons ; les sites cessent de répondre dessus.
• Stockage objet, destructif (Facturation) : délier un projet d'une instance.
• Mise à jour d'un serveur, destructif (Redémarrer les serveurs) : mettre à jour l'agent d'un serveur vers la dernière version publiée ; il redémarre.
• Serveurs, destructif (Provisionner les serveurs) : révoquer un serveur, qui ne pourra plus se reconnecter avec ses identifiants actuels ; le retirer de la liste.
• Invitations, destructif (Gérer les membres) : révoquer une invitation en attente ; son lien cesse de fonctionner.
• Migrations, destructif (Gérer les projets) : lancer l'import, avec un aperçu par défaut (variables reprises et laissées de côté, points bloquants) ; copier la base de données en remplaçant une base qui contient déjà des données ; annuler une migration, qui ne pourra pas reprendre.
• Organisation, destructif (Gérer l'organisation) : renommer l'organisation, avec un aperçu par défaut. Quand son identifiant change, toutes les applications sont recréées sous le nouveau et les adresses fournies par Pierrr changent avec lui ; vos domaines personnalisés restent.

Prévisualiser avant d'agir

Chaque action qui touche vos serveurs ou recrée quelque chose a dryRun: true par défaut : redémarrer, démarrer, arrêter, builder ou supprimer une application, mettre à l'échelle, redémarrer ou supprimer un projet, renommer l'organisation, importer une migration. L'outil décrit ce qu'il ferait sans rien toucher, par exemple les applications et la base de données qu'une suppression de projet emporterait ; le client doit explicitement passer dryRun: false pour l'exécuter réellement.

Les actions destructrices exigent en plus confirm: true, même avec dryRun: false : supprimer une application ou un projet, renommer un projet (son identifiant et ses adresses suivent le nouveau nom), restaurer une sauvegarde, supprimer une variable, appliquer un bloc .env qui supprime des variables (lignes !CLE), remplacer les variables liées à un conteneur, changer la façon dont les variables atteignent les conteneurs, délier ou supprimer un domaine, démonter un volume, supprimer un groupe réseau ou changer la liste de ses applications, délier un projet d'une instance Redis ou de stockage objet, retirer à une application l'accès à la base, au cache ou au stockage, fermer un port TCP, désactiver une extension de base de données, mettre à jour, révoquer ou supprimer un serveur, révoquer une invitation, renommer l'organisation, importer ou annuler une migration, copier une base de données en remplaçant celle qui existe. Sans ça, l'appel est rejeté et le message indique quoi faire.

Pour une action destructrice qui a un aperçu (supprimer une application ou un projet, renommer l'organisation, importer une migration), confirm: true ne suffit plus : l'aperçu renvoie un jeton de confirmation, valable 5 minutes et une seule fois, lié à votre jeton d'accès, à l'outil et aux arguments exacts de l'aperçu. L'appel réel doit le rapporter, avec les mêmes arguments, dryRun: false et confirm: true ; un argument différent l'invalide. Un assistant qui appelait directement ces outils avec confirm: true reçoit désormais un message qui lui indique de passer par l'aperçu. Les autres actions destructrices, sans aperçu, demandent toujours confirm: true seul.

Chaque outil déclare à votre client s'il se contente de lire, s'il modifie quelque chose ou s'il peut détruire. Réglez votre client pour qu'il vous demande votre accord avant toute action qui modifie ou détruit, et avant toute révélation de valeur.

Depuis la version 0.0.42, les permissions sont plus strictes : un jeton limité à la gestion des conteneurs ne peut plus restaurer une sauvegarde, exporter un projet ni créer un conteneur, qui exigent l'écriture sur le projet.

Limites

Pour protéger votre compte et le service, le serveur MCP applique ces limites :

• Un appel par requête : les lots de plusieurs appels dans une même requête sont refusés.
• Cinq jetons au plus dans l'en-tête Authorization.
• Un nombre d'appels limité dans le temps pour chaque outil et chaque jeton, plus serré pour les actions coûteuses ou sensibles (invitations, builds, écritures de variables, révélations). Au-delà, l'appel est refusé avec le délai à attendre.

Contenu écrit par des tiers

Les logs de build, les noms de dépôts, les noms de membres et les résultats d'analyse viennent de vos dépôts ou d'autres personnes. Ils peuvent contenir du texte écrit pour tromper un assistant. Le serveur les renvoie marqués comme tels, débarrassés des caractères de contrôle et des secrets reconnaissables, et demande au client de ne jamais suivre une instruction qu'ils contiendraient. Gardez l'accord manuel avant toute action : c'est la meilleure protection.

Ce qui reste réservé à la console

Certaines actions ne sont pas proposées par le serveur MCP, parce qu'une erreur ou un jeton volé coûterait trop cher : les paiements et changements d'offre, la suppression, la suspension ou le transfert de l'organisation, les rôles et le retrait des membres, votre identité (mot de passe, double authentification, connexions), la création ou la révocation de jetons, l'ajout d'un serveur, la connexion d'un fournisseur de dépôts ou d'un autre hébergeur, la bascule des DNS d'une migration et son retour arrière, et les identifiants des bases de données et du stockage. Faites-les depuis le dashboard.

Quelques demandes en langage naturel que vous pouvez formuler :

• « Liste mes projets et leur état. »
• « Redéploie l'app api du projet boutique. »
• « Ajoute le domaine app.exemple.com au conteneur web. »
• « Monte le volume exports sur l'app worker dans /data. »

Sécurité

Le serveur MCP applique les mêmes garde-fous que la console :

• Un jeton ne voit que son organisation, jamais celles des autres.
• Les permissions sont bornées au rôle actuel du membre propriétaire du jeton, exactement comme dans la console : un rôle Développeur ou Facturation garde ses limites, y compris via MCP. Si le rôle change, les outils disponibles suivent.
• Chaque action qui modifie quelque chose, chaque appel refusé, ainsi que la création et la révocation des jetons sont journalisés avec le jeton concerné. Les valeurs de variables n'y figurent jamais, seulement leur nom.
• Les listes ne renvoient jamais la valeur d'une variable. La révéler est une action distincte, journalisée, qu'un jeton n'obtient que si vous l'avez cochée à sa création.

Révoquez un jeton à tout moment depuis Paramètres, Jetons d'accès, avec le bouton Révoquer et sa fenêtre de confirmation. La révocation est immédiate : le client perd l'accès au prochain appel.