Semantic memory mcp

Semantic Memory MCP Usage

You have access to a subset of the 13 memory MCP tools, depending on your agent's tier. Use the search/recall tools PROACTIVELY -- do not wait to be asked. Only call a tool your agent's tools: frontmatter actually grants — see the tier table below and the mcp-tools skill for the full 13-tool inventory.

Tools Available

Tool	Purpose	All agents	Write agents only	Notes agents only
search_context	Search ingested context chunks	Yes	--	--
semantic_search	Find memories by similarity query	Yes	--	--
semantic_recall	Get formatted memories for current context	Yes	--	--
semantic_store	Store a new memory with embedding	--	Yes	--
store_note / read_note / list_notes	Persist/read/list note documents	--	--	Yes
trigger_ingest	Queue one just-written document (corpus + relative_path) for immediate indexing (~3s to become searchable) instead of waiting up to 15 minutes	--	--	Yes

Write agents (search/recall/store): developer, architect, debugger, analyst, researcher, reviewer, optimizer. Read-only agents: tech-writer, devops, gitops, mcp-builder, prompt-engineer. Notes + trigger_ingest agents: architect, researcher only — trigger_ingest is deliberately withheld from the rest of the write tier because it's only useful paired with store_note (otherwise you're re-indexing a document you didn't write), and each call costs an LLM context-gen call.

trigger_ingest is path-scoped to a single document — it cannot trigger a full backfill — and it is fire-and-forget: it returns once the document is queued, not once indexing completes. Don't expect a synchronous "done" result; the document becomes searchable a few seconds later.

Uwaga: Jesli ten skill jest aktywny w repozytorium bez MCP server memory, pomin te instrukcje. Agent bez dostepu do mcp__memory__* toolow powinien po prostu pracowac bez pamieci semantycznej -- file-based fallback w .scaffolding/agent-memory/ wciaz dziala.

WHEN to Search Memory

At task start (MANDATORY for these scenarios):

• You encounter an unfamiliar pattern or module you haven't worked with before
• The task involves a subsystem with known quirks (deployment, async, database)
• You are debugging and the error message or stack trace is unclear
• You are making an architecture or design decision

Mid-task (RECOMMENDED):

• You hit an unexpected error -- search for the error message or pattern
• You are about to implement a workaround -- check if someone already solved it
• You need to understand why a decision was made in the codebase

How to search effectively:

• Use natural language queries describing the problem, not code snippets
• Keep queries under 100 words for best embedding match
• Use semantic_search when you want structured results with metadata
• Use semantic_recall when you want a quick formatted summary
• Always pass project_id so results are scoped to the current repository. The memory-project-id SessionStart hook injects the value to use (a scaffold:<hash> derived from the git remote); pass that exact value to every semantic_search / semantic_recall / semantic_store call. If no project_id is provided in session context, the backend uses a shared default namespace. Note: project_id (this section's mem0 axis) is distinct from corpus (used by search_context/notes/trigger_ingest, one of three NFS share directories) — don't conflate the two.

Examples:

semantic_recall(context="SQLAlchemy async session event loop issues", project_id="scaffold:ab12cd34ef56")
semantic_search(query="deployment nginx proxy configuration gotchas", project_id="scaffold:ab12cd34ef56")
semantic_search(query="Redis task queue timeout handling", project_id="scaffold:ab12cd34ef56", agent_name="debugger")

WHEN to Store Memory (Write Agents Only)

MUST store (after confirming the insight is correct):

• Root cause of a non-obvious bug -- especially if it took >5 minutes to find
• Architecture decision with rationale -- why X was chosen over Y
• Integration gotcha -- something that fails silently or behaves unexpectedly
• Pattern that deviates from convention -- and why the deviation exists

SHOULD store:

• Workaround for a known limitation -- with context on when it applies
• Performance finding -- specific numbers or thresholds discovered
• Configuration requirement -- non-obvious setup step that blocks progress

Do NOT store:

• Task-specific context (use conversation memory instead)
• Information already in CLAUDE.md, docs/, or KNOWLEDGE.md
• Speculative or unverified conclusions
• Raw code snippets >500 chars (summarize the insight instead)
• Routine operations (file created, test passed, etc.)

How to store effectively:

• Write content as a self-contained insight another agent can understand without context
• Include the why, not just the what
• Use descriptive tags for filtering (3-5 tags)
• Set content_type correctly: learning, error, pattern, or decision
• Keep content under 500 chars when possible (max 2000)

Examples:

semantic_store(
  content="TextBuffer in step event pipeline buffers assistant_text and thinking events but passes all others through immediately. If you add a new bufferable event type, you must add it to TextBuffer._BUFFERED_TYPES or events will be lost silently.",
  agent_name="debugger",
  content_type="pattern",
  tags=["step-events", "text-buffer", "pipeline"]
)

semantic_store(
  content="When creating async SQLAlchemy engine in a worker thread, you must create a NEW engine+session bound to that thread's event loop. Reusing the module-level async_session_maker causes 'attached to a different loop' errors.",
  agent_name="developer",
  content_type="error",
  tags=["sqlalchemy", "async", "threading", "event-loop"]
)

Quality Gate

Before storing, self-check:

1. Is this insight reusable by future agents? (not task-specific)
2. Is it verified through actual experience? (not speculative)
3. Is it not already documented in CLAUDE.md, docs/, or agent-memory files?
4. Would it save another agent >5 minutes of investigation?

If all four are YES, store it. Otherwise, skip or use file-based conversation memory.