de en es ja ko ru zh

Audrey

Name: Audrey
Author: Evilander

by Evilander

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

Why Audrey Exists

Agents forget the exact mistakes they made yesterday. They repeat broken commands, lose project-specific rules, miss contradictions, and treat every new session like a cold start.

Audrey turns those hard-won lessons into a local memory runtime:

memory_recall finds durable context by semantic similarity.
memory_preflight checks prior failures, risks, rules, and relevant procedures before an action.
memory_reflexes converts remembered evidence into trigger-response guidance agents can follow.
memory_validate closes the loop after the action — helpful, used, or wrong outcomes feed salience and decay.
memory_dream consolidates episodes into principles and applies decay.
audrey impact and audrey doctor tell a human or CI system whether the runtime is doing real work and is actually ready.

It is not a hosted vector database, a notes app, or a Claude-only plugin. Audrey is a SQLite-backed continuity layer that can sit under any local or sidecar agent loop.

Related MCP server: GoodMemory

Quick Start

Requires Node.js 20+.

npx audrey doctor
npx audrey demo

doctor verifies Node, the MCP entrypoint, provider selection, memory-store health, and host config generation. demo runs a no-key, no-host, no-network proof: it creates temporary memories, records a redacted failed tool trace, generates a Memory Capsule, proves recall, prints Memory Reflexes, and deletes the demo store.

Expected first-run shape:

Audrey Doctor v0.22.2
Store health: not initialized
Verdict: ready

After the first real memory write, doctor should report the store as healthy.

Install Into Agent Hosts

Preview host setup without editing config files:

npx audrey install --host codex --dry-run
npx audrey install --host claude-code --dry-run
npx audrey install --host generic --dry-run

Generate raw config blocks:

npx audrey mcp-config codex
npx audrey mcp-config generic
npx audrey mcp-config vscode

Claude Code can be registered directly:

npx audrey install
claude mcp list

All local MCP paths default to local embeddings and one shared SQLite-backed memory directory. Use AUDREY_DATA_DIR to isolate projects, tenants, or host identities.

Installer-generated host config does not include provider API keys by default. Prefer setting ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY, or GEMINI_API_KEY in the host runtime environment; use npx audrey install --include-secrets only if you explicitly accept argv/config exposure.

Use With Ollama And Local Agents

Ollama runs models; Audrey supplies memory. Start Audrey as a local REST sidecar and expose its routes as tools in your agent loop:

AUDREY_AGENT=ollama-local-agent npx audrey serve
curl http://localhost:7437/health
curl http://localhost:7437/v1/status

Runnable example:

AUDREY_AGENT=ollama-local-agent npx audrey serve
OLLAMA_MODEL=qwen3 node examples/ollama-memory-agent.js "What should you remember about Audrey?"

Core sidecar tools:

Agent Need	REST Route
Check memory before acting	`POST /v1/preflight`
Get reflex rules for an action	`POST /v1/reflexes`
Store a useful observation	`POST /v1/encode`
Recall relevant context	`POST /v1/recall`
Get a turn-sized memory packet	`POST /v1/capsule`
Check health	`GET /v1/status`

What Ships

Surface	Status
MCP stdio server	20 tools plus status/recent/principles resources and briefing/recall/reflection prompts
CLI	`doctor`, `demo`, `install`, `mcp-config`, `status`, `dream`, `reembed`, `observe-tool`, `promote`, `impact`
REST API	Hono server with `/health` and `/v1/*` routes
JavaScript SDK	Direct TypeScript/Node import from `audrey`
Python client	`pip install audrey-memory`, calls the REST sidecar
Storage	Local SQLite plus `sqlite-vec`, no hosted database required
Deployment	npm package, Docker, Compose, host-specific MCP config generation
Safety loop	preflight warnings, reflexes, redacted tool traces, contradiction handling

Memory Model

Audrey is built around the parts of memory that matter for agents:

Episodic memory: specific observations, tool results, preferences, and session facts.
Semantic memory: consolidated principles extracted from repeated evidence.
Procedural memory: remembered ways to act, avoid, retry, or verify.
Affect and salience: emotional weight and importance influence recall.
Interference and decay: stale, conflicting, or low-confidence memories lose authority over time.
Contradiction handling: competing claims are tracked instead of silently overwritten.
Tool-trace learning: failed commands and risky actions become future preflight warnings.

