Archcore MCP Server

offiziell

Lokaler Stdio-MCP-Server, der KI-Codierungsagenten ermöglicht, strukturierte Architektur, Regeln und Entscheidungen direkt aus Ihrem Repository zu lesen und zu pflegen.

GitHub

Dokumentation

Archcore CLI

Ihr KI-Agent hört auf zu raten und beginnt, Ihrer Architektur zu folgen.

Git liefert Ihren Code. CI/CD liefert Ihre Auslieferung. Archcore liefert Ihr Verständnis.

Archcore speichert Ihre Entscheidungen, Regeln und Konventionen in Git – sodass Ihr KI-Agent ihnen automatisch folgt. Funktioniert mit Claude Code, Cursor, Copilot, Gemini CLI, Codex, OpenCode, Roo Code und Cline.

Archcore wird als CLI und als lokaler stdio-MCP-Server ausgeliefert – jeder MCP-kompatible Coding-Agent kann Ihren Repo-Kontext über Standardwerkzeuge lesen und schreiben, während das Claude Code / Cursor-Plugin eine übergeordnete Workflow-Ebene hinzufügt.

Verwenden Sie Claude Code oder Cursor? Kombinieren Sie die CLI mit dem Archcore Plugin – dieselbe Engine, plus Skills, Intent-Befehle und Leitplanken direkt einsatzbereit. Bei der CLI zu bleiben ist ebenfalls großartig – sie funktioniert mit jedem anderen Agenten.

In 60 Sekunden

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

Öffnen Sie dann Ihren KI-Agenten und sagen Sie:

"Wir verwenden PostgreSQL als Primärspeicher. Diese Entscheidung festhalten."

Erledigt. Es gibt jetzt einen strukturierten ADR in .archcore/, den jede zukünftige Sitzung – in jedem Agenten – lesen kann.

Unter Windows? Verwenden Sie PowerShell: irm https://archcore.ai/install.ps1 | iex. Für WSL go install und andere Optionen siehe Installationsmethoden oder die vollständige Installationsanleitung.

Fragen Sie Ihre KI zum Beispiel

Sobald Ihr Repo einige Dokumente enthält, kann Ihr Agent sie nutzen. Versuchen Sie:

"Bevor ich das Auth-Modul anfasse, welche ADRs und Regeln gelten hier?"

Der Agent lädt die relevanten Entscheidungen und Regeln, die mit diesem Bereich verknüpft sind, bevor er eine einzige Zeile bearbeitet.

"Füge einen neuen API-Handler hinzu und befolge die Konventionen dieses Repos."

Der Agent zeigt die passende Regel an (z. B. "Handler befinden sich in src/api/handlers/") und platziert den Code dort, wo Ihre Architektur es vorsieht.

"Wie lautet unsere Fehlerbehandlungsregel?"

Der Agent liest error-wrapping.rule.md direkt aus .archcore/, anstatt anhand einiger Beispiele in der Codebasis zu raten.

Probieren Sie zuerst diese aus

Diese Prompts erfassen neuen Kontext – Entscheidungen, Regeln, Pläne, Vorfälle. Jeder erstellt ein strukturiertes Dokument, das der Agent (oder jedes Teammitglied) später wiederverwenden kann.

Neues Repo? archcore init erstellt .archcore/. Der MCP-Server funktioniert auch in einem leeren Repo und stellt ein init_project-Werkzeug bereit, sodass der Agent für Sie bootstrappen kann.

"Wir haben uns entschieden, PostgreSQL anstelle von MongoDB für unsere Primärdatenbank zu verwenden. Diese Entscheidung festhalten."

Erstellt infrastructure/use-postgres.adr.md mit Kontext, Entscheidung, betrachteten Alternativen und Konsequenzen.

"Wir haben eine Teamkonvention: Fehler immer mit Kontext unter Verwendung von fmt.Errorf und %w wrappen. Mache dies zu einer Regel."

Erstellt backend/error-wrapping.rule.md mit verbindlicher Anleitung, Begründung und guten/schlechten Codebeispielen.

"Letzte Woche hatten wir einen Vorfall mit Connection-Pool-Erschöpfung, weil inaktive Verbindungen nicht recycelt wurden. Dokumentiere dies, damit es sich nicht wiederholt."

Erstellt incidents/connection-pool-exhaustion.cpat.md mit Ursachenanalyse und Präventionsschritten.

"Ich brauche ein PRD für die Benutzerbenachrichtigungsfunktion – Push, E-Mail-Digests und In-App-Benachrichtigungen."

