The remem server is a local-first memory toolkit for coding agents, allowing you to store, search, retrieve, and govern project memory and user context across sessions. Capabilities include:
Search and recall: search for curated memories (with entity graph expansion), search_raw for literal chat recall, and timeline for chronological context around an anchor.
Memory management: save_memory with deduplication and markdown backup, and get_observations for detailed memory data.
Contextual recall: recall_user_context for task-aware user context and current_state to resolve fact states.
Governance: govern_memory for auditable memory lifecycle with dry-run and confirmation.
Workstreams: workstreams and update_workstream to track active workstreams.
Git integration: lookup_commit and commits_for_session to link memories to commits.
Session analysis: list_raw_sessions for session summaries and timeline_report for project activity and ROI analysis.
Provides persistent memory for OpenAI Codex and Codex CLI sessions, enabling memory of project decisions and patterns across sessions.
Stop re-explaining your project every new coding-agent session.
Language: English | 简体中文
remem automatically captures, distills, searches, and injects engineering
memory across Claude Code and OpenAI Codex CLI sessions. Decisions,
bug-fix rationale, project patterns, and preferences stay available through
hooks, MCP, CLI, and a localhost REST API.
A new Claude Code session recalls the earlier root cause, commit, and open TODO with memory citations and no re-explaining.
Automatic session capture and background LLM distillation.
Project-scoped recall across Claude Code and Codex using one local store.
Searchable decisions, bug fixes, architecture notes, preferences, and raw session evidence.
Source attribution, staleness labels, suppression, review queues, and injection audits.
SQLite with SQLCipher encryption by default for fresh installs.
MCP, CLI, and authenticated localhost REST access from one Rust runtime.
remem prioritizes memory quality. Automatic capture is the primary path;
manual save_memory calls supplement it when a decision needs to be recorded
immediately.
Related MCP server: Longhand
brew install majiayu000/tap/remem
"$(brew --prefix remem)/bin/remem" install --target codexUse --target claude for Claude Code. --target all configures every known
host, including Cursor where its v1 renderer is supported.
curl -fsSL https://raw.githubusercontent.com/majiayu000/remem/main/install.sh | env REMEM_NO_CONFIG=1 sh
~/.local/bin/remem install --target codexnpm install -g @remem-ai/remem
# or
cargo install remem-ai --bin remem
remem install --target codexGitHub Releases: prebuilt binaries for macOS and Linux on x64/arm64, with
published checksums. Use one canonical remem executable on PATH;
remem doctor warns when hooks and terminals resolve different copies.
For channel-specific upgrades, platform boundaries, PATH drift, and manual install notes, read the installation and upgrade guide. The broader documentation guide links plugin and operational material.
Restart the selected coding agent, then run:
remem doctor
remem status
remem search "last decision"A healthy Claude Code or Codex installation injects relevant project memory at
SessionStart and queues durable session distillation at Stop. Codex also uses
UserPromptSubmit to capture each prompt and surface compact optional memory
candidates. remem doctor checks the schema, encryption key, database, hooks,
MCP registration, worker, and common install-path drift.
Repository contributors can verify duplicate SessionStart suppression with the isolated executable smoke fixture.
For a focused, read-only view of current-memory truth:
remem doctor truth --cwd .Capability | Claude Code | Codex CLI | Cursor v1 |
MCP memory tools | Yes | Yes | Yes on macOS/Linux |
SessionStart injection | Yes | Yes | Not supported |
Automatic session memory | Yes | Yes, Stop-based and low-noise | Not enabled by the v1 installer |
Tool-event capture | Installed hooks | No high-frequency Bash hook by default | Runtime command exists; no installed hook |
Compiled command-rule enforcement | Optional warn/block on Bash | Not supported | Not supported |
Windows | Supported | Supported | Not supported |
Cursor's v1 installer registers MCP only. The verified observe and
summarize runtime commands exist, but remem install --target cursor does
not install automatic capture hooks or SessionStart injection.
The repository also includes a Codex plugin wrapper. See plugins/remem/README.md for local plugin runtime and explicit hook activation instructions.
Built-in MEMORY.md, CLAUDE.md, and agent instruction files are ideal for a
small set of stable facts that should always be visible. remem covers the
engineering history that is too large, dynamic, or evidence-heavy to maintain
by hand.
Need | Built-in files | remem |
Stable project rules | Excellent | Supported |
Automatic session capture | Manual upkeep | Hook-driven |
Search older rationale | Limited by loaded text | Curated and raw search |
Branch, time, and staleness handling | Manual | Built in |
Provenance and injection audit | Git history | Database-backed audit |
Review, suppression, and lifecycle governance | Manual edits | First-class commands |
Use both. Keep concise rules in native files and let remem retain the long tail of decisions, failures, evidence, and changing project state.
The broader ecosystem comparison lives in the dated memory-tool survey.
Claude Code / Codex hooks
|
v
append-only captured_events ledger
|
v
coalesced background extraction and session rollup
|
v
governed candidates -> curated memories + workstreams + raw archive
|
v
FTS, entity, temporal, vector, graph, and optional local rerank retrieval
|
v
budgeted, source-attributed SessionStart contextHooks return quickly after durable capture or queueing. Background workers
perform extraction, candidate governance, compression, retrieval enrichment,
and lifecycle cleanup. MCP, CLI, REST, and SessionStart share the same local
store and governance model, but apply surface-specific eligibility policies.
Explicit search is an inspection and recovery surface, so it may return
labeled legacy_unverified memories; default SessionStart and CurrentTruth
exclude those rows and record the reason.
Generated memory is treated as untrusted until it passes source-support, secret, instruction-pattern, scope, and lifecycle checks. Unsafe content is dropped or routed to review with a diagnosable reason.
For module ownership and current data flow, read docs/ARCHITECTURE.md.
The experimental MCP context_bundle tool exposes the versioned, budgeted
compiler to explicit callers. The experimental remem context-plan command
prints a request-specific retrieval plan. These opt-in interfaces are tracked
by the Context Bundle and
retrieval-router contracts.
The default Codex integration stays low-noise: SessionStart provides stable
context, UserPromptSubmit provides a compact candidate index, and Stop
queues background summarization. Prompt candidates contain IDs, titles,
state, retrieval reason, estimated read cost, and a detail lookup hint, but no
memory bodies. They are optional leads that Codex may ignore, open, or search
beyond. The first prompt may also receive up to two continuity anchors so a
prompt such as continue does not depend on lexical overlap. Existing hybrid
RRF ranks memory candidates; no final confidence threshold decides relevance
for the model. Automatic extraction asks for short, specific candidate titles
without a redundant project-name prefix; existing stored titles remain intact.
For your own Codex sidebar, an optional rename convention is
MMDD｜TYPE｜Topic, such as 0903｜FIX｜FTS5 tokenizer mismatch. If you use a
separate host-supported rename workflow, preview its proposed names before
applying a batch. This is host-sidebar organization only: Remem does not rename
host conversations or import those names as intent overrides. Remem's structured
session/workstream fields remain authoritative, and a host title does not change
memory types or workstream identity. See the
session intent contract and
implementation epic #1065.
remem search "database encryption"
remem search "deployment decision" --branch main --explain
remem show <memory-id>
remem why <memory-id>
remem current <state-key>remem search keeps the terminal clean: per-query [INFO] [search-perf]
diagnostics are written to the log file, not stderr, in normal use. Set
REMEM_DEBUG=1 to mirror them to stderr while debugging.
Agents can use MCP search for compact results, then get_observations for
selected details. Use raw recall only when curated memory misses exact
transcript evidence:
remem raw search "exact phrase" --since 2026-06-01 --jsonList complete host-bound sessions before reading an exact transcript:
remem raw sessions --latest 20 --json
remem raw messages --host codex-cli --source-root local \
--project "/path/to/project" --session-id SESSION_ID --json
remem ingest-sessions --root codex-cli:archive=/path/to/sessions --jsonCopy host, source_root, project, and session_id unchanged from one
raw sessions summary into raw messages. Existing scripts must add the
required --host selector and replace --root LABEL=PATH with
--root HOST:LABEL=PATH; the same root format applies to raw reconcile.
The JSON envelope reports excluded_legacy_rows, excluded_legacy_sessions,
and excluded_legacy_identities when some archive rows cannot enter the
host-bound session contract. Each listed session also carries additive nullable
mmdd, session_intent, session_topic, display_label, and
session_intent_source fields. mmdd is derived from the session created epoch
in Asia/Shanghai; the full {MMDD}｜{INTENT}｜{topic} label is present only when
both intent and topic are known. Stop summaries may fill those fields with
source summary; unknown, empty, too-long, or redacted values abstain instead
of blocking the rest of the summary. Automatic Stop rollups preserve manual
label overrides, including explicit clears, across later turns. Listing still returns healthy sessions;
--latest N fills that bound from healthy sessions only and does not let
unresolved rows occupy those slots. Use the skipped identities (source_root,
project, session_id, and host when known) to inspect or repair those
rows. Exact raw messages for a skipped selector stays fail-closed. Do not
re-ingest a skipped row unless ingest can actually claim it — many legacy
rows have no trusted host provenance.
HOST is claude-code or codex-cli, and LABEL becomes the persisted
source_root. Cursor snapshot evidence requires a manually configured and
verified remem summarize --host cursor Stop integration; filesystem --root
ingestion and reconciliation reject cursor explicitly.
remem review list
remem review approve <candidate-id>
remem memory suppress memory:<id> --reason "no longer relevant"
remem govern --action stale --dry-run --json <id>Mutating governance commands expose previews, explicit confirmations, or
review boundaries according to their risk. Run remem <command> --help for
the current contract instead of relying on a copied command inventory.
MCP tools share that store with stricter wire contracts. The canonical MCP contract is GH981, including the #1061 mutation and scope boundary:
save_memory: pass host when the calling host is known. An omitted host is
recorded as unknown, never inferred as codex-cli.
govern_memory: dry-run first to preview IDs and current versions from that
governance transaction. Non-dry-run mutations require expected_versions
for every ID, confirm_destructive=true, and an explicit reason.
recall_user_context: supply project or cwd. The server does not infer
this scope from its own process working directory.
The local Remem app shows session/workstream labels or explicit abstention. Sessions can be filtered by intent and created date in Asia/Shanghai. Operators can correct labels in batches with a Before/After preview, explicit confirmation, and an audit; workstream identity and host conversation titles stay stable.
remem config show
remem model current
remem model use balanced --dry-run
remem embedding status
remem embedding download --model multilingual-e5-small
remem embedding backfill --limit 1000auto embedding mode stays local unless a remem-specific API key is selected.
The verified local model is optional; the labeled feature-hash fallback remains
available. The second-stage local reranker is also optional and disabled until
configured.
Use the current configuration routes, the
local embedding contract, and
remem config, remem embedding, or remem reranker help for details.
remem sync-memory --cwd .
remem export --markdown --output ./remem-memory
remem export --pack .remem-packMarkdown mirrors are human-editable. Project memory packs are deterministic, git-committable exports with provenance-aware import and quarantine behavior. See the memory usage guide and project memory pack contract.
The checked-in public suite separates memory-system capability evidence from coding-agent outcome evidence. Verify it locally with:
cargo run -- bench verify --root eval/public --json-out /tmp/remem-bench-verify.jsonVerification resolves claims/registry.json beside the parent of --root, so
an external bundle keeps public/ and claims/ as siblings and is independent
of the caller's working directory.
Public adversarial SQLite snapshots are capped at 64 MiB and must be canonical
VACUUM images; verifier-consumed artifact targets must also resolve inside the
declared public root.
The current public report does not support public benchmark claims and is
deliberately labeled
directional_only_no_public_claim. The historical isolated coding baseline is
useful engineering evidence, but its preloaded-memory condition is not
comparable with the current SessionStart retrieval path.
Reproduction commands, artifact schemas, claim boundaries, and current gates live in:
README claims intentionally exclude unsealed local metrics that have no checked-in report.
Fresh installs create a SQLCipher-encrypted database and private key file.
The data directory and key use restrictive per-user permissions.
The REST API binds to 127.0.0.1 and requires a bearer token.
Hook-captured event previews are redacted before durable storage.
Memory candidates and injected content pass secret and poisoning defenses.
remem doctor reports encryption, plaintext residue, schema, and audit
failures without printing memory payloads.
Read SECURITY.md for reporting and security policy. Operational contracts for SQLite tuning and memory-poisoning defense are kept outside the landing page.
remem api --port 5567
TOKEN=$(cat ~/.remem/.api-token)
curl -H "Authorization: Bearer $TOKEN" http://127.0.0.1:5567/api/v1/health
curl -H "Authorization: Bearer $TOKEN" http://127.0.0.1:5567/api/v1/capabilitiesClients should feature-detect through /api/v1/capabilities. The current
endpoint and compatibility contract is maintained in
docs/specs/SPEC-web-api.md.
Use docs/README.md as the jump page for installation, configuration, memory lifecycle, retrieval, governance, API, plugin, operations, architecture, and benchmark material.
The most common destinations are:
Preview and remove host hooks and MCP registration without deleting memory:
remem uninstall --dry-run
remem uninstallThe encrypted database remains in the configured REMEM_DATA_DIR. Back it up
before manually deleting that directory if data removal is intended. Ordinary
file deletion removes remem's local data but does not guarantee secure erasure
from filesystem snapshots, backups, or the underlying storage media.
MIT
List git commits linked to a content session ID or remem memory session ID. Its poisoning gate may quarantine the newest eligible unsafe linked session summary. Returns link evidence plus git metadata; it does not guess commit intent when no link exists.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max linked commits to return (default 20, max 100) | |
| project | No | Optional project filter | |
| session_id | Yes | Content session ID or remem memory session ID |
| Name | Required | Description |
|---|---|---|
| commits | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a notable side effect: 'Its poisoning gate may quarantine the newest eligible unsafe linked session summary.' This goes beyond the annotations' destructiveHint: true by specifying what may be quarantined. It also clarifies that the tool does not guess intent when no link exists, adding behavioral nuance beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loaded with the primary purpose. The second and third sentences add important behavioral context about the poisoning gate and non-guessing behavior, though some jargon ('poisoning gate', 'remem') could be clearer. Overall, it earns its place without excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema and well-documented parameters, the description provides sufficient context by covering purpose, side effects, and return details. It lacks explicit usage guidance or exclusions, but given the presence of annotations and schema, the completeness is strong. The side-effect disclosure is particularly valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add additional parameter-level meaning beyond what the schema provides, aside from mentioning the return of link evidence and git metadata, which is output-oriented rather than parameter-oriented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'List git commits linked to a content session ID or remem memory session ID.' This uses a specific verb ('List') and resource ('git commits'), scoped by session ID. It also distinguishes from sibling tools like lookup_commit by clarifying it returns link evidence and does not guess commit intent when no link exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving commits associated with a session, but it does not explicitly state when to use this tool versus alternatives. There are no exclusions or alternative tool names mentioned, so the guidance is indirect rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Experimental Context Bundle v1 compiler. Requires schema_version=1 and a non-blank task. Returns a policy-bounded, source-attributed ContextBundle with a complete selection/drop audit; project is explicit or derived from cwd, and role/risk/token budget have deterministic defaults. Historical as_of_epoch pins and include_superseded=true fail loudly until the canonical loader supports them. This reuses the production SessionStart canonical loader, performs no foreground LLM or network call, and returns canonical load failures as a blocked audited bundle. Its poisoning safety check may quarantine unsafe persisted rows, so callers must not treat it as side-effect-free. The JSON shape is versioned but remains experimental.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory used for canonical loading and project derivation. | |
| risk | No | Risk class: low, medium, or high (default medium). | |
| role | No | Agent role: coder, reviewer, planner, or researcher (default coder). | |
| task | Yes | Task description used for SessionStart relevance selection. | |
| branch | No | Optional Git branch scope filter. | |
| project | No | Exact project key/path. Defaults to the project derived from cwd. | |
| worktree | No | Optional worktree identity recorded in the versioned request. | |
| as_of_epoch | No | As-of epoch-seconds scope pin. Experimental v1 accepts only 0/omitted until historical canonical loading is implemented. | |
| token_budget | No | Total token budget for the bundle (default 4000). | |
| schema_version | Yes | Context Bundle request schema version; v1 requires 1. | |
| include_superseded | No | Allow superseded memories in scope. Experimental v1 accepts only false/omitted until canonical loading supports history. |
| Name | Required | Description |
|---|---|---|
| audit | Yes | |
| plan_hash | Yes | |
| preferences | Yes | |
| workstreams | Yes | |
| memory_index | Yes | |
| current_truth | Yes | |
| degraded_mode | Yes | |
| schema_version | Yes | |
| failure_lessons | Yes | |
| recent_sessions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description goes beyond annotations by detailing side effects: no foreground LLM/network call, canonical load failures become blocked audited bundles, and poisoning safety may quarantine rows, explicitly advising callers not to treat it as side-effect-free. This exceeds the destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with repeated warnings (e.g., about historical support) but is organized and not excessively long. It conveys all necessary points without major redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers essential aspects: purpose, constraints, failure behavior, side effects, and what it returns. Since an output schema exists, not detailing return structure is acceptable. It is complete enough for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions, but the description adds meaningful context: project can be derived from cwd, role/risk/token budget have deterministic defaults, and as_of_epoch/include_superseded fail loudly until supported. This enriches parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compiles a Context Bundle v1, specifying verb 'compile' and resource 'ContextBundle', and distinguishes it from sibling tools like timeline and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context: experimental, requires schema_version=1, non-blank task, deterministic defaults, and explicitly warns about failure modes for historical pins and include_superseded=true. It also clarifies it uses the production SessionStart loader and performs no foreground LLM/network, but does not explicitly compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Resolve one stable state_key to a JSON object with status=current, no_current, not_found, ambiguous, or unresolved_conflict, plus answer, compact history, and why edges. state_key must be non-blank; project/owner/type/as_of filters narrow the resolution. Use this instead of search when the durable key is known; use timeline for chronological observation context. Invalid input or database failures return a tool error.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Memory type filter, e.g. decision or preference. | |
| project | No | Project name filter. Defaults to repo-owned state plus global user state. | |
| owner_key | No | Explicit state-key owner key, e.g. a repo path or user:default. | |
| state_key | Yes | Stable state key, such as a durable topic key. | |
| as_of_epoch | No | Resolve the state that applied at this Unix epoch. | |
| owner_scope | No | Explicit state-key owner scope, e.g. repo or user. |
| Name | Required | Description |
|---|---|---|
| why | No | |
| facts | No | |
| state | No | |
| status | Yes | |
| current | No | |
| history | No | |
| matches | No | |
| conflicts | No | |
| state_key | Yes | |
| as_of_epoch | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/destructive hints already in annotations, the description discloses the possible resolution statuses, the output fields (answer, compact history, why edges), the non-blank constraint, and error conditions ('Invalid input or database failures return a tool error').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with 'Read-only', and every sentence adds value—no repetition of schema or annotations. It is concise yet information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a resolution tool with six parameters and an output schema, the description covers purpose, usage context, input constraints, output structure, error behavior, and sibling relationships. The output schema supplies the remaining structural details, so the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with per-parameter descriptions. The description adds contextual meaning by noting that 'state_key must be non-blank' and that the filter parameters 'narrow the resolution', which goes beyond the schema's literal field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb ('Resolve') and resource ('one stable state_key') and the output shape (JSON object with statuses). It distinguishes from siblings by explicitly naming search and timeline as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool instead of search ('Use this instead of search when the durable key is known') and when to use timeline ('use timeline for chronological observation context'). It also notes the required non-blank state_key and filter behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full details for explicit IDs and record last-accessed metadata for returned memory or observation rows. Use after search, not for discovery; prompt-time anchors may also direct this exact lookup. Pass selected IDs and the exact source from the result. source defaults to 'memory'; source='memory' returns curated memory details and requires its access update to succeed, source='observation' returns current extracted observations and records its access update best-effort (a failed update is logged but details still return), and source='session_summary' returns exact safe session-summary rows without confusing their IDs with observation IDs. Unsupported sources, any missing requested ID, detail-read failures, or memory access-update failures return a tool error.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | List of observation IDs to fetch | |
| source | No | Source type: 'memory', 'observation', or 'session_summary' (default: 'memory') | |
| project | No | Project name filter | |
| include_suppressed | No | Include policy-suppressed memories (default false) |
| Name | Required | Description |
|---|---|---|
| details | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses side effects: it records last-accessed metadata, requires memory access updates to succeed, treats observation updates as best-effort, and enumerates exact failure conditions. This goes well beyond the annotations and does not contradict them; destructiveHint=true is not directly contradicted because the described mutation is a metadata update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, usage rule, source-specific semantics, and error behavior. It is front-loaded with the core action and avoids filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a retrieval-with-side-effect tool: it explains usage context, ID provenance, source disambiguation, side effects, and error conditions. An output schema exists, so return-value details do not need to be repeated in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds significant semantic value for the source parameter by explaining the exact behavior and failure modes for each source value, while ids, project, and include_suppressed remain adequately covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Fetch full details for explicit IDs' and immediately distinguishes the tool from discovery. It also clarifies that it can return memory, observation, or session-summary rows, preventing confusion with similarly named sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use after search, not for discovery' and instructs callers to pass selected IDs and the exact source returned by search. It also mentions prompt-time anchors as another valid trigger, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auditably delete, reject, or mark curated memories stale. Use dry_run=true first to preview affected IDs and their current versions. Non-dry-run mutations require confirm_destructive=true, an explicit reason, and expected_versions containing every target ID. This never deletes raw archive data.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Curated memory IDs to mutate. Use dry_run=true first to preview. | |
| actor | No | Actor initiating the mutation, e.g. user, codex, claude. | |
| action | Yes | Governance action: delete, reject, stale, or acknowledge-pattern. | |
| reason | No | Explicit user-visible reason for the mutation. | |
| dry_run | No | Preview affected memories without writing status changes or audit events. | |
| project | No | Project name filter. Defaults to the MCP process current project. | |
| expected_versions | No | Current memory versions keyed by memory ID. Required for every ID in a non-dry-run mutation; obtain them from dry_run=true. | |
| acknowledge_pattern | No | Pattern id required when action is acknowledge-pattern, e.g. override_previous_instructions. | |
| confirm_destructive | No | Required true for non-dry-run destructive governance mutations. |
| Name | Required | Description |
|---|---|---|
| action | Yes | |
| reason | Yes | |
| dry_run | Yes | |
| affected | Yes | |
| expected_versions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds meaningful behavioral context: mutations are auditable, dry-run previews show affected IDs and versions, non-dry-run mutations require explicit confirmation, and raw archive data is preserved. This goes well beyond what the annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no filler: purpose first, then required workflow, then a scope safeguard. Every sentence carries operational value and the most important safety instruction is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with nested objects and an output schema, the description covers the core workflow, safety requirements, and scope boundary well. The main gap is that the action list omits 'acknowledge-pattern', which is a valid action in the schema and has its own parameter; the schema fills this in, but the description alone would leave an agent unaware of that mode.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds cross-parameter semantics not fully obvious from individual parameter descriptions: dry_run should come first, expected_versions must cover every target ID for non-dry-run, and confirm_destructive is mandatory for destructive writes. This improves an agent's ability to form a correct call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb set ('delete, reject, or mark stale') on a clear resource ('curated memories'), and the phrase 'never deletes raw archive data' distinguishes it from raw-data tools like search_raw and list_raw_sessions. This lets an agent understand the tool's role even before reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit procedural guidance: run dry_run=true first, then provide confirm_destructive=true, a reason, and expected_versions for non-dry-run mutations. It also implies a boundary by stating raw archive data is never deleted, which steers agents away from using this tool for that purpose, though it does not name sibling alternatives directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sessions with raw archive messages inside a time window, grouped by (source_root, host, project, session_id) with a stable session_ref, content_hash, first/last message epoch, message count, and optional role=user message samples. Unresolved or conflicted provenance is skipped and reported in excluded_legacy_identities; latest fills at most that many newest healthy sessions and does not spend slots on skipped rows. Use for recap-style summaries of what happened in a period. Output fields match remem raw sessions --json.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Only sessions with messages at or after this time (Unix epoch, ISO8601 datetime, or YYYY-MM-DD) | |
| until | No | Only sessions with messages at or before this time (Unix epoch, ISO8601 datetime, or YYYY-MM-DD; a date includes that full UTC day) | |
| latest | No | Return only the newest N sessions | |
| sample | No | Sample up to N role=user message texts per session, ascending by time (default 0 = no samples) | |
| project | No | Project name filter |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| latest | No | |
| sample | Yes | |
| project | No | |
| sessions | Yes | |
| since_epoch | No | |
| until_epoch | No | |
| excluded_legacy_rows | Yes | |
| excluded_legacy_sessions | Yes | |
| excluded_legacy_identities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds meaningful behavior: it explains how unresolved/conflicted provenance is skipped and reported in excluded_legacy_identities, and how 'latest' does not waste slots on skipped rows. This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds value: it states the action, grouping, output fields, exclusion handling, and a use case. It is well-structured and front-loaded with the core behavior, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are covered elsewhere. The description covers the grouping, exclusion behavior, use case, and even notes that output fields match a CLI command. An agent has everything needed to decide when and how to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters have individual descriptions. The description adds extra nuance for the 'latest' parameter (fills at most that many healthy sessions, doesn't spend slots on skipped rows) and clarifies the grouping and output structure, which helps parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (list), the resource (sessions with raw archive messages), and the scope (time window, grouped by specific fields). It also mentions the output fields and a use case ('recap-style summaries'), which distinguishes it from siblings like search_raw or timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for use ('Use for recap-style summaries of what happened in a period') but does not explicitly name alternative tools or state when not to use this tool. It implies usage rather than excluding other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up git commit metadata and linked memory sessions by full or short SHA. Its poisoning gate may quarantine the newest eligible unsafe linked session summary. The response separates git metadata from memory-derived summaries so missing links are not inferred.
| Name | Required | Description | Default |
|---|---|---|---|
| sha | Yes | Full or short git commit SHA to look up | |
| project | No | Optional project filter |
| Name | Required | Description |
|---|---|---|
| commits | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructive capability (destructiveHint=true). The description adds specificity about a poisoning gate that may quarantine an unsafe linked session summary, and clarifies the response separates git vs memory-derived data. This provides valuable context beyond the annotations, though the exact conditions of quarantine are not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each covering distinct information: core purpose, a mutation caveat, and response structure. No fluff, front-loaded with the primary verb and resource. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description doesn't need to detail return values. It covers prerequisites (SHA), the potential side-effect (quarantine), and the response separation. It's adequate, though 'poisoning gate' could use unpacking for full clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema, only restating that lookup is by full or short SHA, which the schema already states. No additional parameter-specific semantics are introduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a lookup operation for git commit metadata and linked memory sessions, keyed by SHA. It distinguishes this from sibling tools by highlighting the separation of git metadata from memory-derived summaries, preventing inference of missing links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the primary use case: when you have a full or short SHA and need commit metadata plus linked memory sessions. However, it does not explicitly compare against alternative tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assemble task-aware user context from safe claims, profile summary, repo memories, requested current-state keys, workstreams, and recent sessions. Its poisoning gate may quarantine an unsafe legacy or session summary. Requires a non-blank query and an explicit project or cwd scope. Returns a compact source-attributed JSON object with included items, dropped items, reason codes, and budget metadata. Use search for exhaustive memory matches and current_state for one exact stable key; this tool selects a bounded context bundle instead. Invalid or missing scope input and database failures return a tool error.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory used to derive the project key. Required when project is omitted. | |
| host | No | Host profile, e.g. codex-cli or claude-code. | |
| limit | No | Maximum included recall items. | |
| query | Yes | Task or topic query for user-context recall. | |
| project | No | Project key/path filter. Required when cwd is omitted. | |
| owner_key | No | Explicit user-context owner key. | |
| state_keys | No | Stable current-state keys to resolve exactly. | |
| owner_scope | No | Explicit user-context owner scope. | |
| task_intent | No | Optional task intent, e.g. review, implement, debug, plan. | |
| budget_chars | No | Maximum compact context characters. | |
| current_files | No | Current file paths relevant to the task. | |
| include_sensitive | No | Include personal/sensitive/restricted claims for explicit audit. | |
| include_suppressed | No | Include policy-suppressed claims and memories for explicit audit. |
| Name | Required | Description |
|---|---|---|
| host | No | |
| empty | Yes | |
| query | Yes | |
| context | Yes | |
| dropped | Yes | |
| project | Yes | |
| included | Yes | |
| diagnostics | Yes | |
| task_intent | No | |
| usage_policy | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations declaring readOnlyHint=false and destructiveHint=true, it discloses the poisoning gate that 'may quarantine an unsafe legacy or session summary,' the compact source-attributed JSON response, and the tool-error behavior for invalid scope or database failures. This gives the agent meaningful expectations of side effects and outcomes. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but each sentence earns its place: what it assembles, the quarantine side effect, required inputs, return shape, sibling routing, and error behavior. It is front-loaded with the core purpose and avoids filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter tool with an output schema and annotations covering safety characteristics, the description supplies the remaining operational context: sources, scope requirements, safety gate, response structure, and alternatives. No critical invocation detail appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all 13 parameters; per the calibration baseline this is a 3. The description adds a couple of cross-parameter constraints (non-blank query, project/cwd requirement) but does not systematically elaborate parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Assemble task-aware user context' from a clear enumerated list of sources. It also differentiates itself from siblings by stating this tool selects a 'bounded context bundle' rather than exhaustive search or a single stable key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the alternatives explicitly: 'Use search for exhaustive memory matches and current_state for one exact stable key; this tool selects a bounded context bundle instead.' It also states the preconditions (non-blank query, explicit project or cwd scope) and error cases, so an agent knows when to call it and what to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a memory for future sessions. MUST be called after: (1) architecture decisions — record what was chosen, why, and what was rejected, (2) bug fixes with root cause — record symptom, root cause, fix, and prevention, (3) important discoveries — record finding and its implications, (4) user preferences — record preference and reasoning. Use topic_key for cross-session dedup (same project+topic_key updates existing memory). By default also writes a local markdown backup.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Optional host identifier, e.g. codex-cli or claude-code. Defaults to unknown when omitted. | |
| text | Yes | Memory text content | |
| files | No | List of related file paths | |
| scope | No | Memory scope: 'project' (default, only this project) or 'global' (visible in all projects). Use 'global' only for explicitly cross-project preferences or knowledge. | |
| title | No | Optional title | |
| branch | No | Git branch label. If omitted, the server auto-detects from the MCP process current working directory. Pass an explicit value to override (e.g. when the calling agent is not running inside the project's git checkout). | |
| project | No | Project name | |
| topic_key | No | Stable topic identifier for cross-session dedup. Same project+topic_key updates existing memory instead of creating new one. Format: kebab-case descriptive key, e.g. 'fts5-search-strategy', 'auth-middleware-design'. | |
| local_path | No | Optional local markdown path for backup copy. Relative paths are resolved from current working directory. The resolved path must fall within the remem data directory (REMEM_DATA_DIR); paths outside that boundary are rejected. | |
| session_id | No | Optional host session id. When provided, Stop summary promotion can suppress exact duplicate candidates from the same session. | |
| memory_type | No | Memory type: decision, discovery, bugfix, architecture, preference. Defaults to 'discovery'. | |
| claim_source | No | Optional claim source label. Defaults to manual_save for MCP calls. | |
| claim_enabled | No | Override the session claim toggle. Defaults to true; set false to preserve legacy save behavior without claim rows. | |
| idempotency_key | No | Optional retry identity. Repeating the same key and exact request is idempotent; reusing it with changed content, route, trust, or policy fails. | |
| created_at_epoch | No | Optional override for the memory's creation timestamp (Unix epoch seconds). Use only for backfilling historical entries; defaults to now when omitted. | |
| local_copy_enabled | No | Override the local markdown backup toggle. Default behavior (when omitted) is controlled by the server config. | |
| reference_time_epoch | No | Explicit episode/source event time (Unix epoch seconds) used to resolve relative dates. Preferred for historical backfills; created_at_epoch is used only when this is omitted. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| scope | Yes | |
| branch | No | |
| status | Yes | |
| project | Yes | |
| claim_id | No | |
| upserted | Yes | |
| next_step | Yes | |
| operation | Yes | |
| topic_key | No | |
| local_copy | Yes | |
| local_path | No | |
| claim_error | No | |
| memory_type | Yes | |
| claim_status | Yes | |
| local_status | Yes | |
| created_at_epoch | Yes | |
| updated_at_epoch | Yes | |
| reference_time_epoch | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description discloses two important side effects: same project+topic_key updates existing memory, and a local markdown backup is written by default. This gives the agent useful behavioral context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized, front-loaded with the core purpose, and every sentence carries useful guidance. The conditional 'MUST' list is dense but directly actionable, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 17-parameter tool, the description covers the key invocation contexts, dedup behavior, and default side effects. The output schema exists, so return values need no explanation. It could be strengthened by naming sibling alternatives, but the remaining context is adequately covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter. The description adds meaningful reinforcement around topic_key dedup and the default local backup, but does not need to compensate for missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Save a memory for future sessions,' and then enumerates exact triggering scenarios (architecture decisions, bug fixes, discoveries, user preferences). This clearly distinguishes saving from the sibling search, governance, and timeline tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'MUST be called after' list provides explicit, actionable guidance on when to invoke this tool. It does not explicitly name alternatives or state when not to use it, but the conditions are concrete enough to route an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Search or list curated memories: query is optional for standard search, while project/type/branch and visibility flags filter results. Optional task_intent/role/risk/token_budget/include_superseded compiles a GH-934 RetrievalPlan, applies its search/rerank/fallback policy, and returns retrieval_plan audit metadata. Returns a compact JSON object with results, source='memory', pagination, and next_step for get_observations(ids, source); limit defaults to 20 and offset to 0. Use current_state when an exact stable state_key is known, timeline for chronological observation context, and search_raw for literal chat recall. explain and multi_hop each require a non-blank query, and explain cannot be combined with multi_hop=true. Invalid combinations or curated-search database failures return a tool error; an automatic raw-archive fallback failure preserves the curated results and adds raw_hits_error to the successful response.
| Name | Required | Description | Default |
|---|---|---|---|
| risk | No | Risk class for task-aware retrieval planning: low, medium, or high (default medium). High risk disables raw fallback and only requests router-approved rerank. | |
| role | No | Agent role for task-aware retrieval planning: coder, reviewer, planner, or researcher (default coder). Only used when task-aware routing is requested. | |
| type | No | Observation type filter | |
| limit | No | Max results to return (default 20) | |
| query | No | Search query (semantic search) | |
| branch | No | Git branch filter (e.g. 'main', 'feat/auth'). Only returns memories from this branch. Old data without branch info is always included. | |
| offset | No | Result offset for pagination | |
| explain | No | Include retrieval scoring and visibility explanation for standard search (default false). Not supported with multi_hop=true. | |
| project | No | Project name filter | |
| multi_hop | No | Enable multi-hop search (default false). When true, performs entity graph expansion: finds entities in first-hop results, then searches for memories mentioning those entities. Use for questions that span multiple topics/people, e.g. 'What do Melanie\'s kids like?' or 'What events has Caroline participated in?' | |
| task_intent | No | Optional task-aware retrieval intent. Accepted values: resume_work/resume-work, explain_decision/explain-decision, debug_failure/debug-failure, apply_preference/apply-preference, review_change/review-change, explore_history/explore-history. When set, MCP search compiles a GH-934 RetrievalPlan and applies its execution policy. | |
| token_budget | No | Total token budget recorded in the task-aware RetrievalPlan (default 4000). Must be greater than zero. | |
| include_stale | No | Include stale or archived memories (default false) | |
| include_superseded | No | Allow superseded history in the task-aware RetrievalPlan. This does not replace include_stale; use include_stale=true when the search result set should include inactive rows. | |
| include_suppressed | No | Include policy-suppressed memories (default false) |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| explain | Yes | |
| results | Yes | |
| has_more | No | |
| raw_hits | No | |
| multi_hop | No | |
| next_step | Yes | |
| pagination | Yes | |
| next_offset | No | |
| raw_hits_note | No | |
| raw_hits_error | No | |
| retrieval_plan | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint and idempotentHint annotations, the description adds rich behavioral detail: task-aware RetrievalPlan compilation, fallback behavior, error handling, pagination defaults, and return format metadata. It discloses how invalid combinations or database failures behave.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long due to the tool's complexity, but every sentence provides distinct value: purpose, advanced modes, return format, alternatives, constraints, and error handling. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 15 optional parameters, output schema, and sibling tools, the description covers return format, pagination, error conditions, fallback semantics, and alternatives. It is sufficient for an agent to know when and how to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 15 parameters at 100%, but the description adds cross-parameter context not in the schema: limit/offset defaults, query optionality, task_intent high-level behavior, and the constraint that explain and multi_hop require a non-blank query. It also references get_observations for follow-up.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read-only. Search or list curated memories' with a specific verb and resource. It distinguishes from siblings by explicitly naming current_state, timeline, and search_raw as alternatives for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use current_state when an exact stable state_key is known, timeline for chronological observation context, and search_raw for literal chat recall.' Also specifies constraints like explain/multi_hop requiring a non-blank query and explain not combinable with multi_hop=true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the raw archive (every user/assistant turn captured by the Stop hook). Use this when search returns no curated match or you need to recall a literal phrase from past chats. Returns the untreated conversation content — expect noise. The raw archive is what guarantees 'what was said remains searchable' even when summarize/promote skip a turn.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Role filter: 'user' or 'assistant' (default: both) | |
| limit | No | Max results to return (default 20) | |
| query | Yes | Raw FTS query across every user/assistant turn captured by the raw archive. Unlike `search`, this bypasses all curation and returns literal chat content. Use when `search` comes back empty or you need to recall an exact phrase from past conversations. | |
| since | No | Only rows at or after this time (Unix epoch, ISO8601 datetime, or YYYY-MM-DD) | |
| until | No | Only rows at or before this time (Unix epoch, ISO8601 datetime, or YYYY-MM-DD; a date includes that full UTC day) | |
| branch | No | Git branch filter. Returns raw rows for this branch plus older rows without branch metadata. | |
| offset | No | Result offset for pagination | |
| project | No | Project name filter |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| role | No | |
| count | Yes | |
| limit | Yes | |
| query | Yes | |
| branch | No | |
| offset | Yes | |
| project | No | |
| results | Yes | |
| has_more | Yes | |
| next_offset | No | |
| since_epoch | No | |
| source_type | Yes | |
| until_epoch | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate safety. It adds valuable context: results are 'untreated conversation content — expect noise' and explains the raw archive's role in guaranteeing searchability even when summarize/promote skip a turn. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, when-to-use, and behavioral expectations. No fluff, front-loaded with the core action, and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered. The description explains the tool's niche within the broader toolset (raw vs curated), the data scope ('every user/assistant turn captured by the Stop hook'), and the noise caveat. This is sufficient for a search tool, though it could briefly mention the supported filters (time, branch, project) to aid in selecting parameters, but the schema already covers those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds high-level context (raw FTS, bypasses curation) but does not elaborate on individual parameters beyond what the schema already provides. At full schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and clearly identifies the resource ('raw archive of every user/assistant turn captured by the Stop hook'). It explicitly contrasts with the sibling tool `search`, noting when to use each, which fully distinguishes it from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'when `search` returns no curated match or you need to recall a literal phrase from past chats.' It also warns that results are untreated and noisy, setting clear expectations and contrasting with the curated `search` alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Return a JSON array of observations before and after one center point; provide anchor or query, and anchor takes precedence when both are set. depth_before and depth_after default to 5, and project limits both anchor lookup and results. Use this for local chronological context around an observation; use timeline_report for an aggregated project report, search for curated memories, or current_state for a stable fact. Missing anchors/queries, no query match, or database failures return a tool error.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search query to find anchor | |
| anchor | No | Anchor observation ID | |
| project | No | Project name filter | |
| depth_after | No | Observations after anchor (default 5) | |
| depth_before | No | Observations before anchor (default 5) |
| Name | Required | Description |
|---|---|---|
| observations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description reveals important behavioral traits: anchor takes precedence over query, depth_before/after default to 5, project limits both anchor lookup and results, and error conditions (missing anchors/queries, no match, DB failures). This is substantial context beyond structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: four sentences conveying read-only behavior, return type, conditional anchor/query, defaults, project scope, sibling alternatives, and error handling. Every sentence carries critical information with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and parameters are optional, the description covers all key aspects: purpose, input semantics, defaults, error behavior, and alternatives. It leaves no significant gaps for the agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 5 parameters with descriptions (100% coverage), but the description adds relational semantics not present in the schema, such as anchor/query precedence and the effect of project on both lookup and results. This helps the agent understand how parameters interact, exceeding the baseline for fully documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return a JSON array of observations before and after one center point' with a specific verb and resource, and it explicitly distinguishes this tool from siblings such as timeline_report, search, and current_state by naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage guidance: 'Use this for local chronological context around an observation' and contrasts with timeline_report, search, and current_state. It also warns that missing anchors/queries, no match, or database failures return a tool error, which helps set expectations for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Generate an aggregated Markdown report for the required project with activity history, type distribution, and Token ROI analysis. full defaults to false for the compact report; full=true adds the detailed timeline and monthly breakdown. Use this for project-level reporting, not observation lookup; use timeline for chronological context around one observation. Database failures return a tool error.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | Full report with timeline and monthly breakdown (default false) | |
| project | Yes | Project name (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's 'Read-only' restates these. However, it adds useful behavioral context by disclosing that database failures return a tool error, which is not present in the annotations. This provides a clearer failure model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it opens with purpose, explains parameter behavior, then gives usage guidance and error behavior. Every sentence carries relevant information with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description covers the core functionality, output format (Markdown), parameter effects, usage recommendations, and failure behavior. It is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with descriptions (100% coverage). The description adds value by clarifying the 'full' flag's semantics: 'full defaults to false for the compact report; full=true adds the detailed timeline and monthly breakdown.' This goes beyond the schema's wording by distinguishing compact vs. detailed reports and describing the overall report content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Generate an aggregated Markdown report') with a defined scope (project activity history, type distribution, Token ROI analysis). It explicitly distinguishes itself from sibling tools by stating 'Use this for project-level reporting, not observation lookup; use timeline for chronological context around one observation.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use this for project-level reporting, not observation lookup; use timeline for chronological context around one observation.' It also explains the effect of the 'full' parameter and notes failure behavior, covering both when to use and when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mutates one existing workstream by id. At least one of status, next_action, or blockers is required; omitted fields remain unchanged. status accepts only active, paused, completed, or abandoned. Returns a JSON object with id and updated, where updated=false means no row matched. Use workstreams to list/read rows first. This tool does not create or delete workstreams; an empty update, an unknown status, or a database failure returns a tool error.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | WorkStream ID to update | |
| status | Yes | New status: active, paused, completed, abandoned | |
| blockers | No | Current blockers | |
| next_action | No | Next action to take |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| updated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint=true and readOnlyHint=false, but the description adds return semantics ('Returns a JSON object with id and updated'), no-match behavior, error cases (empty update, unknown status, database failure), and partial-update behavior (omitted fields remain unchanged). This significantly exceeds annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three carefully crafted sentences: first states the core action and constraints, second gives return behavior, third exclusions and errors. No redundant phrasing; all content earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, field constraints, return value, no-match semantics, error conditions, and scope boundaries. Thoroughly complete for a 4-param tool with an output schema, even though the parameter dependency rule is incorrect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's rule 'At least one of status, next_action, or blockers is required' conflicts with the schema's required array, which mandates status. This misleads agents into thinking they can omit status if another field is provided, contradicting the schema and causing a validation error. Schema coverage is 100%, but the added dependency rule is inaccurate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Mutates one existing workstream by id,' a specific verb and resource, and explicitly contrasts with create/delete and read operations via 'Use workstreams to list/read rows first' and 'does not create or delete workstreams.' This clearly distinguishes it from sibling tools like workstreams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage conditions: at least one of status/next_action/blockers required, omitted fields unchanged, and status enum values. It also names the alternative for reading (workstreams) and excludes create/delete operations, making when-to-use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. List existing high-level workstreams for a required project, optionally filtered by status=active, paused, completed, or abandoned. Returns a JSON array with each workstream's status, progress, next action, blockers, and timestamps. Use update_workstream to mutate an existing row; this tool does not create, update, or delete workstreams. A missing project or database failure returns a tool error.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | Status filter: active, paused, completed, abandoned | |
| project | No | Project name filter |
| Name | Required | Description |
|---|---|---|
| workstreams | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, and the description reinforces 'Read-only' consistently. It adds useful behavioral detail beyond the annotations: the JSON array return shape, the per-workstream fields, and the missing-project/database-failure error behavior. The error claim is slightly undercut by the schema making project optional, but the transparency effort is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The read-only nature and primary verb are front-loaded, followed by the filter options, return shape, and an explicit alternative. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is nearly complete: it covers purpose, filters, returns, error cases, and the mutation alternative. The output schema covers the return contract. The only notable gap is the contradictory guidance about required versus optional parameters, which prevents a perfect completeness score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline for parameter semantics is 3. However, the description actively conflicts with the schema: it says 'required project' and 'optionally filtered by status', while the schema marks status as required and project as nullable. This inversion makes it risky for an agent to decide which parameters to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation: 'List existing high-level workstreams' and distinguishes this tool from update_workstream by explicitly stating it 'does not create, update, or delete workstreams'. However, calling project 'required' while the schema lists status as required and project as nullable creates ambiguity about the tool's exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: use it to list workstreams with an optional status filter, and use update_workstream to mutate an existing row. It also explicitly states what this tool does not do, which helps an agent choose between siblings. Error behavior is also disclosed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.6.93list_raw_sessions6 fields changedOutput schema / $defs / RawSessionOutput / properties / display_labelAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / $defs / RawSessionOutput / properties / mmddAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / $defs / RawSessionOutput / properties / session_intentAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / $defs / RawSessionOutput / properties / session_intent_sourceAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / $defs / RawSessionOutput / properties / session_topicAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / $defs / RawSessionOutput / requiredPrevious value: -[
- "session_ref",
- "host",
- "session_mode",
- "source_root",
- "project",
- "session_id",
- "first_epoch",
- "last_epoch",
- "message_count",
- "user_message_count",
- "assistant_message_count",
- "content_hash",
- "user_message_samples"
-]New value: +[
+ "session_ref",
+ "host",
+ "session_mode",
+ "source_root",
+ "project",
+ "session_id",
+ "first_epoch",
+ "last_epoch",
+ "message_count",
+ "user_message_count",
+ "assistant_message_count",
+ "content_hash",
+ "user_message_samples",
+ "mmdd",
+ "session_intent",
+ "session_topic",
+ "display_label",
+ "session_intent_source"
+]workstreams6 fields changedOutput schema / $defs / WorkstreamOutput / properties / display_labelAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / $defs / WorkstreamOutput / properties / mmddAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / $defs / WorkstreamOutput / properties / session_intentAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / $defs / WorkstreamOutput / properties / session_intent_sourceAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / $defs / WorkstreamOutput / properties / session_topicAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / $defs / WorkstreamOutput / requiredPrevious value: -[
- "id",
- "project",
- "title",
- "status",
- "created_at_epoch",
- "updated_at_epoch"
-]New value: +[
+ "id",
+ "project",
+ "title",
+ "status",
+ "created_at_epoch",
+ "updated_at_epoch",
+ "mmdd",
+ "session_intent",
+ "session_topic",
+ "display_label",
+ "session_intent_source"
+]v0.6.90get_observations3 fields changedInput schema / properties / source / descriptionPrevious value: -"Source type: 'memory' or 'observation' (default: 'memory')"New value: +"Source type: 'memory', 'observation', or 'session_summary' (default: 'memory')"Output schema / $defs / DetailOutput / anyOfPrevious value: -[
- {
- "$ref": "#/$defs/MemoryDetailOutput"
- },
- {
- "$ref": "#/$defs/ObservationDetailOutput"
- }
-]New value: +[
+ {
+ "$ref": "#/$defs/MemoryDetailOutput"
+ },
+ {
+ "$ref": "#/$defs/ObservationDetailOutput"
+ },
+ {
+ "$ref": "#/$defs/SessionSummaryDetailOutput"
+ }
+]Output schema / $defs / SessionSummaryDetailOutputAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "completed": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at": {
+ "type": "string"
+ },
+ "created_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "decisions": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "learned": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "memory_session_id": {
+ "type": "string"
+ },
+ "next_steps": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "preferences": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "project": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "request": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "memory_session_id",
+ "created_at",
+ "created_at_epoch"
+ ],
+ "type": "object"
+}govern_memory4 fields changedInput schema / properties / expected_versionsAdded value: +{
+ "additionalProperties": false,
+ "description": "Current memory versions keyed by memory ID. Required for every ID in a non-dry-run mutation; obtain them from dry_run=true.",
+ "nullable": true,
+ "patternProperties": {
+ "^-?\\d+$": {
+ "format": "int64",
+ "type": "integer"
+ }
+ },
+ "type": "object"
+}Output schema / $defs / GovernedMemoryOutput / properties / versionAdded value: +{
+ "format": "int64",
+ "type": "integer"
+}Output schema / $defs / GovernedMemoryOutput / requiredPrevious value: -[
- "id",
- "title",
- "previous_status",
- "new_status"
-]New value: +[
+ "id",
+ "title",
+ "previous_status",
+ "new_status",
+ "version"
+]Output schema / properties / expected_versionsAdded value: +{
+ "additionalProperties": false,
+ "patternProperties": {
+ "^-?\\d+$": {
+ "format": "int64",
+ "type": "integer"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}list_raw_sessions3 fields changedOutput schema / $defs / ExcludedSessionIdentityOutputAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "host": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "project": {
+ "type": "string"
+ },
+ "session_id": {
+ "type": "string"
+ },
+ "source_root": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "source_root",
+ "project",
+ "session_id"
+ ],
+ "type": "object"
+}Output schema / properties / excluded_legacy_identitiesAdded value: +{
+ "items": {
+ "$ref": "#/$defs/ExcludedSessionIdentityOutput"
+ },
+ "type": "array"
+}Output schema / requiredPrevious value: -[
- "sample",
- "count",
- "excluded_legacy_rows",
- "excluded_legacy_sessions",
- "sessions"
-]New value: +[
+ "sample",
+ "count",
+ "excluded_legacy_rows",
+ "excluded_legacy_sessions",
+ "excluded_legacy_identities",
+ "sessions"
+]recall_user_context2 fields changedInput schema / properties / cwd / descriptionPrevious value: -"Current working directory used to derive the project key."New value: +"Working directory used to derive the project key. Required when project is omitted."Input schema / properties / project / descriptionPrevious value: -"Project key/path filter. If omitted, cwd is normalized."New value: +"Project key/path filter. Required when cwd is omitted."save_memory1 field changedInput schema / properties / host / descriptionPrevious value: -"Optional host identifier, e.g. codex-cli, claude-code, api, cli."New value: +"Optional host identifier, e.g. codex-cli or claude-code. Defaults to unknown when omitted."v0.6.84list_raw_sessions10 fields changedInput schema / properties / latestAdded value: +{
+ "description": "Return only the newest N sessions",
+ "format": "int64",
+ "nullable": true,
+ "type": "integer"
+}Output schema / $defs / RawSessionOutput / properties / content_hashAdded value: +{
+ "type": "string"
+}Output schema / $defs / RawSessionOutput / properties / hostAdded value: +{
+ "type": "string"
+}Output schema / $defs / RawSessionOutput / properties / session_modeAdded value: +{
+ "type": "string"
+}Output schema / $defs / RawSessionOutput / properties / session_refAdded value: +{
+ "type": "string"
+}Output schema / $defs / RawSessionOutput / requiredPrevious value: -[
- "source_root",
- "project",
- "session_id",
- "first_epoch",
- "last_epoch",
- "message_count",
- "user_message_count",
- "assistant_message_count",
- "user_message_samples"
-]New value: +[
+ "session_ref",
+ "host",
+ "session_mode",
+ "source_root",
+ "project",
+ "session_id",
+ "first_epoch",
+ "last_epoch",
+ "message_count",
+ "user_message_count",
+ "assistant_message_count",
+ "content_hash",
+ "user_message_samples"
+]Output schema / properties / excluded_legacy_rowsAdded value: +{
+ "format": "uint",
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / excluded_legacy_sessionsAdded value: +{
+ "format": "uint",
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / latestAdded value: +{
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+}Output schema / requiredPrevious value: -[
- "sample",
- "count",
- "sessions"
-]New value: +[
+ "sample",
+ "count",
+ "excluded_legacy_rows",
+ "excluded_legacy_sessions",
+ "sessions"
+]v0.6.82save_memory3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / acknowledge_patternRemoved value: -{
- "description": "Explicitly acknowledge an instruction-pattern match in direct save text after human review. Must match the detected pattern id, e.g. override_previous_instructions.",
- "nullable": true,
- "type": "string"
-}Input schema / properties / idempotency_keyAdded value: +{
+ "description": "Optional retry identity. Repeating the same key and exact request is idempotent; reusing it with changed content, route, trust, or policy fails.",
+ "nullable": true,
+ "type": "string"
+}v0.6.78context_bundle2 fields changedOutput schema / $defs / ContextAuditOutput / properties / shadow_comparisonAdded value: +{
+ "items": {
+ "$ref": "#/$defs/CurrentTruthShadowDiffOutput"
+ },
+ "type": "array"
+}Output schema / $defs / CurrentTruthShadowDiffOutputAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "claim_refs": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "projection_ref": {
+ "default": null,
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "reason": {
+ "type": "string"
+ },
+ "stable_key": {
+ "type": "string"
+ },
+ "verdict": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "stable_key",
+ "verdict",
+ "claim_refs",
+ "reason"
+ ],
+ "type": "object"
+}get_observations4 fields changedOutput schema / $defs / MemoryDetailOutput / properties / classificationAdded value: +{
+ "type": "string"
+}Output schema / $defs / MemoryDetailOutput / properties / classification_reasonAdded value: +{
+ "type": "string"
+}Output schema / $defs / MemoryDetailOutput / properties / current_context_eligibleAdded value: +{
+ "type": "boolean"
+}Output schema / $defs / MemoryDetailOutput / requiredPrevious value: -[
- "id",
- "project",
- "title",
- "text",
- "memory_type",
- "created_at_epoch",
- "updated_at_epoch",
- "status",
- "scope"
-]New value: +[
+ "id",
+ "project",
+ "title",
+ "text",
+ "memory_type",
+ "created_at_epoch",
+ "updated_at_epoch",
+ "status",
+ "scope",
+ "classification",
+ "classification_reason",
+ "current_context_eligible"
+]search4 fields changedOutput schema / $defs / SearchResultOutput / properties / classificationAdded value: +{
+ "type": "string"
+}Output schema / $defs / SearchResultOutput / properties / classification_reasonAdded value: +{
+ "type": "string"
+}Output schema / $defs / SearchResultOutput / properties / current_context_eligibleAdded value: +{
+ "type": "boolean"
+}Output schema / $defs / SearchResultOutput / requiredPrevious value: -[
- "id",
- "type",
- "title",
- "source",
- "source_type",
- "updated_at",
- "project",
- "status"
-]New value: +[
+ "id",
+ "type",
+ "title",
+ "source",
+ "source_type",
+ "updated_at",
+ "project",
+ "status",
+ "classification",
+ "classification_reason",
+ "current_context_eligible"
+]v0.6.45commits_for_session1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "CommitSessionLinkOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "linked_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "memory_session_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "session_id": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "summary": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/SessionSummaryTraceOutput"
+ },
+ {
+ "anyOf": [
+ {
+ "const": null
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ ]
+ }
+ },
+ "required": [
+ "session_id",
+ "source",
+ "linked_at_epoch"
+ ],
+ "type": "object"
+ },
+ "GitCommitOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "authored_at_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "branch": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "changed_files": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "created_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "message": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "project": {
+ "type": "string"
+ },
+ "repo_path": {
+ "type": "string"
+ },
+ "sha": {
+ "type": "string"
+ },
+ "short_sha": {
+ "type": "string"
+ },
+ "updated_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "id",
+ "project",
+ "repo_path",
+ "sha",
+ "short_sha",
+ "changed_files",
+ "created_at_epoch",
+ "updated_at_epoch"
+ ],
+ "type": "object"
+ },
+ "SessionCommitOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "git": {
+ "$ref": "#/$defs/GitCommitOutput"
+ },
+ "link": {
+ "$ref": "#/$defs/CommitSessionLinkOutput"
+ }
+ },
+ "required": [
+ "git",
+ "link"
+ ],
+ "type": "object"
+ },
+ "SessionSummaryTraceOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "completed": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "decisions": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "learned": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "next_steps": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "preferences": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "request": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "commits": {
+ "items": {
+ "$ref": "#/$defs/SessionCommitOutput"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "commits"
+ ],
+ "title": "SessionCommitsOutput",
+ "type": "object"
+}context_bundlecurrent_state1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "CurrentStateAnswerOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "memory_type": {
+ "type": "string"
+ },
+ "project": {
+ "type": "string"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "staleness": {
+ "$ref": "#/$defs/MemoryStalenessOutput"
+ },
+ "status": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "topic_key": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "updated_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "text",
+ "memory_type",
+ "project",
+ "scope",
+ "status",
+ "updated_at_epoch",
+ "staleness"
+ ],
+ "type": "object"
+ },
+ "CurrentStateFactOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "object": {
+ "type": "string"
+ },
+ "predicate": {
+ "type": "string"
+ },
+ "source_event_ids": {
+ "items": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "source_memory_id": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "status": {
+ "type": "string"
+ },
+ "subject": {
+ "type": "string"
+ },
+ "valid_from_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "valid_to_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "subject",
+ "predicate",
+ "object",
+ "status"
+ ],
+ "type": "object"
+ },
+ "CurrentStateKeySummaryOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "current_memory_id": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "memory_type": {
+ "type": "string"
+ },
+ "owner_key": {
+ "type": "string"
+ },
+ "owner_scope": {
+ "type": "string"
+ },
+ "state_key": {
+ "type": "string"
+ },
+ "state_label": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "state_status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "owner_scope",
+ "owner_key",
+ "memory_type",
+ "state_key",
+ "state_status"
+ ],
+ "type": "object"
+ },
+ "CurrentStateMemoryRefOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "evidence_event_ids": {
+ "items": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "memory_type": {
+ "type": "string"
+ },
+ "project": {
+ "type": "string"
+ },
+ "reason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "relation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source_candidate_id": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "source_operation_id": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "staleness": {
+ "$ref": "#/$defs/MemoryStalenessOutput"
+ },
+ "status": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "topic_key": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "updated_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "memory_type",
+ "project",
+ "status",
+ "updated_at_epoch",
+ "staleness"
+ ],
+ "type": "object"
+ },
+ "CurrentStateStatus": {
+ "enum": [
+ "current",
+ "not_found",
+ "ambiguous",
+ "unresolved_conflict",
+ "no_current"
+ ],
+ "type": "string"
+ },
+ "CurrentStateWhyOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "created_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "edge_type": {
+ "type": "string"
+ },
+ "evidence_event_ids": {
+ "items": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "from_memory_id": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "reason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source_candidate_id": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "source_operation_id": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "to_memory_id": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "edge_type",
+ "created_at_epoch"
+ ],
+ "type": "object"
+ },
+ "MemoryStalenessOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "age": {
+ "type": "string"
+ },
+ "error": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "label": {
+ "type": "string"
+ },
+ "source_anchor": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "age",
+ "source_anchor",
+ "label"
+ ],
+ "type": "object"
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "as_of_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "conflicts": {
+ "items": {
+ "$ref": "#/$defs/CurrentStateMemoryRefOutput"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "current": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/CurrentStateAnswerOutput"
+ },
+ {
+ "anyOf": [
+ {
+ "const": null
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ ]
+ },
+ "facts": {
+ "items": {
+ "$ref": "#/$defs/CurrentStateFactOutput"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "history": {
+ "items": {
+ "$ref": "#/$defs/CurrentStateMemoryRefOutput"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "matches": {
+ "items": {
+ "$ref": "#/$defs/CurrentStateKeySummaryOutput"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "state": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/CurrentStateKeySummaryOutput"
+ },
+ {
+ "anyOf": [
+ {
+ "const": null
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ ]
+ },
+ "state_key": {
+ "type": "string"
+ },
+ "status": {
+ "$ref": "#/$defs/CurrentStateStatus"
+ },
+ "why": {
+ "items": {
+ "$ref": "#/$defs/CurrentStateWhyOutput"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "status",
+ "state_key"
+ ],
+ "title": "CurrentStateOutput",
+ "type": "object"
+}get_observations1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "CompressedObservationSourceOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "compressed_observation_id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "compression_session_id": {
+ "type": "string"
+ },
+ "created_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "source_created_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "source_hash": {
+ "type": "string"
+ },
+ "source_observation_id": {
+ "format": "int64",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "compressed_observation_id",
+ "source_observation_id",
+ "source_hash",
+ "source_created_at_epoch",
+ "compression_session_id",
+ "created_at_epoch"
+ ],
+ "type": "object"
+ },
+ "DetailOutput": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/MemoryDetailOutput"
+ },
+ {
+ "$ref": "#/$defs/ObservationDetailOutput"
+ }
+ ]
+ },
+ "MemoryDetailOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "branch": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "files": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "memory_type": {
+ "type": "string"
+ },
+ "project": {
+ "type": "string"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "session_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "type": "string"
+ },
+ "temporal_facts": {
+ "items": {
+ "$ref": "#/$defs/MemoryTemporalFactOutput"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "text": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "topic_key": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "topic_trace": {
+ "items": {
+ "$ref": "#/$defs/TopicTraceOutput"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "updated_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "id",
+ "project",
+ "title",
+ "text",
+ "memory_type",
+ "created_at_epoch",
+ "updated_at_epoch",
+ "status",
+ "scope"
+ ],
+ "type": "object"
+ },
+ "MemoryTemporalFactOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "confidence": {
+ "format": "double",
+ "type": "number"
+ },
+ "learned_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "object": {
+ "type": "string"
+ },
+ "predicate": {
+ "type": "string"
+ },
+ "project": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "subject": {
+ "type": "string"
+ },
+ "valid_from_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "valid_to_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "project",
+ "subject",
+ "predicate",
+ "object",
+ "learned_at_epoch",
+ "confidence",
+ "status"
+ ],
+ "type": "object"
+ },
+ "ObservationDetailOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "branch": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "commit_sha": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "compressed_sources": {
+ "items": {
+ "$ref": "#/$defs/CompressedObservationSourceOutput"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "concepts": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "content_session_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at": {
+ "type": "string"
+ },
+ "created_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "discovery_tokens": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "facts": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "files_modified": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "files_read": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "last_accessed_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "memory_session_id": {
+ "type": "string"
+ },
+ "narrative": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "project": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "type": "string"
+ },
+ "subtitle": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "memory_session_id",
+ "type",
+ "created_at",
+ "created_at_epoch",
+ "status"
+ ],
+ "type": "object"
+ },
+ "TopicTraceOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "covered_from_event_id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "covered_to_event_id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "created_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "evidence_event_ids": {
+ "items": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "type": "array"
+ },
+ "files": {
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "segment_index": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "status": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "topic_key": {
+ "type": "string"
+ },
+ "updated_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "id",
+ "topic_key",
+ "title",
+ "summary",
+ "status",
+ "segment_index",
+ "covered_from_event_id",
+ "covered_to_event_id",
+ "evidence_event_ids",
+ "created_at_epoch",
+ "updated_at_epoch"
+ ],
+ "type": "object"
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "details": {
+ "items": {
+ "$ref": "#/$defs/DetailOutput"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "details"
+ ],
+ "title": "ObservationDetailsOutput",
+ "type": "object"
+}govern_memory1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "GovernedMemoryOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "new_status": {
+ "type": "string"
+ },
+ "previous_status": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "previous_status",
+ "new_status"
+ ],
+ "type": "object"
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "type": "string"
+ },
+ "affected": {
+ "items": {
+ "$ref": "#/$defs/GovernedMemoryOutput"
+ },
+ "type": "array"
+ },
+ "dry_run": {
+ "type": "boolean"
+ },
+ "reason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "dry_run",
+ "action",
+ "reason",
+ "affected"
+ ],
+ "title": "GovernMemoryOutput",
+ "type": "object"
+}list_raw_sessions1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "RawSessionOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "assistant_message_count": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "first_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "last_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "message_count": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "project": {
+ "type": "string"
+ },
+ "session_id": {
+ "type": "string"
+ },
+ "source_root": {
+ "type": "string"
+ },
+ "user_message_count": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "user_message_samples": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "source_root",
+ "project",
+ "session_id",
+ "first_epoch",
+ "last_epoch",
+ "message_count",
+ "user_message_count",
+ "assistant_message_count",
+ "user_message_samples"
+ ],
+ "type": "object"
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "format": "uint",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "project": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sample": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "sessions": {
+ "items": {
+ "$ref": "#/$defs/RawSessionOutput"
+ },
+ "type": "array"
+ },
+ "since_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "until_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "sample",
+ "count",
+ "sessions"
+ ],
+ "title": "RawSessionsOutput",
+ "type": "object"
+}lookup_commit1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "CommitLookupOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "git": {
+ "$ref": "#/$defs/GitCommitOutput"
+ },
+ "sessions": {
+ "items": {
+ "$ref": "#/$defs/CommitSessionLinkOutput"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "git",
+ "sessions"
+ ],
+ "type": "object"
+ },
+ "CommitSessionLinkOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "linked_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "memory_session_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "session_id": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "summary": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/SessionSummaryTraceOutput"
+ },
+ {
+ "anyOf": [
+ {
+ "const": null
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ ]
+ }
+ },
+ "required": [
+ "session_id",
+ "source",
+ "linked_at_epoch"
+ ],
+ "type": "object"
+ },
+ "GitCommitOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "authored_at_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "branch": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "changed_files": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "created_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "message": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "project": {
+ "type": "string"
+ },
+ "repo_path": {
+ "type": "string"
+ },
+ "sha": {
+ "type": "string"
+ },
+ "short_sha": {
+ "type": "string"
+ },
+ "updated_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "id",
+ "project",
+ "repo_path",
+ "sha",
+ "short_sha",
+ "changed_files",
+ "created_at_epoch",
+ "updated_at_epoch"
+ ],
+ "type": "object"
+ },
+ "SessionSummaryTraceOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "completed": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "decisions": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "learned": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "next_steps": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "preferences": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "request": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "commits": {
+ "items": {
+ "$ref": "#/$defs/CommitLookupOutput"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "commits"
+ ],
+ "title": "CommitLookupsOutput",
+ "type": "object"
+}recall_user_context1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "RecallCandidateCountsOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "claims": {
+ "format": "uint",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "current_state": {
+ "format": "uint",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "dropped": {
+ "format": "uint",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "memories": {
+ "format": "uint",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "sessions": {
+ "format": "uint",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "summaries": {
+ "format": "uint",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "workstreams": {
+ "format": "uint",
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "summaries",
+ "claims",
+ "memories",
+ "current_state",
+ "workstreams",
+ "sessions",
+ "dropped"
+ ],
+ "type": "object"
+ },
+ "RecallDiagnosticsOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "budget_chars": {
+ "format": "uint",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "candidate_counts": {
+ "$ref": "#/$defs/RecallCandidateCountsOutput"
+ },
+ "requested_limit": {
+ "format": "uint",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "used_chars": {
+ "format": "uint",
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "requested_limit",
+ "budget_chars",
+ "used_chars",
+ "candidate_counts"
+ ],
+ "type": "object"
+ },
+ "RecallDroppedItemOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "label": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "reason_code": {
+ "type": "string"
+ },
+ "source_id": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "source_type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "source_type",
+ "reason_code"
+ ],
+ "type": "object"
+ },
+ "RecallIncludedItemOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "reason_codes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "source_id": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "source_refs": {},
+ "source_type": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "source_type",
+ "text",
+ "reason_codes",
+ "source_refs"
+ ],
+ "type": "object"
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "context": {
+ "type": "string"
+ },
+ "diagnostics": {
+ "$ref": "#/$defs/RecallDiagnosticsOutput"
+ },
+ "dropped": {
+ "items": {
+ "$ref": "#/$defs/RecallDroppedItemOutput"
+ },
+ "type": "array"
+ },
+ "empty": {
+ "type": "boolean"
+ },
+ "host": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "included": {
+ "items": {
+ "$ref": "#/$defs/RecallIncludedItemOutput"
+ },
+ "type": "array"
+ },
+ "project": {
+ "type": "string"
+ },
+ "query": {
+ "type": "string"
+ },
+ "task_intent": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "usage_policy": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "query",
+ "project",
+ "empty",
+ "context",
+ "included",
+ "dropped",
+ "diagnostics"
+ ],
+ "title": "RecallUserContextOutput",
+ "type": "object"
+}save_memory1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "LocalCopyOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "path": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "reason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ },
+ "SaveMemoryNextStepOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "ids": {
+ "items": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "type": "array"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tool",
+ "ids",
+ "source",
+ "reason"
+ ],
+ "type": "object"
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "branch": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "claim_error": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "claim_id": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "claim_status": {
+ "type": "string"
+ },
+ "created_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "local_copy": {
+ "$ref": "#/$defs/LocalCopyOutput"
+ },
+ "local_path": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "local_status": {
+ "type": "string"
+ },
+ "memory_type": {
+ "type": "string"
+ },
+ "next_step": {
+ "$ref": "#/$defs/SaveMemoryNextStepOutput"
+ },
+ "operation": {
+ "type": "string"
+ },
+ "project": {
+ "type": "string"
+ },
+ "reference_time_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "topic_key": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "updated_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "upserted": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "id",
+ "status",
+ "memory_type",
+ "project",
+ "scope",
+ "operation",
+ "created_at_epoch",
+ "reference_time_epoch",
+ "updated_at_epoch",
+ "upserted",
+ "local_copy",
+ "local_status",
+ "claim_status",
+ "next_step"
+ ],
+ "title": "SaveMemoryOutput",
+ "type": "object"
+}search6 fields changedInput schema / properties / include_supersededAdded value: +{
+ "description": "Allow superseded history in the task-aware RetrievalPlan. This does not replace include_stale; use include_stale=true when the search result set should include inactive rows.",
+ "nullable": true,
+ "type": "boolean"
+}Input schema / properties / riskAdded value: +{
+ "description": "Risk class for task-aware retrieval planning: low, medium, or high (default medium). High risk disables raw fallback and only requests router-approved rerank.",
+ "nullable": true,
+ "type": "string"
+}Input schema / properties / roleAdded value: +{
+ "description": "Agent role for task-aware retrieval planning: coder, reviewer, planner, or researcher (default coder). Only used when task-aware routing is requested.",
+ "nullable": true,
+ "type": "string"
+}Input schema / properties / task_intentAdded value: +{
+ "description": "Optional task-aware retrieval intent. Accepted values: resume_work/resume-work, explain_decision/explain-decision, debug_failure/debug-failure, apply_preference/apply-preference, review_change/review-change, explore_history/explore-history. When set, MCP search compiles a GH-934 RetrievalPlan and applies its execution policy.",
+ "nullable": true,
+ "type": "string"
+}Input schema / properties / token_budgetAdded value: +{
+ "description": "Total token budget recorded in the task-aware RetrievalPlan (default 4000). Must be greater than zero.",
+ "format": "uint32",
+ "minimum": 0,
+ "nullable": true,
+ "type": "integer"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "MemoryStalenessOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "age": {
+ "type": "string"
+ },
+ "error": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "label": {
+ "type": "string"
+ },
+ "source_anchor": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "age",
+ "source_anchor",
+ "label"
+ ],
+ "type": "object"
+ },
+ "RawSearchHitOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "branch": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at": {
+ "type": "string"
+ },
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "preview": {
+ "type": "string"
+ },
+ "project": {
+ "type": "string"
+ },
+ "role": {
+ "type": "string"
+ },
+ "session_id": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "source_type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "source_type",
+ "session_id",
+ "project",
+ "role",
+ "preview",
+ "source",
+ "created_at"
+ ],
+ "type": "object"
+ },
+ "SearchMultiHopOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "entities_discovered": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "hops": {
+ "format": "uint8",
+ "maximum": 255,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "hops",
+ "entities_discovered"
+ ],
+ "type": "object"
+ },
+ "SearchNextStepOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "ids": {
+ "items": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "type": "array"
+ },
+ "include_suppressed": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tool",
+ "source",
+ "ids",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "SearchPaginationOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "has_more": {
+ "type": "boolean"
+ },
+ "limit": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "next_offset": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "offset": {
+ "format": "int64",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "limit",
+ "offset",
+ "has_more"
+ ],
+ "type": "object"
+ },
+ "SearchRerankPolicyOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "candidate_pool": {
+ "format": "uint32",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "enabled": {
+ "type": "boolean"
+ },
+ "output_k": {
+ "format": "uint32",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "require_canonical_evidence_top1": {
+ "type": "boolean"
+ },
+ "timeout_fallback": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "enabled",
+ "candidate_pool",
+ "output_k",
+ "timeout_fallback",
+ "require_canonical_evidence_top1"
+ ],
+ "type": "object"
+ },
+ "SearchResultOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "preview": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "project": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "source_type": {
+ "type": "string"
+ },
+ "staleness": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/MemoryStalenessOutput"
+ },
+ {
+ "anyOf": [
+ {
+ "const": null
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ ]
+ },
+ "status": {
+ "type": "string"
+ },
+ "temporal_facts": {
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "title": {
+ "type": "string"
+ },
+ "topic_key": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": "string"
+ },
+ "updated_at": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "type",
+ "title",
+ "source",
+ "source_type",
+ "updated_at",
+ "project",
+ "status"
+ ],
+ "type": "object"
+ },
+ "SearchRetrievalFiltersOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "as_of_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "branch": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "include_superseded": {
+ "type": "boolean"
+ },
+ "project": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "project",
+ "include_superseded",
+ "as_of_epoch"
+ ],
+ "type": "object"
+ },
+ "SearchRetrievalPlanOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "applied_effects": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "disabled_channels": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "enabled_channels": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "filters": {
+ "$ref": "#/$defs/SearchRetrievalFiltersOutput"
+ },
+ "intent": {
+ "type": "string"
+ },
+ "intent_source": {
+ "type": "string"
+ },
+ "plan_hash": {
+ "type": "string"
+ },
+ "policy_version": {
+ "type": "string"
+ },
+ "reason_codes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "rerank_policy": {
+ "$ref": "#/$defs/SearchRerankPolicyOutput"
+ },
+ "risk": {
+ "type": "string"
+ },
+ "role": {
+ "type": "string"
+ },
+ "schema_version": {
+ "format": "uint32",
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "schema_version",
+ "policy_version",
+ "plan_hash",
+ "intent",
+ "intent_source",
+ "role",
+ "risk",
+ "reason_codes",
+ "applied_effects",
+ "filters",
+ "rerank_policy",
+ "enabled_channels",
+ "disabled_channels"
+ ],
+ "type": "object"
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "explain": {},
+ "has_more": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "mode": {
+ "type": "string"
+ },
+ "multi_hop": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/SearchMultiHopOutput"
+ },
+ {
+ "anyOf": [
+ {
+ "const": null
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ ]
+ },
+ "next_offset": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "next_step": {
+ "$ref": "#/$defs/SearchNextStepOutput"
+ },
+ "pagination": {
+ "$ref": "#/$defs/SearchPaginationOutput"
+ },
+ "raw_hits": {
+ "items": {
+ "$ref": "#/$defs/RawSearchHitOutput"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "raw_hits_error": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "raw_hits_note": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "results": {
+ "items": {
+ "$ref": "#/$defs/SearchResultOutput"
+ },
+ "type": "array"
+ },
+ "retrieval_plan": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/SearchRetrievalPlanOutput"
+ },
+ {
+ "anyOf": [
+ {
+ "const": null
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ ]
+ }
+ },
+ "required": [
+ "mode",
+ "results",
+ "next_step",
+ "pagination",
+ "explain"
+ ],
+ "title": "SearchOutput",
+ "type": "object"
+}search_raw1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "RawArchiveRowOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "branch": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "content": {
+ "type": "string"
+ },
+ "created_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "cwd": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "project": {
+ "type": "string"
+ },
+ "role": {
+ "type": "string"
+ },
+ "session_id": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "source_type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "source_type",
+ "session_id",
+ "project",
+ "role",
+ "content",
+ "source",
+ "created_at_epoch"
+ ],
+ "type": "object"
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "branch": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "count": {
+ "format": "uint",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "has_more": {
+ "type": "boolean"
+ },
+ "limit": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "next_offset": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "note": {
+ "type": "string"
+ },
+ "offset": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "project": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "query": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "$ref": "#/$defs/RawArchiveRowOutput"
+ },
+ "type": "array"
+ },
+ "role": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "since_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "source_type": {
+ "type": "string"
+ },
+ "until_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "query",
+ "limit",
+ "offset",
+ "source_type",
+ "note",
+ "count",
+ "has_more",
+ "results"
+ ],
+ "title": "SearchRawOutput",
+ "type": "object"
+}timeline1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "ObservationOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "branch": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "commit_sha": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "concepts": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "content_session_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at": {
+ "type": "string"
+ },
+ "created_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "discovery_tokens": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "facts": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "files_modified": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "files_read": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "last_accessed_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "memory_session_id": {
+ "type": "string"
+ },
+ "narrative": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "project": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "type": "string"
+ },
+ "subtitle": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "memory_session_id",
+ "type",
+ "created_at",
+ "created_at_epoch",
+ "status"
+ ],
+ "type": "object"
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "observations": {
+ "items": {
+ "$ref": "#/$defs/ObservationOutput"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "observations"
+ ],
+ "title": "TimelineOutput",
+ "type": "object"
+}update_workstream3 fields changedInput schema / properties / status / enumAdded value: +[
+ "active",
+ "paused",
+ "completed",
+ "abandoned"
+]Input schema / requiredPrevious value: -[
- "id"
-]New value: +[
+ "id",
+ "status"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "updated": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "id",
+ "updated"
+ ],
+ "title": "UpdateWorkstreamOutput",
+ "type": "object"
+}workstreams3 fields changedInput schema / properties / status / enumAdded value: +[
+ "active",
+ "paused",
+ "completed",
+ "abandoned"
+]Input schema / requiredAdded value: +[
+ "status"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "WorkstreamOutput": {
+ "additionalProperties": false,
+ "properties": {
+ "blockers": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "completed_at_epoch": {
+ "format": "int64",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "created_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "format": "int64",
+ "type": "integer"
+ },
+ "next_action": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "progress": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "project": {
+ "type": "string"
+ },
+ "status": {
+ "$ref": "#/$defs/WorkstreamStatus"
+ },
+ "title": {
+ "type": "string"
+ },
+ "updated_at_epoch": {
+ "format": "int64",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "id",
+ "project",
+ "title",
+ "status",
+ "created_at_epoch",
+ "updated_at_epoch"
+ ],
+ "type": "object"
+ },
+ "WorkstreamStatus": {
+ "enum": [
+ "active",
+ "paused",
+ "completed",
+ "abandoned"
+ ],
+ "type": "string"
+ }
+ },
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "workstreams": {
+ "items": {
+ "$ref": "#/$defs/WorkstreamOutput"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "workstreams"
+ ],
+ "title": "WorkstreamsOutput",
+ "type": "object"
+}commits_for_sessioncurrent_stateget_observationsgovern_memorylist_raw_sessionslookup_commitrecall_user_contextsave_memorysearchsearch_rawtimelinetimeline_reportupdate_workstreamworkstreamsScored across 15 tools
Most tools include explicit positioning guidance, but the set has several overlapping retrieval/context-assembly tools: search, search_raw, current_state, timeline, context_bundle, and recall_user_context could all plausibly match a lookup request. The long descriptions help disambiguate them, but an agent scanning names alone would likely confuse context_bundle with recall_user_context or timeline with timeline_report.
The set mixes verb-led names like save_memory, update_workstream, and lookup_commit with noun-led names like workstreams, timeline, and context_bundle, plus the odd commits_for_session. There is no single predictable naming pattern, though the names are individually readable and avoid chaotic style mixing.
Fifteen tools is at the upper edge of a compact surface, but the set covers memory management, raw sessions, git commit links, workstreams, and reporting without feeling padded. A few retrieval helpers could be consolidated, so it is slightly heavy rather than perfectly minimal.
The core memory lifecycle is covered: save_memory creates/updates, search and get_observations retrieve, and govern_memory handles deletion/staleness. The main gap is workstreams, which can be listed and updated but not created or deleted, though that is a workable omission for the primary memory-centric workflow.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