The product bet is simple: the next generation of useful agents will not just retrieve facts. They will remember what happened, decide whether a memory is still trustworthy, and use that memory before touching tools.

Use Audrey From Code

JavaScript

import { Audrey } from 'audrey';

const brain = new Audrey({
  dataDir: './audrey-data',
  agent: 'support-agent',
  embedding: { provider: 'local', dimensions: 384 },
});

await brain.encode({
  content: 'Stripe returns HTTP 429 above 100 req/s',
  source: 'direct-observation',
  tags: ['stripe', 'rate-limit'],
});

const memories = await brain.recall('stripe rate limit');

await brain.waitForIdle();
brain.close();

Python

pip install audrey-memory

from audrey_memory import Audrey

brain = Audrey(base_url="http://127.0.0.1:7437", agent="support-agent")
memory_id = brain.encode("Stripe returns HTTP 429 above 100 req/s", source="direct-observation")
results = brain.recall("stripe rate limit", limit=5)
brain.close()

Production Readiness

Audrey is close to a 1.0-ready local memory runtime, but production depends on how it is embedded. Treat it like stateful infrastructure.

Release gates used for this package:

npm run release:gate
npx audrey doctor
npx audrey demo

Recommended runtime checks:

npx audrey doctor --json
npx audrey status --json --fail-on-unhealthy
npx audrey install --host codex --dry-run

Production controls you still own:

Set one AUDREY_DATA_DIR per tenant, environment, or isolation boundary.
Pin AUDREY_EMBEDDING_PROVIDER and AUDREY_LLM_PROVIDER explicitly.
Back up the SQLite data directory before provider or dimension changes.
Keep API keys and raw credentials out of encoded memory content.
Use AUDREY_API_KEY if the REST sidecar is reachable beyond the local process boundary.
Run npx audrey dream on a schedule so consolidation and decay stay current.
Add application-level encryption, retention, access control, and audit logging for regulated environments.

Environment Variables

Variable	Default	Purpose
`AUDREY_DATA_DIR`	`~/.audrey/data`	SQLite memory store path. Use one per tenant or agent identity for isolation.
`AUDREY_AGENT`	`local-agent`	Logical agent identity stamped on writes.
`AUDREY_EMBEDDING_PROVIDER`	`local`	`local`, `gemini`, `openai`, or `mock`. Cloud providers require explicit opt-in.
`AUDREY_LLM_PROVIDER`	auto	`anthropic`, `openai`, or `mock`.
`AUDREY_DEVICE`	`gpu`	Local embedding device (`gpu` or `cpu`). Falls back to CPU if GPU init fails.
`AUDREY_PORT`	`7437`	REST sidecar port.
`AUDREY_HOST`	`127.0.0.1`	REST sidecar bind address. Set to `0.0.0.0` only with `AUDREY_API_KEY`.
`AUDREY_API_KEY`	unset	Bearer token required for non-loopback REST traffic.
`AUDREY_ALLOW_NO_AUTH`	`0`	Set to `1` to allow non-loopback bind without an API key. Don't.
`AUDREY_ENABLE_ADMIN_TOOLS`	`0`	Set to `1` to enable export, import, and forget routes/tools. Disabled by default.
`AUDREY_PROMOTE_ROOTS`	unset	Colon/semicolon-separated extra roots for `audrey promote --yes` writes. By default writes are restricted to `process.cwd()`.
`AUDREY_DEBUG`	`0`	Set to `1` to print MCP info logs (server started, warmup completed). Errors always log.
`AUDREY_PROFILE`	`0`	Set to `1` to emit per-stage timings via MCP `_meta.diagnostics`.
`AUDREY_DISABLE_WARMUP`	`0`	Set to `1` to skip background embedding warmup at MCP boot.
`AUDREY_ONNX_VERBOSE`	`0`	Set to `1` to restore ONNX runtime EP-assignment warnings (suppressed by default).
`AUDREY_PRAGMA_DEFAULTS`	`1`	Set to `0` to revert SQLite PRAGMA tuning to better-sqlite3 defaults.
`AUDREY_CONTEXT_BUDGET_CHARS`	`4000`	Default Memory Capsule character budget.

Benchmarks

Audrey ships two benchmark commands.

Performance snapshot

npm run bench:perf-snapshot measures encode and hybrid recall latency at multiple corpus sizes against the in-process mock provider. It reports p50/p95/p99 plus machine provenance so the numbers are reproducible and honest about what they cover.

