DPR MCP Plattform für KI-gestützte Dokumentenzusammenarbeit

Dieses Projekt ist eine lokale, Git-gestützte Plattform für die Zusammenarbeit an Dokumenten, bei der Menschen und KI-Agenten sicher gemeinsam an Dokumenten arbeiten können.

Sie kombiniert:

• Model Context Protocol-Server

• echten MCP-stdio-Client

• React-Dashboard

• LangGraph-basierte Agenten

• Git-gestützte Versionierung

• isolierte Arbeitsbereiche

• Change Requests

• menschliche Prüfung und Merge

• Konflikterkennung

• Konfliktlösungsvorschläge

• Herkunftsverfolgung (Provenance Tracking)

Die Kernidee:

AI agents can write and review documents, but they cannot silently overwrite main.
Every edit becomes a versioned, reviewable, traceable Change Request.

Warum es dieses Projekt gibt

Normale KI-Dokumentbearbeitung ist riskant, weil ein Agent eine Datei direkt überschreiben, die Historie verlieren, die Änderungen mehrerer Benutzer vermischen oder unklar machen kann, wer was und warum geändert hat.

Dieses Projekt löst das, indem es KI-Agenten hinter ein kontrolliertes Kollaborationsprotokoll stellt:

Agent -> MCP Client -> MCP Server -> Controlled Tools -> Git + SQLite

Der Agent verändert nicht direkt das maßgebliche Dokument-Repository. Er erstellt einen isolierten Workspace, bearbeitet dort Dateien, öffnet einen Change Request und wartet auf die menschliche Prüfung.

Related MCP server: agentsync

Architektur

Gesamte Projektarchitektur:

Agentenarchitektur der Phase 2:

Ablauf auf hoher Ebene:

React Dashboard / External MCP Client
        |
        v
Dashboard API
        |
        v
LangGraph Agents
        |
        v
DPRMCPClient
        |
        v
MCP stdio
        |
        v
DPR MCP Server
        |
        v
MCP Tools
        |
        v
DPR Services
        |
        v
Git Repositories + Isolated Workspaces + SQLite Metadata

Hauptkomponenten

MCP-Server

Der MCP-Server ist die kontrollierte Backend-Schnittstelle. Er stellt sichere Werkzeuge für die Zusammenarbeit an Dokumenten bereit.

Einstiegspunkt:

src/dpr_mcp/server.py

Wichtige Werkzeuge:

• create_project

• create_workspace

• read_project_file

• read_change_file

• create_file

• edit_file

• create_change

• review_change

• approve_change

• merge_change

• get_diff

• get_file_patch

• get_conflicts

• propose_conflict_resolution

• apply_conflict_resolution

• rollback_change

• get_provenance

Direkt ausführen:

python -m dpr_mcp.server

Der Server spricht MCP über stdio. Üblicherweise kommuniziert ein Client mit ihm; man tippt nicht manuell in den Prozess.

Echter MCP-Client

Der wiederverwendbare MCP-Client befindet sich hier:

src/dpr_mcp/mcp/client.py

Er startet bzw. verbindet sich über stdio mit dem DPR-MCP-Server und ruft Werkzeuge namentlich auf. Das ist dasselbe Prinzip, das auch externe MCP-Clients wie Claude Code verwenden.

Demo mit dem echten Client ausführen:

python examples\real_mcp_client.py

Erwartete Ausgabe:

Connected to DPR MCP server. 35 tools available.
Project: client-demo
Workspace: ws-...
Change request: CR-...
Open changes: 1

React-Dashboard

Das Dashboard ist die Benutzeroberfläche für Menschen.

Es ermöglicht einem Benutzer:

• den lokalen DPR-Wurzelordner auszuwählen

• Projekte zu erstellen

• Dokumente anzusehen

• Agenten auszuführen

• Change Requests zu prüfen

• Diffs zu überprüfen

• genehmigte Änderungen zu mergen

• Konflikte zu prüfen

• Verlauf und Provenienz zu betrachten

