Présentation du MCP

Pathrule parle le Model Context Protocol. C'est ce protocole que votre assistant de codage IA utilise pour appeler des outils externes et lire un état externe. Pathrule se présente à l'assistant comme un serveur MCP ordinaire : tout client capable de parler MCP peut donc l'utiliser.

Il existe deux façons de se connecter. Le serveur local est fourni avec le CLI Pathrule et l'extension VS Code de Pathrule : l'assistant communique avec lui via stdio et, sur un espace de travail Cloud, le runtime communique avec Pathrule Cloud via HTTPS. Pour les clients qui se connectent à des serveurs hébergés, Remote MCP accepte une connexion directe via Streamable HTTP, avec connexion OAuth et un accès limité à votre espace de travail. Le stdio local et Remote MCP n'ont ni le même catalogue d'outils ni les mêmes schémas. Consultez tools/list sur le serveur connecté. Pathrule n'envoie pas automatiquement le code source de votre dépôt ; les outils locaux d'apprentissage du projet peuvent examiner les fichiers rattachés à un constat pour le valider.

Ce que le serveur expose

La surface MCP de Pathrule est typée et organisée autour du modèle de données. Les outils principaux ci-dessous couvrent les usages courants autour du contexte, du contenu et de l'activité ; la référence des outils en fait l'inventaire de référence.

Le serveur local annonce l'ensemble de ses outils, lecture comme écriture, dès le premier tools/list : rien n'a besoin d'être débloqué avant la première écriture, et la liste ne change pas en cours de session. Un mode lazy, qui retient les outils d'écriture jusqu'à ce qu'ils soient nécessaires, peut être activé sur demande ; voir Contrôle local des écritures en mode lazy.

Outils de lecture

• pathrule_get_context. Le point d'entrée principal. À partir du répertoire de travail courant et de l'intention de l'utilisateur, il renvoie la bonne portion de mémoires, de règles et de skills pour ce chemin. La réponse contient la vue d'ensemble de l'espace de travail, les règles et mémoires qui correspondent déjà, et une indication sur ce qu'il faut lire ensuite.
• pathrule_read_memory, pathrule_read_rule, pathrule_read_skill. Récupèrent le contenu complet d'un nœud précis à partir de son identifiant, lorsque l'assistant veut le citer ou l'appliquer.
• pathrule_get_tree, pathrule_get_node. Examinent la structure de l'espace de travail ou un nœud précis.
• pathrule_list_memories. Énumère les mémoires situées sous un chemin, pratique pour les prompts d'exploration.

Outils d'écriture

• pathrule_write_memory, pathrule_write_rule, pathrule_write_skill. Créent du contenu à un chemin de l'espace de travail. Les nœuds manquants le long du chemin sont créés à la volée.
• pathrule_update_memory, pathrule_update_rule, pathrule_update_skill. Modifient un enregistrement existant. La concurrence optimiste est garantie par un identifiant de version.
• pathrule_delete_memory, pathrule_delete_rule, pathrule_delete_skill. Suppression logique, annulable pendant trente jours.

Activité et maintenance

• pathrule_log_activity. Appelé après chaque réponse qui modifie des fichiers, afin que l'équipe voie ce que l'assistant a fait et où.
• pathrule_goto. Déplace le nœud de travail de l'assistant lorsque l'utilisateur demande du contenu d'une autre portée.
• pathrule_ping. Un contrôle de santé qui confirme que le serveur est bien branché et affiche le répertoire de travail tel que le voit le runtime.

Le rôle des hooks

Sur les clients qui prennent en charge les hooks, ce sont eux qui permettent à Pathrule de garder l'assistant rapide. Au démarrage de la session et autour des appels d'outils, le superviseur de hooks lit une portion mise en cache pour le répertoire de travail courant et la transmet à l'agent comme contexte. Dans le cas courant, on évite ainsi un aller-retour MCP synchrone. Le hook de démarrage de session fournit aussi le protocole Pathrule lui-même : sur un client compatible avec les hooks, le fichier d'instructions de votre dépôt se réduit donc à une courte note.

Tous les clients ne sont pas atteints de la même manière :

• Claude Code et Codex disposent de hooks, dont un hook de soumission de prompt : les connaissances pertinentes arrivent avec chaque prompt, avant que l'agent n'agisse.
• Cursor et GitHub Copilot disposent de hooks de session et d'outils, mais pas de hook de soumission de prompt. Le contexte arrive au démarrage de la session et autour des appels d'outils.
• Windsurf n'a pas de hooks. Il lit un fichier de règles Pathrule au démarrage de la session et s'appuie sur les outils MCP pour tout ce qui va plus loin.

Quand le hook suffit, l'assistant n'a pas besoin d'appeler pathrule_get_context. Il dispose déjà de la bonne portion. Les outils MCP sont réservés à deux cas.

1. L'assistant a besoin de plus que ce que le hook a remonté. Par exemple, un prompt d'exploration qui nécessite le contenu complet d'une mémoire, ou un refactoring qui touche un chemin que le hook n'avait pas anticipé.
2. Quelque chose mérite d'être conservé. L'assistant propose une mémoire, une règle ou un skill et l'écrit une fois que vous avez confirmé, ou bien vous lui demandez directement d'en écrire une. Les écritures passent par les outils d'écriture ; chacune est marquée comme écrite par l'assistant et versionnée, ce qui vous permet de la relire ou de l'annuler.

Consultez Fonctionnement des hooks pour le détail des mécanismes.

Intégrations avec les agents

Pathrule est la couche d'intelligence ; votre agent de codage reste le moteur d'exécution et conserve son propre fournisseur de modèle. Le CLI et l'extension VS Code relient les agents que vous utilisez déjà au même espace de travail, via les hooks, les fichiers d'instructions et le MCP que chaque client prend en charge.

• Claude Code et Codex : hooks (dont un hook de soumission de prompt), fichiers d'instructions et serveur MCP local. Tous deux peuvent aussi se connecter à Remote MCP.
• Cursor et GitHub Copilot : hooks de session et d'outils, fichiers d'instructions et serveur MCP local. L'extension VS Code enregistre le serveur pour le mode agent de Copilot.
• Windsurf : un fichier de règles Pathrule et le serveur MCP local, sans hooks.
• Tout autre client MCP : se connecte via stdio. Ajoutez la commande MCP de Pathrule à la configuration de votre client et il verra la même surface d'outils.
• Clients qui se connectent à des serveurs hébergés : pointez-les vers Remote MCP via Streamable HTTP et connectez-vous avec OAuth. Remote MCP n'installe aucun hook et n'écrit aucun fichier local.

Pour aller plus loin

• Fonctionnement des hooks pour ce qui se passe entre le cache et l'éditeur.
• Concepts clés pour le modèle de données sur lequel opèrent les outils.
• Installation du CLI pour mettre en place le runtime qui héberge le serveur.