npm run build
npm run bench:perf-snapshot                                 # default sizes 100, 1000, 5000
node benchmarks/perf-snapshot.js --sizes 1000,10000 --json  # custom shape

Sample output from benchmarks/snapshots/perf-0.22.2.json (24-core Ryzen 9 7900X3D, Node 25.5.0, mock 64-dim embedding, hybrid recall, limit 5):

Corpus size	Encode p50 (ms)	Encode p95 (ms)	Recall p50 (ms)	Recall p95 (ms)	Recall p99 (ms)
100	0.33	0.63	0.52	1.3	3.1
1,000	0.31	1.3	0.63	0.99	7.0
5,000	0.29	1.7	2.1	2.5	18.0

These numbers cover Audrey's own pipeline (SQLite + sqlite-vec + hybrid ranking) and exclude embedding-provider cost. Real-world recall p95 with a local 384-dim provider is typically 5–15× higher; with a hosted provider it is dominated by the API round-trip. Run on your own hardware before quoting numbers anywhere.

Behavioral regression suite

npm run bench:memory:check is a release gate. It runs a small set of retrieval and lifecycle scenarios (information extraction, knowledge updates, multi-session reasoning, conflict resolution, privacy boundary, overwrite, delete-and-abstain, semantic/procedural merge) against Audrey and three weak baselines (vector-only, keyword+recency, recent-window) and asserts Audrey doesn't regress. The baseline comparisons exist to catch correctness regressions in retrieval logic, not to make marketing claims.

npm run bench:memory          # full regression suite (writes JSON + report)
npm run bench:memory:check    # release gate, exits non-zero on regression

Command Reference

# First contact
npx audrey doctor
npx audrey demo

# MCP setup
npx audrey install --host codex --dry-run
npx audrey mcp-config codex
npx audrey mcp-config generic
npx audrey install
npx audrey uninstall

# Health and maintenance
npx audrey status
npx audrey status --json --fail-on-unhealthy
npx audrey dream
npx audrey reembed

# Closed-loop visibility
npx audrey impact
npx audrey impact --json --window 7 --limit 5

# Tool-trace learning
npx audrey observe-tool --event PostToolUse --tool Bash --outcome failed
npx audrey promote --dry-run

# REST sidecar
npx audrey serve
docker compose up -d --build

The Node sidecar defaults to 127.0.0.1:7437. The Docker image intentionally binds inside the container on 3487; override the published host port with AUDREY_PUBLISHED_PORT when using Compose.

Documentation

Security policy
Public setup, runtime, benchmark, and command guidance is maintained in this README.

Development

npm ci
npm run release:gate
python -m unittest discover -s python/tests -v
python -m build --no-isolation python

On some locked-down Windows hosts, Vitest/Vite can fail before tests start with spawn EPERM. That is an environment process-spawn blocker, not an Audrey runtime failure. Use npm run release:gate:sandbox, direct dist/ smokes, and GitHub Actions as the release evidence path.

License

MIT. See LICENSE.

Available Tools

23 tools

memory_capsuleD

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Scope tool-failure risks to the project containing this directory.
`mode`	No	Capsule mode: conservative = fewer, higher-confidence entries; aggressive = broader sweep.
`limit`	No	Max recall results to consider before categorization.
`query`	Yes	Natural-language query for the turn. Drives what gets surfaced.
`scope`	No	agent restricts memory recall to this MCP server agent identity. shared searches the whole store. Defaults to agent.
`budget_chars`	No	Token budget in characters (defaults to AUDREY_CONTEXT_BUDGET_CHARS or 4000).
`include_risks`	No	Include recent tool failures as risks (default true).
`include_contradictions`	No	Include open contradictions (default true).
`recent_change_window_hours`	No	How far back "recent_changes" looks (default 24h).

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_consolidateD

ParametersJSON Schema

Name	Required	Description	Default
`min_cluster_size`	No	Minimum episodes per cluster
`similarity_threshold`	No	Similarity threshold for clustering

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_decayD

ParametersJSON Schema

Name	Required	Description	Default
`dormant_threshold`	No	Confidence below which memories go dormant (default 0.1)

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_dreamD

ParametersJSON Schema

Name	Required	Description
`min_cluster_size`	No	Minimum episodes per cluster (default 3)
`dormant_threshold`	No	Confidence below which memories go dormant (default 0.1)
`similarity_threshold`	No	Similarity threshold for clustering (default 0.85)

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_encodeD