Backend:

src/dpr_mcp/dashboard.py

Frontend:

frontend/

LangGraph-Agenten

Die AgentenWorkflow-Agentenestar liegt hier:

src/dpr_mcp/agents/workflows.py

Die Live-Agentenaktionen im Dashboard erzeugen einen echten DPRMCPClient, verbinden sich über stdio mit dem MCP-Server und rufen MCP-Tools auf. Der Agentenpfad ist damit:

Dashboard -> LangGraph Agent -> DPRMCPClient -> MCP Server -> MCP Tools

Aktuelle Agenten:

• Draft Agent

• Reviwer Agent

• Compliance Agent

• Conflict Resolver AgentSure

Die LLM-Integration befindet sich hier:

src/dpr_mcp/agents/llm.py

Unterstützte Modi:

• Groq

• OpenAI

• Modus abhängig von Fallback, wenn kein Schlüssel konfiguriert ist

Agent-Workflow

Draft Agent

Der Draft Agent erstellt oder verbessert ein Dokument.

Beispiel-Prompt:

Write a detailed report about smart waste segregation for a college campus.

Interner Ablauf:

Dashboard
-> LangGraph Draft Agent
-> DPRMCPClient
-> MCP server
-> list_files
-> read_project_file if the file exists
-> create_workspace
-> create_file or edit_file
-> create_change

Ergebnis:

A new Change Request is created.
The file is not directly merged into main.

Reviewer Agent

Der Reviewer Agent prüft:

• Klarheit

• Ordnungsstruktur

• Vollständigkeit

• technischen Nutzen

• ob die Änderung der Absicht des Benutzers entspricht

Interner Ablauf:

Reviewer Agent
-> DPRMCPClient
-> get_change
-> get_diff
-> get_file_patch
-> review_change

Ergebnis:

A review comment is added to the Change Request.

Der Reviewer Agent ersetzt keine menschliche Genehmigung. Er bietet nur Feedback, bevor ein Mensch über einen Merge entscheidet.

Compliance Agent

Der Compliance Agent prüft, ob eine Änderung sicher und richtlinienkonform ist.

Er sucht nach:

• nicht unterstützten Dateitypen

• Geheimnissen oder Zugangsdaten

• Platzhaltertext

• erfundenen Angaben

• riskanten Behauptungen

• fehlenden Berichtsschnitten

Interner Ablauf:

Compliance Agent
-> DPRMCPClient
-> get_change
-> get_diff
-> get_file_patch
-> review_change

Ergebnis:

The Change Request receives a compliance review.
If there is a blocking issue, the review requests changes.

Conflict Resolver Agent

Der Conflict Resolver Agent wird eingesetzt, wenn Git an unseren Flug eine echten Merge-Konflikt erkennt.

Interner Ablauf:

Resolver Agent
-> DPRMCPClient
-> get_change
-> get_conflicts
-> create_workspace
-> read_project_file
-> read_change_file
-> edit_file
-> propose_conflict_resolution

Ergebnis:

A new resolution Change Request is created.
The human still reviews and merges the resolution.

Der Resolver umgeht die Überprüfung nicht. Er schlägt nur einen Fix vor.

Welche echten Konflikte entstehen

Ein Konflikt entsteht, wenn zwei Änderungen auf Basis derselben alten Vorstufe dieselbe Stelle derselben Datei bearbeiten.

Beispiel:

main has report.md

Dann:

Agent A creates CR-1 editing report.md
Agent B creates CR-2 editing the same paragraph in report.md
Human merges CR-1 first
Human tries to merge CR-2
Git detects that CR-2 was based on old main and touched the same lines
CR-2 becomes conflicted

Dann:

Conflict Resolver Agent reads current main and incoming CR-2
Resolver writes a combined version in a new workspace
Resolver opens a resolution CR
Human reviews and merges the resolution CR

Das ist ein echter, realer-Konflikt-Handlung nicht UI-only beeinflusst.

Grundlagen: Wo Dateien erstellt werden

