Archcore MCP Server

officiel

Serveur MCP stdio local qui permet aux agents de codage IA de lire et de maintenir l'architecture structurée, les règles et les décisions directement depuis votre dépôt.

GitHub

Documentation

Archcore CLI

Votre agent IA arrête de deviner et commence à suivre votre architecture.

Git livre votre code. CI/CD livre votre livraison. Archcore livre votre compréhension.

Archcore stocke vos décisions, règles et conventions dans Git — afin que votre agent IA les suive automatiquement. Fonctionne avec Claude Code, Cursor, Copilot, Gemini CLI, Codex, OpenCode, Roo Code et Cline.

Archcore est livré sous forme de CLI et de serveur MCP stdio local — tout agent de codage compatible MCP peut lire et écrire le contexte de votre dépôt via des outils standard, tandis que le plugin Claude Code / Cursor ajoute une couche de flux de travail de niveau supérieur.

Vous utilisez Claude Code ou Cursor ? Associez la CLI au Plugin Archcore — même moteur, plus des compétences, des commandes d'intention et des garde-fous prêts à l'emploi. S'en tenir à la CLI est également très bien — cela fonctionne avec tous les autres agents.

En 60 secondes

curl -fsSL https://archcore.ai/install.sh | bash
cd your-project && archcore init

Ensuite, ouvrez votre agent IA et dites :

"Nous utilisons PostgreSQL pour le stockage principal. Enregistrez cette décision."

C'est fait. Il y a maintenant un ADR structuré dans .archcore/ que chaque session future — dans n'importe quel agent — peut lire.

Sous Windows ? Utilisez PowerShell : irm https://archcore.ai/install.ps1 | iex. Pour WSL, go install, et d'autres options, consultez Méthodes d'installation ou le guide d'installation complet.

Demandez à votre IA des choses comme

Une fois que votre dépôt contient quelques documents, votre agent peut les utiliser. Essayez :

"Avant de toucher au module d'authentification, quels ADR et règles s'appliquent ici ?"

L'agent charge les décisions et règles pertinentes liées à cette zone avant de modifier une seule ligne.

"Ajoutez un nouveau gestionnaire d'API et suivez les conventions de ce dépôt."

L'agent fait apparaître la règle correspondante (par exemple, "les gestionnaires résident dans src/api/handlers/") et place le code là où votre architecture dit qu'il doit être.

"Quelle est notre règle de gestion des erreurs ?"

L'agent lit error-wrapping.rule.md directement depuis .archcore/ au lieu de deviner à partir de quelques exemples dans la base de code.

Essayez d'abord ceci

Ces invites capturent un nouveau contexte — décisions, règles, plans, incidents. Chacune crée un document structuré que l'agent (ou tout coéquipier) peut réutiliser plus tard.

Nouveau dépôt ? archcore init crée .archcore/. Le serveur MCP fonctionne également dans un dépôt vide et expose un outil init_project, afin que l'agent puisse amorcer pour vous.

"Nous avons décidé d'utiliser PostgreSQL au lieu de MongoDB pour notre base de données principale. Enregistrez cette décision."

Crée infrastructure/use-postgres.adr.md avec le contexte, la décision, les alternatives envisagées et les conséquences.

"Nous avons une convention d'équipe : toujours envelopper les erreurs avec le contexte en utilisant fmt.Errorf et %w. Faites-en une règle."

Crée backend/error-wrapping.rule.md avec des conseils impératifs, la justification et des exemples de code bon/mauvais.

"La semaine dernière, nous avons eu un incident d'épuisement du pool de connexions parce que les connexions inactives n'étaient pas recyclées. Documentez ceci pour ne pas le répéter."

Crée incidents/connection-pool-exhaustion.cpat.md avec une analyse des causes profondes et des étapes de prévention.

"J'ai besoin d'un PRD pour la fonctionnalité de notifications utilisateur — push, résumés par e-mail et alertes in-app."

Crée notifications/user-notifications.prd.md avec les objectifs, les user stories, les exigences et les indicateurs de succès.

"Créez un plan de mise en œuvre pour le PRD des notifications et liez-les ensemble."

Crée notifications/notifications-implementation.plan.md, puis le lie au PRD avec une relation implements.