ParametersJSON Schema

Name	Required	Description
`tags`	No	Optional tags for categorization
`affect`	No	Emotional affect - how this memory feels
`source`	Yes	Source type of the memory
`content`	Yes	The memory content to encode
`context`	No	Situational context as key-value pairs (e.g., {task: "debugging", domain: "payments"})
`private`	No	If true, memory is only visible to the AI and excluded from public recall results
`salience`	No	Importance weight 0-1
`wait_for_consolidation`	No	If true, wait for post-encode validation/interference/resonance work before returning. Defaults to false.

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_exportD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_forgetD

ParametersJSON Schema

Name	Required	Description
`id`	No	ID of the memory to forget
`purge`	No	Hard-delete the memory permanently (default false, soft-delete)
`query`	No	Semantic query to find and forget the closest matching memory
`all_agents`	No	Widen the query match across every agent namespace instead of only this server agent (default false). Admin-only cleanup escape hatch.
`min_similarity`	No	Minimum similarity for query-based forget (default 0.9)

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_greetingD

ParametersJSON Schema

Name	Required	Description	Default
`scope`	No	agent keeps greeting scoped to this server agent identity. shared includes the whole store. Defaults to agent.
`context`	No	Optional hint about this session. When provided, Audrey also returns semantically relevant memories.

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_groundD

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No	Directory identifying the project to check against. Defaults to the server cwd.

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_guard_afterD

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Working directory at the time of the action.
`tool`	No	Tool or command family that completed, e.g. Bash, npm test, Edit, deploy.
`files`	No	File paths to fingerprint (size + mtime + content hash).
`input`	No	Tool input. Hashed and never stored raw; redacted metadata is only stored when retain_details is true.
`output`	No	Tool output. Same redaction and storage policy as input.
`outcome`	No	Outcome classification
`metadata`	No	Arbitrary structured metadata (redacted before storage).
`receipt_id`	Yes	Receipt id returned by memory_guard_before.
`session_id`	No	Session identifier for grouping related guard events.
`error_summary`	No	Short error description if the action failed. Redacted and truncated to 2 KB.
`retain_details`	No	If true, redacted input and output payloads are stored alongside hashes. Defaults to false.
`override_reason`	No	Reason for recording a succeeded outcome against a Guard receipt that blocked for a reason other than an exact-repeated failure. Not needed for acknowledged exact-failure retries.
`evidence_feedback`	No	Map of evidence ids from the guard receipt to memory validation outcomes.

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_guard_beforeD

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Working directory for the action.
`mode`	No	Underlying capsule mode. Defaults to conservative.
`tool`	No	Tool or command family about to be used, e.g. Bash, npm test, Edit, deploy.
`files`	No	File paths to fingerprint in the required guard receipt.
`limit`	No	Max recall results to consider before preflight categorization.
`scope`	No	agent restricts memory recall to this server agent identity. shared searches the whole store. Defaults to agent.
`action`	Yes	Natural-language description of the action the agent is about to take.
`strict`	No	If true, high-severity memory warnings produce decision=block instead of caution.
`session_id`	No	Session identifier for grouping the required guard receipt event.
`budget_chars`	No	Capsule budget in characters.
`include_status`	No	Include memory health in the response and warning calculation. Defaults to true.
`include_capsule`	No	If false, omit the embedded Memory Capsule from the response.
`failure_window_hours`	No	How far back to check failed tool events. Defaults to 168 hours.
`acknowledge_prior_failure`	No	Acknowledge an exact prior failure and request one audited caution-level retry. Does not bypass unrelated Guard blocks.

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_importD

ParametersJSON Schema

