@ogygie/mcp

Serveur MCP du framework Ogygie : il donne à un espace de conception (claude.ai, Claude Desktop, Claude Code) un accès en lecture aux fichiers de gouvernance et aux features de N repos Ogygie — sans copie, sans recherche sémantique, sans connaître le produit. Le manifeste est l'index : une feature qu'il ne déclare pas n'existe pas. Depuis la 0.13, il sait aussi proposer : une spec ou un fichier de décisions devient une pull request, jamais un fichier écrit sur l'hôte (D17).

Lancement

# Depuis un projet Ogygie, sur le projet courant
pnpm add -D @ogygie/mcp@<version d'@ogygie/cli>   # lockstep D2
pnpm ogygie mcp

# Sur un hôte, sans projet Ogygie, en servant plusieurs repos
npx @ogygie/mcp --config ogygie-mcp.config.json --http --port 3010

Le registre nomme les repos servis :

{
  "repos": [
    { "id": "mon-produit", "rootPath": "/srv/clones/mon-produit" },
    { "id": "autre-produit", "rootPath": "/srv/clones/autre-produit" }
  ]
}

Sans --config, le serveur sert le projet courant sous l'id local.

Outils

| Outil | Ce qu'il rend | |---|---| | ogygie_list_repos | les repos servis, leur version Ogygie, le ref git lu | | ogygie_read_manifest | le manifeste validé — l'index du repo | | ogygie_list_specs | les specs (id, statut, priorité, dépendances, différés) | | ogygie_read_spec | une spec entière : frontmatter parsé + corps | | ogygie_read_decisions | une décision D<n>, ou les deux fichiers entiers | | ogygie_read_governance | AGENTS.md, AGENTS.product.md ou FAILURES.md | | ogygie_read_feature | les fichiers d'une feature, ou l'un d'eux | | ogygie_impact | le rayon d'impact d'une feature ou d'un package | | ogygie_propose_change | (repos avec bloc github + jeton) une spec ou un fichier de décisions → commit sur une branche mcp/… + pull request |

Chaque réponse porte sa provenance { repo, path, ref } : ce qui a été lu, où, et à quel commit.

Transport HTTP

OGYGIE_MCP_TOKEN est obligatoire (32 caractères au moins) : sans lui, le serveur refuse de démarrer. Les requêtes portent Authorization: Bearer <token> et sont refusées avant toute lecture. Le serveur n'écoute que 127.0.0.1 tant qu'un --host n'est pas écrit à la main. La synchronisation des clones (git fetch) est un problème d'hébergement : le serveur lit ce que le disque porte, et le date par ref.

Écriture par proposition

Un repo devient écrivable quand son entrée de registre porte ses coordonnées GitHub et que l'hôte porte OGYGIE_MCP_GITHUB_TOKEN (jeton à portée minimale : contenus + pull requests sur les seuls repos servis) :

{ "id": "mon-produit", "rootPath": "/srv/clones/mon-produit",
  "github": { "owner": "mon-org", "repo": "mon-produit", "defaultBranch": "main" } }

Périmètre fermé : specs/<id>.spec.md, DECISIONS.md, DECISIONS.product.md. Le contenu est validé comme verify-specs le ferait (frontmatter, sections, références D<n>, numérotation des décisions), une spec ne passe jamais implemented par cette voie, un conflit avec la tête distante est refusé avec le contenu à jour, et une seconde proposition sur le même chemin met à jour la même pull request. --write-rate-limit <n> borne les propositions par repo et par heure (20 par défaut). Sans bloc github ni jeton, l'outil n'est pas listé : un serveur de lecture reste un serveur de lecture.

Ce qu'il ne fait pas

Aucune écriture sur le disque de l'hôte, aucune écriture hors des specs et des décisions, aucun merge. Aucune exécution de code du repo servi. Aucun accès hors carte : .env, secrets et artefacts de build sont inatteignables par construction, pas par liste noire. Aucun cache : chaque lecture touche le disque, la fraîcheur est l'objectif.

Licence

MIT — voir LICENSE.