Click on "Install 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.
A portable learning-loop kit for AI-agent projects: an MCP server (stdio) plus a thin CLI that index, search and validate lessons learned across project repositories, closing the loop — read lessons when a task starts, record verified solutions while working, consolidate on close — without loading full files into every conversation.
The source of truth stays each project's git-tracked docs/lessons.md and
docs/metrics/errors.yaml (Markdown/YAML). This server builds a local SQLite
index (FTS5 + sqlite-vec) over them and validates format/conventions.
Verified solutions are appended to docs/metrics/solutions.yaml
(git-tracked, write-through) and mirrored into the derived index.
learning-loop-mcp repo (single source) [kit root]
├── src/learning_loop_mcp/ MCP server + CLI + loop orchestration
├── skills/learning-loop/ the ritual, one skill (auto-loads by relevance)
├── templates/ canonical seeds (lessons.md, errors.yaml,
│ solutions.yaml, AGENTS ritual block)
├── scripts/install.sh idempotent installer (Hermes MCP registration)
├── scripts/init-project.sh per-project bootstrap
└── docs/lessons-format.md canonical format (also served as a resource)The canonical files and format are served by the MCP server as
learning-loop:// resources — the agent reads them by URI, it never needs
to know where the kit lives.
The ritual is one skill (learning-loop), not duplicated text in every
repo. Project AGENTS.md files reference the skill in a single line.
No absolute host paths anywhere: the projects root comes from an env
var, the kit locates itself by __file__, docs live under
<PROJECTS_ROOT>/<project>/docs/.
Related MCP server: LumenCore
Parser + validator of the canonical docs/lessons.md format
(areas, bullets, Error class: / Check: / Task: markers) crossed with
docs/metrics/errors.yaml (error classes, checks, dedup).
Hybrid search: SQLite FTS5 (lexical, citable snippets with file:line) + sqlite-vec KNN (semantic) fused with RRF, per-project isolation.
Local embeddings via fastembed (small EN models), offline fallback to FTS5; no external APIs.
Verified-solution registry: append-only solutions table (immutable
events, incremental revisions, forward-only states with per-state gates) +
durable per-project YAML write-through + drift detection in status.
Portable project root: LEARNING_LOOP_PROJECTS_ROOT resolves per call,
so one install serves repos anywhere on disk (a fresh Hermes with different
paths only sets this env).
Python >= 3.11, uv.
uv sync --extra dev # creates .venv with deps + dev extras
uv run pytest # full suite
uv run ruff check src tests # lint./scripts/install.sh # uv sync + register with hermes + testIdempotent: safe to re-run. If a legacy index exists at
~/.cache/learning-loop-mcp/index.db and the destination has no copy, it is
migrated to ~/.local/share/learning-loop-mcp/index.db (XDG data home).
Useful overrides (env):
LEARNING_LOOP_MCP_DB — explicit index path.
LEARNING_LOOP_PROJECTS_ROOT — project repos root (default ~/Proyectos).
LEARNING_LOOP_INSTALL_SKIP_HERMES=1 — sync + migration only.
LEARNING_LOOP_INSTALL_WITH_SKILLS=1 — also copy skills/ to
$HERMES_HOME/skills.
LEARNING_LOOP_INSTALL_DEV=0 — production host with a dedicated venv
(skips dev extras).
After installing, restart the Hermes gateway so the server tools and
learning-loop:// resources appear in new sessions.
scripts/init-project.sh /path/to/<project>Creates docs/lessons.md, docs/metrics/{errors,solutions}.yaml (canonical
seeds), and appends the one-line ritual reference to the project's
AGENTS.md. Never overwrites existing files; safe to re-run.
CLI (entry point learning-loop-mcp):
learning-loop-mcp index <project> [--lessons PATH] [--with-embeddings] [--db PATH]
learning-loop-mcp search "query" [--project P] [--with-embeddings] [--max-distance N] [--json]
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 [--db PATH] [--json]
learning-loop-mcp solutions <project> [--solution-id X] [--status E] [--db PATH] [--json]
learning-loop-mcp reindex-solutions <project> [--solutions-path PATH] [--db PATH] [--json]
learning-loop-mcp backup [--db PATH] [--out PATH]backup copies the SQLite index (online-safe, via the SQLite backup API) to a
timestamped file next to the index by default (e.g.
~/.local/share/learning-loop-mcp/learning-loop-20260906-120000.db) and runs
an integrity check before reporting success. To restore: stop the server and
copy the backup over the index path.
MCP server (stdio, entry point learning-loop-mcp-server): tools search,
learning_context, learning_status, index, register_solution,
reindex_solutions, solutions; resources learning-loop://format/... and
learning-loop://templates/....
Defaults: docs live in <PROJECTS_ROOT>/<project>/docs/; the index lives in
$LEARNING_LOOP_MCP_DB or $XDG_DATA_HOME/learning-loop-mcp/index.db.
Exit codes: 0 ok, 1 error-severity findings, 2 usage/IO error.
Note for mcp SDK clients: stdio_client uses a curated environment by
default; pass env=dict(os.environ) in StdioServerParameters so the server
sees LEARNING_LOOP_MCP_DB / LEARNING_LOOP_PROJECTS_ROOT.
English (ADR-0001): canonical lessons and everything new (code, docs, messages) are written in English, which keeps small local EN embedding models discriminative.
project repos (docs/lessons.md + docs/metrics/errors.yaml
+ docs/metrics/solutions.yaml) [source of truth]
↓ parser / validator
local SQLite FTS5 + sqlite-vec + per-project metadata
↓ query domain (loop.py, single source CLI ↔ MCP)
CLI ─ MCP stdio server ─ learning-loop:// resources (kit files)FastMCP logs go to stderr; stdout is reserved for JSON-RPC (do not pollute it).
Tests are offline and credential-free; embeddings use synthetic vectors or the cached model.
MIT — see LICENSE.
(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 ONLY lessons of the given project applicable to the tarea
(hybrid search filtered by project, with cites).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| tarea | Yes | ||
| project | Yes | ||
| 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 present, the description carries the full behavioral burden. It discloses that this is a read-style search operation, that results are filtered by project and task relevance, that it uses hybrid search, and that citations are included. This is meaningful behavioral transparency, though it omits details like pagination or any limits on result size.
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 tight sentence communicates scope, filtering behavior, and output characteristic ('with cites') with no filler. The 'ONLY' qualifier is front-loaded, immediately telling the agent what is excluded. 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?
The core purpose and two required parameters are covered, and the presence of an output schema reduces the need to describe return values. However, with no annotations and three undocumented optional parameters, an agent cannot fully determine how to tune the search (e.g., what max_distance affects or when to enable embeddings). The description is adequate but not complete for confident invocation.
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 all parameters. It explains 'project' and 'tarea', the two required parameters, fairly well. However, 'limit', 'max_distance', and 'with_embeddings' receive no explanation, and their roles are not inferable from 'hybrid search' alone. This leaves significant parameter ambiguity.
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 verb ('Returns'), a specific resource ('lessons'), and precise scoping ('of the given project applicable to the tarea'). The parenthetical adds a concrete mechanism ('hybrid search filtered by project, with cites'), making the tool's role unambiguous among siblings.
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 emphasis on 'ONLY lessons applicable to the tarea' implies this tool is for task-scoped lesson retrieval, which gives some context for when to use it. However, it does not explicitly state when not to use it or name alternatives like 'search' or 'solutions', leaving the agent to infer the boundary between this tool and its siblings.
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.
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. Dates show when Glama detected each change.
v0.4.0indexlearning_contextlearning_statusregister_solutionreindex_solutionssearchsolutionsThe search and learning_context tools both perform hybrid lesson search, but one is explicitly global and the other is scoped by project and tarea. Index and reindex_solutions overlap in name/idea but target different data (lessons vs solutions table). Overall, each tool has a distinct role once descriptions are read.
Names are readable but do not follow a single convention: search and index are bare verbs, learning_context and learning_status are noun phrases, while register_solution and reindex_solutions are verb+noun. This is a mixed style rather than a consistent pattern, though subareas are somewhat predictable.
Seven tools cover a bounded learning-loop workflow: lesson indexing/search/context, project status, and solution ledger operations. This is a well-scoped set with no obvious bloat or thinness.
The set covers the core learning-loop lifecycle: indexing lessons, searching and contextualizing them, reporting status, and maintaining an append-only solution ledger with register/rebuild/trace. Minor gaps such as no direct project listing or single-lesson retrieval tool exist, but search and context likely cover those needs.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tiempor3al/learning-loop-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server