Skip to main content
Glama
README.md
# 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

B3/5.0

Scored across 32 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues