Power your agent
पब्लिशर की अपनी कमांड। PlugMCP एंडपॉइंट नहीं।
Host a copy with our keys and logs.
npx -y @mashware/[email protected]Claude Code में लोकल कमांड के लिए इंस्टॉल लिंक नहीं है। नीचे दी गई कमांड कॉपी करें और टर्मिनल में चलाएँ।
claude mcp add mashware-domain-memory -- npx -y @mashware/domain-memory-server@0.2.4टर्मिनल में चलाएँ।
{ "mcpServers": { "mashware-domain-memory": { "command": "npx", "args": [ "-y", "@mashware/[email protected]" ] } }}claude_desktop_config.json
रिमोट URL या आपकी मशीन पर कमांड? दोनों इंस्टॉल में क्या अंतर है
PlugMCP पर चलाएँ
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
लॉन्चA local MCP server that accumulates the business-domain knowledge of a software project — flows, integrations, decisions, nuances — and makes it available to any MCP-compatible agent (Claude Code, Cursor, Copilot, Gemini, OpenCode).
The goal is to capture the why behind the code: the stuff a new developer would need six months from now to understand why a thing is built the way it is. The what is already in the code — domain-memory does not duplicate it.
Status: Functional. Local install, single developer, local SQLite.
Domain Memory is a living glossary of your project's business domain — the concepts, rules, entities, and the why behind decisions — that grows as you build. The frame that matters: this is semantic memory (what "a German invoice" or "a deactivated account" means in your project, and why it behaves the way it does), not episodic memory (what you changed last Tuesday and in which commit). The episodic record already lives in git history; Domain Memory holds the part no diff captures.
You don't stop to write documentation. As the agent works it records findings on its own, and they are folded into the glossary when you run /save-knowledge or open a pull request — so the knowledge accrues from real work instead of becoming a separate authoring chore you have to remember.
Everything is plain markdown you own and version in git. Each entry is a human-readable file under .domain-memory/; the search index is derived from those files and can be rebuilt from them at any time, so the knowledge stays portable, reviewable in a pull request, and never locked inside a database.
If what you want is a history of work sessions, cross-machine sync, or generic per-user assistant memory, this is deliberately not that. Domain Memory stays narrow on purpose: the domain knowledge of one project, and nothing else.
Domain Memory occupies a narrow niche. The closest neighbours and where it differs:
If you're asking "where does the agent remember that I prefer dark mode?", you want mem0. If you're asking "where does the agent remember that we deliberately bypass tax validation for German invoices because of the 2024 ruling?", you want this.
Three principles run the whole system:
.md file under .domain-memory/knowledge/. SQLite is a derived index that can be rebuilt from disk at any time (domain-memory reindex).The unit is the feature (checkout, auth, notifications, search…). Each feature is one directory with a feature.md and optional aspects/ underneath:
.domain-memory/knowledge/
checkout/
feature.md ← high-level prose + Mermaid of the whole flow
aspects/
taxes.md ← specific subtopic
stripe.md
webhook.md
A feature is the primary context: the general Mermaid diagram in feature.md typically answers 70% of questions. Aspects are loaded on demand when the agent needs detail on a specific slice.
Each entry carries three layers:
file_paths + qualified symbol names.While you work, the agent appends findings to .domain-memory/staging/<branch>.jsonl. Findings survive session compaction, browser closes, new sessions on the same branch — indexed by git branch, not by session id. When you open a PR or run /save-knowledge, the staging is consolidated into real entries.
If you sometimes push without going through the agent, those findings can sit unconsolidated. The optional pre-push reminder closes that gap: domain-memory install --git-hook writes a non-blocking .git/hooks/pre-push that prints a one-line nudge when the branch you are pushing still has staged findings. It never blocks the push, stays silent when there is nothing to consolidate, and is a no-op if the CLI is not on PATH. It is opt-in — plain install asks before touching .git/hooks.
search_knowledge runs three matchers in parallel and fuses them:
The fusion is weighted: path = 0.5, embedding = 0.3, bm25 = 0.2. Path/symbol is weighted strongest because it is the most reliable signal when two pieces of knowledge are about the same code.
Every entry stores SHA-256 hashes of the files it references. On PR open, the agent cross-references the PR's touched files against the knowledge store via check_drift and asks the developer to review any affected entries. Rename/move is absorbed by matching on basename and short symbol; deletes are caught on the next reindex.
Every entry has a confidence (0–100) that decays -5 points every 30 days without verification. Computed lazily at read time — no scheduled job, always consistent with the wall clock. Below 50 the entry shows up red in /stale and the web viewer. A human review resets it with domain-memory verify <id>.
Two ways to run it. Pick the one that matches what you're trying to do.
Add it to your MCP client's config. No global install needed — npx fetches and runs it on demand.
{
"mcpServers": {
"domain-memory": {
"command": "npx",
"args": ["-y", "@mashware/domain-memory-server"]
}
}
}
That goes in .mcp.json (Claude Code), .cursor/mcp.json (Cursor), .vscode/mcp.json (Copilot), .gemini/settings.json (Gemini), or opencode.json (OpenCode).
Restart your client. From then on the agent will call search_knowledge at the start of each session.
If you also want the domain-memory CLI (to bootstrap entries, run the web viewer, check drift, etc.):
npm install -g @mashware/domain-memory
This installs three commands globally: domain-memory, domain-memory-server, domain-memory-web. Then in any project:
cd /path/to/your/project
domain-memory install # writes the MCP config + pointer blocks for the clients you use
domain-memory doctor # sanity check
domain-memory web # open the viewer at http://localhost:4373
install is idempotent — re-running updates files in place without clobbering your content.
npm update -g @mashware/domain-memory
npm uninstall -g @mashware/domain-memory
To remove domain-memory from a specific project: delete .domain-memory/, remove the `` block from the client instruction files, and drop the domain-memory entry from .mcp.json / .cursor/mcp.json / .vscode/mcp.json / .gemini/settings.json / opencode.json. If you installed the pre-push reminder, also remove the # >>> domain-memory pre-push >>> block from .git/hooks/pre-push (or delete the file if it contains nothing else).
If you want to hack on the project itself, see CONTRIBUTING.md for the clone-and-link dev workflow.
The server exposes six tools over stdio MCP:
search_knowledge(query, context?) — run the triple matcher, return ranked candidates. Respects a 2000 ms timeout (configurable via DOMAIN_MEMORY_SEARCH_TIMEOUT_MS).resolve_topic_key(topic_key) — deterministic dedup lookup. Returns the active entry under a canonical key (feature slug, or "<featureSlug>/<aspectSlug>" for aspects) or null. Use before save_knowledge(create) when you already know the exact slug.save_knowledge({action: create|update|archive|supersede, …}) — persist an entry with optimistic locking. Detects conflict_stale (a race on expected_updated_at) and conflict_duplicate (create under an existing active topic_key). Semantic contradictions are the agent's job.stage_finding(branch, finding) — append to the branch's JSONL staging.read_staging(branch) — read the staged findings for a branch.check_drift(file_paths) — return entries that reference any of the given files. Respects a 2000 ms timeout.The same tools are reachable over HTTP via domain-memory http: each is a POST /api/<tool_name> route with the MCP payload as JSON body. This is the integration point for CI hooks, shell scripts, and any future pipeline agents.
Agent behavior is defined in templates/instructions.md, which the install script copies to .domain-memory/instructions.md in the target project. Every supported client gets a short pointer block that tells its agent to read the full instructions at session start.
The install writes one delimited block per file (/). Re-running install updates the block in place — your own content is never clobbered.
A fresh install on a large, mature codebase starts empty. The system learns by silence by default: the agent only stages findings when the developer explicitly explains a "por qué" during a session. In a legacy project with years of history, that means most of the valuable knowledge never appears organically — it is already obvious to whoever wrote the code, and they will never think to dictate it.
Three mechanisms are available to populate and enrich the store without falling into the trap of auto-generating what the code already says:
domain-memory bootstrap — guided cold startScans the project tree, ranks directories by code density, and writes
a .domain-memory/bootstrap-plan.md with one checkbox per candidate
feature. Already-documented directories are marked [x]. The command
prints a ready-to-paste prompt that tells the agent to work the plan
one candidate at a time, reading the code and asking you the
por-qué questions it cannot answer alone.
domain-memory bootstrap
# review and edit .domain-memory/bootstrap-plan.md
# open a session and paste the printed prompt
# the agent walks the list, one feature at a time, asking you questions
A good bootstrap takes 3-5 focused 30-minute sessions for a project of 15-20 features. Do it incrementally, not in one sitting — quality depends on your attention.
When you open a PR that touches an already-documented feature, the agent asks you once, optionally, if anything you learned while working deserves to be added to the feature's entry. Default answer is "skip". No friction, no mandatory ritual — but the opportunity is there every single PR. Over months, this is what keeps entries fresh.
domain-memory enrich <feature> — dirigido deepeningFor when you want to explicitly sit down and improve a specific entry:
domain-memory enrich checkout
Prints a prompt that tells the agent to reread the existing entry, open all the referenced code, and ask you 5-10 pointed questions whose answers would actually improve the entry. You spend 20 minutes, you answer in voice, the agent updates everything.
None of these auto-generate knowledge. Auto-generated knowledge is noise: the agent reading code can only describe what the code does, and that is the part that already lives in the code. The valuable content — the why, the contraintuitive decisions, the trade-offs — lives in the human's head. The three mechanisms get that human talking in the right moments. The agent listens and writes.
domain-memory web starts a Hono-backed HTTP server on port 4373 with:
flowchart LR of feature relations with clickable nodes./api/stats, /api/graph for tooling.Read-only by design. Writes go through the CLI or the MCP tools.
domain-memory/
├── DESIGN.md ← architectural decisions and principles
├── SCHEMA.md ← file layout, frontmatter, SQLite schema, tool payloads
├── templates/ ← single source of truth for installed instructions
│ ├── instructions.md
│ ├── save-knowledge-command.md
│ └── pointer-blocks/
└── packages/
├── server/ ← @mashware/domain-memory-server (MCP stdio + storage + search + flows)
├── cli/ ← @mashware/domain-memory (install, reindex, doctor, mode, verify, check-drift, web)
└── web/ ← @mashware/domain-memory-web (Hono SSR viewer)
npm install
npm run build # all workspaces
npm run typecheck # all workspaces
# Tests
cd packages/server && npx vitest run
cd packages/cli && npx vitest run
# Run the MCP server directly (stdio) for debugging
node packages/server/dist/index.js
# Run the web viewer directly
node packages/web/dist/index.js
# Point install at a custom server bin
DOMAIN_MEMORY_SERVER_BIN=/custom/path/to/server.js domain-memory install
The markdown templates live at templates/ and are resolved at install time via DOMAIN_MEMORY_TEMPLATES (override) → packaged templates/ → monorepo dev fallback. Editing a template and re-running install picks up the change immediately.
Contributions are welcome. Please read CONTRIBUTING.md before opening a PR, and abide by the Code of Conduct.
For security issues, follow the disclosure process in SECURITY.md — please do not file public issues for vulnerabilities.
Apache License 2.0 © 2026 Alberto Vioque.
Local MCP server that captures the why behind your code — domain knowledge for Claude, Cursor, Copilot, and any MCP agent.
{ "mcpServers": { "mashware-domain-memory": { "command": "npx", "args": [ "-y", "@mashware/[email protected]" ] } }}टूल
अभी टूल सूची नहीं है। रिमोट सर्वर को पहले हेल्थ चेक के बाद सूची मिलती है।
FAQ
इस पेज पर Cursor, Claude Desktop, Claude Code या VS Code के लिए stdio कॉन्फ़िग कॉपी करें। यह पब्लिशर का इंस्टॉल इस्तेमाल करता है, PlugMCP प्रॉक्सी नहीं।
इस रिकॉर्ड में कोई ज़रूरी एनवायरनमेंट वेरिएबल दर्ज नहीं है।
Domain Memory stdio पर लोकल चलता है।
पिछली जाँच 2026-10-28 को हुई। Local MCP server that captures the why behind your code — domain knowledge for Claude, Cursor, Copilot, and any MCP agent.