Das Dashboard fragt nach einem Wurzelordner.

Wenn für den Rootfolder gilt:

C:\Users\janan\dpr-mcp\data

dann verwendet das System:

data\projects      -> canonical Git repositories
data\workspaces    -> isolated Git worktrees
data\dpr_mcp.db    -> SQLite metadata database

Wichtig:

Documents are local files inside Git-backed project repositories.
Workspaces are temporary isolated edit areas.
SQLite stores metadata such as workspaces, changes, reviews, conflicts, and roles.

Warum Git verwendet wird

Git übernimmt:

• Commits

• Branches

• Worktrees

• Diffs

• Die-Mergbarkeits-Überprüfung

• Merge-Konflikte

• Merge-Verlauf

• Rollback über Forward-Commits

Das Projekt erfindet keine Versionsverwaltung neu. Es nutzt Git als Source of Truth und klemmt einen Kollaborations-Workflow darüber.

Warum SQLite verwendet wird

Git ist gut für Datei-Historie, aber es speichert Metadaten der Zusammenarbeit nicht naturschützend, etwa:

• Change-Request-Status

• Reviewer-Kommentare

• Genehmigungen

• Konfliktlösungs-Protokolle

• Workspace-Eigentum

• Rollenbindungen

• Event-Logs

Diese Metadaten werden in SQLite gespeichert.

Human-Governance

Das System ist bewusst human-in-the-Loop konzipiert.

Agenten können:

• Dokumente entwerfen

• Änderungen überprüfen

• Compliance überprüfen

• Konfliktlösungen vorschlagen

Menschen steuern:

• die endgültige Genehmigung

• den Merge

• Rollback

• Projektzugriff bzw. Auswahl des Wurzelordners

Das ist wichtig, denn das Projekt zielt sichere KI-gestützte Zusammenarbeit, nicht unkontrolliertes autonomes Bearbeiten.

Sicherheitsmodell

Dateifoperationen sind auf die konfigurierten Repository- und Workspace-Wurzel.

Die DateisicherheitsEbene lehnt ab:

• absolute Pfade

• Path-Traversal:

• Symlink-Escapes

• Null-Bytes

• Steuerzeichen

• sensibele argumentierenen Dateinamen wie .env, private Schlüssel und Zugangsdaten

Relevante Dateien:

src/dpr_mcp/files/security.py
src/dpr_mcp/files/service.py
tests/security/

Setup

Von Command Zeile unter Windows (gilt evtl. Windows):

cd /d C:\Users\janan\dpr-mcp
python -m venv .venv
.venv\Scripts\activate
pip install -e ".[dev]"
cd frontend
npm install
cd ..

Falls das Environment bereits existiert:

cd /d C:\Users\janan\dpr-mcp
.venv\Scripts\activate

Umgebungsvariablen

Erstellen Sie eine .env-Datei im Projektroot, falls echte LLMs eingesetzt werden.

Für Groq:

DPR_LLM_PROVIDER=groq
GROQ_API_KEY=your_key_here
DPR_LLM_MODEL=llama-3.3-70b-versatile

Für OpenAI:

DPR_LLM_PROVIDER=openai
OPENAI_API_KEY=your_key_here
DPR_LLM_MODEL=gpt-5

Wenn kein Schlüssel konfiguriert ist, laufen die Agenten im Fallback-Modus-Weiter, aber der Inhalt würde uneinsam sein.

Dashboard starten

Backend:

cd /d C:\Users\janan\dpr-mcp
.venv\Scripts\activate
python -m dotenv run -- python -m dpr_mcp.dashboard --host 127.0.0.1 --port 8787 --root data

Frontend:

cd /d C:\Users\janan\dpr-mcp\frontend
npm run dev

Öffnen Sie die Vite-URL, die das z.B.: Termin anzeigt:

http://127.0.0.1:5173

Die API des Dashboard-Backends läuft unter:

http://127.0.0.1:8787

Den MCP-Server direkt ausführen