Erstellt notifications/user-notifications.prd.md mit Zielen, User Stories, Anforderungen und Erfolgsmetriken.

"Erstelle einen Implementierungsplan für das Benachrichtigungs-PRD und verknüpfe sie miteinander."

Erstellt notifications/notifications-implementation.plan.md und verknüpft ihn dann mit dem PRD über eine implements-Relation.

Wenn Ihnen etwas davon zusagt, ist der Rest von Archcore ähnlich – nur strukturiert.

Was sich nach der Installation ändert

Ohne Archcore ignoriert der Agent:

Ihre Architektur
bricht Ihre Konventionen
dupliziert bereits vorhandene Logik
verhandelt Entscheidungen neu, die Ihr Team bereits getroffen hat
benötigt die Wiederholung derselben Konventionen in jedem Chat
verliert das Projektwissen, sobald die Sitzung endet

Mit Archcore produzieren dieselben Anfragen Code, der:

dort landet, wo Ihre Architektur es vorsieht
ADRs, Spezifikationen und Regeln respektiert, die bereits in Git sind
Teamkonventionen befolgt, die automatisch zu Sitzungsbeginn geladen werden
neue Entscheidungen als zukünftige Leitplanken widerspiegelt, nicht als Markdown-Friedhöfe

KI sollte Ihrem System folgen, nicht es erraten.

Verwenden Sie Archcore, wenn

Ihr Agent Code schreibt, aber nicht so, wie es dieses Repo erwartet
Ihre CLAUDE.md / .cursorrules / AGENTS.md ständig wächst und abdriftet
Sie mit 2+ Agenten oder 2+ Host-Tools arbeiten (Claude Code + Cursor + Copilot)
Sie Entscheidungen, Regeln und Spezifikationen in Git haben möchten – nicht im Chat-Verlauf

Nicht geeignet für – Chat-Speicher, eine Prompt-Bibliothek oder einen einmaligen Spec-to-Code-Generator. Archcore ist eine Repo-Wahrheitsschicht für Coding-Agenten, kein Methodik-Kit.

Warum nicht einfach Anweisungsdateien?

CLAUDE.md, AGENTS.md und Repository-Anweisungen sind nützliche Ausgangspunkte, aber sie stoßen an ihre Grenzen, wenn Ihr Team Folgendes benötigt:

mehr als eine flache Speicherdatei
strukturierte Dokumenttypen – ADRs, Regeln, Pläne, Vorfälle
wiederverwendbaren Kontext über mehrere KI-Tools hinweg
versioniertes Projektwissen, das mit der Codebasis wächst
Beziehungen zwischen Dokumenten (ein Plan, der ein PRD implementiert, ein RFC, der einen ADR erweitert)
Vorfall-Erkenntnisse und wiederkehrende Workflows, die Agenten später aufgreifen können

Anweisungsdateien sagen dem Agenten, was Sie wollen. Archcore sagt dem Agenten, wie Ihr System funktioniert – sodass der Agent Ihrem System folgen kann, anstatt es zu erraten.

Unterstützte Agenten

Die Archcore CLI ist selbst ein lokaler stdio-MCP-Server – das ist die gemeinsame Integrationsfläche für jeden MCP-kompatiblen Agenten in der folgenden Tabelle. Hooks fügen proaktiven Sitzungsstart-Kontext hinzu, wo der Agent dies unterstützt.

Agent	Hooks	MCP
Claude Code	ja	ja
Cursor	ja	ja
Gemini CLI	ja	ja
GitHub Copilot	ja	ja
OpenCode	—	ja
Codex CLI	—	ja
Roo Code	—	ja
Cline	—	manuell

Wie es funktioniert

Initialisieren Sie Ihr Repo archcore init erstellt .archcore/ und installiert Integrationen für unterstützte Agenten.
Erfassen Sie dauerhaften Kontext Speichern Sie Architekturentscheidungen, Regeln, Pläne, Produktdokumente und Vorfall-Erkenntnisse als strukturierte Markdown-Dateien.
Lassen Sie Agenten ihn wiederverwenden Hooks und MCP ermöglichen es Ihren Coding-Agenten, vorhandenen Kontext zu lesen und während der eigentlichen Arbeit Dokumente zu erstellen oder zu aktualisieren.
Behalten Sie es in Git Überprüfen Sie Kontextänderungen wie Code, entwickeln Sie sie im Laufe der Zeit weiter und halten Sie sie toolübergreifend portabel.

Denkmodell