Name	Required	Description	Default
`snapshot`	Yes	A validated snapshot from memory_export

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_introspectD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_observe_toolD

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Working directory at the time of the tool call
`tool`	Yes	Tool name being observed (Bash, Edit, Write, etc.)
`event`	Yes	Hook event name (PreToolUse, PostToolUse, PostToolUseFailure, PreCompact, PostCompact, etc.)
`files`	No	File paths to fingerprint (size + mtime + content hash)
`input`	No	Tool input. Hashed and never stored raw; redacted metadata is only stored when retain_details is true.
`output`	No	Tool output. Same redaction and storage policy as input.
`outcome`	No	Outcome classification
`metadata`	No	Arbitrary structured metadata (redacted before storage)
`session_id`	No	Session identifier for grouping related events
`error_summary`	No	Short error description if the tool failed. Redacted and truncated to 2 KB.
`retain_details`	No	If true, redacted input and output payloads are stored alongside hashes. Defaults to false.

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_preflightD

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Working directory for the action.
`mode`	No	Underlying capsule mode. Defaults to conservative.
`tool`	No	Tool or command family about to be used, e.g. Bash, npm test, Edit, deploy.
`files`	No	File paths to fingerprint if record_event is true.
`limit`	No	Max recall results to consider before preflight categorization.
`scope`	No	agent restricts memory recall to this server agent identity. shared searches the whole store. Defaults to agent.
`action`	Yes	Natural-language description of the action the agent is about to take.
`strict`	No	If true, high-severity memory warnings produce decision=block instead of caution.
`session_id`	No	Session identifier for grouping the optional preflight event.
`budget_chars`	No	Capsule budget in characters.
`record_event`	No	Record a redacted PreToolUse event for this preflight. Defaults to false.
`include_status`	No	Include memory health in the response and warning calculation. Defaults to true.
`include_capsule`	No	If false, omit the embedded Memory Capsule from the response.
`failure_window_hours`	No	How far back to check failed tool events. Defaults to 168 hours.

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_promoteD

ParametersJSON Schema

Name	Required	Description
`yes`	No	Confirm write. Without this or dry_run=false the command stays in dry-run mode.
`limit`	No	Max candidates to return/apply (default 20).
`target`	No	Promotion target. Only claude-rules is implemented in PR 4 v1.
`dry_run`	No	If true (default), return candidates without writing. Pair with yes=true to actually write.
`project_dir`	No	Absolute path to the project root where .claude/rules/ should be created. Defaults to process.cwd().
`min_evidence`	No	Minimum supporting episode count (default 2).
`min_confidence`	No	Minimum memory confidence for promotion (default 0.7 for procedural, 0.8 for semantic).

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_recallD

ParametersJSON Schema

Name	Required	Description
`mood`	No	Current mood - boosts recall of memories encoded in similar emotional state
`tags`	No	Only return episodic memories with these tags
`after`	No	Only return memories created after this ISO date
`limit`	No	Max results (default 10)
`query`	Yes	Search query to match against memories
`scope`	No	agent restricts recall to this MCP server agent identity. shared searches the whole store. Defaults to shared for backward compatibility.
`types`	No	Memory types to search
`before`	No	Only return memories created before this ISO date
`context`	No	Retrieval context - memories encoded in matching context get boosted
`sources`	No	Only return episodic memories from these sources
`retrieval`	No	Retrieval strategy. hybrid is the default (vector + FTS/BM25 fusion); vector bypasses FTS for lower latency but loses lexical exact-match signal.
`min_confidence`	No	Minimum confidence threshold

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_recent_failuresD

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Scope failures to the project containing this directory
`limit`	No	Max rows to return (defaults to 20)
`since`	No	ISO timestamp lower bound (defaults to 7 days ago)
`include_resolved`	No	Include failure streaks already resolved by a later success (default false)

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_reflectD

ParametersJSON Schema

Name	Required	Description	Default
`turns`	Yes	Conversation turns to reflect on. Call at end of meaningful conversations to form lasting memories.

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_reflexesD

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Working directory for the action.
`mode`	No	Underlying capsule mode. Defaults to conservative.
`tool`	No	Tool or command family about to be used, e.g. Bash, npm test, Edit, deploy.
`files`	No	File paths to fingerprint if record_event is true.
`limit`	No	Max recall results to consider before preflight categorization.
`scope`	No	agent restricts memory recall to this server agent identity. shared searches the whole store. Defaults to agent.
`action`	Yes	Natural-language description of the action the agent is about to take.
`strict`	No	If true, high-severity memory warnings produce decision=block instead of caution.
`session_id`	No	Session identifier for grouping the optional preflight event.
`budget_chars`	No	Capsule budget in characters.
`record_event`	No	Record a redacted PreToolUse event for this preflight. Defaults to false.
`include_status`	No	Include memory health in the response and warning calculation. Defaults to true.
`include_capsule`	No	If false, omit the embedded Memory Capsule from the response.
`include_preflight`	No	If true, include the full underlying preflight report.
`failure_window_hours`	No	How far back to check failed tool events. Defaults to 168 hours.

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_resolve_truthD