cd /d C:\Users\janan\dpr-mcp
.venv\Scripts\activate
python -m dpr_mcp.server

Das startet den MCP-Server über stdio.

Demo des echten MCP-Clients ausführen

cd /d C:\Users\janan\dpr-mcp
.venv\Scripts\activate
python examples\real_mcp_client.py

Das beweits:

Python client
-> MCP stdio server
-> MCP tools
-> project/workspace/file/change created

Repository-Übersicht

src/dpr_mcp/server.py              MCP server entry point
src/dpr_mcp/dashboard.py           local dashboard HTTP API
src/dpr_mcp/mcp/tools.py           MCP tool definitions
src/dpr_mcp/mcp/client.py          real MCP stdio client
src/dpr_mcp/mcp/gateway.py         in-process MCP-shaped gateway
src/dpr_mcp/agents/workflows.py    LangGraph agent workflows
src/dpr_mcp/agents/llm.py          Groq/OpenAI/fallback generation
src/dpr_mcp/projects/              project repository management
src/dpr_mcp/workspace/             isolated worktree management
src/dpr_mcp/collaboration/         changes, reviews, approvals, conflicts
src/dpr_mcp/files/                 safe local file access
src/dpr_mcp/git/                   Git CLI wrapper
src/dpr_mcp/persistence/           SQLite models and repositories
src/dpr_mcp/provenance/            provenance reconstruction
frontend/                          React dashboard
examples/                          runnable MCP and conflict demos
tests/                             unit, integration, security, MCP tests
docs/                              architecture and technical docs

Aktueller Stand

Implementiert:

• MCP-Server

• echten native Client

• React-Dashboard

• LangGraph-Agenten

• LLM-Integration

• lokale GitHub Repository-Projekte

• isolierte Workspaces

• Change Requests

• Reviews

• Compliance-Prüfungen

• Merge-Flow

• Konflikterkenntnis

• KonfliktlösungsVorschläge

• Rollback

• Provenienz

• Architektur-Diagramme

• Tests# DPR MCP Plattform für KI-gestützte Dokumentenzusammenarbeit

Dieses Projekt ist eine lokale, Git-gestützte Plattform für die Zusammenarbeit an Dokumenten, auf der Menschen und KI-Agenten sicher an gemeinsamen Dokumenten arbeiten können.

Sie kombiniert:

• Model Context Protocol Server

• echten MCP-stdio-Client

• React-Dashboard

• LangGraph-basierte Agenten

• Git-gestützte Versionierung

• isolierte Workspaces

• Change Requests

• menschliche Prüfung und Merge

• Konflikterkennung

• Konfliktlösungsvorschläge

• Provenienz-Nachverfolgung

Die Kernidee:

AI agents can write and review documents, but they cannot silently overwrite main.
Every edit becomes a versioned, reviewable, traceable Change Request.

Warum es dieses Projekt gibt

Normale KI-Dokumentbearbeitung ist riskant, weil ein Agent eine Datei direkt überschreiben, die Historie verlieren, die Änderungen mehrerer Benutzer vermischen oder unklar machen kann, wer was und warum geändert hat.

Dieses Projekt löst das, indem es KI-Agenten hinter ein kontrolliertes Kollaborationsprotokoll stellt:

Agent -> MCP Client -> MCP Server -> Controlled Tools -> Git + SQLite

Der Agent verändert nicht direkt das verbindliche Dokument-Repository. Er erstellt einen isolierten Workspace, bearbeitet dort Dateien, öffnet einen Change Request und wartet auf die menschliche Prüfung.

Architektur

Gesamte Projektarchitektur:

Agentenarchitektur der Phase 2:

Ablauf auf hoher Ebene:

React Dashboard / External MCP Client
        |
        v
Dashboard API
        |
        v
LangGraph Agents
        |
        v
DPRMCPClient
        |
        v
MCP stdio
        |
        v
DPR MCP Server
        |
        v
MCP Tools
        |
        v
DPR Services
        |
        v
