Écosystème AI-KIDO · Serveur MCP

Kimono, pour habiller votre pratique de l'AI-KIDO.

Quelle que soit votre ceinture, enfilez votre Kimono et rejoignez le dojo. En rendant accessibles par MCP les connaissances, commandes, personas, skills et workflows d'AI-KIDO, Kimono habille la méthode pour vous permettre de pratiquer à plusieurs, autour des mêmes repères et plus sereinement.

Connectez vos assistants à la même Memory Bank AI-KIDO. Recherchez, retrouvez les instructions et travaillez sur un projet autorisé, sans chat ni LLM embarqué dans le serveur.

Donnez une référence commune à vos assistants

Rendez la méthode et les connaissances AI-KIDO accessibles aux clients MCP comme VS Code et Claude Code. Commencez en lecture seule, testez sur votre machine, puis choisissez comment partager la base.

Une seule source

Ne faites plus circuler des copies obsolètes

Exposez documents, commandes, personas, skills et workflows depuis une racine de connaissances configurée. Plusieurs sessions HTTP peuvent partager cette même instance.

Inférence locale

Retrouvez le sens, pas seulement les mots

Les recherches littérales et regex complètent la recherche sémantique locale E5 multilingue avec ONNX Runtime. À l'exécution, l'inférence sémantique ne dépend d'aucune API d'inférence externe.

Le client garde la main

Gardez votre assistant habituel

activate et execute renvoient des instructions. Votre client les applique avec ses outils et approbations ; Kimono n'exécute pas de workflow LLM autonome.

Écosystème AI-KIDO · Serveur MCP

Kimono : une base de connaissances, des assistants connectés

Kimono expose une racine de connaissances AI-KIDO via le Model Context Protocol (MCP). Les humains utilisant un client MCP et les agents connectés peuvent retrouver les mêmes documents, commandes, agents/personas, skills et workflows, les rechercher et agir sur un projet autorisé. Utilisez-le de façon autonome ou comme brique d'une plateforme telle que Tatami.

Découvrir

La Memory Bank accessible par MCP

aikido, les ressources et les prompts rendent les connaissances accessibles aux clients comme VS Code et Claude Code. aikido_root initialise la racine configurée depuis le dépôt Git officiel ou un dépôt personnalisé.

Rechercher localement

Du texte exact au sens

aikido_search propose des recherches littérales, regex, sémantiques ou par vecteur existant. Les embeddings E5 multilingues sont calculés localement avec ONNX Runtime. aikido_embed expose l'identité et les paramètres du modèle actif ; aikido_index maintient les index et suit la progression sémantique.

Agir avec des garde-fous

Édition documentaire et Git structuré

aikido_file exige le contenu précédent exact pour modifier ou supprimer un document. aikido_git fournit des opérations structurées sur le projet. L'écriture s'active explicitement sur des projets ou forks de confiance ; l'origine officielle AI-KIDO reste protégée et le push exige l'approbation explicite du client.

Usage autonome

Docker Compose ou stdio natif

Docker Compose est recommandé : Git, outils de recherche Rust, runtime et modèle d'embedding sont inclus. Les clients se connectent au point d'accès HTTP /mcp avec un jeton Bearer. Le mode stdio natif est une alternative pour une connexion dédiée à un seul client, avec ses propres prérequis.

Connaissances partagées

Une instance HTTP, plusieurs clients

Un processus, une racine et un cache persistant offrent une vue commune des connaissances. Les recherches synchronisent l'index à la demande, y compris après des éditions externes, et seuls les chunks modifiés sont ré-embeddés. La lecture seule est la plus simple ; l'écriture partagée exige un coordinateur Git ou des workspaces séparés.

Intégration plateforme

Une brique pour Tatami

Prévoyez une instance par workspace autorisé, avec un cache persistant privé et un jeton distinct. Les points d'accès de santé, disponibilité et statut, ainsi que l'arrêt gracieux, facilitent l'intégration. Provisionnement, autorisations, routage des sessions, secrets et quotas restent à la charge du gestionnaire de plateforme.

Un serveur de connaissances, pas un assistant autonome. Kimono n'embarque ni chat ni LLM : activate / execute renvoient des instructions que le client applique avec ses propres outils et approbations. Ce n'est pas une plateforme multi-tenant dans un processus unique.

Le partage a ses limites. Tous les détenteurs du jeton d'une instance ont les mêmes droits. Plusieurs appels ne forment pas une transaction et l'accès Git n'est pas une sandbox. Ne partagez jamais un cache entre processus indépendants ; séparez aussi les clones pour isoler les écritures. Un accès HTTP distant exige TLS et un reverse proxy avec autorisation.