Si l'un de ces éléments résonne, le reste d'Archcore est du même ordre — juste structuré.

Ce qui change après l'installation

Sans Archcore, l'agent :

ignore votre architecture
enfreint vos conventions
duplique la logique qui existe déjà
remet en cause les décisions que votre équipe a déjà prises
a besoin que les mêmes conventions soient répétées dans chaque chat
perd la vérité du projet dès la fin de la session

Avec Archcore, les mêmes demandes produisent du code qui :

atterrit là où votre architecture dit qu'il doit être
respecte les ADR, les spécifications et les règles déjà dans Git
suit les conventions d'équipe chargées automatiquement au début de la session
reflète les nouvelles décisions comme de futurs garde-fous, pas comme des cimetières de markdown

L'IA devrait suivre votre système, pas le deviner.

Utilisez Archcore quand

Votre agent écrit du code, mais pas de la manière attendue par ce dépôt
Votre CLAUDE.md / .cursorrules / AGENTS.md ne cesse de croître et de dériver
Vous travaillez avec plus de 2 agents ou plus de 2 outils hôtes (Claude Code + Cursor + Copilot)
Vous voulez des décisions, des règles et des spécifications dans Git — pas dans l'historique de chat

Pas pour — la mémoire de chat, une bibliothèque d'invites ou un générateur ponctuel de spécifications vers code. Archcore est une couche de vérité de dépôt pour les agents de codage, pas un kit méthodologique.

Pourquoi ne pas simplement utiliser des fichiers d'instructions ?

CLAUDE.md, AGENTS.md et les instructions de dépôt sont des points de départ utiles, mais ils échouent lorsque votre équipe a besoin de :

plus d'un fichier de mémoire plat
types de documents structurés — ADR, règles, plans, incidents
contexte réutilisable sur plusieurs outils d'IA
connaissances de projet versionnées qui évoluent avec la base de code
relations entre les documents (un plan qui met en œuvre un PRD, une RFC qui étend un ADR)
apprentissages d'incidents et flux de travail récurrents que les agents peuvent reprendre plus tard

Les fichiers d'instructions disent à l'agent ce que vous voulez. Archcore dit à l'agent comment votre système fonctionne — afin que l'agent puisse suivre votre système au lieu de le deviner.

Agents pris en charge

La CLI Archcore est elle-même un serveur MCP stdio local — c'est la surface d'intégration partagée pour chaque agent compatible MCP dans le tableau ci-dessous. Les hooks ajoutent un contexte proactif de début de session là où l'agent les prend en charge.

Agent	Hooks	MCP
Claude Code	oui	oui
Cursor	oui	oui
Gemini CLI	oui	oui
GitHub Copilot	oui	oui
OpenCode	—	oui
Codex CLI	—	oui
Roo Code	—	oui
Cline	—	manuel

Comment ça fonctionne

Initialisez votre dépôt archcore init crée .archcore/ et installe les intégrations pour les agents pris en charge.
Capturez un contexte durable Stockez les décisions d'architecture, les règles, les plans, la documentation produit et les apprentissages d'incidents sous forme de fichiers Markdown structurés.
Laissez les agents le réutiliser Les hooks et MCP permettent à vos agents de codage de lire le contexte existant et de créer ou mettre à jour des documents pendant le travail réel.
Conservez-le dans Git Examinez les changements de contexte comme du code, faites-les évoluer au fil du temps et gardez-les portables entre les outils.

Modèle mental

La CLI Archcore est le compilateur de contexte — elle transforme des documents épars en contexte structuré et lisible par machine. MCP et les hooks sont le runtime — la surface que les agents utilisent pour consommer ce contexte pendant le travail réel. Le Plugin Archcore pour Claude Code et Cursor est un runtime de niveau supérieur construit par-dessus.

implicit repo knowledge  →  structured context  →  AI-readable system

Ce qui réside dans `.archcore/`

.archcore/
├── settings.json
├── .sync-state.json
├── auth/
│   ├── jwt-strategy.adr.md
│   └── auth-redesign.prd.md
├── backend/
│   └── error-wrapping.rule.md
├── incidents/
│   └── connection-pool-exhaustion.cpat.md
└── notifications/
    └── notifications-implementation.plan.md

