aoci-code MCP server

AOCI-CODE

A persistent, Git-versioned map of your entire codebase — written by your coding agent, governed by a local MCP server. Agents read it once and know the system, instead of re-reading the repo on every task.

🇺🇸 English | 🇨🇳 简体中文

https://github.com/user-attachments/assets/31636873-3e05-401f-849a-1f1ea87cd0a4

What it does

Build large systems without losing the plot. In Codex, Claude Code, Cursor, OpenCode, and similar agents, your agent starts every task already knowing the whole system: what each file is for, what it depends on, and what must not break. It stops searching and re-reading the codebase for every request. People who are not professional developers can keep iterating on their own systems; professional developers can hand the whole system to an agent and keep their attention on architecture and design.

Take over an existing system in one step. Point the agent at an existing codebase of up to about 500,000 lines and ask it to build the index. It reports how well it knows each area, then picks up development from there. The practical limit is the size of the index, not the line count: a 700,000-line commercial system is developed this way today, with an index of about 300K tokens.

Change people, agents, or conversations without starting over. The index lives in the repository next to the code and is versioned by Git. When a project changes hands, switches agents, or opens a new conversation, one read of the index picks up where things left off.

After the first index, maintenance is automatic. The MCP server detects code changes and issues the entries that need updating. The agent fills them in as it finishes each task, so the index matches the current code and you never stop to maintain it.

What it looks like

One line per file, written by the model from the actual source. This is a real entry from this repository's own index:

atomic.go[CG9L]: F:Provides durable replace CAS, create CAS, atomic writes, and no-clobber recovery moves | R:code:internal/fs/atomic_exchange_linux.go,code:internal/fs/atomic_exchange_windows.go,code:internal/fs/lock.go | A:AtomicWrite,AtomicWriteCAS,AtomicCreateCAS,AtomicMoveCAS | S:Native publication never degrades to an overwriting rename; on a race, unsafe type, or unverifiable bytes, preserve third-party state

F is what the file is responsible for, R is what you have to read along with it, A is what callers depend on, and S is what you cannot infer from the code but must not get wrong. The tag [CG9L] places the file by layer, domain, importance, and size. A few hundred lines like this cover a whole system, and an agent can read them in one pass. The entry format explains each field.

How is this different from CodeGraph?

• CodeGraph parses your code into a graph of symbols and calls. When the agent asks a question, it returns the exact source and call paths. It is a precise lookup tool for the task at hand.
• AOCI-CODE has the model write one line per file and table: what it is for, what it connects to, and what must not break. The agent reads the whole index first, so it knows the system before the task starts. The index lives in Git and is kept in step with the code.
• Use both: the index to know the system, CodeGraph to fetch the exact code while working.

The full comparison covers RAG, LSP, and repo maps too.

What to expect

The first index takes a while. The agent reads every managed file and writes one entry per file: about an hour per 200,000 lines of code, depending on the model and the agent's speed. It runs in batches and resumes where it stopped if interrupted.

Have a database? Index it too. MySQL and PostgreSQL are supported, and openGauss 6.0.5 with constraints. MySQL means 5.7.6 and later; MariaDB is not supported. Build the code index first, then the database index. With code and table-level knowledge delivered together, the agent understands the system more completely.

Local only: read-only on your system, no Internet, no stored credentials. AOCI-CODE reads your source code and database table structures, never business data. It writes its index files and its own state inside the project directory, plus the status page's registration in your user cache directory. It never reaches the Internet and uploads nothing: the only connections it opens are to the database you declare, for catalog metadata, and to its own loopback status page. Database credentials are referenced by environment-variable name and never stored. The index text is written locally by your own agent through the model channel you already use; AOCI-CODE adds no new data exit.

Quick start

Give your agent the following instruction to download AOCI-CODE and wire it up. After you restart the agent, send the second instruction to build the index.

AOCI-CODE project: https://github.com/aoci-spec/aoci-code

Download the newest release package, pre-releases included, for this operating system and
CPU architecture from https://github.com/aoci-spec/aoci-code/releases, and follow the
installation instructions on the Release page to verify it. If no compatible release
package exists, or if I explicitly request the latest source, build it from the official
repository.

After extracting the package, place aoci (aoci.exe on Windows) at a stable absolute path.
Then use that absolute path to do the following for my project:

