This MCP server lets agents query, index, and maintain a project's durable learning-loop context (lessons, decisions, failures, solutions, ADRs, runbooks) through MCP, with read-only checks where required and CLI-equivalent operations.
Search lessons with hybrid FTS5 + semantic search, returning citable project/file:line results and sources.
Get learning context for a task: legacy lesson list or v2 ADD continuity package with warnings, sources, and optional read-only Kanban state.
Capture task outcomes as validated drafts without promoting them into canonical lessons or solutions.
Run amnesia checks and amnesia evaluations to verify continuity evidence and combine structural facts with an explicit Amnesia Test report.
Run project preflight to check the read-only project start contract (workspace, board, card, files) before implementation.
Show project status with metrics and validation findings.
Index projects into the local SQLite index and reindex solutions from versioned YAML.
Register and trace solutions via an append-only ledger with state gates, plus list solution events by revision/status/id.
Serve learning-loop resources (learning-loop://format/..., learning-loop://templates/...) for clients.
Provides project continuity and queryable memory for Hermes agents, allowing them to retrieve indexed lessons, decisions, and task context, capture outcome drafts, and validate project state before starting work.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@learning-loop-mcp search lessons learned about handling flaky tests"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
learning-loop-mcp is a continuity layer for projects developed with Hermes or
other AI agents. It documents and makes the project's journey queryable—not
only its final lessons—so an agent can recover important context between
sessions through MCP or the CLI instead of starting every conversation from
scratch.
If you use Hermes Desktop or the Hermes MCP screen, choose Add custom MCP and enter:
Name: learning-loop-mcp
Transport: stdio
Command: uvx
Arguments: --from learning-loop-mcp==0.5.2 learning-loop-mcp-server
Environment:
LEARNING_LOOP_PROJECTS_ROOT=/home/your-user/Proyectos
LEARNING_LOOP_MCP_DB=/home/your-user/.local/share/learning-loop-mcp/index.db
Use the actual path where your project repositories live. The index path is optional.
From a terminal, the equivalent command is:
hermes mcp add learning-loop-mcp \
--command uvx \
--env LEARNING_LOOP_PROJECTS_ROOT=/home/your-user/Proyectos \
--env LEARNING_LOOP_MCP_DB=/home/your-user/.local/share/learning-loop-mcp/index.db \
--args --from learning-loop-mcp==0.5.2 learning-loop-mcp-server
hermes mcp test learning-loop-mcpPreflight: before changing files or installing dependencies, run the read-only project gate:
learning-loop-mcp project-preflight PROJECT \
--kanban-board BOARD --task-id TASK_ID --jsonThe equivalent MCP tool is project_preflight. It requires an explicit board,
an existing workspace with README.md, AGENTS.md, docs/lessons.md,
docs/metrics/errors.yaml, and docs/metrics/solutions.yaml, a Hermes project
linked to that board and workspace, and an initial card containing Purpose,
Expected result, Acceptance criteria, and Planned tests.
A result with ready: false is a blocking stop signal. The tool is read-only:
it never creates or changes a board, project, card, file, dependency, or
private Hermes database. Use the official Hermes CLI to repair the reported
condition, read the board and card back, then run preflight again. Set
--hermes-bin or HERMES_BIN when the MCP process cannot resolve hermes on
its own.
uvx downloads the pinned release from PyPI and starts the server. For Hermes,
use learning-loop-mcp-server. The command learning-loop-mcp is the
separate CLI for indexing, searching, validation, backups, recovery, and
preflight.
The full workflow E2E runs inside a disposable Ubuntu container. The Fedora host only needs rootless Podman and a built wheel:
uv build --wheel
podman run --rm --network host \
-v "$PWD:/mnt/repo:Z" \
-v "$PWD/dist:/mnt/dist:Z" \
ubuntu:24.04 \
bash /mnt/repo/scripts/e2e-hermes-learning-loop.shThe script installs Python and the build tools inside the container before it
locates the wheel. DIST_DIR, PROJECTS_ROOT, and DB can be overridden for
local runners. The script creates an isolated Hermes home, board, project, and
MCP registration; it does not use the host Hermes state.
After the server is connected, initialize each project once from a checkout:
./scripts/init-project.sh /path/to/your-project
learning-loop-mcp index /path/to/your-projectRelated MCP server: LumenCore
A conversation may contain important decisions, but a conversation is not a durable memory source. When a session ends or the agent changes, the project can lose:
its original purpose;
decisions and the reasons behind them;
constraints that must not be broken;
investigated failures and their checks;
task state and the concrete next action.
The result is repeated work, contradictory decisions, and agents that appear to continue successfully but actually depend on someone retelling the history.
The project keeps this context in versioned files inside the repository being
developed. learning-loop-mcp validates, indexes, and exposes those files for
queries:
At the start of a task, the agent queries relevant project context and applicable lessons.
While working, it can capture a task outcome as a validated draft without automatically turning it into canonical knowledge.
When closing the task, a person or authorized agent explicitly decides what should be promoted to a lesson, solution, ADR, or runbook.
In another session, the next agent queries that context through MCP or the CLI and continues with evidence, constraints, and the next action.
The source of truth is versioned Markdown/YAML. Together, those files form a queryable project log: they record not only what was decided, but also why, what was tried, what failed, which check confirmed it, and what remains to be done. SQLite is only a rebuildable local index for fast queries; it is not the primary memory or a second source of truth.
The practical consequence is important: for a question such as “why is it designed this way?” or “what have we already tried?”, the agent can recover an answer with citations and state. If the evidence is missing or insufficient, the system reports that it is unknown instead of filling the gap with a guess.
Project repository
├── docs/lessons.md purpose and lessons
├── docs/metrics/errors.yaml error classes and checks
├── docs/metrics/solutions.yaml verified solutions
├── docs/adr/ decisions and rationale
└── docs/runbooks/ operational procedures
│
│ parser + validator + derived index
▼
Local SQLite (FTS5 + sqlite-vec)
│
├── learning-loop-mcp-server ← MCP stdio for Hermes/agents
└── learning-loop-mcp ← CLI for people and scriptsBecause current code rarely explains its entire history.
Three months later, someone may return to the project and ask:
Why was this architecture chosen?
Which alternative was rejected?
What constraint existed at the time?
Is this strange behavior intentional or is it a bug?
What was tried before, and why did it not work?
Without durable memory, they have to search old conversations, inspect commits without context, or ask the person who made the decision. Sometimes that person is no longer available.
With learning-loop-mcp, those answers can remain documented together with the
decision, its circumstances, the tests, and the sources. They can be queried by
question without manually reading the entire repository:
Why does this service use a queue instead of calling the API directly?The answer can include the decision, the rejected alternative, the failure that motivated it, and the evidence that confirmed it. If there is not enough information, the system says so instead of inventing an explanation.
That is the reason to install it: to turn the project's technical history into recoverable context for the people and agents who will maintain it later.
The loop is not just a document search tool. It is a way to make work accumulate instead of disappearing when a session ends.
Reconstruct decisions months later, including their circumstances and rejected alternatives.
Distinguish intentional odd behavior from a pending bug.
Find what was tried and what failed without repeating experiments.
Understand the real work state: done, blocked, verified, or pending.
Onboard another person without transferring the entire history orally.
Start with relevant context instead of an anonymous repository.
Receive previous constraints and decisions before proposing changes.
Query concrete sources instead of blindly summarizing documents.
Know which next action was expected.
Report that something is unknown when there is not enough evidence.
Decisions survive sessions, agents, and people.
Failures become reusable checks.
Verified solutions stay separate from drafts and assumptions.
Documentation becomes a log of how the system evolved rather than a static snapshot.
Knowledge remains versioned, reviewable, and recoverable alongside the code.
The cycle is simple:
query → work → capture what happened → verify → decide what to promote
↑ │
└──────────── next session / next agent ─────────────────┘Imagine a project that develops an online store.
During one session, the team discovers that payments must be confirmed through a webhook, not through Stripe's immediate response. They document the decision, the reason, and the test that confirmed it. They also record that the webhook still lacks retries and that this is the next task.
In another session, the agent receives a short request:
Add retries for the payment webhook.Without context, it would have to guess how payment confirmation works and might
use Stripe's immediate response again. With learning-loop-mcp, it queries the
project journey and finds:
Decision: confirm payments through a webhook.
Reason: the immediate response does not guarantee that payment completes.
Check: asynchronous confirmation tests.
Pending: add webhook retries.
Source: docs/adr/0003-payment-webhook.md, docs/lessons.md:42-55.The agent now knows not only what code to write, but why the system is designed that way, what must not be broken, and which task is pending. If the answer is not documented, the system must say so instead of inventing it.
It is for teams and individuals who:
work in repositories over many sessions;
use Hermes, MCP, or other programming agents;
need decisions and constraints to survive session changes;
want Git-auditable memory rather than an opaque conversation;
prefer retrieving relevant context instead of loading complete documents into every prompt.
It is not a task manager, a remote database of conversations, or a system that decides by itself which knowledge is correct. Hermes Kanban state can be queried read-only through the official Hermes CLI, but the board remains Hermes' responsibility.
The current published version is 0.5.2 and requires Python >=3.13.
Hermes can install and run it from PyPI without a checkout or a manually managed
virtual environment.
In Hermes, open the MCP screen and choose Add custom MCP. Enter:
Name: learning-loop-mcp
Transport: stdio
Command: uvx
Arguments:
--from learning-loop-mcp==0.5.2 learning-loop-mcp-serverEnvironment variables:
LEARNING_LOOP_PROJECTS_ROOT=/home/your-user/Proyectos
LEARNING_LOOP_MCP_DB=/home/your-user/.local/share/learning-loop-mcp/index.dbUse the actual path to the directory that contains your project repositories. The index path is optional; the default XDG data path is also valid.
uvx downloads the pinned package from PyPI and launches the MCP server. You
do not need to clone this repository, create a virtual environment, find the
server executable, or edit Hermes' config.yaml.
The equivalent Hermes configuration is:
mcp_servers:
learning-loop-mcp:
command: uvx
args:
- --from
- learning-loop-mcp==0.5.2
- learning-loop-mcp-server
env:
LEARNING_LOOP_PROJECTS_ROOT: /home/your-user/Proyectos
LEARNING_LOOP_MCP_DB: /home/your-user/.local/share/learning-loop-mcp/index.dbThe equivalent CLI command is:
hermes mcp add learning-loop-mcp \
--command uvx \
--env LEARNING_LOOP_PROJECTS_ROOT=/home/your-user/Proyectos \
--env LEARNING_LOOP_MCP_DB=/home/your-user/.local/share/learning-loop-mcp/index.db \
--args --from learning-loop-mcp==0.5.2 learning-loop-mcp-server
hermes mcp test learning-loop-mcpRestart Hermes, or use its MCP reload action if available, so the tools and
learning-loop:// resources are discovered.
For a manually managed Hermes host:
uv tool install learning-loop-mcp==0.5.2
hermes mcp add learning-loop-mcp \
--command "$HOME/.local/bin/learning-loop-mcp-server" \
--env LEARNING_LOOP_MCP_DB="$HOME/.local/share/learning-loop-mcp/index.db" \
--env LEARNING_LOOP_PROJECTS_ROOT="$HOME/Proyectos"
hermes mcp test learning-loop-mcpIf uv tool install prints a different executable path, use that path in
--command. Restart Hermes after registering the server.
The initialization scripts are available from a repository checkout. Clone the repository and run:
git clone https://github.com/tiempor3al/learning-loop-mcp.git
cd learning-loop-mcp
./scripts/init-project.sh /path/to/your-projectThe script creates canonical templates under docs/ and adds the ritual
reference to AGENTS.md. It does not overwrite existing files and is safe to
run more than once.
learning-loop-mcp index /path/to/your-project
learning-loop-mcp learning-context \
/path/to/your-project \
"continue the pending task while respecting project decisions"In Hermes, the agent can use the learning_context MCP tool to receive relevant
context. The response can include read-only Kanban state when
LEARNING_LOOP_KANBAN_BOARD is configured.
Durable memory versus conversation: context is kept in project files and Git; prompts and complete conversations are not stored. The documentation preserves the journey: decisions, attempts, failures, tests, constraints, and next steps.
Source of truth versus index: versioned Markdown/YAML is primary; SQLite
can be deleted and rebuilt with index.
Capture versus promotion: capture-outcome writes a draft to the explicit
path and returns promoted: false; it does not automatically edit canonical
lessons, ADRs, runbooks, or solutions.
MCP versus CLI: MCP lets an agent query during a session; the CLI serves people, scripts, and reproducible operations.
Checks versus semantic judgment: deterministic checks verify facts,
citations, and state; the Amnesia Test also requires explicit evaluation. The
system returns score: unknown when that evaluation cannot be determined and
never invents a score from the mere presence of documents.
Parser and validator for the canonical docs/lessons.md format, including
Error class:, Check:, and Task: markers.
Hybrid search: SQLite FTS5 for citable lexical matches and sqlite-vec for
semantic search, fused with RRF.
Local embeddings through small fastembed models, with an offline FTS5
fallback and no external APIs.
Append-only verified-solution registry with explicit states and gates, write-through YAML, and drift detection.
Typed discovery and indexing of ADRs and runbooks while keeping their files authoritative.
amnesia-check for deterministic continuity checks.
amnesia-evaluate for combining verifiable facts with an explicit Amnesia
Test report evaluation.
Export, consistent SQLite backups, and recovery bundles with manifests and checksums.
Configurable project root through LEARNING_LOOP_PROJECTS_ROOT; one
installation can serve repositories in different paths.
For developing the project or installing its scripts and skill as well:
uv sync --extra dev
uv run pytest
uv run ruff check src tests
./scripts/install.sh./scripts/install.sh is idempotent. It can migrate a legacy index and accepts
these overrides:
LEARNING_LOOP_MCP_DB — explicit index path;
LEARNING_LOOP_PROJECTS_ROOT — repository root;
LEARNING_LOOP_INSTALL_SKIP_HERMES=1 — sync without registering MCP;
LEARNING_LOOP_INSTALL_WITH_SKILLS=1 — also install skills/ into
$HERMES_HOME/skills;
LEARNING_LOOP_INSTALL_DEV=0 — skip development extras.
After installation, restart the Hermes gateway so the tools and
learning-loop:// resources appear.
The learning-loop-mcp entry point includes, among others, these commands:
learning-loop-mcp index PROJECT [--lessons PATH] [--with-embeddings] [--db PATH]
learning-loop-mcp search QUERY [--project PROJECT] [--with-embeddings] [--json]
learning-loop-mcp learning-context PROJECT TASK [--version 1|2] [--kanban-board BOARD] [--json]
learning-loop-mcp capture-outcome PROJECT --draft PATH --output PATH [--json]
learning-loop-mcp amnesia-check PROJECT [--kanban-board BOARD] [--json]
learning-loop-mcp amnesia-evaluate PROJECT [--evaluation PATH] [--ignore-evaluation]
learning-loop-mcp validate PROJECT [--errors PATH] [--tests-dir PATH] [--json]
learning-loop-mcp status PROJECT [--json]
learning-loop-mcp register-solution PROJECT --solution-id X --title T --status E [--json]
learning-loop-mcp solutions PROJECT [--solution-id X] [--status E] [--json]
learning-loop-mcp reindex-solutions PROJECT [--solutions-path PATH] [--json]
learning-loop-mcp backup [--db PATH] [--out PATH]
learning-loop-mcp backup --recovery --kanban-board BOARD [--checkpoint PATH] [--out PATH]
learning-loop-mcp export PROJECT... [--out PATH] [--json]
learning-loop-mcp import BUNDLE [--projects-root PATH] [--db PATH] [--json]
learning-loop-mcp import-recovery BUNDLE [--projects-root PATH] [--db PATH] [--json]
learning-loop-mcp resume PROJECT [--checkpoint PATH] [--json]export creates a versioned bundle with canonical documents and a checksum
manifest. backup --recovery adds a consistent SQLite snapshot and a Kanban
archive exported through hermes kanban boards export, without reading Hermes'
private database. Extraction validates members and prevents path traversal.
Restores operate in a new directory and do not modify the original project or
board. The technical backup command also creates a SQLite snapshot using
sqlite3.Connection.backup() and runs PRAGMA integrity_check.
The server uses stdio and runs with:
learning-loop-mcp-serverIt exposes the search, learning_context, capture_outcome, amnesia_check,
amnesia_evaluate, learning_status, index, register_solution,
reindex_solutions, and solutions tools. It also serves
learning-loop://format/... and learning-loop://templates/... resources.
learning_context keeps the legacy response by default. With
context_version=2, it returns the ADD continuity package, including warnings,
sources, and—when configured—read-only Kanban state. It only invokes the
official hermes kanban ... list --json CLI; it never modifies cards or reads
Hermes' private SQLite database.
For SDK-based MCP clients, stdio_client uses a curated environment by default.
Pass env=dict(os.environ) in StdioServerParameters so the server receives
LEARNING_LOOP_MCP_DB and LEARNING_LOOP_PROJECTS_ROOT.
Lessons and all new project content are written in English by decision of ADR-0001, keeping local search and embeddings consistent. Spanish exceptions belong to historical migration files.
LEARNING_LOOP_PROJECTS_ROOT — repository root, resolved on every call;
LEARNING_LOOP_MCP_DB — SQLite index path;
LEARNING_LOOP_KANBAN_BOARD — Hermes board that can be queried read-only;
0 — operation succeeded;
1 — error-severity findings;
2 — usage or I/O error.
By default, documents live under
<LEARNING_LOOP_PROJECTS_ROOT>/<project>/docs/ and the index lives at
$LEARNING_LOOP_MCP_DB or $XDG_DATA_HOME/learning-loop-mcp/index.db.
project repositories (versioned Markdown/YAML) [source of truth]
↓ parser / validator
local SQLite FTS5 + sqlite-vec [derived index]
↓ loop.py, shared domain
CLI ───────── MCP stdio ───────── learning-loop:// resourcesNo absolute host paths are embedded in the package: the project root is
configured through the environment and the installed kit locates its own
resources through __file__.
Prompts, complete conversations, tokens, and invasive telemetry are not stored.
The presence of files alone does not prove that an architecture is understandable. Semantic evaluation and automatic evaluation remain separate.
If sources are missing or a result cannot be determined, the system reports
unknown instead of guessing.
FastMCP logs go to stderr; stdout is reserved for JSON-RPC.
Tests are offline and require no credentials. Embeddings use synthetic vectors or the cached model.
.github/workflows/ci.yml runs tests, lint, and compilation on every PR and push
to main, using Python 3.13. Dependabot maintains the uv dependencies and
official GitHub Actions.
Publishing uses PyPI Trusted Publishing with GitHub OIDC. The workflow requests
only contents: read and id-token: write; it uses no persistent PyPI token. To
publish a new version, merge the change first, then create a vX.Y.Z tag and
GitHub Actions publishes the artifact through the publisher configured in PyPI.
MIT — see LICENSE.
Runs the deterministic, read-only ADD continuity check.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| kanban_board | No | ||
| projects_root | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does disclose two meaningful behavioral traits: the operation is 'deterministic' and 'read-only'. Since no annotations are provided, this helps an agent understand that the tool is safe and repeatable. However, it does not explain what the check does, what inputs affect behavior, or what state or conditions it inspects.
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 efficient sentence with no wasted words and front-loads the action. However, it is more under-specified than usefully concise; critical context about the check and its parameters is absent.
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?
Even though an output schema exists and reduces the need to describe return values, the description omits essential context: what 'ADD' stands for, what qualifies as a continuity issue, when to run the check, and how the parameters affect execution. An agent would struggle to decide when or how to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the three parameters ('project', 'kanban_board', 'projects_root'). The parameter names offer some hints, but the tool's purpose and the role of each parameter remain unexplained, so the description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource ('Runs the deterministic, read-only ADD continuity check') and conveys that it performs some kind of check. However, the acronym 'ADD' is never expanded and the nature of the 'continuity check' is opaque, so an agent cannot fully tell what is being checked. It also does not differentiate this tool from the related sibling 'amnesia_evaluate'.
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 guidance is given about when to use this tool versus alternatives such as 'amnesia_evaluate' or 'project_preflight'. The description only says it runs a check, leaving the triggering conditions and exclusions entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collects structural evidence and validates an explicit Amnesia Test report.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| kanban_board | No | ||
| projects_root | No | ||
| evaluation_path | No | ||
| ignore_evaluation | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says the tool 'collects' and 'validates,' but does not say whether this is a read-only analysis, whether it writes or modifies anything, whether it reads a specific report file, or how ignore_evaluation changes behavior.
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 sentence with no filler or redundant phrasing. However, its brevity borders on under-specification, so it is concise but not maximally useful in structure.
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 having an output schema, the description is insufficient for a tool with five parameters and several closely related siblings. It does not clarify what an 'Amnesia Test report' is, when evaluation is needed, or how the optional parameters control the validation process.
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 0%, and the description does not explain any of the five parameters. An agent has no way to know the meaning or expected format of evaluation_path, projects_root, kanban_board, or ignore_evaluation based on the tool definition alone.
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 names a specific action ('collects structural evidence and validates') and a specific resource ('explicit Amnesia Test report'), so an agent can tell this is an evaluation/validation tool. However, it does not differentiate it from the sibling amnesia_check, and 'structural evidence' remains vague about what exactly is collected.
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 no guidance on when to use this tool versus alternatives such as amnesia_check, capture_outcome, or search. An agent is left to infer the appropriate context from the tool name and vague description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates and stores a task-local outcome draft without promotion.
| Name | Required | Description | Default |
|---|---|---|---|
| draft | Yes | ||
| project | Yes | ||
| output_path | Yes | ||
| projects_root | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It does communicate key facts: the tool validates, stores, and avoids promotion. However, it omits details like whether existing drafts are overwritten, whether failures are partial, or what side effects validation has.
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. 'Validates and stores' is placed at the start, and 'without promotion' is a high-value differentiator. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, three required, a nested draft object, and no parameter descriptions, the description is too thin. An agent would not know how to populate the draft or what output_path represents. The output schema may cover return values, but the input semantics and validation behavior remain underspecified.
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 0%, so the description must compensate for the bare parameter names. It does not explain project, draft, output_path, or projects_root. The phrase 'task-local outcome draft' loosely maps to draft/project, but the critical output_path and projects_root roles are 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?
The description gives a specific verb-resource pairing: 'Validates and stores a task-local outcome draft.' The phrase 'without promotion' sharply separates it from sibling tools like register_solution, making the distinctive scope clear.
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 its use case—capturing a draft that should not be promoted to a broader state—but does not explicitly state when to prefer it over register_solution or other siblings. The distinction is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
(Re)indexes the project into the local index. JSON with the number of
lessons indexed. lessons_path is optional (default convention).
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| lessons_path | No | ||
| with_embeddings | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the burden of disclosing side effects. It hints at re-indexing behavior and returns a count, but it does not explain whether the existing index is overwritten, whether with_embeddings affects behavior, or whether the operation is safe/idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loads the primary action. The output mention is useful and not redundant. It could be slightly richer with parameter hints, but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, so the JSON count mention is somewhat redundant. However, the description fails to explain the required project parameter, the role of with_embeddings, or any side effects. For a tool with no annotations and 0% schema coverage, this is incomplete.
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 0%, and the description only clarifies lessons_path ('optional, default convention'). It leaves the required project parameter unexplained and gives no meaning to with_embeddings, which is non-obvious from the schema alone. The description does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—'(Re)indexes the project into the local index'—and identifies the resource (lessons/project). It also mentions the JSON output, making it clear this is an indexing operation. It is distinct from siblings like search or reindex_solutions, though it does not explicitly differentiate.
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 guidance is given on when to use this tool versus siblings such as search, learning_status, or reindex_solutions. The only contextual hint is that lessons_path is optional, but there is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a legacy lesson list or an explicit cross-source v2 package.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| tarea | Yes | ||
| project | Yes | ||
| kanban_board | No | ||
| max_distance | No | ||
| context_version | No | ||
| with_embeddings | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits, but it only says 'Returns', implying a read operation. It does not explicitly state read-only behavior, side effects, prerequisites, or how the legacy versus v2 mode is chosen, which is a significant transparency gap.
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 concise sentence with the verb front-loaded, which is structurally efficient. However, it is too sparse for a tool with seven parameters and two output modes, so it earns the middle score rather than higher.
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 seven parameters, zero schema descriptions, and no annotations, the description is severely under-specified. The output schema covers the return shape, but the two modes and their selection criteria are unexplained, and no sibling differentiation is given.
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 0%, so the description must compensate, but it does not explain any of the seven parameters. The phrase 'cross-source' vaguely hints at the project/tarea inputs, but there is no mapping to context_version, kanban_board, max_distance, or with_embeddings.
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 ('Returns') and names a resource ('lesson list' or 'cross-source v2 package'), so it is not a tautology and conveys a general function. However, it does not differentiate from sibling tools like search or solutions, and the terms 'legacy' and 'explicit cross-source v2 package' are jargon that leave the exact scope unclear.
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?
There is no guidance on when this tool should be used versus alternatives such as search, solutions, or learning_status. The mention of two output modes implies some selection condition, but the description never states it, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Learning-loop status of the project (metrics + validation findings).
Same dict as learning-loop-mcp status --json. JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| tests_dir | No | ||
| errors_path | No | ||
| lessons_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does add value by stating the exact output shape ('same dict as learning-loop-mcp status --json') and content (metrics + validation findings), but it does not explicitly state whether the operation is read-only, what errors may occur, or any other side-effect information.
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 no filler. It front-loads the core purpose, adds a precise CLI-equivalence detail, and avoids repeating schema information.
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 is simple and has an output schema, so return-value documentation is covered. However, with no annotations and no parameter explanations, the description leaves gaps around parameter semantics and any behavioral caveats, making it minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters. The parameter names (project, tests_dir, errors_path, lessons_path) are somewhat self-explanatory, but with low coverage the description should 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 clearly identifies the tool as returning the learning-loop status of a project, including metrics and validation findings. It is not a tautology because it adds specifics about content and references the equivalent CLI command, though it does not explicitly differentiate among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: agents should call this when they need project learning-loop status or validation metrics. However, there is no explicit guidance about when to prefer this over siblings like learning_context or solutions, and no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks the read-only project start contract before implementation.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| task_id | No | ||
| hermes_bin | No | ||
| kanban_board | No | ||
| projects_root | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly says 'read-only' and 'checks,' which is valuable because no annotations are provided and it signals a non-mutating operation. However, it does not describe what happens if the contract fails, what resources are inspected, or whether any system state is read or cached, leaving the behavioral picture 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?
The description is a single front-loaded sentence with no wasted words; it communicates the action and the read-only safety property efficiently. It is concise, though the terseness comes at the cost of missing critical context.
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 five parameters, 0% schema coverage, and no annotations, the description is far from sufficient to invoke the tool correctly. It never explains what the 'project start contract' consists of, how to provide the required project value, or what the optional parameters do. The presence of an output schema helps but does not compensate for these 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 0%, and the description provides no meaning for any of the five parameters: project, task_id, hermes_bin, kanban_board, and projects_root. An agent cannot infer how to populate the required project parameter or what the optional parameters control.
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 gives a specific verb ('checks'), a specific resource ('read-only project start contract'), and a clear timing context ('before implementation'). However, it doesn't define what the contract contains, and sibling tools like amnesia_check also perform checks, so differentiation from other tools is weak.
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 phrase 'before implementation' implies when the tool should be used, giving useful context. But there is no explicit guidance about when not to use it, no mention of alternatives, and no exclusions or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Registers (append-only) a verified solution of the project.
Forward-only states: observed, fixed-locally, externally-verified,
documented, indexed. JSON with the created revision, or error if the
payload does not pass the state gates. If the project has versioned YAML
(or solutions_path is passed), the event is also written to
docs/metrics/solutions.yaml (git).
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| checks | No | ||
| status | Yes | ||
| commits | No | ||
| project | Yes | ||
| task_id | No | ||
| evidence | No | ||
| error_class | No | ||
| recipe_path | No | ||
| solution_id | Yes | ||
| solutions_path | No | ||
| documentation_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does it well. It discloses append-only semantics, forward-only state progression, gate-failure behavior returning `error`, and the conditional YAML/git side effect triggered by versioned YAML or `solutions_path`. It leaves some details unstated, such as idempotency and permissions, but the core side-effect profile is clear.
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 compact and front-loaded with the core action, followed by the state list and then behavior/side effects. It is dense but scannable, with no filler. The last sentence is slightly overloaded with conditions, keeping it just short of a top score.
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 complex 12-parameter mutation tool with no annotations, the description covers the essential invocation context: what is registered, the valid state progression, error behavior, return value, and the YAML/git side effect. It does not fully document every optional parameter or explicit sibling alternatives, but it is reasonably actionable as written.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameter descriptions, so the description must compensate. It adds real meaning by listing the forward-only states for `status` and tying `solutions_path` to the YAML side effect. However, most optional parameters (`checks`, `commits`, `evidence`, `error_class`, `recipe_path`, `documentation_path`) are left to name-based inference, which is a meaningful gap across 12 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Registers'), an object ('a verified solution'), and the append-only nature, making the core purpose clear. It does not explicitly name sibling tools to differentiate from reindex_solutions or index, but the state list helps clarify the intended operation.
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?
Usage is implied: use this tool when a verified solution needs to be recorded through a forward-only state transition. There is no explicit when-not-to-use guidance or routing to sibling tools like search, index, or reindex_solutions, so the agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rebuilds the solutions table from the project's versioned YAML
(docs/metrics/solutions.yaml). JSON with the number of rows
re-inserted.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| solutions_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does state that the table is rebuilt and rows are re-inserted, implying a destructive or state-changing operation. However, it does not explicitly warn about data loss, required permissions, or other side effects, and the mention of 're-inserted' is the only safety-related hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short and the core action is front-loaded. However, the second sentence is a broken fragment ('JSON with the number of rows re-inserted.'), missing a verb like 'Returns'. It is concise but not well-formed.
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 one required parameter that is never explained, making a successful invocation uncertain. There is no usage guidance, no mention of side effects or prerequisites, and while an output schema exists, the description itself is incomplete about the required 'project' parameter and the meaning of 'solutions_path'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description adds no information about the two parameters. It is unclear what 'project' refers to or how 'solutions_path' modifies behavior; the YAML path mentioned appears to be an internal default, not clearly tied to the parameter. This is a critical gap for a required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Rebuilds the `solutions` table from the project's versioned YAML', identifying both the resource and the data source. The return value is also mentioned ('JSON with the number of rows re-inserted'), though the sentence is a fragment. It does not explicitly contrast with sibling tools like 'index' or 'solutions', but the verb 'Rebuilds' is distinctive enough.
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 guidance is given about when to use this tool versus alternatives. The description only states what the tool does, with no mention of conditions, exclusions, or relationships to the other listed tools such as 'index' or 'register_solution'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches lessons (hybrid FTS5 + KNN) and returns JSON results with a
cite project/file:line and sources (fts5/vec). Identical to the CLI.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| project | No | ||
| max_distance | No | ||
| with_embeddings | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral context. It discloses the hybrid retrieval method, the JSON return format, and the cite/sources components, which is helpful. However, it omits any side effects, authorization requirements, rate limits, or behavior on empty results. It gives meaningful but not exhaustive disclosure.
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 that immediately states the core action and resource. It includes meaningful extra details (hybrid FTS5 + KNN, JSON results, cite/sources, CLI equivalence) without redundancy. Every clause adds information.
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 the description captures the core purpose and output shape, it is incomplete for an agent to invoke the tool correctly with all parameters. The presence of an output schema removes some need to describe returns, but the zero parameter coverage and lack of usage guidance leave significant gaps, especially for 'max_distance' and 'with_embeddings'.
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 0%, and the description adds no explanation for any of the five parameters. It does not define how 'query', 'limit', 'project', 'max_distance', or 'with_embeddings' behave or interact. The agent is left to infer semantics purely from opaque parameter names, with no compensatory description.
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 ('Searches') with a clear resource ('lessons') and adds technical precision ('hybrid FTS5 + KNN') and output details (JSON with cite `project/file:line` and sources). It inherently distinguishes itself from sibling tools like 'solutions' by targeting lessons, so the agent can tell them apart at a glance.
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 no explicit guidance on when to use this tool versus alternatives. It does not mention when to prefer 'search' over 'solutions' or any other sibling, and it offers no exclusionary conditions. Usage context is only implied by the word 'Searches'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trace (append-only) of the project's solutions ledger. JSON with the list of events ordered by revision.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| project | Yes | ||
| solution_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals that the data is append-only, is a JSON list, and is revision-ordered. However, it does not mention filtering behavior, pagination, or any edge conditions such as empty ledgers.
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 brief and front-loaded, with two sentences of useful information. It avoids fluff, though the first sentence is slightly awkward and the second sentence could be more precise about ordering direction.
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 annotations and no parameter descriptions in the schema, the description is incomplete for a tool with three parameters. It would need to explain parameter semantics and when to choose this over 'search' or 'register_solution' to be fully actionable.
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 0%, so the description must compensate by explaining the parameters. It only implicitly references the 'project' scope and says nothing about 'status' or 'solution_id'. The agent cannot infer how these optional parameters affect the returned events.
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 that the tool provides an append-only trace of a project's solutions ledger and returns a JSON list of events ordered by revision. It is understandable as a read/query tool, though it does not explicitly distinguish itself from the sibling 'search' tool.
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 no guidance on when to use this tool versus alternatives like 'search' or 'register_solution'. It does not state exclusions, prerequisites, or conditions that would route an agent to a sibling tool.
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.5.4amnesia_checkamnesia_evaluatecapture_outcomelearning_context2 fields changedInput schema / properties / context_versionAdded value: +{
+ "default": 1,
+ "type": "integer"
+}Input schema / properties / kanban_boardAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}project_preflightv0.4.0indexlearning_contextlearning_statusregister_solutionreindex_solutionssearchsolutionsScored across 11 tools
Most tools have distinct purposes, but several pairs overlap in surface intent: amnesia_check vs amnesia_evaluate both concern continuity/Amnesia validation, and learning_context vs search both return lesson-related content. The descriptions help a careful agent differentiate them, but the boundaries are not immediately obvious.
All names use snake_case and are readable, but the pattern is mixed: some are verb_noun (capture_outcome, register_solution, reindex_solutions), some are noun phrases (learning_status, learning_context, project_preflight), and some are bare words (index, search, solutions). This is not chaotic, but it lacks a consistent convention.
Eleven tools is well within the ideal range for a domain-specific server. Each tool serves a distinct role in the learning-loop lifecycle, and none feel redundant or purely decorative.
The toolset covers the main learning-loop workflow: preflight, outcome capture, Amnesia validation, indexing, solution registration, status, and retrieval. Minor gaps exist—such as no explicit promotion tool or lesson deletion—but these may be intentional given the append-only and forward-only design.
Project memory, semantic code search, and grounded agent context.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Project memory for coding agents: requirements, decisions, code graph and delivery telemetry.