La structure est libre — organisez les documents par domaine, fonctionnalité, équipe ou tout ce qui convient à votre dépôt. Les catégories sont virtuelles et déduites du type de document dans le nom de fichier (slug.type.md).

Utilisez .archcore/ pour :

les décisions d'architecture
les règles et conventions de codage
les plans de mise en œuvre
les exigences produit
les incidents et les post-mortems
les connaissances de flux de travail réutilisables

Consultez le dépôt de la CLI Archcore lui-même pour un exemple concret : .archcore/ dans ce dépôt

Ce qui est livré dans la boîte

18 types de documents couvrant la vision, la connaissance et l'expérience
4 types de relations — related, implements, extends, depends_on
10 outils MCP — list_documents, get_document, create_document, update_document, remove_document, search_documents, init_project, plus la gestion des relations (add_relation, remove_relation, list_relations)
5 invites multi-documents — des cascades de suivi invocables en tant que commandes slash depuis les agents compatibles MCP
Intégrations de hooks pour 4 agents (Claude Code, Cursor, Gemini CLI, GitHub Copilot) et intégrations MCP pour 8

Types de documents

Archcore organise le contexte en 3 couches de connaissances : Vision, Connaissance et Expérience.

Vision

Type	Nom complet	Description
`prd`	Document d'exigences produit	Objectifs, user stories, critères d'acceptation et indicateurs de succès
`idea`	Idée	Capture légère d'une idée produit ou technique pour une exploration future
`plan`	Plan	Liste de tâches phasée avec critères d'acceptation et dépendances

Archcore prend également en charge deux pistes d'exigences supplémentaires pour les équipes qui ont besoin d'une découverte structurée ou d'une décomposition formelle :

Piste Sources (MRD → BRD → URD) — capture d'où viennent les exigences :

Type	Nom complet	Description
`mrd`	Document d'exigences du marché	Paysage du marché, TAM/SAM/SOM, analyse concurrentielle et besoins du marché
`brd`	Document d'exigences métier	Objectifs métier, parties prenantes, ROI et règles métier
`urd`	Document d'exigences utilisateur	Personas utilisateur, parcours, exigences d'utilisabilité et critères d'acceptation

Piste ISO/IEC/IEEE 29148:2018 (BRS → StRS → SyRS → SRS) — capture comment les exigences se décomposent :

Type	Nom complet	Description
`brs`	Spécification des exigences métier	Mission, objectifs, buts et concept opérationnel métier
`strs`	Spécification des exigences des parties prenantes	Besoins des parties prenantes, concept opérationnel et exigences utilisateur
`syrs`	Spécification des exigences système	Fonctions système, interfaces, performances et contraintes de conception
`srs`	Spécification des exigences logicielles	Fonctions logicielles, interfaces externes et spécifications comportementales détaillées

Utilisez le PRD pour la plupart des projets. Ajoutez la piste sources lorsque vous avez besoin d'une découverte structurée des exigences. Ajoutez ISO 29148 lorsque vous avez besoin d'une traçabilité formelle pour les systèmes réglementés ou complexes multi-équipes. Mélangez librement — certaines fonctionnalités peuvent utiliser un PRD tandis que d'autres utilisent la cascade complète.

Connaissance

Type	Nom complet	Description
`adr`	Enregistrement de décision d'architecture	Capture une décision technique finalisée avec le contexte, les alternatives et les conséquences
`rfc`	Demande de commentaires	Propose un changement significatif ouvert à l'examen et aux commentaires de l'équipe
`rule`	Règle	Norme de codage ou de processus avec des conseils impératifs et des exemples
`guide`	Guide	Instructions étape par étape pour accomplir une tâche spécifique
`doc`	Document	Documentation de référence, registres et matériel descriptif
`spec`	Spécification	Contrat normatif canonique pour un système, un composant, une interface ou un protocole

Expérience

Type	Nom complet	Description
`task-type`	Type de tâche	Liste de contrôle et flux de travail réutilisable pour une tâche récurrente
`cpat`	Modèle de modification de code	Analyse des causes profondes d'un bug ou d'un incident avec étapes de prévention

