dpr-mcp
# DPR Git-Backed MCP Collaboration Server
A standalone [Model Context Protocol](https://modelcontextprotocol.io) server
that provides a safe, multi-agent, human-in-the-loop collaboration interface
over a local Git repository.
Git remains the source of truth for files, commits, branches, diffs, and
merge history. This server adds the collaboration control plane above it:
identity, authorization, isolated workspaces, Change Requests, reviews,
approval policy, conflict workflow, rollback, and provenance.
This is **Phase 1**: a standalone server, independently usable by Claude
Code, VS Code agents, or any other MCP-compatible client. It has no
dependency on the DPR multi-agent reasoning project.
## Quick start
```bash
python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
# Optional: configure who this server instance acts as. Defaults to
# human:$USER driving agent:claude-code.
export DPR_PRINCIPAL_ID=charan
export DPR_ACTOR_ID=claude-code
# Optional: where projects/workspaces/the collaboration DB live.
export DPR_REPOSITORY_ROOT=./data/projects
export DPR_WORKSPACE_ROOT=./data/workspaces
export DPR_DATABASE_URL=sqlite:///./data/dpr_mcp.db
dpr-mcp
```
The server speaks MCP over stdio. Point any MCP-compatible client (Claude
Code, an MCP Inspector, a custom client) at the `dpr-mcp` command.
## Example flow
```
create_project(project_id="demo", name="Demo Project")
create_workspace(project_id="demo") -> workspace_id
create_file(workspace_id, "notes.md", "# Hi")
create_change(workspace_id, rationale="Add notes") -> change_id
review_change(change_id, decision="APPROVED") # as a human reviewer
merge_change(change_id)
get_provenance(change_id)
```
See `examples/` for runnable scripts, including a multi-agent conflict
scenario (`examples/multi_agent_demo.py`, `examples/conflict_demo.py`).
## Architecture
See [`docs/architecture.md`](docs/architecture.md) for the full picture.
In short:
```
MCP Client
|
v
DPR MCP Server (identity, authz, workspaces, changes, reviews, policy,
| conflicts, provenance)
v
Git Repository (commits, branches, diffs, merge)
```
Git is never reinvented: branches, commits, diffs, and merges are all
delegated to the real `git` CLI via a single `GitRepository` abstraction
(`src/dpr_mcp/git/repository.py`). Collaboration state Git doesn't model
(change requests, reviews, approvals, workspaces, policies) lives in a
small SQLite database (`src/dpr_mcp/persistence/`).
## Security
File access is sandboxed to the configured project root: path traversal,
absolute paths, and symlink escapes are rejected (`src/dpr_mcp/files/security.py`).
Sensitive filenames (`.env`, `.pem`, `.key`, `*credentials*`) are blocked by
default. See [`docs/security.md`](docs/security.md) and
`tests/security/` for the full threat model and the tests that enforce it.
## Development
```bash
pytest # unit + integration + security + mcp tests
ruff check src tests
mypy src
```
## Phase 2
Phase 2 (not implemented here) will make the existing DPR multi-agent
orchestrator (`https://github.com/Skanda-P-R/Multi-Agent-Reasoning`) an MCP
client of this server, so DPR's internal agents can inspect, create, modify,
review, and collaboratively integrate project artifacts through exactly this
interface, with Git still holding the version-control ground truth and DPR
handling reasoning/orchestration.
TDQS
Scored across 32 tools
Every tool targets a distinct resource-action pair: projects, files, workspaces, changes, and conflicts. Even the convenience wrappers (approve_change, request_changes) are clearly labeled and do not overlap with the core review_change. The boundaries between get_history, get_revision, and get_diff are evident from their descriptions.
All 32 tool names follow a strict verb_noun pattern in lowercase snake_case (e.g., create_project, list_workspaces, rebase_change). Verbs are consistently imperative and specific, making the toolset predictable and easy to navigate.
32 tools is heavy compared to typical server scopes, but the domain (Git-backed project management with workspaces, change lifecycle, and conflict resolution) is broad enough to justify a larger surface. Still, it leans toward the upper limit, and some consolidation could be possible without losing clarity.
The toolset covers the full lifecycle: project creation, file manipulation, workspace management, change creation/review/merge/rollback, and conflict handling. Minor gaps exist (e.g., no delete_project or rename operations), but the core workflow is complete and agents can accomplish all major tasks without dead ends.