Die Archcore CLI ist der Kontext-Compiler – sie verwandelt verstreute Dokumente in strukturierten, maschinenlesbaren Kontext. MCP und Hooks sind die Laufzeitumgebung – die Oberfläche, die Agenten nutzen, um diesen Kontext während der eigentlichen Arbeit zu konsumieren. Das Archcore Plugin für Claude Code und Cursor ist eine darauf aufbauende, übergeordnete Laufzeitumgebung.

implicit repo knowledge  →  structured context  →  AI-readable system

Was sich in `.archcore/` befindet

.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

Die Struktur ist frei gestaltbar – organisieren Sie Dokumente nach Domäne, Funktion, Team oder was auch immer zu Ihrem Repo passt. Kategorien sind virtuell und werden aus dem Dokumenttyp im Dateinamen abgeleitet (slug.type.md).

Verwenden Sie .archcore/ für:

Architekturentscheidungen
Codierungsregeln und -konventionen
Implementierungspläne
Produktanforderungen
Vorfälle und Postmortems
wiederverwendbares Workflow-Wissen

Sehen Sie sich das Archcore CLI-Repository selbst als funktionierendes Beispiel an: .archcore/ in diesem Repo

Was enthalten ist

18 Dokumenttypen aus den Bereichen Vision, Wissen und Erfahrung
4 Relationstypen — related, implements, extends, depends_on
10 MCP-Werkzeuge — list_documents, get_document, create_document, update_document, remove_document, search_documents, init_project, plus Relationsverwaltung (add_relation, remove_relation, list_relations)
5 Multi-Dokument-Prompts — Track-Kaskaden, die als Slash-Befehle von MCP-kompatiblen Agenten aufrufbar sind
Hook-Integrationen für 4 Agenten (Claude Code, Cursor, Gemini CLI, GitHub Copilot) und MCP-Integrationen für 8

Dokumenttypen

Archcore organisiert Kontext in 3 Wissensebenen: Vision, Wissen und Erfahrung.

Vision

Typ	Vollständiger Name	Beschreibung
`prd`	Produktanforderungsdokument	Ziele, User Stories, Akzeptanzkriterien und Erfolgsmetriken
`idea`	Idee	Leichtgewichtige Erfassung einer Produkt- oder technischen Idee zur späteren Erkundung
`plan`	Plan	Phasenweise Aufgabenliste mit Akzeptanzkriterien und Abhängigkeiten

Archcore unterstützt auch zwei zusätzliche Anforderungs-Tracks für Teams, die eine strukturierte Entdeckung oder formale Zerlegung benötigen:

Quellen-Track (MRD → BRD → URD) – erfasst, woher Anforderungen kommen:

Typ	Vollständiger Name	Beschreibung
`mrd`	Marktanforderungsdokument	Marktlandschaft, TAM/SAM/SOM, Wettbewerbsanalyse und Marktbedürfnisse
`brd`	Geschäftsanforderungsdokument	Geschäftsziele, Stakeholder, ROI und Geschäftsregeln
`urd`	Benutzeranforderungsdokument	Benutzer-Personas, Journeys, Usability-Anforderungen und Akzeptanzkriterien

ISO/IEC/IEEE 29148:2018-Track (BRS → StRS → SyRS → SRS) – erfasst, wie Anforderungen zerlegt werden:

Typ	Vollständiger Name	Beschreibung
`brs`	Geschäftsanforderungsspezifikation	Mission, Ziele, Vorgaben und betriebliches Betriebskonzept
`strs`	Stakeholder-Anforderungsspezifikation	Stakeholder-Bedürfnisse, Betriebskonzept und Benutzeranforderungen
`syrs`	Systemanforderungsspezifikation	Systemfunktionen, Schnittstellen, Leistung und Entwurfsbeschränkungen
`srs`	Softwareanforderungsspezifikation	Softwarefunktionen, externe Schnittstellen und detaillierte Verhaltensspezifikationen

Verwenden Sie PRD für die meisten Projekte. Fügen Sie den Quellen-Track hinzu, wenn Sie eine strukturierte Anforderungsermittlung benötigen. Fügen Sie ISO 29148 hinzu, wenn Sie formale Nachverfolgbarkeit für regulierte oder komplexe Multi-Team-Systeme benötigen. Mischen Sie frei – einige Funktionen können ein PRD verwenden, während andere die vollständige Kaskade nutzen.

Wissen