Comment les briques se connectent

Pour un accès partagé : un processus HTTP, une racine de connaissances et un cache privé persistant. Le cache reste en dehors de l'arbre documentaire.

Plusieurs clients accèdent par Kimono à un arbre de connaissances commun et à son cache de recherche séparé.
Clients

Humains et agents

VS Code · Claude Code
Autres clients MCP

MCP + jeton Bearer

Kimono HTTP

Découverte · recherche
Actions fichiers / Git sur option

Stockage local

Racine AI-KIDO + cache

Arbre des connaissances
Index de recherche persistants

Plusieurs clients partagent le même arbre de travail et les mêmes droits sur l'instance. Les recherches synchronisent les index à la demande ; ce n'est pas un watcher permanent.

Intégrer Kimono à Tatami ou à votre plateforme

Une plateforme externe route vers deux workspaces distincts, chacun avec son instance Kimono, son arbre de connaissances et son cache.

Gestionnaire plateforme

Autorisations · routage
Secrets · cycle de vie · quotas

Workspace A

Kimono A · racine A
Cache privé A · jeton A

Workspace B

Kimono B · racine B
Cache privé B · jeton B

La plateforme route chaque client vers son instance autorisée, et non du workspace A vers B. Dans l'organisation actuelle de Tatami, un workspace correspond au couple (utilisateur, projet). Le provisionnement dynamique et le routage sont une intégration distincte, pas des fonctions de Kimono.

1. Récupérer Kimono sur GitHub

Ouvrez un terminal avec Git installé. Ces commandes créent un nouveau clone ; choisissez un dossier qui ne contient pas déjà un clone de Kimono.

git clone https://github.com/lcalmejane/kimono-mcp-server.git
cd kimono-mcp-server

Choisissez ensuite Docker Compose pour le runtime et le modèle d'embedding inclus, ou le mode stdio natif pour une connexion dédiée à un client. GitHub héberge les sources ; GitHub Pages ne peut pas exécuter ce serveur MCP.

2A. Tester avec Docker Compose

Recommandé pour un premier essai. Installez Docker Engine ou Docker Desktop avec Compose v2 et démarrez Docker. Lancez ces commandes depuis le dossier Kimono cloné. Le premier build télécharge les dépendances, ONNX Runtime et le modèle d'embedding : il nécessite Internet et peut prendre du temps.

Préparer la configuration locale

cp .env.example .env
openssl rand -hex 32

Copiez la valeur aléatoire générée dans MCP_AUTH_TOKEN du fichier .env. Pour cet essai, conservez les autres valeurs par défaut ci-dessous ; ne versionnez jamais votre jeton.

AIKIDO_HOST_PARENT=./data
AIKIDO_DIR=aikido
AIKIDO_WRITABLE=false
AIKIDO_VOLUME_MODE=ro
AIKIDO_INCLUDE_SPEC=false
MCP_PORT=3000

Installer une base AI-KIDO neuve, puis démarrer le serveur

mkdir -p data
docker compose --profile install run --build --rm install-aikido
docker compose up --build -d kimono-mcp-server
docker compose ps
curl --fail http://127.0.0.1:3000/healthz

L'installation clone explicitement AI-KIDO dans ./data/aikido. Cette cible doit être absente ou vide ; une cible non vide n'est pas écrasée. Pour une base existante, configurez plutôt son dossier parent et son nom, vérifiez qu'elle contient prompts/index.md ou index.md, et sautez l'installation.

Résultat attendu : un conteneur démarré et un HTTP 200 sur /healthz. Ce test vérifie la vivacité, pas la disponibilité des connaissances ni la fin de l'indexation sémantique. /readyz et /statusz nécessitent votre jeton Bearer. Le conteneur utilise l'UID 1000 : ses dossiers montés doivent être lisibles, et inscriptibles pendant l'installation.

Connecter VS Code en HTTP

Ajoutez cette entrée à la configuration MCP du client. Pour VS Code, fusionnez-la dans .vscode/mcp.json, en conservant les serveurs et les entrées déjà présents. Le jeton demandé est celui défini dans .env.

{
  "inputs": [
    {
      "type": "promptString",
      "id": "kimono-token",
      "description": "Jeton MCP Kimono",
      "password": true
    }
  ],
  "servers": {
    "kimono": {
      "type": "http",
      "url": "http://127.0.0.1:3000/mcp",
      "headers": {
        "Authorization": "Bearer ${input:kimono-token}"
      }
    }
  }
}

Démarrez la connexion depuis les contrôles MCP de VS Code et approuvez-la lorsque le client le demande. Les autres clients MCP utilisent la même URL et l'authentification Bearer. Si vous changez MCP_PORT, adaptez aussi l'URL.