1. Run init to initialize AOCI and integrate MCP for the current host; if this host does
   not write project configuration (Cursor, for example), give me the configuration I
   need to paste myself
2. Run scan

   scan takes its file inventory from Git, so do not add the cognition assets
   init writes (aoci.txt, aoci.meta.txt, aoci.code.txt, AGENTS.md) to .gitignore
   or .git/info/exclude — an ignored asset is silently skipped and the index
   cannot be built. Leave the host-config ignore init writes for itself as it is.

3. Tell me to restart the agent so the newly written MCP server takes effect

Stop after those three steps and do not build the index yet — I will tell you to continue
after the restart.

After restarting the agent, send this one:

First confirm the AOCI MCP server is connected, then build the AOCI index for this project. When it is complete, give me the AOCI panel link.

The agent starts the panel in the background with aoci ui --detach --json and hands you the link. AOCI panel covers what it shows and its other commands.

Why the restart: the index is written through AOCI's MCP tools, and the session that ran init has not loaded the MCP server init just wrote. A host that loads MCP servers dynamically may not need a restart; Host integration explains how to tell.

If your project has a database (PostgreSQL and MySQL are supported, plus constrained openGauss 6.0.5), index it as well. Declare the source as described under Database Cognition, provide the connection-string environment variable in the host environment (AOCI stores no credentials), then send:

Build the AOCI database index for this project.

If the context has been compacted, or you want the agent to rebuild its picture of the system, send this:

Using only AOCI, establish whole-framework cognition of this project, tell me your mastery of each area as a percentage, and whether you can take over development.

How it works

AOCI (AI-Oriented Cognition Infrastructure) is the method and protocol: a layer between coding agents and software systems. Models reason, agents plan and execute, and AOCI keeps an up-to-date description of the system, covering code, configuration, tests, and database structure, for agents to read before they act. AOCI-CODE is this project: the aoci CLI, the MCP server, and the index they maintain.

AOCI-CODE distills what actually matters for understanding and changing a system into a dense, plain-text index that combines symbols and meaning. When model context is limited, an agent reads the index first, gets most of the project's key information in one pass, and then starts the task. That cuts repeated searching and re-learning, and it carries understanding across tasks and sessions.

• Not a one-time summary. The index evolves with the system and stays in the project, where you can diff, review, version, and roll it back with Git.
• More than "where files are." It records responsibilities, strong relationships, public contracts, transaction boundaries, compatibility constraints, and other things that are hard to infer from code structure.
• Portable. The index is stored with the project, not tied to a model, an agent, or a session. While it is aligned with the code, any agent and any later session can reuse it without rebuilding its understanding from scratch.
• Code and databases together. The model can build a separate table-level index for database tables. Delivered together, the two give the agent a fuller picture of the system.

The index is a set of governed plain-text files stored with the project:

• Root (aoci.txt) declares what makes up the current index and is its activation entry point.
• Meta (aoci.meta.txt) holds the tag dictionary, the FRAS rules, and the authoring constraints.
• Code (aoci.code.txt) holds the model-authored entries for code and other repository assets.
• Database (aoci.database.txt) holds optional table-level entries when Database Cognition is enabled.

Root, Meta, and the participating object Volumes together form the Whole-Index. The workflow on top of them has three stages:

1. Build the index under governance. The model reads source code and accepted evidence. AOCI-CODE governs Managed Scope and the entries the model writes for every managed object with the index role.
2. Read before acting. The agent reads the project rules, the live guide, and the current Whole-Index, then checks source and other evidence for the task at hand.
3. Maintain after verified change. Once code and tests are stable, the project rules and the MCP workflow have the agent update the affected entries and bring the index back to aligned.

Because these files are plain text in the repository, Git versions them. While the index stays aligned with the current system version, any agent and any later session can read and reuse the same Whole-Index.

Manual integration

Get AOCI-CODE from the canonical source or use a signed package from GitHub Releases. Before using a prebuilt binary, follow the basic, recommended, or full verification level in the installation guide, and report which level completed. Give this README and the verified binary's stable absolute path to a coding agent you trust, such as Codex, Claude Code, Cursor, or OpenCode. The agent can follow the in-project instructions to initialize AOCI, integrate MCP, and build the first index.

