Zaxy is a production memory fabric for agent teams, providing auditable, citeable, and queryable persistent memory through an MCP-native interface. It supports local-first operation with an embedded graph (LadybugDB), optional Neo4j integration, and MCP-native compatibility with frameworks like Codex, Claude Code, Cursor, LangGraph, CrewAI, and AutoGen.
Available tools:
memory_checkout — Primary entry point: retrieve current, cited, prompt-ready memory state for a session. Supports token budgets, replay from a sequence number, and purpose-conditioned guidance.
memory_append — Append typed events (e.g. goal.created) to the agent's persistent, immutable memory log for future retrieval.
memory_query — Query the temporal knowledge graph with natural language, supporting temporal filters, pagination/cursors, and cross-session scoping.
context_assemble — Assemble a replay of recent events plus ranked retrieval results into a single prompt-ready context bundle with optional token budget packing.
memory_feedback — Record whether a retrieved memory item was useful, stale, corrected, or reinforced, closing the feedback loop to improve future retrieval.
memory_invalidate — Mark a specific fact as invalid at a given point in time (bi-temporal update), preserving full history while surfacing corrections in future checkouts.
memory_capabilities — Discover active capabilities, tool profiles, and available tools — useful at session start or when tool awareness is unclear.
memory_feeling_of_knowing — Experimental ultra-fast metamemory pre-check (~1ms) that predicts whether memory_checkout would return relevant results, using only in-memory state without embedding or graph calls.
Enables CrewAI agents to use the same memory interface for capturing tool observations, citations, and approved merges into a durable, queryable history.
Integrates with LangGraph agents to provide an immutable event log and graph-based memory for session isolation, conflict review, and hybrid retrieval.
Offers an observe-only packet analyzer that forwards OpenAI-compatible model calls to a configured endpoint and records provenance events in Eventloom.
Production memory for agent teams that need receipts.
Zaxy turns agent context into an auditable project memory fabric. It captures parent missions, worker sessions, tool observations, cited findings, conflict review, approval packets, and accepted merge-back into one durable history that can be queried, replayed, and inspected.
Under the hood, Zaxy uses Eventloom append-only JSONL as the source of truth and an embedded LadybugDB graph projection for local reasoning. It is built for agents that need to remember what happened, cite where it came from, and avoid turning project state into a pile of markdown files and vector chunks.
The embedded LadybugDB graph projection is the default local runtime.
The plain install uses embedded LadybugDB. Install zaxy-memory[neo4j] only for the
optional Neo4j sidecar, and zaxy-memory[pathlight] only for Pathlight tracing.
Auditable memory: every accepted fact can point back to Eventloom history.
Agent-team coordination: parent and worker sessions stay isolated until findings are reviewed and merged.
Local-first runtime: the default path uses embedded LadybugDB, no Neo4j sidecar.
MCP-native integration: Codex, Claude Code, Cursor, VS Code, Hermes Agent, LangGraph, CrewAI, and AutoGen can use the same memory interface.
Benchmark claims withdrawn (2026-07-03). The prior LongMemEval numbers were withdrawn: they were produced in oracle mode (mean ~1.9 candidate sessions per question, so Recall@5/citation-coverage were ~1.0 by construction, not by retrieval) and the preference-question scores rested on a hardcoded answer table that has since been removed. Zaxy does not currently publish a LongMemEval score. A real, full-haystack LongMemEval run is planned; until it lands, treat the earlier
0.956/0.910/1.000figures as retracted. The Harvey LAB claim is pending the same audit.
Related MCP server: midas-memory-mcp
pipx install zaxy-memory
zaxy init
zaxy memory log --eventloom-path .eventloom --limit 5
zaxy memory bootstrap --eventloom-path .eventloom
zaxy doctor --eventloom-path .eventloomThe PyPI distribution is zaxy-memory; the import package and console command
are still zaxy. Bare zaxy init sets up the local embedded graph posture,
repo-local profile, deterministic capture config, genesis event, heartbeat, and
MCP guidance. For Codex, the printed activation launcher starts the managed
capture watcher when the local capture config is present; pass --capture start
only when you want init itself to start the watcher before opening Codex. The
default human output is compact and action-first; add --verbose when you need
the full setup diagnostics, optional checks, fallback commands, resume guidance,
and notes.
For automation, zaxy init --json keeps the raw onboarding fields and adds
setup.status, setup.issues, setup.pending, readiness.status,
readiness.reasons, readiness.actions, and structured
readiness.action_items for both commands and non-command review tasks. Each
structured action carries label, command, original source, and hints
for compact-output tips such as activation <task> replacement and path-stable
command guidance. Installers can render those tips without parsing prose. It also
includes setup.summary, readiness.summary,
readiness.required_action_count, and readiness.reason_count, so client UIs
can render compact status without parsing human output. It also
separates readiness.blocking_diagnostics from
readiness.non_blocking_diagnostics so scripts can distinguish setup
completion, required actions, and advisory doctor warnings before relying on
live memory.
For Codex, zaxy init --codex-mcp-install auto is the default. It writes or
reuses the user-level Codex MCP config when that can be done without replacing
an existing zaxy server entry. If no safe config target exists, it prints the
copyable codex mcp add command. If an existing zaxy entry differs, it asks
you to review that config before replacing it because Codex can silently replace
servers with the same name. Use an explicit mode when you need to force one side
of that decision after review:
zaxy init --codex-mcp-install user
# or: zaxy init --codex-mcp-install commandBoth Codex paths keep the server workspace-neutral. After init, start or
restart Codex through the printed zaxy activate codex ... --launch command so
the MCP server list and Zaxy activation packet are loaded together. The printed
command includes explicit --eventloom-path and --workspace-root values, so
it still targets the initialized repo when copied from another shell.
Run the single-agent memory example:
python examples/single_agent_memory.pyYour local data lives under .eventloom/ as one append-only JSONL file per
session.
For Claude Code instead of Codex:
zaxy init . --domain my-project --preset local-claude --infra checkFor Hermes Agent:
zaxy ide-config hermes --installFor repository development, use pip install -e ".[dev]", ./scripts/setup.sh,
and zaxy status. Start Docker sidecars only for integration tests or explicit
backend comparisons. Production setup writes Docker secret files under
./secrets/; see docs/deployment.md.
Agent (LangGraph / Any MCP Client)
|
v
MCP Server — memory_append / memory_query / memory_feedback / memory_replay / memory_invalidate
|
v
Eventloom (immutable JSONL log) → Hybrid Extraction → Embedded LadybugDB graph
| |
+—————— Optional Pathlight traces ———————————————→ Query Router
|
Hybrid Retrieval
(exact + BM25 + vector + traversal)Zaxy also includes an observe-only OpenAI-compatible packet analyzer for model
call provenance. It forwards packets to one configured upstream endpoint and
records llm.packet.completed events to Eventloom without acting as a router.
See LLM Packet Analyzer.
Public static site: site/index.html
Why Zaxy: docs/why-zaxy.md
Getting started: docs/getting-started.md
MCP quickstart: docs/mcp-quickstart.md
Architecture: docs/architecture.md
Configuration: docs/configuration.md
MCP interface: docs/mcp.md
Memory export contract: docs/export-contract.md
Eventloom contract: docs/eventloom.md
Graph schema: docs/graph-schema.md
Retrieval: docs/retrieval.md
Benchmarks: docs/benchmarks.md
LLM packet analyzer: docs/packet-analyzer.md
Embeddings: docs/embeddings.md
Security: docs/security.md
Operations and deployment: docs/operations.md, docs/deployment.md, docs/runbook.md
Python API: docs/api.md
Stability commitment: docs/stability-commitment.md
Migration guide: docs/migration.md
Archived benchmark iteration notes, release drafts, and research notes live
under docs/archive/, docs/announcements/, and docs/research/.
Contributing: CONTRIBUTING.md
Immutable audit trail: Eventloom append-only JSONL with SHA-256 hash chains.
Bi-temporal graph: Facts have validity windows (valid_from, valid_to).
Hybrid extraction: Rule-based for typed events (60–80% cost reduction), LLM fallback.
Hybrid retrieval: Exact + keyword + vector + graph traversal with configurable fusion weights.
Session sharding: One Eventloom log per agent/session, with a shared graph.
MCP-native: Drop-in memory for any MCP-compatible agent framework over stdio or SSE.
Observable: Optional Pathlight traces, breakpoints, and diff support via zaxy-memory[pathlight].
Hardened local defaults: bounded MCP inputs, safe session IDs, no-sidecar embedded graph projection, and optional admin token support for replay/invalidation.
File | Purpose |
| Eventloom JSONL I/O + hash chain integrity |
| Hybrid extraction engine + rule registry |
| Embedded LadybugDB projection store |
| Optional Neo4j bi-temporal wrapper via |
| Hybrid retrieval router |
| MCP stdio/SSE server |
| Optional Pathlight observability hooks |
| MemoryFabric orchestrator |
| Per-session Eventloom log manager |
| Shared validation and input bounds |
| CLI ( |
Zaxy supports Docker/Kubernetes-style secret files for sensitive settings:
Variable | Secret-file variant |
|
|
|
|
|
|
Direct environment variables take precedence over their *_FILE variants.
Use docker-compose.prod.yml as the production compose baseline.
Tests first (Karpathy rule). Every public function has a test.
Unit tests mock external services. Integration tests use Docker for optional sidecar backends.
Coverage gate: ≥92% enforced by CI.
Lint/format: ruff. Types: mypy.
# Run full suite with coverage gate
pytest
# Run integration tests (requires Docker)
./scripts/generate-certs.sh .certs
docker compose --profile integration up -d neo4j-test neo4j-tls
pytest -m integration --no-cov
# Lint and type-check
ruff check src tests
mypy src
# LongMemEval benchmark numbers are WITHDRAWN (see the note at the top of this
# README). The `--dataset .cache/.../longmemeval_oracle.json` path only exercises
# the answer step over pre-selected gold sessions (oracle mode) and does NOT
# measure retrieval on the full LongMemEval haystack; do not publish figures from
# it as a LongMemEval score. A real full-haystack harness is TBD.
# Harvey LAB external memory-ablation comparison
# Consumes externally generated Harvey normalized-result artifacts for Zaxy;
# does not reuse LongMemEval statistics as legal-agent benchmark evidence.
# Current full external Harvey LAB evidence:
# reports/benchmarks/harvey-lab-memory-ablation/publishable-statistics.md
# reports/benchmarks/harvey-lab-memory-ablation/harvey-lab-benchmark.json
# 10/10 tasks, mean criterion pass rate 0.788, +0.184 vs regular/no-memory,
# +0.081 vs article-best task rows, 9/10 wins vs article-best rows.
# Production deployment preflight
scripts/validate-deployment.sh --root .
# Build and validate Python release artifacts
scripts/build-dist.sh --root .
# Verify local release metadata, PyPI Trusted Publishing, and LangGraph smoke
zaxy doctor --release-smoke
# Validate public site and documentation links
scripts/validate-docs.sh --root .
# Clean-repo beta UAT: install into a throwaway workspace and verify init,
# bootstrap, deterministic capture, doctor, and memory checkout.
scripts/beta-uat.sh
# Summarize beta readiness gates without external services.
zaxy doctor --beta-readiness
# Go-live release gate
scripts/release-check.sh --root .The full suite must stay at or above 92% coverage before a sprint is complete.
The PyPI distribution name is zaxy-memory because zaxy is already occupied
on PyPI. Published releases build from GitHub Actions and upload to
https://pypi.org/project/zaxy-memory/ using PyPI Trusted Publishing with
GitHub OIDC. The import package and console command remain zaxy.
Before publishing, run zaxy doctor --release-smoke to verify the package
version, changelog entry, release workflow, tokenless publishing posture, and
dependency-light LangGraph example.
MIT
Assemble replay plus ranked retrieval into a prompt-ready context bundle. memory_checkout, the front door, wraps this assembly with current facts, citations, and a trust contract.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| max_tokens | No | Optional prompt token budget; sections are greedily packed and elisions are reported in the budget payload. | |
| session_id | No | ||
| replay_from_seq | No | ||
| max_recent_events | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions assembly of replay and retrieval but does not state whether the tool has side effects, requires authentication, or what happens on error. The mention of 'greedily packed' in the max_tokens schema description is not in the tool description.
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 two sentences, front-loading the core purpose. The second sentence provides useful context about the relationship with memory_checkout. It is concise without waste, but could be slightly more informative.
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 no output schema, six parameters (only one required), and no annotations, the description is insufficient. It does not explain the return value, the assembly process, parameter interactions, or how this tool differs from the sibling memory_checkout adequately.
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 only 17% (only max_tokens described). The tool description does not explain the parameters (query, session_id, replay_from_seq, limit, max_recent_events, max_tokens) beyond the vague mention of 'replay' and 'ranked retrieval.' It fails to compensate for low schema coverage.
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's action: 'Assemble replay plus ranked retrieval into a prompt-ready context bundle.' It distinguishes from siblings by mentioning 'memory_checkout, the front door, wraps this assembly,' implying this is a lower-level tool. However, it could be more explicit about the primary function.
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 that context_assemble is used internally or directly when the full wrapping of memory_checkout is not needed. No explicit guidance on when to use vs. alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append a typed event to the agent's persistent memory log. Appended state becomes retrievable through memory_checkout, the front door for reading memory back.
| Name | Required | Description | Default |
|---|---|---|---|
| actor | Yes | Actor that emitted the event | |
| thread | No | Logical thread / session ID (legacy, use session_id) | |
| payload | Yes | Structured payload | |
| event_type | Yes | Event type, e.g. 'goal.created' | |
| session_id | No | Session ID for multi-agent sharding |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some behavioral context by stating that appended state becomes retrievable, but does not cover idempotency, error handling, or side effects.
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?
Two sentences, no wasted words, efficiently communicates core functionality and a key linkage to a sibling tool.
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 no output schema and moderate complexity, the description covers the essential purpose and retrieval linkage, though it omits details about return value or payload structure guidance.
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 descriptions for each parameter; the tool description adds no additional parameter-level meaning beyond what the schema already provides.
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 appends a typed event to persistent memory, using specific verb and resource, and distinguishes it from the reading tool memory_checkout.
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 implicitly guides usage by noting that appended state is retrievable via memory_checkout, but lacks explicit when-not-to-use or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover Zaxy's memory surface: active capabilities, the ambient usage loop, the active tool profile, and which tools remain callable beyond the listed set. memory_checkout is the front door; call this at session start or whenever tool awareness is unclear.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | ||
| current_task | No | Current task or question to seed checkout guidance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'discovers' information, implying a read-only operation, but does not explicitly confirm no side effects or disclose permissions, rate limits, or any behavioral constraints. Some context is provided but incomplete.
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?
Two sentences with no waste: first lists what the tool does, second gives usage guidance. However, it uses jargon ('ambient usage loop') which slightly impacts clarity. Efficient overall.
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?
No output schema, so the description should describe return values. It mentions discovering capabilities, usage loop, etc., but does not specify the format or structure of the output. Also, parameter effects on output are not explained. Given the complexity (multiple memory siblings), the description provides a starting point but lacks completeness.
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 50%: current_task has a description in schema, session_id does not. The description adds no additional meaning for either parameter; it does not explain how to use session_id or how current_task affects behavior. The description fails to compensate for the gap in schema coverage.
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?
Description uses 'discover' as a specific verb and lists what is discovered (capabilities, usage loop, tool profile, callable tools). It provides a clear purpose and differentiates from siblings by referencing memory_checkout as the front door, though the relationship could be clearer.
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?
Explicitly advises calling 'at session start or whenever tool awareness is unclear,' providing clear context. Mentions memory_checkout as the front door, suggesting a distinction, but does not give explicit when-not-to-use or alternative tools beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The front door to Zaxy memory: call this first, before substantial work, to checkout current, cited, prompt-ready memory state for a session. Start here; every other memory tool is plumbing or power use, discoverable through memory_capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Memory ref to checkout, e.g. HEAD or refs/heads/main | |
| limit | No | ||
| query | Yes | ||
| purpose | No | Purpose profile name or object used to condition checkout guidance. | |
| max_tokens | No | Optional prompt token budget; sections are greedily packed and elisions are reported in diagnostics. | |
| session_id | No | ||
| replay_from_seq | No | ||
| max_recent_events | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description calls it 'checkout' but does not disclose if it locks state, has side effects, or requires specific authorization. Lacks behavioral context beyond being an entry point.
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?
Two efficient sentences, front-loaded with key purpose, 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 an 8-parameter tool with no output schema and no annotations, the description is too sparse. It lacks details on output format, parameter usage, and error conditions.
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?
Description does not mention any of the 8 parameters. With 38% schema coverage, it fails to compensate; parameters like session_id, ref, and purpose remain unexplained.
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?
Clearly states 'front door' and 'checkout current, cited, prompt-ready memory state'. Distinguishes from siblings by labeling them 'plumbing or power use'.
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?
Explicitly says 'call this first, before substantial work' and 'Start here', providing 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.
After using retrieved context, record whether a memory item was useful, stale, corrected, or reinforced. This closes the loop on context surfaced by memory_checkout, the front door.
| Name | Required | Description | Default |
|---|---|---|---|
| actor | No | Actor recording feedback | zaxy |
| query | No | Query that returned the context | |
| score | No | Original retrieval score | |
| reason | No | Short rationale for the feedback | |
| source | No | Retrieval source | mcp |
| outcome | No | Optional action outcome, e.g. supported_handoff or avoided_failed_path | |
| purpose | No | Optional purpose profile or preset that made this memory useful | |
| citation | No | Eventloom citation for the retrieved context | |
| feedback | Yes | Retrieval outcome to record | |
| importance | No | Optional 0..1 reinforcement importance for positive feedback | |
| session_id | No | Session ID for multi-agent sharding | |
| entity_name | Yes | Retrieved graph entity name | |
| entity_type | Yes | Retrieved graph entity type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details. It only states that feedback is recorded, but lacks information on updates, side effects, permissions, or the mismatch between described feedback types ('useful, stale, corrected, reinforced') and the actual enum ('used', 'helpful', 'irrelevant').
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?
Two sentences, concise and front-loaded. The first sentence states the action, the second provides context. No unnecessary details.
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 has 13 parameters and no output schema, the description is insufficient. It does not explain the impact of feedback on future retrievals, how to choose between enum values, or the overall workflow. More context is needed for a comprehensive understanding.
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 descriptions cover all 13 parameters, so baseline is 3. The tool description adds no additional semantics beyond the schema, such as explaining how parameters like 'purpose' or 'outcome' should be used in context.
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's purpose: recording feedback on a memory item after using retrieved context. It specifies the possible feedback types (useful, stale, corrected, reinforced) and explicitly ties to sibling memory_checkout, distinguishing it from other 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 indicates the tool should be used after memory_checkout, as it 'closes the loop' on that context. It does not explicitly state when not to use or list alternatives, but the context is clear enough for an agent to infer proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Experimental metamemory pre-check: predict whether memory_checkout would likely return something for a query, in roughly a millisecond, from in-memory session state only (no embedding call, no graph query). Returns a non-authoritative verdict (likely | possible | unlikely) with its signal breakdown and raw score. It is a cheap prediction about checkout, never a memory answer or evidence, and its calibration against real checkout outcomes is still being measured — when in doubt, call memory_checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| cues | No | Optional encoding-specificity cue fields (e.g. mission, workspace, tool, phase); cue values are probed against session memory alongside the query terms. | |
| query | Yes | The query you are considering sending to memory_checkout | |
| session_id | No | Session ID for scoped prediction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fully discloses behavioral traits: the tool is non-authoritative, cheap (no embedding call or graph query), returns a verdict with breakdown, and its calibration is still being measured. This provides rich transparency beyond what annotations might offer.
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-loading the key purpose and constraints. Every sentence adds value, with no redundancy or fluff. It is 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?
Although there is no output schema, the description adequately explains the return value (a verdict with signal breakdown and raw score). It covers all necessary aspects for an agent to decide when to use this tool, including its limitations and relation to memory_checkout.
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 baseline is 3. The description adds value by explaining cues as 'encoding-specificity cue fields' probed alongside query terms, which enriches understanding beyond the schema's 'Optional encoding-specificity cue fields' description. This justifies a slight increase.
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's purpose: an experimental metamemory pre-check to predict whether memory_checkout would return something for a query. It uses specific verbs ('predict') and resource ('memory_checkout result'), and distinguishes from sibling tools by emphasizing it is cheap, non-authoritative, and based only on in-memory session state.
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 provides clear usage context: use this tool for a quick, cheap prediction about memory_checkout. It explicitly advises 'when in doubt, call memory_checkout', giving a decision rule. However, it does not list specific scenarios where this tool should or should not be used compared to siblings, though the context is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a fact as invalid at a given time (bi-temporal update). History is preserved; the correction surfaces in later memory_checkout (front door) results.
| Name | Required | Description | Default |
|---|---|---|---|
| invalid_at | Yes | ISO-8601 timestamp | |
| admin_token | No | Admin token if configured | |
| entity_name | Yes | ||
| entity_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on full behavioral disclosure. It explains the bi-temporal update, history preservation, and that corrections surface in memory_checkout. This provides useful context about the tool's effect. However, it does not mention the need for an admin token or what happens if the entity doesn't exist.
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, containing only two sentences that are front-loaded with the core purpose. Every sentence adds value 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?
Given the tool's complexity (bi-temporal update with 4 parameters, no output schema), the description explains the core behavior and links to memory_checkout. However, it lacks details on error handling, prerequisites (e.g., entity must exist), and the optional admin_token parameter. It is adequate but has gaps.
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 50%, with only 'invalid_at' and 'admin_token' having descriptions. The tool description adds no extra meaning for the parameters 'entity_name' and 'entity_type', which lack schema descriptions. The description should have compensated for the missing parameter documentation but did not.
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's purpose: 'Mark a fact as invalid at a given time (bi-temporal update).' It identifies the verb 'Mark' and the resource 'fact', and mentions the bi-temporal nature. It references memory_checkout as a related tool where corrections appear, providing some differentiation, but does not explicitly distinguish from other siblings like memory_append or memory_query.
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 invalidating facts while preserving history, but does not explicitly state when to use this tool versus alternatives. Sibling tools include memory_append (add facts) and memory_query (search), but no guidance on when to choose memory_invalidate over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the temporal knowledge graph for relevant context. Power use behind the memory_checkout front door: reach for it when you need targeted hits, temporal filters, or pagination rather than a prompt-ready packet.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results | |
| paged | No | Return contexts with pagination metadata | |
| query | Yes | Natural language query | |
| cursor | No | Opaque cursor from a prior paged memory_query call | |
| session_id | No | Session ID for scoped retrieval | |
| session_ids | No | Local-only explicit cross-session query scope | |
| temporal_filter | No | ISO-8601 point-in-time filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose whether the tool is read-only, requires authentication, or has any side effects. While the name 'query' suggests read-only, the description fails to explicitly state this or any other behavioral traits.
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 extremely concise: one sentence stating the core action, followed by a usage guideline sentence. No wasted words, and the main purpose 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?
Despite 7 parameters and no output schema, the description explains the tool's role and usage context adequately. However, it lacks behavioral transparency and does not describe return values or pagination behavior in detail, limiting completeness.
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 baseline is 3. The description adds overall context (e.g., 'targeted hits, temporal filters, pagination') but does not add specific parameter details beyond what the schema already provides.
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 'Query the temporal knowledge graph for relevant context,' specifying the verb and resource. It distinguishes itself from siblings like memory_checkout by noting it is for targeted hits, temporal filters, or pagination rather than a prompt-ready packet.
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 'reach for it when you need targeted hits, temporal filters, or pagination rather than a prompt-ready packet,' providing clear when-to-use guidance and contrasting with an alternative tool (memory_checkout).
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. Dates show when Glama detected each change.
context_assemblememory_appendmemory_capabilitiesmemory_checkoutmemory_feedbackmemory_feeling_of_knowingmemory_invalidatememory_queryMost tools have distinct purposes, but context_assemble and memory_checkout overlap in functionality since checkout wraps assembly. memory_feeling_of_knowing is clearly experimental and distinct. Descriptions guide usage, preventing major confusion.
Naming is inconsistent: most tools start with 'memory_', but context_assemble does not. Verbs and nouns are mixed (e.g., memory_append vs memory_capabilities), and context_assemble uses noun_verb order instead of verb_noun.
8 tools is appropriate for a memory management system. Each tool covers a core operation (append, invalidate, query, feedback, capabilities, prediction, assembly), without being excessive or sparse.
The tool set covers the memory lifecycle: add (append), retrieve (checkout/query), update (invalidate), feedback, and discovery (capabilities). Missing a dedicated delete tool, but invalidate handles temporal updates. Minor gaps, but core workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Persistent memory for AI agents. EU-hosted, privacy-first, hybrid recall, contradiction detection.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/syndicalt/zaxy'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