Git Repositories + Isolated Workspaces + SQLite Metadata

Hauptkomponenten

MCP-Server

Der MCP-Server ist die kontrollierte Backend-Schnittstelle. Er stellt sichere Werkzeuge für die Dokumentenzusammenarbeit bereit.

Einstiegspunkt:

src/dpr_mcp/server.py

Wichtige Werkzeuge:

• create_project

• create_workspace

• read_project_file

• read_change_file

• create_file

• edit_file

• create_change

• review_change

• approve_change

• merge_change

• get_diff

• get_file_patch

• get_conflicts

• propose_conflict_resolution

• apply_conflict_resolution

• rollback_change

• get_provenance

Direkt ausführen:

python -m dpr_mcp.server

Der Server spricht MCP über stdio. Üblicherweise kommuniziert ein Client mit ihm; Sie müssen nicht manuell in den Prozess.

Echter MCP-Client

Der wiederverwendbare MCP-Client befindet sich hier:

src/dpr_mcp/mcp/client.py

Er startet bzw. verbindet sich über stdio mit dem DPR-MCP-Server und ruft namentlich Werkzeuge auf. Dasselbe Prinzip verwenden auch externe MCP-Clients wie Claude Code.

Demo mit dem echten Client ausführen:

python examples\real_mcp_client.py

Erwartete Ausgabe:

Connected to DPR MCP server. 35 tools available.
Project: client-demo
Workspace: ws-...
Change request: CR-...
Open changes: 1

React-Dashboard

Das Dashboard ist die Benutzeroberfläche für Menschen.

Es ermöglicht Benutzern:

• den lokalen DPR-Wurzelordner zu wählen

• Projekte zu erstellen

• Dokumente anzusehen

• Agenten auszuführen

• Change Requests zu überprüfen

• Diffs zu überprüfen

• genehmigte Änderungen zu mergen

• Konflikte zu überprüfen

• Verlauf und Provenienz anzusehen

Backend:

src/dpr_mcp/dashboard.py

Frontend:

frontend/

LangGraph-Agenten

Die Agentenworkflow-Ebene befindet sich hier:

src/dpr_mcp/agents/workflows.py

Die Agent-Aktionen im Live-Dashboard erzeugen einen echten DPRMCPClient, verbinden sich über stdio mit dem MCP-Server und rufen MCP-Tools auf. Der Agentenpfad ist also:

Dashboard -> LangGraph Agent -> DPRMCPClient -> MCP Server -> MCP Tools

Aktuelle Agenten:

• Draft Agent

• Reviewer Agent

• Compliance Agent

• Conflict Resolver Agent

Die LLM-Integration befindet sich hier:

src/dpr_mcp/agents/llm.py

Unterstützte Modi:

• Groq

• OpenAI

• Fallback-Modus, wenn kein Schlüssel konfiguriert ist

Agent-Workflow

Draft Agent

Der Draft Agent erstellt oder verbessert ein Dokument.

Beispiel-Prompt:

Write a detailed report about smart waste segregation for a college campus.

Interner Ablauf:

Dashboard
-> LangGraph Draft Agent
-> DPRMCPClient
-> MCP server
-> list_files
-> read_project_file if the file exists
-> create_workspace
-> create_file or edit_file
-> create_change

Ergebnis:

A new Change Request is created.
The file is not directly merged into main.

Reviewer Agent

Der Reviewer Agent prüft:

• Klarheit

• Struktur

• Vollständigkeit

• technischen Nutzen

• ob die Änderung der Absicht des Benutzers entspricht

Interner Ablauf:

Reviewer Agent
-> DPRMCPClient
-> get_change
-> get_diff
-> get_file_patch
-> review_change

Ergebnis:

A review comment is added to the Change Request.

Der Reviewer Agent ersetzt keine menschliche Genehmigung. Er gibt Feedback, bevor ein Mensch über einen Merge entscheidet.

Compliance Agent

Der Compliance Agent prüft, ob eine Änderung sicher und policykonform ist.