ParametersJSON Schema

Name	Required	Description	Default
`contradiction_id`	Yes	ID of the contradiction to resolve

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_statusD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_validateD

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	ID of the memory to validate
`outcome`	Yes	How the memory played out: "used" (referenced without obvious value), "helpful" (drove a correct action — reinforces salience and retrieval), "wrong" (memory was misleading — bumps challenge_count and decreases salience).

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

23 tool updatesv2.0.0Sep 22, 2026
- First observedmemory_capsule
- First observedmemory_consolidate
- First observedmemory_decay
- First observedmemory_dream
- First observedmemory_encode
- First observedmemory_export
- First observedmemory_forget
- First observedmemory_greeting
- First observedmemory_ground
- First observedmemory_guard_after
- First observedmemory_guard_before
- First observedmemory_import
- First observedmemory_introspect
- First observedmemory_observe_tool
- First observedmemory_preflight
- First observedmemory_promote
- First observedmemory_recall
- First observedmemory_recent_failures
- First observedmemory_reflect
- First observedmemory_reflexes
- First observedmemory_resolve_truth
- First observedmemory_status
- First observedmemory_validate

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

D1.6/5.0

Scored 2026-09-22 23:50 across 23 tools

Disambiguation2/5

All tools share the memory_ prefix and many names describe overlapping cognitive operations (e.g., memory_consolidate, memory_reflect, memory_dream, memory_encode, memory_recall, memory_introspect) with no descriptions to clarify boundaries. An agent would struggle to choose between several of these tools.

Naming Consistency5/5

Every tool follows the exact snake_case memory_<verb> pattern with a clear prefix and action verb. The naming convention is perfectly consistent across all 23 tools.

Tool Count3/5

23 tools is on the heavy side for a single server, even for a memory-focused domain. The count is manageable but begins to feel bloated, especially with many near-synonymous operations.

Completeness2/5

Without descriptions, the intended domain is only inferable from names, which suggest a memory lifecycle. Obvious operations like search/list or a clear memory store are absent, while many speculative tools (memory_dream, memory_greeting, memory_capsule) exist, creating significant gaps in a coherent surface.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

memnodeOAuth
dev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Knowledge & Memory Autonomous Agents Agent Orchestration
2
ContextLattice
io.github.sheawinkler
Private-by-default, local-first memory/context/task orchestrator for MCP apps and agents.
Knowledge & Memory Agent Orchestration Autonomous Agents
2152
WhiteMagic — governed local memory for agent continuity B
io.github.lbailey94
Local-first, governed memory and session continuity for AI coding agents. No cloud, no telemetry.
Knowledge & Memory Autonomous Agents Developer Tools
91
connect B
ai.odei
Governed personal world model and memory for your AI agent. Pair once, connect over MCP.
Knowledge & Memory Autonomous Agents
72

Related MCP Servers

tartarus-mcp
Knowledge & Memory Search
saluca-labs
A
license
Not graded
quality
B
maintenance
A local-first MCP memory server providing persistent, searchable memory for AI agents, powered by SQLite.
Updated 5 days ago (2026-09-17 23:28 UTC)
1 npm
1
Apache 2.0
GoodMemory
RAG Systems Knowledge & Memory Coding Agents
hjqcan
A
license
B
quality
A
maintenance
Local-first, auditable memory for Codex, Claude Code, and MCP clients. It stores scoped user/project memory in SQLite or Postgres, serves read-only recall and inspection tools by default, and supports opt-in governed writeback with review and forget controls.
Updated 9 days ago (2026-09-14 13:41 UTC)
8
145 npm
18
MIT
nuzo-memory
Knowledge & Memory Databases
fabionfsc
A
license
Not graded
quality
F
maintenance
Local-first, auditable memory for AI agents. Provides durable context for MCP hosts with SQLite storage, CLI, and MCP tools for memory management.
Updated a month ago (2026-08-14 21:46 UTC)
2
Apache 2.0
mnemo
Knowledge & Memory RAG Systems
krat214
A
license
Not graded
quality
B
maintenance
Persistent memory MCP server for AI agents, featuring a visual interface to browse, search, edit, and delete memory. It provides tools for capturing episodes, recalling, consolidating, crystallizing traits, and forgetting, with local SQLite storage and optional authenticated web UI.
Updated 2 months ago (2026-08-04 17:57 UTC)
MIT