AI Extensions : GitHub MCP Server 1.13.0 ajoute des outils pour masquer les commentaires
Un serveur MCP capable de masquer une revue de pull request ne se contente plus de lire votre dépôt.
Un serveur MCP capable de masquer une revue de pull request ne se contente plus de lire votre dépôt. GitHub MCP Server 1.13.0, publié le 1er octobre, ajoute ce genre de capacité d’écriture : bon moment pour vérifier comment s’articulent jeux d’outils, mode lecture seule et mode lockdown.
En bref
Projet officiel : github/github-mcp-server, licence MIT. La version v1.13.0 ajoute des outils fins pour masquer et rétablir les commentaires d’issues, les commentaires de PR et les revues de PR, et retire le drapeau qui bloquait l’interface MCP Apps sur le serveur distant. Observé le 2 octobre : 33 324 étoiles, 5 070 forks, dernier push à 10:48:50 UTC. Les étoiles mesurent l’attention, pas la qualité ni la sécurité. J’ai examiné le projet sur GitHub sans l’installer ni l’exécuter. ↗
Ce qui change dans 1.13.0
La version a été publiée le 1er octobre à 19:11:31 UTC. Le journal liste les outils de masquage et de rétablissement, un correctif qui conserve les agents utilisateurs versionnés de l’API STDIO entre protocoles MCP, des révisions source pour les builds Docker hors version et l’activation permanente de MCP Apps UI. La pull request décrit une paire d’outils par type d’objet, des mutations GraphQL minimize, un classificateur obligatoire comme SPAM ou OFF_TOPIC au masquage, et les drapeaux issues_granular et pull_requests_granular. ↗
Avant d’installer : réglages, licence, activité
Le README documente un serveur distant hébergé par GitHub avec OAuth ou un jeton d’accès personnel, et un serveur local via Docker (image ghcr.io/github/github-mcp-server) ou en binaire. Le fichier LICENSE est MIT. Versions récentes : v1.12.2 le 16 septembre et v1.13.0 le 1er octobre, donc maintenance active. Les étoiles et forks du 2 octobre signalent de l’intérêt, rien de plus. Pour un premier essai, je fixerais la version, utiliserais un jeton ou une portée OAuth limités à un dépôt jetable et noterais exactement les jeux d’outils activés. ↗
Où passent les lignes de permission
Le README indique que les jeux d’outils se choisissent avec --toolsets et que le mode lecture seule est prioritaire : les outils d’écriture sont ignorés avec --read-only, même demandés via --tools. Le lockdown est décrit comme un filtre au mieux sur le contenu de dépôts publics écrit par des auteurs sans droit de push, pour réduire le risque d’injection de prompt, et explicitement pas une frontière d’autorisation. Mon analyse : la lecture seule contrôle ce que le serveur propose, le lockdown une partie de ce qu’il renvoie, et le jeton ce que GitHub acceptera. Le texte d’un dépôt reste une entrée non fiable pour le modèle. Un nouvel outil d’écriture mérite une décision délibérée, pas une mise à jour par défaut.
Une liste de contrôle que j’ai écrite
Le code ci-dessous est une comptabilité exécutée en local avec des noms d’outils inventés. Il filtre une liste de revue par préfixe de nom pour montrer ce qu’un plan en lecture seule écarterait. Le serveur n’applique rien ainsi : testez le vrai drapeau --read-only sur un dépôt jetable et vérifiez que les outils de masquage ne sont pas proposés.
Vérification synthétique originale
write_prefixes = ("hide_", "unhide_", "create_", "update_", "merge_", "delete_")
tools = ["get_issue", "list_issues", "hide_issue_comment", "unhide_issue_comment"]
read_only = [t for t in tools if not t.startswith(write_prefixes)]
assert read_only == ["get_issue", "list_issues"]
print("kept in a read-only plan:", read_only)
# Name-prefix bookkeeping for a review list. The server's --read-only flag,
# not this script, is the control to test.