🇬🇧 English | 🇧🇷 Português | 🇪🇸 Español | 🇮🇹 Italiano | 🇫🇷 Français | 🇩🇪 Deutsch | 🇨🇳 中文 | 🇯🇵 日本語

A local intelligence layer for coding agents.
Local execution. MCP over stdio. Optional HTTP/UI surface in the default build.

What m1nd Is · What That Intelligence Covers · What m1nd Is Not · Capability Map · Quick Start · Default Agent Workflow · Evidence · Limits · Architecture · Wiki · Examples · Use Cases

m1nd is a local MCP runtime that gives coding agents structural retrieval, change reasoning, document grounding, operations, and continuity through a graph they can reason over before, during, and after change.

It ingests repositories, documentation, history, runtime-adjacent signals, and graph-native knowledge into a local graph. That graph is the operational model the agent works against instead of rebuilding context from scratch on every step.

It is not only a query surface. It is an operational layer: answers and edit surfaces can carry proof state, next-step guidance, recovery hints, observable execution, verified writes, stateful navigation, and persisted continuity across sessions.

With m1nd, an agent can:

• build a durable operational model of a codebase from code, docs, history, runtime signals, and graph-native knowledge
• retrieve and navigate the right context by text, path, intent, neighborhood, relationship, route, or failure trace
• reason about change before, during, and after it happens, including blast radius, co-change, missing work, structural claims, plan validity, drift, and counterfactuals
• analyze architecture, quality, security, duplication, type flow, trust boundaries, hidden dependencies, volatility, and refactor opportunities across the graph
• bind specs and docs back to implementation, including universal documents, graph-native L1GHT, provider health, automatic document ingest, and drift detection
• maintain continuity across turns, sessions, baselines, branches, and repo boundaries with perspectives, trails, session coverage, federation, persisted memory, and persisted state
• coordinate many agents against one shared runtime while preserving per-agent navigation state, perspective isolation, and resumable handoff context
• monitor and verify the system over time with audits, graph-vs-disk checks, daemon watches, alerts, metrics, diagrams, panoramic scans, reports, runtime overlays, and persisted state
• prepare, preview, and apply connected edits with graph-aware context, including atomic multi-file writes and post-write verification through apply_batch
• learn from feedback and reinforce useful paths over repeated investigations through automatic plasticity and explicit feedback
• measure savings, inspect the live runtime surface, and route itself with built-in reporting and help

• Structure: repo shape, dependencies, neighborhoods, hidden relationships, graph-aware retrieval, type flows, architectural layers, and guided routes beyond raw text matches.
• Change: blast radius, co-change prediction, missing work, structural claims, counterfactuals, drift, simulations, proof states, next-step hints, and graph-aware edit preparation, atomic multi-file execution, or post-write verification.
• Docs: universal document ingestion, graph-native L1GHT, provider health, automatic ingest, bindings between specs and implementation, local-first document runtime behavior, and document drift detection.
• Operations: audits, graph-vs-disk verification, daemon monitoring, alerts, metrics, diagrams, runtime overlays, panoramas, savings, reporting, built-in help, and recovery-oriented workflow routing.
• Continuity: perspectives, trails, session coverage, boot memory, persisted state, feedback-driven reinforcement, multi-agent isolation, and cross-repo or cross-session investigative state.

m1nd is not just:

• a code search tool with a larger index
• a repo RAG layer that only retrieves files or chunks
• a graph database that leaves workflow decisions to the client
• a static analysis replacement for the compiler, tests, or security tooling
• an MCP bundle of unrelated utilities

It is the layer that turns those surfaces into an operational system an agent can reason over and act through.

The live MCP surface evolves with releases. Use tools/list for the exact tool count and names in your current build.

If you want the shortest path to value:

git clone https://github.com/maxkle1nz/m1nd.git
cd m1nd
cargo build --release
./target/release/m1nd-mcp

Then connect it to your client using the integration matrix.

The canonical live tool names are the bare names returned by tools/list, such as ingest, activate, and audit.

Then do three things:

// 1. Build graph truth
{"method":"tools/call","params":{"name":"ingest","arguments":{"path":"/your/project","agent_id":"dev"}}}

// 2. Get a single-request structural orientation pass
{"method":"tools/call","params":{"name":"audit","arguments":{"agent_id":"dev","path":"/your/project","profile":"auto"}}}

// 3. Ask a structural question
{"method":"tools/call","params":{"name":"activate","arguments":{"query":"authentication flow","agent_id":"dev"}}}

Before risky edits, move to impact, predict, and validate_plan, then use surgical_context_v2 for connected edit prep.

If docs or specs matter too:

{"method":"tools/call","params":{"name":"ingest","arguments":{
  "path":"/your/docs","adapter":"universal","mode":"merge","agent_id":"dev"
}}}

For graph-native semantic docs, use adapter: "light" instead.

Make m1nd the default investigative layer before rg, filesystem globbing, or manual file reads when the task depends on structure, docs, impact, or change.

exact text                -> `search`
path pattern              -> `glob`
purpose or subsystem      -> `seek` or `activate`
unfamiliar repo           -> `audit`
runtime error or trace    -> `trace`
risky change              -> `impact`, `predict`, `validate_plan`, then usually `surgical_context_v2`
docs or specs             -> `ingest` with `universal` or `light`, then `document_*`
long-lived investigation  -> `perspective_*`, `trail_*`, `coverage_session`, `daemon_*`, `alerts_*`, `persist`
unsure what to call       -> `help(stage=..., intent=...)` or `help(error_text="...")`

Detailed client-by-client setup lives in the canonical wiki, the local integration matrix, and deeper examples in EXAMPLES.md.

m1nd complements rather than replaces:

• your LSP
• your compiler
• your test runner
• your security scanners
• your observability stack

It is most useful before search, review, or change, and whenever docs, impact, or continuity matter.

It is less useful when:

• exact text search already answers the question
• compiler or runtime truth is the only thing you need
• the task is a trivial local file action with no structural uncertainty

The workspace is split into three core crates plus one auxiliary bridge crate:

• m1nd-core — graph engine and reasoning primitives
• m1nd-ingest — extraction, routing, and graph construction
• m1nd-mcp — MCP server and operational runtime surface
• m1nd-openclaw — auxiliary OpenClaw integration surface

Current crate versions:

• m1nd-core 0.8.0
• m1nd-ingest 0.8.0
• m1nd-mcp 0.8.0

• Canonical wiki
• API reference
• Tool matrix
• Architecture overview
• Examples
• Use Cases
• Deployment & Production Setup
• Docs surface guide
• Release notes

Contributions are welcome across:

• extractors and adapters
• MCP/runtime tooling
• benchmarks
• docs
• graph algorithms

See CONTRIBUTING.md.

MIT. See LICENSE.