memori-mcp-usage

# Memori skills file

## Overview

Memori is agent-native memory infrastructure: an LLM-agnostic layer that structures memory from natural language and from agent execution trace.

Memori automatically captures and structures memory from conversation and execution trace, including the agent's actions, tool results, decisions, and outcomes. Use it to maintain continuity across sessions, preserve decisions and constraints, and help the agent understand what it actually did so future work is more accurate and efficient.

## Core Instruction

When Memori MCP tools are available, treat this skill as the source of truth for how to use Memori through MCP.

Use it to understand:

- Available Memori capabilities
- Tooling and integrations
- Expected behavior and constraints
- Safety and privacy implications

MCP server configuration supplies authenticated user or tenant context through request headers. Do not invent entity, process, project, or session identifiers.

Current user instructions, verified local context, and tool results outrank recalled memory.

## Quick Reference

- `memori_recall`: retrieve precise memories by query, project, session, time range, or an allowed source/signal pair.
- `memori_recall_summary`: retrieve a state summary for session starts, daily briefs, or broad status checks.
- `memori_compaction`: retrieve a structured post-compaction brief to continue work after context compaction.
- `memori_advanced_augmentation`: store durable memory from a completed user/assistant turn.
- `memori_feedback`: report irrelevant, missing, stale, or especially useful memory behavior.
- `memori_signup`: create a Memori account or request an API key when the user explicitly asks.
- `memori_quota`: check usage, quota, storage, or memory capacity when the user asks or limits appear to be reached.

## When to Use Memori

Use Memori when:

- The task depends on prior context
- The user refers to previous sessions or decisions
- You need known constraints, preferences, or patterns
- You are starting a meaningful session and need current state
- You want to understand what has already been done

## When Not to Use Memori

Do not use Memori when:

- The task is fully self-contained
- The answer depends only on the current prompt
- No historical context is required
- The query is simple or one-off
- The message is trivial, administrative, or closing (for example "thanks", "ok", "goodbye")

Avoid unnecessary recall.

## Recall Behavior

Recall is agent-controlled and intentional. Prefer targeted recall over broad queries.

Use:

- `memori_recall`

Supported parameters:

- `query`: natural language search query
- `projectId`: project or workspace context, when the tool schema exposes it
- `sessionId`: specific session, only with `projectId`
- `dateStart` / `dateEnd`: UTC time-bounded recall
- `source`: type of memory (must be paired with `signal` from the allowed combinations below)
- `signal`: how the memory was derived (must be paired with `source` from the allowed combinations below)

If a `sessionId` is provided, a `projectId` must also be provided. All timestamps are stored in UTC.

Pass optional scope fields only when the tool schema exposes them and the active client or workspace provides reliable values.

Allowed source + signal combinations:

`source` and `signal` are not independent. They must be set together (or both omitted). Only the following `(source, signal)` pairs are valid:

- `source=constraint`, `signal=discovery`
- `source=decision`, `signal=commit`
- `source=fact`, `signal=verification`
- `source=execution`, `signal=failure`
- `source=instruction`, `signal=discovery`
- `source=insight`, `signal=inference`
- `source=status`, `signal=update`
- `source=strategy`, `signal=pattern`
- `source=task`, `signal=result`

Any combination of `source` and `signal` not in this list is invalid and must not be sent to `memori_recall`.

Use one of the allowed `(source, signal)` pairs to prioritize high-signal memory when possible; never set `source` or `signal` independently.

Default behavior:

- No date range means all-time memory.

Best practices:

- Best query: use the latest user message verbatim.
- Good query: use a short rephrased intent when the message is long or noisy.
- Avoid generic queries like "preferences", "memory", or "context".
- Start narrow with project or workspace scope, then expand only if needed.
- Prefer one recall call per turn.
- Do not recall on every turn.

## Summary Behavior

Summaries are used for state awareness, not precise retrieval.

Use:

- `memori_recall_summary`

Supported parameters:

- `projectId`
- `sessionId`
- `dateStart`
- `dateEnd`

Summaries do not support `source` or `signal`.

Default behavior:

- No date range means Memori's summary default, currently the recent working window.

## Daily Brief Behavior

At the start of a meaningful session, retrieve a structured summary.

Use the daily brief to understand:

- Current state
- Prior decisions
- Constraints
- Open work

Useful daily brief shape:

- Today at a glance
- Top next actions
- Top risks
- Verify before acting
- Recent decisions
- Mission stack
- Hard constraints
- Current status
- Open loops
- Known failures and anti-patterns
- Staleness warnings

Treat summaries as working state, not unquestionable truth. If the answer depends on one specific decision, preference, or prior outcome, use `memori_recall` or verify against current sources.

## Post-Compaction Brief Behavior

Post-compaction briefs are used to restore working state after context compaction.

Use them when:

- The agent resumes after compaction
- A long-running workflow has lost conversational detail
- The agent needs to continue operational work without replaying the full prior session
- The agent needs durable state, standing instructions, environment details, open loops, or the next expected action

Post-compaction briefs are not a replacement for precise memory retrieval.

Use:

- `memori_compaction`

Supported parameters