# AVCS [Health: Active]

**Category:** 🔄 Version Control  
**Repository:** https://github.com/izagood/avcs  
**GitHub Stars:** 1  
**npm Downloads (last month):** 1098  
**Views:** 1  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/avcs

## Description
AI-native version control where intent, operation, evidence and decision are first-class objects.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "avcs": {
    "command": "npx",
    "args": ["-y","@izagood/avcs"]
  }
}
```

## Documentation

## What the AVCS MCP server does

The AVCS MCP server exposes an agent-oriented version-control system through MCP. AVCS is designed for humans and AI agents that edit the same codebase concurrently. It does not present Git’s commit, branch, merge, and conflict-marker model as its primary abstraction. Instead, work is represented by content-addressed objects, including intents, sessions, operations, evidence, decisions, checkpoints, views, releases, and policies.

The central record is an operation graph. An operation describes a semantic change, while an intent carries the goal, constraints, and permitted scope. Sessions connect work episodes to intents. Evidence records machine-checkable results such as tests, type checks, linting, or scans. Decisions preserve the rationale for conflict resolution or design choices instead of leaving only the resulting bytes.

## How it works

AVCS derives a code tree from a base state, an operation DAG, decisions, a policy, and a materializer. Identical inputs produce the same projected tree on each replica. Merging is therefore a deterministic reduction rather than a text-selection step.

The policy grades concurrent work. Changes to different entities or disjoint line regions can be merged automatically. Overlapping edits can produce a policy decision that is recorded in the history. Behavior changes without trusted evidence can be blocked, and public-API breaks require a human decision routed to the relevant owners. Code does not default to last-write-wins.

The AVCS MCP server is intended to reduce the version-control context an agent must consume. A stale-head change can be absorbed without a branch rebase, and a same-line collision becomes a decision object rather than conflict markers. The project describes itself as Git-incompatible, although Git bridge documentation exists for interoperability scenarios.

## Tools and capabilities

Through MCP, the server provides an agent-facing surface for working with AVCS objects and repository state.

Supported concepts include:

- Recording and working with intents, sessions, operations, evidence, and decisions.
- Building agent context from the operation history and intent.
- Applying deterministic policy-based reduction to concurrent operations.
- Preserving conflict rationale as signed or recorded decision data.
- Using checkpoints, views, releases, and policies as version-control objects.
- Applying evidence gates so untrusted or insufficiently supported changes can be blocked.

## Limitations and notes

AVCS is explicitly marked experimental and described as a research prototype. The current implementation reaches working-MVP depth for language-neutral text three-way merge and Ed25519 signing. Structure-aware merge, semantic-break detection, multi-signature trust, and hardened distributed synchronization are listed as future roadmap work.

The system is deliberately Git-incompatible at its core, so existing Git workflows should not be assumed to transfer directly.

Evidence trust is significant: an operation’s author cannot independently vouch for its own evidence. The evidence gate and passing-test bonus require evidence from a trusted, non-authoring actor such as CI or a human. The AVCS MCP server should therefore be evaluated alongside the project’s trust, policy, and collaboration requirements rather than treated as a drop-in Git replacement.

_Full upstream README: https://allmcps.com/mcp/avcs/readme_