Er sucht nach:

• nicht unterstützten Dateitypen

• Geheimnissen oder Zugangsdaten

• Platzhaltertext

• erfundenen Belegen

• unsicheren Behauptungen

• fehlenden Berichtsabschnitten

Interner Ablauf:

Compliance Agent
-> DPRMCPClient
-> get_change
-> get_diff
-> get_file_patch
-> review_change

Ergebnis:

The Change Request receives a compliance review.
If there is a blocking issue, the review requests changes.

Conflict Resolver Agent

Der Conflict Resolver Agent wird eingesetzt, wenn Git einen echten Merge-Konflikt erkennt.

Interner Ablauf:

Resolver Agent
-> DPRMCPClient
-> get_change
-> get_conflicts
-> create_workspace
-> read_project_file
-> read_change_file
-> edit_file
-> propose_conflict_resolution

Ergebnis:

A new resolution Change Request is created.
The human still reviews and merges the resolution.

Der Resolver umgeht die Prüfung nicht. Er schlägt nur einen Fix vor.

Entstehen eines echten Konflikts

Ein Konflikt entsteht, wenn zwei Änderungen auf derselben alten Ausgangsbasis denselben Teil derselben Datei bearbeiten.

Beispiel:

main has report.md

Dann:

Agent A creates CR-1 editing report.md
Agent B creates CR-2 editing the same paragraph in report.md
Human merges CR-1 first
Human tries to merge CR-2
Git detects that CR-2 was based on old main and touched the same lines
CR-2 becomes conflicted

Dann:

Conflict Resolver Agent reads current main and incoming CR-2
Resolver writes a combined version in a new workspace
Resolver opens a resolution CR
Human reviews and merges the resolution CR

Das ist ein echter Git-Konfliktablauf, kein künstlicher UI-metastas KonfliktYO.

Where Files Are Created - Wo Dateien erstellt werden

Das Dashboard fragt nach einem Wurzelordner.

Wenn der Wurzelordner lautet:

C:\Users\janan\dpr-mcp\data

dann verwendet das System:

data\projects      -> canonical Git repositories
data\workspaces    -> isolated Git worktrees
data\dpr_mcp.db    -> SQLite metadata database

Wichtig:

Documents are local files inside Git-backed project repositories.
Workspaces are temporary isolated edit areas.
SQLite stores metadata such as workspaces, changes, reviews, conflicts, and roles.

Why Git Is Used

Git übernimmt:

• Commits

• Branches

• Worktrees

• Diffs

• Mergeability Checks

• Merge-Konflikte

• Merge-Historie

• Rollback über Forward-Commits

Das Projekt erfindet die Versionskontrolle nicht neu. Es verwendet Git als Saatquelle der Wahrheit und fügt obendrauf einen Kollaborationsworkflow hin asüge.

Why SQLite Is Used

Git eignet sich für die Dateihistorie, aber es speichert nicht von Netz aus Kollaborations-Metadaten wie:

Status des Change Request, reviewer comments, Abnahmen, Konfliktlösungs-Protokol..

• Change-Request-Status

• Prüferkommentare

• Genehmigungen

• Aufzeichnungen zur Konfliktlösungen

• Workspace-Eigentümer

• Rollenbindungen

• Ereignis-Logs

Diese Metadaten werden in SQLite gespeichert.

Human Governance

Das System ist absichtlich human-in-the-Loop.

Agenten können:

• Dokumente entwerfen

• Änderungen überprüfen

• Compliance prüfen

• Konfliktlösungen vorschlagen

Menschen kontrollieren:

• die endgültige Genehmigung

• den Merge

• Rollback

• Projektzugriff bzw. Wurzelwahl

Das ist wichtig, denn das Projekt schafft sich auf sichere KI-gestützte Zusammenarbeit, nicht auf unkontrolliertes autonomes Bearbeiten.

Security Model

Dateioperationen: auf das konfigurierte Repository und die Workspace-Stammverzeichnisse beschränkt sind.

Die Dateisicherheitsebene lehnt angewiesene Operationen:

• absolute Pfade

• Verzeichnisüberschreitungen

• Symlink-Eskapaden

• Null-Bytes

• Steuerzeichen

• sensitive Dateinamen wie .env, private Schlüssel und Anmeldedaten

Relevant files.

src/dpr_mcp/files/security.py
src/dpr_mcp/files/service.py
tests/security/

Setup

Aus der CMD auf Windows:

cd /d C:\Users\janan\dpr-mcp
python -m venv .venv
.venv\Scripts\activate
pip install -e ".[dev]"
cd frontend
npm install
cd ..

Wenn das Environment bereits existiert:

cd /d C:\Users\janan\dpr-mcp
.venv\Scripts\activate

Environment-Variablen

Erstellen Sie eine .env-Datei im Projektstamm.

Für Groq:

DPR_LLM_PROVIDER=groq
GROQ_API_KEY=your_key_here
DPR_LLM_MODEL=llama-3.3-70b-versatile

Für OpenAI:

DPR_LLM_PROVIDER=openai
OPENAI_API_KEY=your_key_here
DPR_LLM_MODEL=gpt-5

Wenn kein Schlüssel konfiguriert ist, laufen die Agenten im Fallback-Modus weiter, aber der /Inhalt bleibt Butterfly.

Dashboard starten

Backend:

cd /d C:\Users\janan\dpr-mcp
.venv\Scripts\activate
python -m dotenv run -- python -m dpr_mcp.dashboard --host 127.0.0.1 --port 8787 --root data

Frontend:

cd /d C:\Users\janan\dpr-mcp\frontend
npm run dev

Öffnen Sie die Vite-URL, die normalerweise auf Methode des Terminals angezeigt wird:

http://127.0.0.1:5173

Die Backend-API des Dashboard läutert und:

http://127.0.0.1:8787

Den MCP-Server direkt starten

cd /d C:\Users\janan\dpr-mcp
.venv\Scripts\activate
python -m dpr_mcp.server

Damit wird der MCP-Server über stdio gestartet.

Demo des echten MCP-Clients

cd /d C:\Users\janan\dpr-mcp
.venv\Scripts\activate
python examples\real_mcp_client.py

Das beweist:

Python client
-> MCP stdio server
-> MCP tools
-> project/workspace/file/change created

Repository-Übersicht

src/dpr_mcp/server.py              MCP server entry point
src/dpr_mcp/dashboard.py           local dashboard HTTP API
src/dpr_mcp/mcp/tools.py           MCP tool definitions
src/dpr_mcp/mcp/client.py          real MCP stdio client
src/dpr_mcp/mcp/gateway.py         in-process MCP-shaped gateway
src/dpr_mcp/agents/workflows.py    LangGraph agent workflows
src/dpr_mcp/agents/llm.py          Groq/OpenAI/fallback generation
src/dpr_mcp/projects/              project repository management
src/dpr_mcp/workspace/             isolated worktree management
src/dpr_mcp/collaboration/         changes, reviews, approvals, conflicts
src/dpr_mcp/files/                 safe local file access
src/dpr_mcp/git/                   Git CLI wrapper
src/dpr_mcp/persistence/           SQLite models and repositories
src/dpr_mcp/provenance/            provenance reconstruction
frontend/                          React dashboard
examples/                          runnable MCP and conflict demos
tests/                             unit, integration, security, MCP tests
docs/                              architecture and technical docs

Aktueller Stand

Implemented:

• MCP-Server

• echtem MCP-stdio-Client

• React-Dashboard

• LangGraph-Agenten

• LLM-Integration

• lokalen Git-Projekt-Repositories

• isolierte Workspaces

• Änderungsanfragen (Change Requests)

• Reviews

• Compliance-Prüfungen

• Merge-Flow

• Konflikterkennung

• Konfliktlösungsvorschläge

• Rollback

• Provenienz

• Architekturdiagramme

• Tests