Aidimag

What the aidimag MCP server does

The aidimag MCP server provides persistent memory for software repositories rather than general chat-history or user-preference storage. Memory can include implementation decisions, coding conventions, known pitfalls, failed approaches, guardrails, and reusable procedures. Records are kept as claims with grounding evidence inside a .aidimag/ directory next to the repository.

The system separates proposed knowledge from approved knowledge. Commits, pull requests, AI conversations, pasted documents, and repository surveys can produce proposals, but those proposals remain outside durable memory until a person reviews them. This makes it suitable for teams that want agents to retain project context while keeping humans responsible for what becomes authoritative.

How it works

Run the server for a repository by configuring an MCP client to launch npx -y aidimag mcp and setting AIDIMAG_REPO to the repository path. The server exposes live memory operations to compatible agents. The command-line interface handles initialization, review, verification, briefings, context generation, ticket setup, and other repository workflows.

Each memory can include evidence such as a static shell check, commit reference, test result, execution trace, or human attestation. Verification reruns applicable evidence against the current checkout. A failed check changes the related memory to stale status and can create a recovery proposal. Evidence received through team synchronization is not executed automatically; shell-based evidence must be trusted explicitly.

Recall combines FTS5 keyword search with optional vector search. Embeddings can use OpenAI, local Ollama, or AWS Bedrock, while keyword-only operation remains available without an embedding provider. Path-scoped recall helps keep results relevant to the code being edited.

Setup and configuration

Install the package globally with Node.js 22 or newer:

npm install -g aidimag

From a repository, dim init creates .aidimag/ and installs additive Git hooks. dim setup --yes combines initialization with detected-agent MCP configuration and context-file generation. dim doctor checks the resulting setup. A minimal MCP configuration uses the aidimag command through npx and points AIDIMAG_REPO at the target repository.

For agents that do not use MCP, dim generate-context --format all --auto can render verified memory into files such as .cursorrules, CLAUDE.md, AGENTS.md, .windsurfrules, and .github/copilot-instructions.md. These files provide a static alternative to live MCP access.

Tools and capabilities

The aidimag MCP server includes tools for searching and proposing memory, capturing live context notes, harvesting sessions with server-side secret redaction, and critiquing agent output against verified memory. Session-start briefings, session-end extraction, scratchpad operations, and ticket retrieval are also supported.

Other capabilities include:

• Human-reviewed capture from commits, pull requests, chats, and documents.
• Guardrails with never, ask-first, and always behavior, checked through pre-commit workflows and memory critique.
• Skills represented as step-by-step procedures.
• Knowledgebase ingestion for design documents, ADRs, PDFs, and DOCX files.
• Ticket connections for Jira, GitHub Issues, Linear, GitLab Issues, Azure DevOps, ClickUp, Shortcut, YouTrack, Asana, Trello, Notion, Pivotal Tracker, custom HTTP middleware, and remote team sync.
• Local-first synchronization through dim serve and dim sync.
• A scratchpad with expiring, non-synchronized session notes.

Limitations and notes

Memory is repository-scoped, so it is not intended to represent general personal preferences or arbitrary conversation history. Durable capture is gated by review; proposals do not become memory silently. Verification can make previously accepted claims stale when repository evidence changes, which means agents may see gaps or recovery proposals instead of an always-current answer.

The server requires Node.js 22 or newer. Semantic vector recall depends on an embedding provider, although keyword search works without one. Ticket credentials are stored per repository rather than shared across projects. VS Code and IntelliJ extensions are listed as additional interfaces, while non-MCP agents rely on generated context files rather than live MCP tools.