@legba-core/mcp-docs

Ce que ça fait

Sert la documentation docs/ du monorepo à un modèle de langage via un serveur MCP (transport stdio), avec 5 outils : list_packages, get_symbol, search_docs, get_recipe, get_error.

Symboles publics

Symbole	Rôle
createDocsServer	Construit le serveur MCP avec les 5 outils déjà enregistrés
createFsDocsRepository	Construit un accès à docs/ qui relit le disque à chaque appel
resolveRepoRoot	Retrouve la racine du monorepo depuis n’importe quel fichier du paquet
resolveDocsRoot	Retrouve docs/ à la racine du monorepo
SERVER_NAME	Nom déclaré par le serveur MCP
SERVER_VERSION	Version déclarée par le serveur MCP

Les 5 outils

Outil	Ce qu’il rend
list_packages	Les paquets @legba-core/* connus, décrits depuis docs/packages/*.md
get_symbol	Le fichier docs/api/<symbole>.md complet d’un symbole nommé
search_docs	Les fichiers dont le contenu correspond à un mot-clé (recherche littérale, pas une regex)
get_recipe	Le contenu de docs/recipes/<nom>.md
get_error	Le fichier définissant un code d’erreur stable, ex. "LEGBA_INVALID_TOKEN_REQUEST"

La logique de chaque outil (src/tools/*.ts) est séparée du câblage MCP (src/server.ts) : elle prend un DocsRepository en paramètre, jamais un accès disque direct, pour rester testable avec un double.

Installation

pnpm add @legba-core/mcp-docs

Pièges

• Chaque outil relit docs/ à son propre appel, jamais une copie figée à la construction du serveur : la documentation servie est toujours celle actuellement sur disque, jamais celle de la branche principale ou d’une version précédente.
• Une réponse dépassant environ 8000 jetons rend un index des résultats et invite à préciser la requête, plutôt que de tout renvoyer d’un coup.
• resolveRepoRoot/resolveDocsRoot ne fonctionnent que depuis l’intérieur du monorepo legba-core (ils remontent les dossiers à la recherche de pnpm-workspace.yaml).
• L’exécutable bin (legba-mcp-docs) parle stdio : jamais de log applicatif sur stdout, uniquement stderr, sous peine de corrompre le flux JSON-RPC.