MCP connecte Claude Code, Codex et les IDE au contexte projet. Comprenez les transports, les permissions et le premier test à réaliser avant une mission.
Dernière relecture le 3 octobre 2026
MCP (Model Context Protocol) permet à un outil de code IA de découvrir et d’appeler les outils d’un service externe. Claude Code ou Codex peut ainsi retrouver les critères d’une carte et les décisions du projet pendant une session de code, au lieu de travailler à partir d’un contexte copié manuellement.
Un assistant de code peut alors devenir un agent qui lit une issue, consulte des erreurs de production, retrouve des décisions projet, met à jour le delivery et renvoie des preuves, sans intégration spécifique pour chaque client.
MCP ne rend pas tous les clients équivalents. Il ne sécurise pas un serveur non fiable. Et il ne remplace ni les permissions, ni les approbations, ni l’observabilité, ni une API produit bien conçue.
Les explications sur la connexion, les configurations Claude Code/Codex et le parcours Stellary ont été revérifiés le 3 octobre 2026. Les références Cursor, VS Code et GitHub conservent leur revue du 1er septembre. Le hub MCP rassemble le journal des changements et les intégrations.
L’architecture officielle de MCP repose sur un modèle client-serveur :
Le protocole définit l’initialisation de la connexion, la négociation des capacités, la découverte des primitives, les requêtes et le retour de résultats structurés. Il s’articule actuellement autour de trois primitives serveur :
| Primitive MCP | Ce qu’elle expose | Exemple pour le code |
|---|---|---|
| Tools | Fonctions que le modèle peut appeler | Interroger Sentry, créer une carte projet ou lancer une mission gouvernée |
| Resources | Contexte que le client peut lire | Charger un brief technique, un schéma, un runbook ou une décision projet |
| Prompts | Modèles d’interaction réutilisables | Démarrer une revue de release ou un triage d’incident |
MCP définit aussi les transports. Les serveurs locaux utilisent souvent stdio, tandis que les services distants utilisent généralement Streamable HTTP. La négociation des capacités évite qu’un client tente d’utiliser une fonction absente d’un serveur.
Premier changement concret : un outil IA découvre les capacités du serveur au lieu de dépendre d’un long prompt qui décrit informellement une intégration.
| Besoin | Connexion à choisir | Ce que cela implique |
|---|---|---|
| Lire les cartes et documents pendant une session Claude Code ou Codex | Client connecté au serveur MCP distant | Le projet reste hébergé ; le client appelle les outils autorisés |
| Lancer une mission de code depuis une carte Stellary | Desktop connecté au dépôt local | La machine exécute la CLI dans le dossier lié au projet |
| Faire tourner l’inférence sur votre machine | Un moteur et un modèle locaux compatibles | À vérifier séparément du client MCP et du dossier d’exécution |
Un serveur MCP distant ne donne pas automatiquement accès à vos fichiers locaux. Une CLI exécutée sur votre machine peut utiliser un modèle hébergé chez un fournisseur. Vérifiez donc la connexion au projet, le lieu d’exécution du code et le fournisseur du modèle séparément.
Pour configurer le client, suivez le guide Claude Code ou le guide Codex. Ils distinguent OAuth, le jeton MCP et le parcours Desktop.
Prenons la demande : « Corrige la régression de checkout signalée dans notre board de delivery. »
Sans systèmes connectés, le développeur ou l’agent doit réunir manuellement l’issue, la release concernée, les logs, les décisions d’architecture et les critères d’acceptation. L’outil peut produire un patch plausible tout en ignorant le contexte opérationnel.
Avec des serveurs MCP bien conçus, le workflow peut devenir :
Toutes les étapes n’ont pas besoin de MCP. L’édition du dépôt et le terminal peuvent rester des capacités natives du client. MCP sert de couche de connexion vers le contexte et les actions externes.
Le support est assez large pour faire de MCP un vrai critère d’achat, mais les implémentations diffèrent.
| Client | Rôle MCP documenté | À vérifier avant déploiement |
|---|---|---|
| Cursor | Connecte outils et données externes par des serveurs locaux ou distants | Primitives, transport, authentification et configuration du workspace |
| Claude Code | Connecte les sessions de code aux outils et données externes | Portée de configuration, permissions, limites de sortie et confiance du serveur |
| Codex | Connecte les sessions aux serveurs MCP, avec OAuth ou un jeton fourni par l’environnement | Serveur actif, identité, accès au projet et outils disponibles |
| Visual Studio Code | Ajoute tools, resources, prompts et interactions aux workflows agentiques | Demandes de confiance, politiques d’organisation, sandbox et outils activés |
| GitHub Copilot | Rend les serveurs configurés accessibles aux surfaces Copilot compatibles | Politiques du dépôt, accès cloud, secrets et listes d’outils autorisés |
| Stellary | Expose contexte projet, actions de board, signaux cockpit, missions d’agents et outils de plugins via Streamable HTTP | Identité humaine ou agent, autonomie, approbations et périmètre du workspace |
« Compatible MCP » ne signifie pas que tous les clients proposent les mêmes primitives, transports, flux d’authentification ou expériences d’approbation.
Ce scénario sert à vérifier une connexion, sans modifier le projet :
stellary_init, puis list_projects et les outils de lecture de la carte avec les identifiants retournés.La configuration enregistrée, la lecture réussie et la mission terminée sont trois résultats différents. Une réponse 401 invite à reconnecter l’identité ; une réponse 403 demande de vérifier les permissions et l’accès au projet. Les guides d’intégration détaillent ces contrôles.
Un prompt contient un instantané. Une resource ou un tool MCP peut récupérer l’état actuel d’un projet, incident, document ou service au moment où l’agent en a besoin.
Cela réduit le copier-coller et aide à ancrer le modèle dans la source de vérité. Le serveur doit toutefois rester ciblé : trop de contexte non filtré peut dégrader le résultat.
Un serveur peut exposer la même surface protocolaire à plusieurs hôtes compatibles. Il devient moins nécessaire de reconstruire une intégration par éditeur ou agent.
La portabilité reste relative. Les clients diffèrent sur la configuration, les fonctions prises en charge, les confirmations, le sampling et la présentation des résultats.
Le travail de code ne s’arrête pas à un fichier modifié. Il faut aussi lire des tickets, inspecter des déploiements, mettre à jour la documentation, demander une revue et communiquer le statut.
MCP fournit une manière standard de franchir ces frontières. Dans Stellary, un agent externe peut par exemple réclamer une mission en attente via le serveur MCP, lire le contexte des cartes et documents, exécuter les outils permis, puis terminer ou faire échouer la mission tout en synchronisant le board.
Un serveur peut exposer des outils plus étroits qu’un token API généraliste ou qu’un shell sans limite. Le produit peut appliquer identité, périmètre du workspace, politique d’autonomie et règles d’approbation avant qu’une écriture atteigne la source de vérité.
Cette protection est plus robuste qu’une consigne de sécurité cachée dans un prompt système. L’application doit être faite par le serveur et la couche de politique produit.
MCP ne fournit pas automatiquement :
Le protocole définit l’échange des capacités. Le serveur décide ce qu’un outil peut faire, le client décide comment le présenter et l’appeler, et le produit sous-jacent reste responsable de l’autorisation et de l’intégrité des données.
La documentation officielle propose un modèle d’autorisation MCP pour les serveurs distants protégés et recommande HTTPS, des scopes minimaux, un stockage sûr des tokens et l’absence de credentials dans les logs.
Vérifiez :
Ne notez pas un produit sur un simple « MCP : oui ou non ». Rejouez un vrai workflow et contrôlez le chemin complet.
Le client retrouve-t-il le vrai brief, l’état actuel des cartes, les décisions et la documentation pertinente sans saturer le contexte ?
Les noms et descriptions rendent-ils l’usage évident ? Les entrées sont-elles typées et bornées ? Une écriture renvoie-t-elle un identifiant stable et un résultat clair ?
Pouvez-vous distinguer un humain d’un agent de service et limiter ce dernier à un projet et quelques outils ?
Les lectures peuvent-elles s’exécuter directement tandis que les écritures importantes deviennent des propositions ? L’approbation est-elle appliquée dans le produit ?
Que se passe-t-il lors d’un timeout, d’un token expiré, d’une ressource absente ou d’un retry ? Une intégration crédible renvoie une erreur exploitable plutôt qu’un succès partiel silencieux.
Un reviewer voit-il les outils exécutés, les enregistrements modifiés et les tests qui soutiennent le résultat ?
Testez configuration, authentification, découverte et approbations dans chaque client visé. Ne supposez pas un comportement identique.
Commence par un workflow étroit et surtout en lecture :
Un bon premier cas d’usage est la préparation d’une release : lire le périmètre livré, collecter les blocages ouverts, inspecter la documentation concernée et rédiger une note de release. Un humain vérifie les preuves avant qu’un statut ou un message externe ne soit écrit.
Un mauvais premier cas d’usage est un agent autonome avec un accès à tout le workspace, des envois de messages externes, des identifiants de production et aucune trace d’audit durable.
Utilisez MCP lorsqu’un client IA doit découvrir du contexte et choisir dynamiquement ses outils. Utilisez une API REST lorsqu’un logiciel a besoin d’un endpoint déterministe et d’un flux explicite.
De nombreux produits sérieux ont besoin des deux :
Les deux surfaces doivent partager les mêmes règles d’autorisation et la même source de vérité. Stellary documente cette séparation dans ses références MCP et API REST.
MCP est passé d’un pattern d’intégration intéressant à une composante pratique de la stack de code IA.
Sa vraie valeur n’est pas « plus d’outils », mais un contrat plus clair entre un client IA et les systèmes qui contiennent le contexte projet et les actions opérationnelles.
Les meilleures intégrations MCP en 2026 ont cinq qualités :
Si ces fondations manquent, MCP ne fait que standardiser une intégration faible. Si elles sont présentes, il aide les agents de code à travailler entre dépôt, système projet, documentation et delivery sans perdre le contrôle.
Model Context Protocol est un protocole ouvert qui permet à un hôte de code IA de se connecter à des serveurs externes, de découvrir leurs capacités, de lire des ressources contextuelles et d’appeler des outils dans un échange client-serveur standard.
Oui, si un serveur connecté expose un outil d’édition. En pratique, de nombreux clients modifient le dépôt avec leurs outils natifs et utilisent MCP pour les systèmes externes : boards projet, documentation, suivi d’erreurs, bases de données ou déploiements.
Non. Une équipe doit toujours utiliser des serveurs de confiance, des identités fortes, des scopes minimaux, des credentials protégés, des règles d’approbation, des défenses contre l’injection de prompt et des résultats auditables.
Souvent les deux. REST convient aux intégrations logicielles déterministes et au provisioning ; MCP aux clients IA qui découvrent dynamiquement du contexte et des outils. Les deux doivent appliquer les mêmes permissions et règles produit.
Dix serveurs MCP qui ont leur place dans une configuration Claude Code — dépôt, docs, navigateur, base de données, outil projet — et l’ordre pour les ajouter.
MCP ou API REST pour un agent IA ? Choisissez selon qui décide de l’opération : le code, le modèle, ou les deux dans une architecture hybride.
Connectez Cursor, Claude Code, Claude Desktop ou un agent externe à Stellary via MCP, avec le bon endpoint, la bonne identité et les permissions adaptées.
Comprendre l'architecture MCP, les tools, les resources, les transports, les permissions et les limites de compatibilité avant de connecter une IA à vos outils.
Stellary réunit ton board, tes docs et tes agents IA dans un seul centre de commande.