Votre assistant, pointé sur votre keel

Pointer un client dessus

Les deux blocs ci-dessous sont ceux du moteur, cités verbatim de sa documentation du serveur — adaptez les chemins à votre déploiement.

Lancer le serveur

uv run keel --db keel.db --config config.yaml mcp

L'enregistrer auprès de votre client

{
  "mcpServers": {
    "keel": {
      "command": "keel",
      "args": ["--db", "keel.db", "--config", "config.yaml", "mcp"]
    }
  }
}

L'instruction du moteur tient en une ligne : pointez n'importe quel client MCP stdio sur la commande — Claude Desktop, Cursor, Codex, VS Code, Zed consomment tous cette même forme mcpServers. Où chaque client garde cette configuration relève de la documentation du client ; la part de keel, c'est la commande et la clôture autour d'elle.

Vérifier dans le dépôt : docs/mcp-server.md · La référence complète du serveur est récupérée du moteur au moment du build et rendue dans la Documentation — cette page résume ; cette page-là est le document.

Ce que les huit outils permettent à un assistant

Huit outils, chacun déléguant aux mêmes coutures de service que l'interface d'un opérateur appelle — un assistant et un terminal ne peuvent donc pas se voir raconter deux comptes différents d'un même déploiement. Toutes les listes sont bornées ; l'argent arrive en chaînes de caractères, jamais arrondi deux fois par un flottant JSON.

• doctor — Les mêmes constats que calcule keel doctor — fraîcheur de l'abonnement, états des garde-fous, marge du quota, vetos récents, santé des données, admissibilité du dimensionnement — chacun avec la commande qui le résout.
• capabilities — L'inventaire des capacités en lignes : chaque action qui élargit ce que keel peut faire sans redemander, et le verrou qui la couvre.
• profiles — Les fichiers de configuration du déploiement en lignes structurées — liste blanche, plafonds, budget DCA, granularités. Un fichier qui ne charge pas est listé avec son erreur.
• orders — Des lignes du journal d'audit des ordres, filtrées par mode, produit ou statut, les plus récentes en dernier, bornées.
• veto_log — Les événements de veto des garde-fous, extraits du journal JSONL du moteur depuis un horodatage, avec les violations de chaque événement.
• purification — Le rapport de purification des revenus §65.9 — ce qui est dû par actif, unités issues de sources entachées, entrées en attente de classification humaine. Rapport uniquement, comme la CLI.
• trials — Le registre des essais de recherche : nombres de lignes et de décisions, erreurs de vérification de la chaîne de hachage, lignes les plus récentes. Les essais uniquement — l'argent a son propre registre.
• reports — Les corpus de recherche : lister les documents, ou lire un document borné — un nom simple, jamais un chemin de système de fichiers.

Vérifier dans le dépôt : keel/mcp/tools.py

Ce qu'il ne peut délibérément pas faire

La moitié intéressante. Le serveur ne peut ni attester un actif, ni promouvoir une règle, ni armer l'autonomie, ni passer, arrêter ou libérer un ordre — non par politique, mais parce que la surface d'écriture n'existe pas. La page du moteur nomme la clôture, en six murs :

• Un vocabulaire de verbes d'écriture — chaque nom et chaque description d'outil est scanné contre arm, attest, promote, kill, place et les autres verbes d'écriture. Une description ne peut pas annoncer une écriture, car une description est ce qu'un modèle lit avant de choisir un outil.
• Aucune action verrouillée n'est atteignable par son nom — rien dans le serveur ne référence les entrées module.function du registre des capacités.
• Un scan AST qui refuse tout appel d'écriture — la liste blanche est vide, et épinglée vide. Une exemption existe : PRAGMA query_only = ON, l'application de la lecture seule au niveau du moteur elle-même.
• Le verrou de confirmation interactive n'apparaît nulle part dans le paquet — un processus relié par un tuyau ne doit pas emprunter la cérémonie faite pour un humain à un terminal.
• Un épinglage de la documentation — un outil documenté qui n'existe pas, ou un outil exposé que la documentation cache, fait échouer la CI.
• Une surface d'imports fermée — le paquet n'importe ni l'exécuteur ni l'agent ; les chemins de trading démarrent indisponibles, pas simplement inutilisés.

Le gardien est un test — tests/mcp/test_readonly.py — livré avant que keel/mcp/ n'existe, si bien que le serveur est né dans la clôture plutôt que déplacé dans une plus tard. La page du moteur est honnête sur la limite : un scan statique ne peut pas fermer la répartition dynamique.

Et à l'exécution, chaque connexion s'ouvre avec PRAGMA query_only = ON — écrire une ligne est impossible au niveau du moteur, par construction et non par politique. Ce qui ne sera jamais exposé est nommé aussi : les identifiants, le contenu du .env, tout ce qui vient du trousseau du système.

Vérifier dans le dépôt : tests/mcp/test_readonly.py

L'ajustement honnête : l'assistant propose, le verrou décide

La note de conception du flux d'analyse de keel énonce le motif en cinq mots — l'Analyzer propose, le verrou décide : le flux propose des actifs à l'attestation humaine, le verrou déterministe de keel décide, et rien de nouveau ne touche l'admission, le dimensionnement ou le passage d'ordres. Le serveur MCP hérite de la même asymétrie. Un assistant qui lit vos rapports peut expliquer ce que votre keel a fait et pourquoi un garde-fou a tiré ; rien de ce qu'il dit n'atteint un ordre.

Cette frontière est la fonctionnalité. Un chatbot capable de rédiger une stratégie et de la promouvoir contournerait l'échelle candidate → papier → réel et son contrôle de surapprentissage en une seule phrase. La réponse de keel n'est pas un chatbot mieux élevé ; c'est un serveur qui ne peut pas, gardé par un test qui échoue s'il apprend jamais comment.

keel#579 · docs/mcp-server.md

Les assistants proposent. Les verrous de keel décident toujours.