Chaque document est un fichier Markdown avec un frontmatter YAML :

---
title: "Use PostgreSQL for Primary Storage"
status: draft
tags: [database, infrastructure]
---

## Context

...

Statuts valides : draft, accepted et rejected. Les tags sont optionnels et libres — utilisez-les pour marquer des sujets transversaux (security, golang, frontend).

Relations entre documents

Les documents peuvent être liés par des relations dirigées vers d'autres documents :

related — association générale
implements — la source implémente ce que la cible spécifie
extends — la source s'appuie sur la cible
depends_on — la source nécessite la cible pour continuer

Les relations sont stockées dans .sync-state.json et gérées automatiquement par l'agent IA via les outils MCP.

Intégration de l'agent IA

Archcore s'intègre aux agents de codage IA de trois manières :

Hooks injectent du contexte au démarrage de la session, afin que l'agent soit conscient de vos documents .archcore/ dès le premier message.
Outils MCP donnent à l'agent les capacités de lister, rechercher, lire, créer, mettre à jour et lier des documents en temps réel. Le serveur MCP fonctionne également dans un dépôt vide et expose un outil init_project, afin que les agents puissent amorcer .archcore/ eux-mêmes.
Prompts MCP sont des flux de travail multi-documents prêts à l'emploi que vous déclenchez depuis votre agent sous forme de commandes slash.

Prompts

Les prompts orchestrent des cascades complètes de documents en un seul appel — l'agent crée et lie chaque document de la piste pour vous. La plupart des agents compatibles MCP les exposent sous forme de commandes slash (par ex. /architecture_track) ; le préfixe exact dépend du client.

Prompt	Ce qu'il fait
`product_track`	idée → PRD → plan (flux de fonctionnalité léger)
`architecture_track`	ADR → spec → plan (conception technique + implémentation)
`standard_track`	ADR → règle → guide (codifier un standard d'équipe)
`sources_track`	MRD → BRD → URD (découverte marché / métier / utilisateur)
`iso_track`	BRS → StRS → SyRS → SRS (cascade formelle ISO 29148)

Exemple. Dans votre agent, exécutez /product_track feature="user notifications". L'agent ébauche une idée, dérive un PRD, construit un plan d'implémentation et les lie automatiquement.

Serveur MCP local

Archcore ne nécessite pas de service hébergé. La CLI exécute un serveur MCP stdio local :

archcore mcp

Par défaut, archcore mcp sert les documents du répertoire courant. Passez --project /path/to/repo (ou définissez ARCHCORE_PROJECT_ROOT) pour pointer ailleurs — utile lorsque le serveur est lancé depuis un répertoire qui n'est pas votre espace de travail (par exemple, par une intégration d'éditeur).

Câblez-le dans Claude Code :

claude mcp add --transport stdio archcore -- archcore mcp

Ou installez automatiquement pour un agent pris en charge :

archcore mcp install --agent cursor

Installer les intégrations

# Auto-detect agents in your project and install everything
archcore hooks install

# Or target a specific agent
archcore mcp install --agent opencode
archcore hooks install --agent cursor

Commandes

Commande	Description
`archcore init`	Initialiser le répertoire `.archcore/` de manière interactive
`archcore doctor`	Vérifier votre configuration archcore et résoudre les problèmes
`archcore status`	Vérifier la structure .archcore/ et la santé des documents
`archcore config`	Voir ou modifier les paramètres
`archcore hooks install`	Installer les hooks pour les agents IA détectés
`archcore update`	Mettre à jour Archcore vers la dernière version
`archcore mcp`	Exécuter le serveur MCP stdio
`archcore mcp install`	Installer la configuration MCP pour les agents détectés

Mise à jour

archcore update

La commande vérifie les GitHub Releases pour une version plus récente, la télécharge, vérifie la somme de contrôle SHA-256 et remplace atomiquement le binaire actuel.

Méthodes d'installation

macOS / Linux

curl -fsSL https://archcore.ai/install.sh | bash

Windows

irm https://archcore.ai/install.ps1 | iex

Installe archcore.exe sous %LOCALAPPDATA%\Programs\archcore et l'ajoute à votre PATH utilisateur. Ouvrez une nouvelle fenêtre PowerShell après l'installation pour que le changement PATH soit pris en compte.