Typ	Vollständiger Name	Beschreibung
`adr`	Architekturentscheidungsprotokoll	Erfasst eine finalisierte technische Entscheidung mit Kontext, Alternativen und Konsequenzen
`rfc`	Kommentaranforderung	Schlägt eine bedeutende Änderung vor, die zur Teamüberprüfung und für Feedback offen ist
`rule`	Regel	Codierungs- oder Prozessstandard mit verbindlicher Anleitung und Beispielen
`guide`	Anleitung	Schritt-für-Schritt-Anleitung zur Durchführung einer bestimmten Aufgabe
`doc`	Dokument	Referenzdokumentation, Register und beschreibendes Material
`spec`	Spezifikation	Kanonischer normativer Vertrag für ein System, eine Komponente, eine Schnittstelle oder ein Protokoll

Erfahrung

Typ	Vollständiger Name	Beschreibung
`task-type`	Aufgabentyp	Wiederverwendbare Checkliste und Workflow für eine wiederkehrende Aufgabe
`cpat`	Code-Änderungsmuster	Ursachenanalyse eines Fehlers oder Vorfalls mit Präventionsschritten

Jedes Dokument ist eine Markdown-Datei mit YAML-Frontmatter:

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

## Context

...

Gültige Status: draft, accepted und rejected. Tags sind optional und frei wählbar – verwenden Sie sie, um übergreifende Themen zu kennzeichnen (security, golang, frontend).

Dokumentbeziehungen

Dokumente können mit gerichteten Beziehungen zu anderen Dokumenten verknüpft werden:

related — allgemeine Assoziation
implements — Quelle implementiert, was Ziel spezifiziert
extends — Quelle baut auf Ziel auf
depends_on — Quelle benötigt Ziel, um fortzufahren

Beziehungen werden in .sync-state.json gespeichert und automatisch vom KI-Agenten über MCP-Tools verwaltet.

KI-Agenten-Integration

Archcore integriert sich auf drei Arten mit KI-Coding-Agenten:

Hooks injizieren Kontext zu Sitzungsbeginn, sodass der Agent Ihre .archcore/-Dokumente ab der ersten Nachricht kennt.
MCP-Tools geben dem Agenten die Fähigkeit, Dokumente in Echtzeit aufzulisten, zu suchen, zu lesen, zu erstellen, zu aktualisieren und zu verknüpfen. Der MCP-Server funktioniert auch in einem leeren Repository und stellt ein init_project-Tool bereit, sodass Agenten .archcore/ selbst bootstrappen können.
MCP-Prompts sind vorgefertigte Multi-Dokument-Workflows, die Sie von Ihrem Agenten als Slash-Befehle auslösen.

Prompts

Prompts orchestrieren vollständige Dokumentkaskaden in einem Aufruf – der Agent erstellt und verknüpft jedes Dokument im Track für Sie. Die meisten MCP-kompatiblen Agenten zeigen sie als Slash-Befehle an (z. B. /architecture_track); das genaue Präfix hängt vom Client ab.

Prompt	Was er bewirkt
`product_track`	Idee → PRD → Plan (schlanker Feature-Ablauf)
`architecture_track`	ADR → Spezifikation → Plan (technisches Design + Implementierung)
`standard_track`	ADR → Regel → Leitfaden (einen Teamstandard kodifizieren)
`sources_track`	MRD → BRD → URD (Markt-/Geschäfts-/Benutzererkundung)
`iso_track`	BRS → StRS → SyRS → SRS (formale ISO-29148-Kaskade)

Beispiel. Führen Sie in Ihrem Agenten /product_track feature="user notifications" aus. Der Agent entwirft eine Idee, leitet ein PRD ab, erstellt einen Implementierungsplan und verknüpft sie automatisch.

Lokaler MCP-Server

Archcore benötigt keinen gehosteten Dienst. Die CLI führt einen lokalen stdio-MCP-Server aus:

archcore mcp

Standardmäßig bedient archcore mcp Dokumente aus dem aktuellen Verzeichnis. Übergeben Sie --project /path/to/repo (oder setzen Sie ARCHCORE_PROJECT_ROOT), um auf ein anderes Verzeichnis zu verweisen – nützlich, wenn der Server aus einem Verzeichnis gestartet wird, das nicht Ihr Arbeitsbereich ist (z. B. durch eine Editor-Integration).

Binden Sie ihn in Claude Code ein:

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

Oder installieren Sie ihn automatisch für einen unterstützten Agenten:

archcore mcp install --agent cursor

Integrationen installieren

# 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

Befehle