How long the first index takes depends on repository size. A normal integration is four steps: prepare the binary, have the agent or yourself initialize the target repository, ask the host to "build the index," and verify alignment. After that you do not need to end every request with "maintain the index." The project rules and the MCP workflow have the agent maintain the index incrementally whenever managed objects change.

Requirements

• A verified release package or a checkout of the canonical AOCI-CODE source repository.
• For source builds only: the Go toolchain declared by go.mod, make, and the other tools the repository requires.
• A supported MCP host, such as Codex, Claude Code, Cursor, or OpenCode.
• Normal read and write access to the target repository.

AOCI-CODE integrates with the MCP host, not with a model-provider API. DeepSeek and other models can use AOCI-CODE when the agent or host running them supports standard stdio MCP and can follow the tool contract; a model name alone does not establish compatibility.

The signed-package route and executable verification commands are in the installation guide. The source-build route is below.

Current release: use a verified package or build from source

[!IMPORTANT] AOCI-CODE v0.2.0-rc1 is the current release. It is Fair Source/source-available software under FSL-1.1-MIT; see LICENSE. Build from canonical source or use a signed package from the v0.2.0-rc1 GitHub Release after following the release verification procedure.

The signed Release binary identifies itself as aoci version 0.2.0-rc1. A source build identifies the exact checkout instead and may report a development version such as v0.2.0-rc1-1-g<short-commit> (plus -dirty when applicable), together with its Git commit. These are different build inputs, not a version conflict.

To download with GitHub CLI, authenticate first, then download the tagged Release assets:

gh auth login
gh release download v0.2.0-rc1 --repo aoci-spec/aoci-code

For an anonymous download, open the v0.2.0-rc1 Release page in a browser and download the archive and verification assets you need.

To build from source, clone the canonical repository, build the binary, and keep the resulting path stable:

git clone https://github.com/aoci-spec/aoci-code.git
cd aoci-code
mkdir -p build
make build
./build/aoci --version

On Windows, build the same source in PowerShell:

git clone https://github.com/aoci-spec/aoci-code.git
Set-Location .\aoci-code
New-Item -ItemType Directory -Force .\build | Out-Null
make build
.\build\aoci.exe --version

Then give this README to an agent you already trust with the project and ask:

Read this AOCI-CODE README and use the built aoci binary at its stable absolute path
to initialize AOCI for the current project, integrate MCP, and run scan. Stop there and
tell me to restart the agent; I will ask you to build the index afterwards.

The agent should identify the project root, use a stable absolute path to the built binary, run the initialization that fits the current host, and tell you clearly when a host restart or real human approval is required. The binary can stay in the AOCI-CODE checkout or move to a shared tools directory, as long as the MCP configuration points at the correct absolute path.

Manual initialization

To initialize AOCI yourself, run the following from the target repository root, or pass an explicit path through --repo:

AOCI=/absolute/path/to/aoci-code/build/aoci
"$AOCI" --repo . init --locale en-US --agent codex
"$AOCI" --repo . scan

init writes the locale configuration, the managed AGENTS.md rules block, the Git boundaries, and an empty index skeleton. Configuration and prompting vary by host; see Host integration. It does not invent business meaning from filenames, directories, or an AST.

For a new repository, the first scan establishes the managed Baseline. For a project that already has a governed Baseline, adding, removing, or changing managed scope goes through the formal Scope Change workflow; scan --force is not a shortcut for redefining governance facts. --force also cannot erase unresolved drift, receipts, or recovery boundaries.

$Aoci = (Resolve-Path "C:\path\to\aoci-code\build\aoci.exe").Path
& $Aoci --repo . init --locale en-US --agent codex
& $Aoci --repo . scan

Confirm that $Aoci points to a stable absolute path.

Have the agent build the first index (important)

Once initialization and scan are done, check whether the agent session already exposes the AOCI tools; refresh or restart it if not. Then enter the following in the agent for the target project:

First confirm the AOCI MCP server is connected, then build the AOCI index for this project. When it is complete, give me the AOCI panel link.

The agent starts the panel in the background with aoci ui --detach --json and hands you the link. AOCI panel covers what it shows and its other commands.

The host reads the project's AOCI rules and live guide, inspects source code, tests, configuration, and relevant evidence, and then writes FRAS candidates for every managed object whose role is index. You do not need to orchestrate Plan, Stage, Check, Diff, CAS, or Apply yourself.

