git clone https://github.com/anthroos/openexp.git
cd openexp
./setup.shThat installs the four hooks into Claude Code, brings up Qdrant in Docker, and registers the MCP server.
Prerequisites: Python 3.11+, Docker, jq.
No API key required for core functionality. Embeddings run locally via FastEmbed. An Anthropic API key is optional and only powers the two-prompt pipeline (anonymize + extract experience) when you publish.
To install the seed pack (a real 57-day B2B sales arc, anonymized) and try retrieval against a worked example, see exp-inbound-acquisition-with-free-pilot — install instructions in its README.
Related MCP server: Longhand
When you close a deal, ship a feature, or lose a client — how did it happen? Which decisions, in what order, against which context, on which hypotheses? Today's AI agents can't answer that. They follow skills and instructions perfectly, but they don't accumulate grounded knowledge about how outcomes actually arrived.
OpenExp captures every human-AI decision as a step in a trajectory, links those steps into coherent journeys, and grades each journey retroactively when reality returns its verdict — a deal closes, a sprint ships, a payment lands. The result is a continuously growing labeled dataset of decisions tied to outcomes, ready to train domain-specific intuition.
A few terms repeat throughout. Settling them up front:
Trajectory — an ordered timeline of decisions a human and AI made together over the life of one closed arc (a deal, a feature, an incident). The unit of data.
Pack — a published, anonymized trajectory plus its meta.yaml. The unit of distribution. Lives in its own GitHub repo.
Skill — how Claude Code installs and invokes a pack. Naming convention: openexp:<author>:<slug>.
openexp-use — the universal applier skill that, given an installed pack, reads its trajectory and answers your situation with a cited day.
Not a Q-learning memory system. We tried Q-values for 8 months. Mean Q-value across 27,000 memories was 0.006; 90% of memories never received any reward signal. Removed on 2026-04-26.
Not Mem0 / Zep / Letta. Those are storage layers. Storage is the easy part — semantic search alone doesn't tell you which memory actually led to a result.
Not a replacement for skills or CLAUDE.md. Those say how to do something. OpenExp captures what happened and how it ended.
We do not hand-craft features at step level (tone: urgent, signal: positive, hypothesis: probable). Pre-labeling injects the labeler's biases and corrupts the eventual training signal. Same hygiene as credit scoring: collect rich features per applicant, label only the terminal outcome (paid / didn't), let the model learn what predicts repayment from data alone.
Only terminal outcomes get labels:
outcome — closed_won / closed_lost / failed / abandoned
grade — 0.0 to 1.0, school-style
Steps are stored raw. Authors annotate their own intent, hypotheses, and decisions ("I believed X at this point", "I chose Y because Z"). They do not label the signal quality of individual events — that's what the eventual model learns.
Casual analogy: kids in school don't get annotations on every homework problem. They turn in work, get a grade at the end of the term, and develop intuition over hundreds of grades.
Four hooks run automatically inside Claude Code:
Hook | When | What |
| Session opens | Searches Qdrant for relevant memories, injects top results as context |
| Every message | Lightweight per-prompt recall |
| After Write / Edit / Bash | Captures observations as JSONL |
| Session closes | Ingests transcript into Qdrant; extracts decisions via Opus 4.x (async) |
Retrieval ranks via semantic similarity + BM25 + recency. No magic numbers. No Q-value scoring component.
When you decide to publish an experience — turn a real, terminal trajectory into a shareable artifact — two prompts do the work:
prompts/anonymize.md — takes raw trajectory data (transcripts, emails, decisions) and produces an anonymized YAML trajectory. PII is replaced by category tokens (<counterparty_cto>, <regulated_industry>, <value:10k-100k>, <local_currency>, day_+5) while structural features are preserved. The prompt enforces a reverse-identification rule: tokens narrow enough to identify a counterparty in jurisdiction must be generalized one level up before publication.
prompts/extract_experience.md — reads the anonymized trajectory plus the terminal outcome label and produces a facts-only meta.yaml (id, outcome label, duration, step count, category tokens, license). It deliberately refuses to write applies_when, searchable_summary, or a grade reason — those are interpretations and belong to the reader's Claude at use time, not to the publisher at publish time.
You run both prompts inside your own Claude Code, against your own Qdrant. Nothing is sent to a central server.
A published experience is its own GitHub repo (one repo per pack), containing four files:
exp-<slug>/
├── meta.yaml # facts only: id, outcome label, duration, category tokens, license
├── trajectory.anonymized.yaml # raw ordered timeline of N steps, anonymized
├── README.md # human-readable face for the catalog
└── SKILL.md # Claude entry point — read first when skill is invokedEach pack has its own repo so authors own their content (issues, license, versioning), and the engine repo stays focused on the runtime. See docs/publishing-a-pack.md for the author guide.
meta.yaml shape (abridged from the seed pack exp-inbound-acquisition-with-free-pilot):
pack:
id: d49e0997-8455-4d3c-90ca-d6cf54d0f662
author: ivan-pasichnyk
license: MIT
schema_version: 3
outcome:
label: closed_won # fact, not interpretation
closed_at: day_+57
duration_days: 57
step_count: 26
category_tokens: # what appears in the trajectory
- <counterparty_cto>
- <counterparty_pm>
- <regulated_industry>
- <e_signing_platform_local>
# ...No applies_when, no searchable_summary, no grade_reason. Earlier schemas (v2) baked the publisher's read of the timeline into the artifact — one Claude's interpretation, frozen. Schema v3 inverts that: the pack ships raw, and the reader's Claude derives match on the fly against the reader's actual situation. Different readers, different contexts, different inferences from the same trajectory. See CHANGELOG.md for the full v2 → v3 transition rationale.
A published experience is a namespaced Claude Code skill:
openexp:<author-handle>:<experience-slug>Drop the pack into ~/.claude/skills/openexp:<author>:<slug>/ (rename the directory to the skill-namespaced form on copy). Claude Code auto-discovers it on the next session.
# Install the seed pack as a skill
git clone https://github.com/anthroos/exp-inbound-acquisition-with-free-pilot.git
ln -s "$PWD/exp-inbound-acquisition-with-free-pilot" \
~/.claude/skills/openexp:ivan-pasichnyk:inbound-acquisition-with-free-pilotTwo layers of identity:
Author identity is public — it signs the pack, like authorship on a research paper.
Counterparty identity stays anonymized — the skill name reveals who created the pack, never who they were dealing with.
SKILL.md inside the pack is the entry point — it tells the user's Claude when to invoke, how to use the trajectory, and what not to do (no fabrication, no de-anonymization, attribution required).
See docs/skill-architecture.md for the full naming convention, install flow, and design rationale.
This engine repo is the runtime — it does not bundle packs. Each published pack lives in its own repo (see the seed pack as the reference shape). A web catalog at openexp.ai aggregates published packs; an automated registry index is on the roadmap. A directory of installable experiences is the eventual surface, not a built product today.
Five focused tools (hippocampus model — write everything, retrieve selectively):
Tool | Description |
| Hybrid search: semantic similarity + BM25 + recency |
| Store a memory. Supports |
| Log a pack-grounded prediction. Required when an installed experience pack cites a specific |
| Resolve a prediction with the observed signal — interpretation-free record. |
| Collection stats: point counts by source/type, session count |
Pack-grounded predictions are how the system learns whether a published experience pack actually moves real-world outcomes. Without prediction/outcome pairs, pack value cannot be measured against any baseline, and any future experiment (cross-pack voting, embedding retrieval, new packs from new authors) is unfalsifiable.
Trigger criterion is sharp. Logging fires only when the assistant cites a pack's specific relative_day as the reason for an action recommendation. No day-citation → no log. Description of a situation without a recommendation → no log. This keeps the dataset honest and the cost low.
log_prediction (new path, schema_version 2)
Field | Required | Purpose |
| yes | The pack's slug |
| yes | Author handle |
| yes | The exact |
| yes | External reference (CRM lead_id, ticket ID, deal ID — opaque string) |
| yes | What was recommended TO do |
| yes | Observable resolution |
| yes | Deadline in days for |
| optional | Negative-space prediction — what was recommended NOT to do (often the higher-value half) |
| optional | Free-text context |
log_outcome (new path, schema_version 2)
Field | Required | Purpose |
| yes | ID returned from |
| yes | What was observed — raw fact, no interpretation |
| yes | How many days from prediction to resolution |
| optional | Free-text, e.g. unexpected events |
What's deliberately NOT in the schema: confidence (Claude-side confidence is uncalibrated until ≥30 outcome datapoints), alternative_action_if_no_pack and predicted_outcome_alternative (the same Claude that writes the prediction would invent the counterfactual, biased toward "the pack helped" — real ablation needs a pack-blind run, separate track).
Backward compatibility. The legacy schema (prediction, confidence, strategic_value, memory_ids_used) is still accepted by both tools. Calling log_outcome with outcome + reward continues to update Q-values for memory_ids_used exactly as before. New-path entries are marked schema_version: 2 in the JSONL row.
openexp search -q "stalled enterprise procurement" -n 5
openexp ingest # ingest pending transcripts into Qdrant
openexp stats # Q-cache + collection statsEnvironment variables (.env):
Variable | Default | Description |
|
| Qdrant server host |
|
| Qdrant server port |
|
| Qdrant collection name |
|
| Predictions, retrieval logs |
|
| Hook output |
|
| Session summaries |
|
| Embedding model (local, free) |
| (optional) | Required only for the publishing pipeline |
Pilot. Architecture freeze landed 2026-04-26. First experience seed published as a standalone repo: exp-inbound-acquisition-with-free-pilot — a 57-day inbound acquisition that closed at grade 1.0 (author's own assessment), anonymized to category tokens.
Honest about what isn't done:
The marketplace UI is just a directory in this repo. No web surface yet.
Anonymization is conservative but not bulletproof for readers with deep domain knowledge.
Schema may iterate — author-annotation fields (author_intent, author_hypothesis, author_decision) are a likely near-term addition.
The eventual ML model trained on this corpus does not exist yet. ≥30 graded trajectories first.
See docs/redesign-2026-04-26.md for the full architecture freeze and docs/claude-design-brief.md for the v2 product framing.
This project is in early stages. See CONTRIBUTING.md for setup and workflow.
The most useful contribution right now is publishing a real experience. Take one of your own closed trajectories, run it through prompts/anonymize.md and prompts/extract_experience.md, and open a PR adding a new directory under experiences/.
MIT © Ivan Pasichnyk
Store a new memory with FastEmbed embedding and Q-value tracking
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | fact | |
| agent | No | main | |
| content | Yes | ||
| client_id | No | Associated client/entity ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the behavioral burden. It does mention that the tool computes a FastEmbed embedding and tracks Q-values, which is extra implementation behavior. However, it does not explicitly state that the operation creates permanent state (mutation), or whether it is destructive/idempotent, or what happens to existing memories.
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 a single, front-loaded sentence with no filler. The verb and core function are stated immediately, and every word adds something useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema, while the description explains only a generic store action. The meaningful distinction between type/agent/client_id is not given, and no information about the result of the operation is provided. Given the overall simplicity, this is adequate but contains clear 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 low (25% - only client_id gets a description). The tool description does not explain the type, agent, or content parameters, nor does it clarify allowed values or relationships. Since schema coverage is low, the description must compensate, and it does 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 uses a specific verb-resource pair ('Store a new memory') and adds implementation detail (FastEmbed embedding, Q-value tracking). It is clear what the tool does, and it is easily distinguishable from sibling tools like search_memory (retrieval) and log_prediction/log_outcome (logging different events).
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 the tool should be used to add memories, but it does not explicitly say when to choose it over siblings or when not to use it. No mention of alternatives or exclusions is present, so the guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a prediction with observed facts. New path: provide actual_signal and days_to_resolve — interpretation-free record of what happened. Legacy path: provide outcome + reward to keep updating Q-values for memory_ids_used from older predictions. The two paths can coexist.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Optional free-text context (e.g. unexpected events) | |
| reward | No | [deprecated — only used on the legacy Q-update path. Omit on the new path.] | |
| outcome | No | [deprecated alias for actual_signal — accepted for backward compat] | |
| actual_signal | No | What was observed — raw fact, no interpretation. Required on the new path. | |
| prediction_id | Yes | ID from log_prediction | |
| cause_category | No | [deprecated, accepted for backward compat] | |
| days_to_resolve | No | How many days from prediction to resolution. Required on the new path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals a core behavior: the new path records an 'interpretation-free' fact, while the legacy path updates Q-values. It also hints at state mutability ('resolve a prediction' and 'updating Q-values'). However, it does not mention side effects like whether the prediction is marked resolved, idempotency, or error handling. Still, it covers the most critical behavioral distinction (new vs legacy) clearly.
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 (with a dash for emphasis) and front-loads the primary purpose. Every clause earns its place: the purpose, the two-path distinction, the key parameters per path, and the coexistence note. There is zero fluff; it is both concise and information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, one required, and no output schema, the description provides enough context for an agent to know how to call it: it explains both paths and the necessary parameters. It does not describe the return value or side effects beyond Q-updates, but that information is not strictly required for correct invocation. The coverage is strong for the dominant usage cases, so a 4 rather than a 5 is appropriate.
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 each parameter is already described. The description adds critical usage semantics by mapping parameters to paths: it tells the agent that actual_signal and days_to_resolve are the new-path requirements, while outcome and reward belong to the legacy path. This goes beyond the schema, which only marks parameters as deprecated, and clarifies when to use what, so the added value justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-resource pair: 'Resolve a prediction with observed facts.' It explicitly identifies the tool's function and differentiates itself from the sibling log_prediction (which creates predictions) by focusing on resolution. It also distinguishes two execution paths (new vs legacy), making its scope unambiguous without needing to inspect the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance for each code path: 'New path: provide actual_signal and days_to_resolve' and 'Legacy path: provide outcome + reward to keep updating Q-values.' It also notes that the two paths can coexist, preventing confusion about exclusivity. This directly tells an agent which parameters to use in which situation, exceeding minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log a pack-grounded prediction. REQUIRED whenever the assistant cites a specific relative_day of an installed experience pack as the basis for a real-world action recommendation. Captures: which step was cited, which case it applies to, what was recommended (and what was explicitly NOT recommended), the observable signal that resolves the prediction, and the window in days. Returns prediction_id for later log_outcome.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Optional free-text context | |
| case_id | No | External reference for this case (CRM lead_id, ticket ID, etc.) — opaque string | |
| pack_id | No | The pack's slug (e.g. 'inbound-acquisition-with-free-pilot') | |
| client_id | No | [deprecated alias for case_id, accepted for backward compat] | |
| cited_step | No | The exact relative_day cited (e.g. 'day +57') | |
| confidence | No | [deprecated, removed from required schema 2026-04-27 — Claude confidence is uncalibrated until ≥30 outcome datapoints. Accepted for backward compat.] | |
| prediction | No | [deprecated] Free-text prediction. Use applied_action + expected_signal instead. Accepted for backward compat. | |
| pack_author | No | The pack's author handle (e.g. 'ivan-pasichnyk') | |
| applied_action | No | What the assistant recommended TO do, derived from the cited step | |
| expected_signal | No | Observable signal that resolves this prediction (e.g. 'counterparty signs both sides') | |
| memory_ids_used | No | Memory IDs that were retrieved for this prediction (for legacy Q-value updates on log_outcome) | |
| strategic_value | No | [deprecated, accepted for backward compat] | |
| prevented_action | No | What the assistant recommended NOT to do (negative-space prediction). Optional but encouraged — often the higher-value half. | |
| expected_window_days | No | Deadline in days for log_outcome to be called |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool logs a prediction and returns prediction_id for later use, which is relevant behavioral context. However, it does not address side effects beyond logging, persistence, idempotency, or access expectations; these are minor for a logging tool but still unstated.
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 front-loaded with the mandatory usage condition, uses a compact list to communicate the captured dimensions, and closes with the return value's downstream purpose. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter tool with no output schema and no annotations, the description covers the core semantics: when to call it, what to include, and what comes back. It omits explicit mention of optional/deprecated parameters, but those are fully documented in the input schema, so the practical coverage is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even without extra prose. The description adds a useful conceptual grouping (cited step, case, recommended/not-recommended action, resolving signal, window), but it does not add per-parameter meaning beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource, 'Log a pack-grounded prediction', and immediately defines the exact trigger condition. It also distinguishes the tool from its sibling log_outcome by noting this tool returns a prediction_id used for a later outcome call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit, hard requirement: use this tool whenever the assistant cites a specific relative_day of an installed experience pack as the basis for a real-world recommendation. It does not explicitly discuss when not to use it or name alternative actions, but the trigger condition is concrete and the relationship to log_outcome is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get memory system health: point counts by source/role, pending predictions, date range, Q-cache size
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The verb 'Get' and the term 'health' strongly imply a read-only operation, but the description does not explicitly state 'no side effects', auth needs, or output size. It does add value by listing what stats are returned.
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?
A single sentence that front-loads the action and immediately defines the return scope. Every phrase adds useful information: source/role, pending predictions, date range, and Q-cache size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless health-check tool with no output schema, the description provides enough context about what is returned. It could be more explicit about the output shape or any naming conventions of the metrics, but the listed categories give an agent a solid starting point.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add parameter-level semantics. Per the rubric, 0 params earns a baseline of 4; no further parameter information is necessary.
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?
States a specific verb ('Get') and resource ('memory system health') and enumerates the returned categories: point counts by source/role, pending predictions, date range, Q-cache size. This clearly differentiates it from sibling tools like search_memory and add_memory.
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 a monitoring/health-check use case and the sibling names suggest alternatives, but it never explicitly states when to use it instead of search_memory, add_memory, log_prediction, or log_outcome. Agents must infer the distinction from the term 'health'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search memories with FastEmbed + Qdrant, hybrid BM25 scoring, lifecycle filtering, and Q-value reranking
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Filter by role: user or assistant | |
| type | No | Filter by memory type | |
| agent | No | Filter by agent name | |
| limit | No | ||
| query | Yes | Search query | |
| source | No | Filter by source: transcript, decision, etc. | |
| date_to | No | End date (ISO format, e.g. 2026-04-08) | |
| client_id | No | Filter by client ID | |
| date_from | No | Start date (ISO format, e.g. 2026-04-01) | |
| session_id | No | Filter by session ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does disclose ranking and filtering behaviors ('hybrid BM25 scoring', 'Q-value reranking', 'lifecycle filtering') but omits basic read-only/safety disclosure and response format. 'Search' implies non-mutating, but with 10 parameters and no output schema, more behavioral context is needed.
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 a single dense sentence that packs technical terms (FastEmbed, Qdrant, BM25, Q-value) without hierarchy or explanation. It is concise but not well-structured for an agent to parse, and the jargon-heavy phrasing may obscure the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and no annotations, the description leaves ambiguity about result shape, how 'lifecycle filtering' works, and what 'Q-value reranking' means for returned results. The tool's complexity demands more context than this one-liner provides.
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 90%, so the schema already documents the parameters. The description adds only 'lifecycle filtering', which is too vague to map to date_from/date_to or other filters, providing negligible extra semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search memories', a specific verb and resource, and it is the only search tool among siblings (add_memory, log_prediction, log_outcome, memory_stats), so its role is clear. However, the rest of the description is technical jargon that doesn't add functional scope or explicitly distinguish it from the 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?
No mention of when to use this tool versus memory_stats or add_memory, and no exclusions or conditions are stated. The intended use is implied by the verb 'Search' and sibling names, but the description offers no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_memorylog_outcomelog_predictionmemory_statssearch_memoryScored across 5 tools
Each tool targets a distinct operation: memory insertion, memory retrieval, prediction logging, prediction resolution, and system stats. The prediction lifecycle tools are clearly complementary rather than overlapping.
Most tools follow a clean verb_noun pattern: search_memory, add_memory, log_prediction, log_outcome. memory_stats deviates slightly by leading with a noun, but the naming style is otherwise predictable and readable.
Five tools is well-scoped for the server's apparent purpose: memory management plus prediction logging. Each tool covers a necessary core function without redundancy.
The core workflows are covered: memories can be added and queried, predictions can be logged and resolved, and system health is observable. Minor gaps exist such as no direct memory update/delete or list-predictions endpoint, but agents can work around these.
Persistent, outcome-grounded episodic memory for Claude. 14ms CPU retrieval, no GPU, no vector DB.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