Befehl	Beschreibung
`archcore init`	`.archcore/`-Verzeichnis interaktiv initialisieren
`archcore doctor`	Ihr Archcore-Setup prüfen und Probleme beheben
`archcore status`	.archcore/-Struktur und Dokumentzustand prüfen
`archcore config`	Einstellungen anzeigen oder ändern
`archcore hooks install`	Hooks für erkannte KI-Agenten installieren
`archcore update`	Archcore auf die neueste Version aktualisieren
`archcore mcp`	Den MCP-stdio-Server ausführen
`archcore mcp install`	MCP-Konfiguration für erkannte Agenten installieren

Aktualisieren

archcore update

Der Befehl prüft GitHub Releases auf eine neuere Version, lädt sie herunter, verifiziert die SHA-256-Prüfsumme und ersetzt die aktuelle Binärdatei atomar.

Installationsmethoden

macOS / Linux

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

Windows

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

Installiert archcore.exe unter %LOCALAPPDATA%\Programs\archcore und fügt es Ihrem Benutzer-PATH hinzu. Öffnen Sie nach der Installation ein neues PowerShell-Fenster, damit die PATH-Änderung übernommen wird.

Windows (WSL)

Installieren Sie WSL und führen Sie dann darin aus:

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

Go-Installation

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

Aus dem Quellcode

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

Unterstützte Plattformen: macOS, Linux, Windows – amd64 und arm64.

Informationen zu Umgebungsvariablen (ARCHCORE_VERSION, ARCHCORE_INSTALL_DIR, GITHUB_TOKEN) und PATH-Fehlerbehebung finden Sie im vollständigen Installationsleitfaden auf docs.archcore.ai.

Konfiguration

Einstellungen werden in .archcore/settings.json gespeichert und während archcore init erstellt.

Feld	Beschreibung	Werte
`sync`	Synchronisationsmodus. Cloud und On-Prem folgen in Kürze.	`none` (nur lokal), `cloud`, `on-prem`
`language`	Dokumentsprache. Hilft dem Agenten, Dokumentation in der richtigen Sprache zu generieren.	Zeichenkette, Standard `en`

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

Entwicklung

Voraussetzungen

Go 1.24+

Bauen & Testen

# 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

Projektstruktur

├── 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

Ist Archcore wie BMAD / Spec Kit / Memory Bank?

Nein – diese lösen unterschiedliche Probleme. Kurzübersicht:

Tool	Kategorie	Was es ist	Wie sich Archcore unterscheidet
BMAD	Methodik	Agentische SDLC-Methodik – 12+ Rollen, 34+ Workflows	Archcore speichert Artefakte; BMAD schreibt Prozesse vor
Spec Kit	Methodik	Spezifikationsgetriebener Workflow: `specify → plan → tasks → implement`, einmalig	Spec Kit ist eine einmalige Übergabe; Archcore pflegt einen lebendigen Graphen, der sich mit der Codebasis entwickelt
Agent OS	Methodik	Extraktion von Codebasis-Standards + spezifikationsgetriebene Entwicklung	Nächste Positionierung. Archcore fügt typisierte Dokumente, validierte Beziehungen und eine optionale ISO-Kaskade hinzu
claude-mem / Mem0	Speicher	Erfasst automatisch Sitzungsspeicher, agentenübergreifender Abruf	Speicher-Tools merken sich, was Sie getan haben; Archcore speichert, wie das System gebaut ist und was entschieden wurde
Cline Memory Bank	Dokumente	Markdown-Dateien mit festem Schema (`projectbrief`, `activeContext`, `systemPatterns`…)	Gleicher Geist, weniger Zeremoniell. Archcore fügt typisierte Beziehungen, MCP-Validierung und mehrstufige Kaskaden hinzu
CLAUDE.md / .cursorrules	Anweisungen	Einzelne flache Datei, die der Agent zu Sitzungsbeginn liest	Archcore ersetzt eine wachsende Anweisungsdatei durch typisierte, verknüpfte, abfragbare Dokumente

Wählen Sie ein Methodik-Tool für einen meinungsstarken Entwicklungsablauf. Wählen Sie ein Speicher-Tool für Sitzungskontinuität. Wählen Sie Archcore, wenn Sie typisierte, abfragbare Projektwahrheit – die Entscheidungen, Regeln und Architektur dieses Repos – möchten, die Ihr Coding-Agent bei jeder Anfrage respektiert.

Links & Lizenz

Dokumentation: docs.archcore.ai
Website: archcore.ai
Plugin (Claude Code, Cursor): github.com/archcore-ai/archcore-plugin
Issues: github.com/archcore-ai/cli/issues
Lizenz: Apache 2.0