Once the first index is complete, send ordinary development requests as usual, for example:

Add priorities to tasks, including the frontend, backend, database, and test changes.

You do not need to append "maintain the AOCI index at the end." The project rules and MCP have the agent check for index changes once code and tests are stable, then update the affected entries through the formal workflow. When the project uses automation.mode=auto, AOCI-CODE interrupts you only when real human approval is required, an external action must be performed, recovery cannot be proven, a safety check fails, or a third-party concurrency conflict is found. Other automation modes follow their own runtime contracts.

Verify alignment

After onboarding completes, run:

"$AOCI" --repo . verify
"$AOCI" --repo . check

The index and the current managed source should converge back to aligned. If they do not, consult the live guide first; do not duplicate the internal state machine in a wrapper script:

"$AOCI" --repo . index agent guide --agent codex --json

Run basic diagnostics

"$AOCI" --repo . capabilities
"$AOCI" --repo . doctor

To confirm which AOCI the host is actually connected to, read what the server reports about itself rather than what is on disk. In any aoci_overview check_only response or any aoci_maintain response, cognition_receipt.mcp_service_version is the running version and runtime_repository_root is the repository it governs. The matching binary path is the command in the project's .mcp.json or the equivalent host configuration: .codex/config.toml, opencode.json, or .cursor/mcp.json. Replacing bytes on disk does not change a running MCP process, so recheck against those facts after an upgrade or a rollback.

For a one-off walkthrough, use examples/minimal-repository in the repository.

If you are developing AOCI-CODE itself, run the fast quality gate during ordinary development and before a commit:

make fast

Run the following when you need Full Confidence verification and an executable:

make full
./build/aoci --version

make full is the Full Confidence gate and already includes make build. make check is only a compatibility alias for the same full gate, so there is no need to run both. Use make release-check for stable-release rehearsals. If you only need a direct build, run:

mkdir -p build
CGO_ENABLED=0 go build -o build/aoci ./cmd/aoci

The AOCI-CODE CLI is a CGO-free, single-binary Go program. The make build target uses Go's native executable suffix: build/aoci on Linux and macOS, and build/aoci.exe on Windows. Before a release or delivery, rely on the actual binary's --version and capabilities output and on the formal Release Manifest, not on a version string in the README.

What appears after initialization

A typical repository contains these index files:

aoci.txt                    Root: declares the current CognitionSet and participating Volumes
aoci.meta.txt               Meta: tag dictionary, FRAS rules, and authoring constraints
aoci.code.txt               Code: model-authored entries for code and repository assets
aoci.database.txt           Database: optional table-level entries; absent by default
.aoci/
├── config.json             Team policy, Locale, Scope, and budgets
├── baseline.json           Governed Baseline for source, index, and database bindings
├── curation.json           Optional file-level include/exclude decisions
└── ...                     Drafts, Ledger, transactions, and recovery evidence; normally not committed to Git

Initializing a new project creates the Root, Meta, and an empty Code Volume; Database is absent by default. AOCI-CODE does not generate business meaning for the repository or the database on its own.

aoci init --agent <name> additionally writes host integration configuration (.mcp.json, .claude/settings.json, .codex/config.toml, or opencode.json) whose command and repository paths are machine-bound absolute paths. Add those files to the repository's .gitignore and do not commit them: a committed copy breaks on every other machine, and because the installers detect an existing entry by key presence, re-running init there silently keeps the broken paths.

How a development task runs

The two diagrams below show the workflow as you experience it, not AOCI's internal implementation.

New project: build a simple system first, then bring in AOCI

flowchart TD
    I["The user proposes a product idea and requirements"] --> S["Use the agent's existing capabilities to build a simple new system"]
    S --> Q["Integrate AOCI MCP"]
    Q --> V["The agent builds the Whole-Index and verifies aligned"]
    V --> N["The user continues with ordinary development requests"]
    N --> M["The agent completes code, tests, and incremental index maintenance"]
    M --> N

A new system does not need AOCI-CODE from the first line of code. Build a prototype with the agent's existing capabilities first; roughly 10,000–30,000 lines is a good point to bring it in (not a hard threshold). Teams that want cross-session continuity earlier can integrate sooner.