Windows (WSL)

Installez WSL, puis exécutez à l'intérieur :

curl -fsSL https://archcore.ai/install.sh | bash

Go install

go install github.com/archcore-ai/cli@latest

Depuis les sources

git clone https://github.com/archcore-ai/cli.git
cd cli
go build -o archcore .

Plateformes supportées : macOS, Linux, Windows — amd64 et arm64.

Pour les variables d'environnement (ARCHCORE_VERSION, ARCHCORE_INSTALL_DIR, GITHUB_TOKEN) et le dépannage du PATH, consultez le guide d'installation complet sur docs.archcore.ai.

Configuration

Les paramètres sont stockés dans .archcore/settings.json et créés lors de archcore init.

Champ	Description	Valeurs
`sync`	Mode de synchronisation. Cloud et on-prem arrivent bientôt.	`none` (local uniquement), `cloud`, `on-prem`
`language`	Langue du document. Aide l'agent à générer la documentation dans la bonne langue.	Chaîne, par défaut `en`

archcore config                              # show all settings
archcore config get <key>                    # get a specific value
archcore config set <key> <value>            # set a value

Développement

Prérequis

Go 1.24+

Build & test

# Build
go build -o archcore .

# Run all tests
go test ./...

# Run a specific package
go test ./cmd/

# Run a single test
go test ./cmd/ -run TestConfigCmd

Structure du projet

├── cmd/              # Cobra commands (init, doctor, config, status, hooks, mcp, ...)
├── internal/
│   ├── agents/       # Supported AI agents with hooks/MCP capabilities
│   ├── api/          # HTTP client for archcore server
│   ├── config/       # Settings management and directory init
│   ├── display/      # Terminal output formatting (lipgloss)
│   ├── update/       # Self-update logic (version check, download, verify, replace)
│   ├── mcp/          # MCP stdio server, tools, and prompts
│   └── sync/         # Sync logic
├── templates/        # Document type templates
├── install.sh        # Install script
└── .goreleaser.yaml  # Release configuration

Archcore est-il comme BMAD / Spec Kit / Memory Bank ?

Non — ceux-ci résolvent des problèmes différents. Carte rapide :

Outil	Catégorie	Ce que c'est	En quoi Archcore diffère
BMAD	Méthodologie	Méthodologie SDLC agentique — 12+ rôles, 34+ flux de travail	Archcore stocke des artefacts ; BMAD prescrit un processus
Spec Kit	Méthodologie	Flux de travail piloté par les spécifications : `specify → plan → tasks → implement`, one-shot	Spec Kit est un transfert unique ; Archcore maintient un graphe vivant qui évolue avec la base de code
Agent OS	Méthodologie	Extraction de standards de base de code + développement piloté par les spécifications	Positionnement le plus proche. Archcore ajoute des documents typés, des relations validées et une cascade ISO optionnelle
claude-mem / Mem0	Mémoire	Capture automatique de la mémoire de session, rappel inter-agents	Les outils de mémoire se souviennent de ce que vous avez fait ; Archcore stocke comment le système est construit et ce qui a été décidé
Cline Memory Bank	Docs	Fichiers markdown à schéma fixe (`projectbrief`, `activeContext`, `systemPatterns`…)	Même esprit, moins de cérémonie. Archcore ajoute des relations typées, une validation MCP et des cascades en plusieurs étapes
CLAUDE.md / .cursorrules	Instructions	Fichier plat unique que l'agent lit au début de la session	Archcore remplace un fichier d'instructions croissant par des documents typés, liés et interrogeables

Choisissez un outil de méthodologie pour un flux de développement opiniâtre. Choisissez un outil de mémoire pour la continuité de session. Choisissez Archcore lorsque vous voulez une vérité projet typée et interrogeable — les décisions, les règles et l'architecture de ce dépôt — que votre agent de codage respecte à chaque requête.

Liens & licence

Documentation : docs.archcore.ai
Site web : archcore.ai
Plugin (Claude Code, Cursor) : github.com/archcore-ai/archcore-plugin
Problèmes : github.com/archcore-ai/cli/issues
Licence : Apache 2.0