Inspecter puis arrêter le test

docker compose logs --tail=100 kimono-mcp-server
docker compose down

Cet arrêt conserve le dossier de connaissances sur l'hôte et le volume nommé du cache. N'ajoutez pas --volumes, sauf si vous souhaitez supprimer les index en cache.

2B. Tester localement en stdio natif

Alternative à Docker : Node.js 24+, npm, Git et Rust/Cargo sont nécessaires. Ce parcours démarre avec la recherche littérale/regex. La recherche sémantique native exige aussi le helper, les fichiers du modèle et la bibliothèque ONNX de la configuration sémantique officielle ; Docker les inclut.

cargo install fast-grep --version 0.5.0 --locked
npm ci
npm run build
node dist/cli.js init --root /absolute/path/to/aikido --ref main

Remplacez /absolute/path/to/aikido par un nouveau chemin absolu d'installation. La dernière commande clone la base officielle ; pour une base existante, sautez-la. Le binaire de recherche s'appelle fgr et doit être dans le PATH du client.

Fusionnez cette entrée dans .vscode/mcp.json de VS Code, en remplaçant les deux chemins absolus :

{
  "servers": {
    "kimono": {
      "type": "stdio",
      "command": "node",
      "args": ["/absolute/path/to/kimono-mcp-server/dist/cli.js",
               "serve", "--root", "/absolute/path/to/aikido"]
    }
  }
}

Le client lance lui-même le processus. Cette configuration stdio n'utilise ni port HTTP ni jeton Bearer. Lancer séparément la commande depuis plusieurs clients crée plusieurs processus, pas des sessions d'un serveur HTTP commun ; ne partagez jamais un cache entre processus indépendants. Préférez HTTP pour une racine partagée.

3. Effectuer les premiers appels MCP

Depuis votre assistant connecté ou un inspecteur d'outils MCP, choisissez l'outil et fournissez les arguments JSON ci-dessous. Ce sont des appels d'outils, pas des commandes shell. Commencez par la découverte en lecture seule.

Découvrir

aikido

{"operation":"list"}

Vous devez retrouver le catalogue des connaissances découvertes dans la racine configurée. Demandez à votre assistant d'en expliquer une commande ou un persona.

Rechercher

aikido_search

{"mode":"literal",
 "query":"AI-KIDO",
 "limit":5}

Repérez les chemins, numéros de ligne et extraits. Avec la configuration sémantique de Docker, essayez mode: "semantic" et une question en langage naturel.

Mode sémantique Docker

aikido_embed

{"operation":"info"}

Consultez le modèle d'embedding actif et ses paramètres de prétraitement. La première recherche sémantique peut être plus longue pendant l'indexation ; la disponibilité seule ne garantit pas un index terminé.

Pour suivre la progression sémantique sans lancer d'inférence, appelez aikido_index avec {"operation":"status","mode":"semantic"}. Après un redémarrage du serveur, reconnectez le client MCP pour créer une nouvelle session.

Commencer simplement. Garder des limites claires.

Lecture seule d'abord

Conservez la protection de la base officielle. Les écritures fichiers/Git sont réservées à des projets ou forks de confiance distincts, explicitement activées avec un montage inscriptible. L'API Git n'est pas une sandbox.

Partager en connaissance de cause

Tous les clients détenteurs du jeton ont les mêmes droits. Les appels passent par la file du runtime, mais plusieurs appels ne forment pas une transaction. Désignez un coordinateur Git ou isolez les workspaces en écriture.

Garder un accès local

Compose n'expose que l'interface locale. Un accès distant exige TLS et un reverse proxy authentifié avec autorisation. Séparez jetons, racines et caches pour isoler les workspaces ; ne placez jamais les identifiants dans Git.

Si le premier démarrage échoue

  • Connexion refusée : vérifiez que Docker tourne, docker compose ps, le port publié et les logs du serveur.
  • Erreur d'authentification : vérifiez que le jeton Bearer du client correspond à MCP_AUTH_TOKEN.
  • Racine indisponible : vérifiez le résultat de l'installation, le chemin configuré, le fichier d'entrée et les permissions pour l'UID 1000.
  • Premier appel sémantique lent : prévoyez un délai client suffisant et consultez le statut de l'index ; en natif, installez les prérequis sémantiques supplémentaires.

Essayez-le dès votre prochaine session

Une base, une connexion en lecture seule et une première recherche suffisent pour découvrir l'intérêt de Kimono. Le dépôt reste la référence pour la configuration et les limites opérationnelles qui évoluent.