1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MnemoQ log learning about JWT token expiry handling" 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.

MnemoQ

Official

by Mnemoq

Overview Schema Related Servers Score Discussions

Python

Local

MnemoQ

Local-first memory engine for AI agents — MCP-native, graph-linked, spaced repetition.

Agent ──log──▶ MnemoQ Engine ──store──▶ learnings.jsonl
Agent ◀──retrieve── MnemoQ Engine ◀──read── learnings.jsonl
Agent ──MCP──▶ mnemoq-mcp ──read/write──▶ learnings.jsonl

PyPI version Python versions License: AGPL-3.0-or-later

Install

pip install mnemoq

CLI-only users (no Python project needed):

pipx install mnemoq

Related MCP server: Cortex

Quick Start

1. Scaffold a project

mnemoq-scaffold ./my-project --defaults

This creates a memory/ directory with config.json and learnings.jsonl in your project.

Wire memory into your IDE/agent platform:

mnemoq-scaffold ./my-project --defaults --ide windsurf
mnemoq-scaffold ./my-project --defaults --ide windsurf,cursor,claude-code
mnemoq-scaffold ./my-project --defaults --ide all
mnemoq-scaffold --ide ?

Supported platforms: opencode, windsurf, cursor, claude-code, copilot, all.

2. Log a learning

mnemoq --log '{"step":3,"source_agent":"claude","type":"pattern","domain":"backend","components":["api","auth"],"files_touched":["src/auth.py"],"trigger":"JWT validation failed on expired tokens","action":"Added explicit expiry check before signature verification","reason":"PyJWT silently accepts expired tokens when verify_exp is not set","importance":8,"severity":"major"}'

PowerShell-safe alternative (avoids JSON quoting issues):

mnemoq --log-file learning.json

3. Retrieve relevant learnings

mnemoq --step 3 --components api,auth --domain backend

4. Other commands

mnemoq --stats                          # Memory statistics
mnemoq --resolve 2025-06-25T10:30:00    # Mark a learning resolved
mnemoq --review-agents --step 3         # AGENTS.md section health report
mnemoq --consolidate                    # Archive + promote (sleep cycle)
mnemoq --install-hooks                  # Install git post-commit auto-learn hook

For the full retrieve → work → log → evaluate → auto-learn loop and how to wire it into any IDE or agent, see the Integration Guide.

5. MCP server

MCP is the primary integration path for AI agents. The server runs over stdio (JSON-RPC 2.0) with no HTTP dependency.

mnemoq-mcp                                # auto-discovers memory/ in cwd
mnemoq-mcp --memory-dir /path/to/memory   # explicit path

Or via environment variable: AGENT_MEMORY_DIR=/path/to/memory mnemoq-mcp

Tools exposed: retrieve_learnings, log_learning, resolve_learning, get_stats, consolidate

Works with Claude Desktop, Cursor, Windsurf, VS Code, and any MCP-compatible client. See the full MCP integration guide for client configuration snippets, tool reference, and troubleshooting.

CLI Reference

Command	Description
`mnemoq`	Log, retrieve, consolidate, and manage agent memories
`mnemoq-scaffold`	Initialize a new project with memory directory and config
`mnemoq-update`	Update engine files in existing projects
`mnemoq-mcp`	Start MCP server (JSON-RPC over stdio)
`scripts/generate_fakes.py`	Generate synthetic memory entries for testing

See docs/cli-reference.md for all flags, examples, and mutual-exclusion rules.

Configuration

memory/config.json tunes retrieval scoring, retention, embeddings, reranking, and access control for your project. Below is a summary of all parameters — see the full Config Tuning Guide for ranges, defaults, and tuning recipes.

Parameter	Default	What it controls
`project_name`	`"<PROJECT_NAME>"`	Project identifier
`engine_min_version`	`"1.15.0"`	Minimum engine version
`schema_version`	`1`	Config schema version
`max_step`	`null`	Cap on step values (`null` = no cap)
`valid_domains`	`null`	Accepted domain whitelist
`valid_source_agents`	`null`	Accepted agent whitelist
`retrieval_only_agents`	`null`	Agents that can retrieve but not log
`domain_mappings`	`null`	Custom domain → canonical tag mappings
`api_key`	`null`	HTTP API auth key (`null` = no auth)
`embedding_model`	`"all-MiniLM-L6-v2"`	sentence-transformers model name
`embedding_cache_dir`	`"~/.agent-memory/models/"`	Model file cache path
`reranker`	`"none"`	Reranker mode: `none`, `cross-encoder`, `llm-local`
`reranker_top_n`	`20`	Number of top results to rerank
`reranker_model`	`"cross-encoder/ms-marco-MiniLM-L-12-v2"`	Cross-encoder model name
`reranker_llm_endpoint`	`null`	LLM endpoint URL for `llm-local` mode
`reranker_llm_model`	`null`	LLM model name for `llm-local` mode
`tuning.decay_rate`	`0.995`	Exponential decay per step (recency)
`tuning.score_threshold`	`0.15`	Minimum score for non-critical candidates
`tuning.component_weight`	`1.0`	Weight when task components match
`tuning.file_weight`	`0.7`	Weight when task files match
`tuning.domain_weight`	`0.4`	Weight when domain matches
`tuning.no_match_weight`	`0.1`	Weight when nothing matches
`tuning.max_warnings`	`5`	Max critical entries per retrieval
`tuning.max_patterns`	`15`	Max non-critical entries per retrieval
`tuning.minor_retention`	`5`	Step window for minor entries
`tuning.major_retention`	`20`	Step window for major entries
`tuning.escalation_threshold`	`30`	Step age for escalation flagging
`tuning.bm25_k1`	`1.5`	BM25 term frequency saturation
`tuning.bm25_b`	`0.75`	BM25 document length normalization
`tuning.rrf_k`	`60`	Reciprocal rank fusion constant
`tuning.embedding_alpha`	`0.5`	Blend weight: `alpha * rrf + (1-alpha) * cosine`
`tuning.semantic_dedup_threshold`	`0.85`	Cosine similarity for duplicate detection
`tuning.sleep_cycle_days`	`1`	Days between consolidation triggers
`tuning.sleep_cycle_quarantine_threshold`	`20`	Quarantine count that triggers consolidation

Data Schema

Each entry in learnings.jsonl is a JSON object with these required fields:

Field	Type	Constraint
`step`	`int`	≥ 1
`source_agent`	`str`	must be a valid agent name
`type`	`str`	`bug_fix`, `optimization`, or `architectural_pattern`
`domain`	`str`	e.g. `backend`, `testing`, `security`
`components`	`list[str]`	non-empty
`files_touched`	`list[str]`	non-empty
`trigger`	`str`	must start with `When`
`action`	`str`	must contain `ALWAYS` or `NEVER`
`reason`	`str`	non-empty
`importance`	`int`	1–10
`severity`	`str`	`minor`, `major`, or `critical`

The engine auto-stamps ts, commit, access_count, reinforcement_count, embedding, schema_version, and provenance fields at log time. See docs/data-schema.md for the full reference including optional fields, enum values, schema versioning, and sample entries.

Development

git clone https://github.com/Mnemoq/MnemoQ.git
cd MnemoQ
pip install -e ".[dev]"
pytest

Structure

src/mnemoq/ — Engine source (CLI, retrieval, validation, consolidation, MCP server, dashboard, SDK)
src/mnemoq/engine/ — Core modules (retrieval, scoring, reranking, consolidation, validation, server)
tests/ — Test suite
templates/ — Config templates, prompts, eval data
docs/ — Architecture documentation (index)
scripts/ — Deploy scripts

Changelog

See CHANGELOG.md.

Roadmap

See docs/ROADMAP.md for current status and planned features.

License

AGPL-3.0-or-later. See LICENSE for details.

Contributing

See CONTRIBUTING.md. Submitting a PR constitutes acceptance of the CLA.

Security

Report vulnerabilities privately via GitHub Security Advisories. See SECURITY.md for details.

Available Tools

8 tools

capture_interactionA

Capture a conversation interaction as memory. Extracts learnable moments from raw text and auto-logs them. Three-tier extraction: online LLM, offline LLM, heuristic fallback.

ParametersJSON Schema

Name	Required	Description	Default
`step`	No	Current plan step (default: 1)
`conversation`	Yes	Raw conversation text (human and AI turns)

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses the three-tier extraction process (online LLM, offline LLM, heuristic fallback), which reveals internal behavior. However, it does not mention side effects, auth requirements, or failure modes.

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

Conciseness5/5

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

The description is three sentences, front-loaded with the purpose, and contains no redundant information. Every sentence contributes value: purpose, automatic logging, and extraction tiers.

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

Completeness3/5

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

Given the simple schema and no output schema, the description explains the extraction process but omits important details like what the tool returns (e.g., success confirmation, memory ID) or how it interacts with sibling tools. It lacks completeness for a full understanding.

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

Parameters3/5

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

Schema description coverage is 100%, meaning the input schema already fully documents both parameters. The tool description adds no extra meaning beyond what the schema provides, so it meets the baseline but does not enhance parameter understanding.

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

Purpose5/5

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

The description clearly states the action ('capture'), the resource ('conversation interaction as memory'), and the specific outcomes ('extracts learnable moments', 'auto-logs them'). It distinguishes itself from siblings like 'log_learning' and 'retrieve_learnings' by focusing on the initial capture step.

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

Usage Guidelines3/5

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

The description implies the tool is for storing raw conversation text as memory, but it lacks explicit guidance on when to use it versus alternatives like 'log_learning' or 'consolidate'. It does not specify prerequisites or scenarios where it is inappropriate.

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

consolidateB

Trigger a Sleep Cycle (consolidation): archives unresolved entries, generates promotion candidates, detects contradictions, and checks for stale entries.

ParametersJSON Schema

Name	Required	Description	Default
`force`	No	Overwrite existing archive if one exists.
`sprint_number`	No	Sprint number for archive file naming. Auto-inferred if omitted.

TDQS

B3.2/5.0

Behavior2/5

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 lists actions but does not mention side effects (e.g., data destruction via overwrite), authentication needs, rate limits, or return values. The 'force' parameter hints at destructive potential, but this is not explicitly stated in the description.

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

Conciseness5/5

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

The description is a single sentence that effectively communicates the tool's purpose through a list of actions. It is front-loaded and contains no unnecessary words.

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

Completeness2/5

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

Given the complexity (four actions, two parameters, no output schema), the description is incomplete. It lacks explanation of the tool's output or result, prerequisites, and the concept of a 'Sleep Cycle'. The absence of output schema context leaves the agent guessing about return behavior.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description does not add any additional parameter information beyond what the schema provides. However, the schema descriptions are adequate and cover both parameters.

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

Purpose5/5

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

The description uses a clear verb ('Trigger') and specifies the resource ('Sleep Cycle (consolidation)') with explicit sub-actions: archives unresolved entries, generates promotion candidates, detects contradictions, and checks for stale entries. This distinguishes it from sibling tools that capture, evaluate, log, or retrieve data.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or conditions. The description simply states what the tool does without contextualizing its appropriate use cases.

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

evaluate_promptB

Evaluate a structured prompt summary for learnable moments. Runs heuristic detectors on the summary, auto-logs high-confidence signals, and returns suggestions for medium-confidence ones.

ParametersJSON Schema

Name	Required	Description
`step`	Yes	Current plan step number
`text`	No	Salient gist of the interaction
`outcome`	Yes	Outcome category of the prompt/response cycle
`components`	Yes	Components involved in the interaction
`error_text`	No	Error message if outcome is bug_fixed (optional)
`prompt_type`	Yes	Who issued the prompt being evaluated
`files_touched`	Yes	Files modified or discussed
`rejected_action`	No	What the human said not to do
`corrected_action`	No	What the human said to do instead

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions auto-logging and returning suggestions but does not disclose side effects (e.g., data modification), authorization needs, or rate limits. The auto-logging behavior is stated but not elaborated.

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

Conciseness5/5

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

The description is extremely concise, using one sentence (two clauses) to convey purpose and mechanism. It is front-loaded with the main verb and resource, and every phrase adds value.

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

Completeness2/5

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

Despite 9 parameters and no output schema, the description lacks details about return structure (suggestions) and the auto-logging effect. The agent is left unsure of what the tool returns or whether it modifies state, making it incomplete for a complex tool.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it only describes high-level behavior without elaborating on any specific parameter.

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

Purpose5/5

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

The description clearly states the verb 'evaluate' and the resource 'structured prompt summary' with specific purpose 'for learnable moments'. It distinguishes from siblings like capture_interaction and log_learning by focusing on heuristic detection and suggestion generation.

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

Usage Guidelines3/5

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

The description implies usage after a prompt summary is created but does not explicitly state when to use this tool versus alternatives like log_learning or retrieve_learnings. No exclusions or context are provided.

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

get_statsA

Get memory system statistics: total entries, unresolved/resolved counts, severity/type/scope breakdowns, reinforcement patterns, and sleep cycle status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations exist, so the description carries the burden. It indicates a read-only operation (getting statistics) but does not elaborate on behavioral details such as whether results are cached, how frequently they update, or whether the tool is safe to call repeatedly.

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

Conciseness5/5

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

The description is a single, well-structured sentence that front-loads the core purpose and efficiently lists details, with no extraneous words.

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

Completeness4/5

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

Given zero parameters, no output schema, and no annotations, the description provides a comprehensive overview of what statistics are available. It could mention the return format or whether the data is a snapshot, but overall it is fairly complete.

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

Parameters4/5

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

With zero parameters and 100% schema coverage, the description adds meaningful context by enumerating the specific statistical categories provided, which goes beyond the empty schema.

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

Purpose5/5

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

The description clearly states the verb 'Get', the resource 'memory system statistics', and lists specific breakdowns (total entries, unresolved/resolved counts, etc.), making the purpose highly specific and distinguishable from sibling tools like 'capture_interaction' or 'consolidate'.

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

Usage Guidelines3/5

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

The description implies usage for retrieving statistics but does not explicitly state when to use this tool versus alternatives. No guidance on prerequisites or exclusions is provided.

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

log_learningA

Log a new learning entry. Validates, checks for duplicates/semantic duplicates, and appends to memory. Returns status (added/duplicate/semantic_duplicate/conflict/quarantined) and entry details.

ParametersJSON Schema

Name	Required	Description	Default
`entry`	Yes	Learning entry object with fields: step, source_agent, type, domain, components, files_touched, trigger, action, reason, importance, severity, scope, debt_level, etc.

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations, the description effectively discloses key behaviors: validation, duplicate checking, semantic duplicate detection, appending to memory, and possible return statuses. This gives the agent a clear understanding of what happens when the tool is invoked.

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

Conciseness5/5

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

The description is extremely concise at three sentences, with the primary action front-loaded. Every sentence adds value: logging, behavior, and return value, with no wasted words.

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

Completeness4/5

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

Given the complexity of a nested object with many fields and no output schema, the description provides sufficient behavioral context (validation, duplicates, return status). It does not explain parameter details, but the schema covers that adequately.

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

Parameters3/5

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

Schema description coverage is 100% (the 'entry' parameter has a field list). The tool description adds no additional meaning to the parameters beyond what the schema provides, so a baseline score of 3 is appropriate.

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

Purpose4/5

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

The description uses a specific verb ('Log') and resource ('a new learning entry'), clearly stating the action. While it does not explicitly differentiate from sibling tools like 'capture_interaction' or 'retrieve_learnings', the purpose is unambiguous.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. Sibling tools exist (e.g., 'retrieve_learnings', 'resolve_learning'), but the description does not mention usage context or exclusions.

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

resolve_learningB

Mark an existing learning entry as resolved by its timestamp.

ParametersJSON Schema

Name	Required	Description	Default
`timestamp`	Yes	Entry timestamp (YYYY-MM-DDTHH:MM:SSZ format)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states 'mark as resolved' without explaining side effects, permissions, or reversibility. For a mutation tool, this is insufficient.

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

Conciseness5/5

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

The description is a single, efficient sentence with no redundant information. It is appropriately sized and front-loaded.

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

Completeness3/5

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

The tool has a single parameter and no output schema or annotations. The description covers the basic action but lacks details on return values, effects, or prerequisites. Adequate for a simple tool but not fully complete.

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

Parameters3/5

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

Schema coverage is 100% (one parameter with format description). The description's mention of 'by its timestamp' adds little beyond the schema. Baseline score of 3 is appropriate as no additional semantic value is provided.

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

Purpose5/5

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

The description clearly states the action ('Mark') and the resource ('existing learning entry') with the specific criterion ('by its timestamp'). It distinguishes from sibling tools like log_learning (create) and retrieve_learnings (read).

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

Usage Guidelines2/5

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

The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., consolidate or evaluate_prompt). No context for exclusions or prerequisites is given.

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

retrieve_learningsA

Retrieve relevant learnings for the current task context. Returns warnings (critical issues) and patterns (architectural guidance), scored and ranked by relevance.

ParametersJSON Schema

Name	Required	Description
`step`	Yes	Current plan step number
`files`	No	File paths being worked on
`domain`	No	Coarse domain tag (e.g. 'ui', 'data', 'tooling')
`components`	No	Component names relevant to the task

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description must convey behavioral traits. It states that the tool returns scored/ranked warnings and patterns, implying a read-only query, but it does not explicitly confirm no side effects, rate limits, or other behaviors. For a retrieval tool, this is adequate but not thorough.

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

Conciseness5/5

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

The description is two sentences long, front-loaded with the verb and resource, and every word contributes value. No redundancy or filler.

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

Completeness4/5

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

Given the lack of an output schema, the description provides necessary details about return content (warnings and patterns, scored/ranked). Parameter semantics are covered by the schema. The description could be improved by specifying the output format or any prerequisites, but it is largely complete for its purpose.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning or guidance beyond what the schema already provides for each parameter (step, files, domain, components).

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

Purpose5/5

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

Description explicitly states 'Retrieve relevant learnings' and specifies the output (warnings and patterns, scored/ranked). The verb and resource are clear, and the purpose is distinct from siblings like log_learning (capture) and resolve_learning (resolution).

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

Usage Guidelines3/5

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

The description indicates usage 'for the current task context' but provides no explicit when-to-use or when-not-to-use guidance. No alternatives or exclusions are mentioned, leaving the agent to infer appropriate usage from the context.

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

review_agentsB

Diagnostic report on AGENTS.md section health. Cross-references recent learnings with AGENTS.md sections, categorizing sections as active (referenced by learnings), cold (no references), and identifying unmatched learnings.

ParametersJSON Schema

Name	Required	Description	Default
`step`	Yes	Current plan step number
`threshold`	No	Step window for considering learnings recent

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden. It describes the analytical action but does not disclose whether the tool modifies data, requires permissions, or has side effects. The agent cannot infer if this is a read-only operation.

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

Conciseness5/5

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

The description is two sentences with no extraneous information. The key functionality is stated upfront, making it easy for an agent to parse quickly.

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

Completeness2/5

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

The tool lacks an output schema and does not describe the return format. For a diagnostic tool, the agent needs to know what the report looks like (e.g., categorical output). Additionally, behavioral transparency is missing, making the definition incomplete despite clear purpose.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already documents both parameters. The tool description adds minimal extra meaning beyond the schema, merely echoing the step and threshold concepts. Baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool's purpose: producing a diagnostic report on AGENTS.md section health. It specifies the verb (diagnostic), resource (AGENTS.md sections), and the cross-referencing action. This distinguishes it from sibling tools like capture_interaction or get_stats.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description implies a use case (checking AGENTS.md health) but does not specify when it should be preferred over siblings like evaluate_prompt or when not to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.1.0Jul 9, 2026
- First observedcapture_interaction
- First observedconsolidate
- First observedevaluate_prompt
- First observedget_stats
- First observedlog_learning
- First observedresolve_learning
- First observedretrieve_learnings
- First observedreview_agents

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: capturing raw interactions, logging structured learning, evaluating prompts, retrieving relevant learnings, resolving entries, consolidating memory, and reviewing agent documentation. No two tools overlap in function.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern in snake_case (e.g., capture_interaction, log_learning, retrieve_learnings). However, 'consolidate' breaks the pattern as a single verb without a noun, causing a minor inconsistency.

Tool Count5/5

With 8 tools, the server covers core memory operations (create, read, update, consolidate, evaluate) without being overwhelming. The count is well-scoped for a memory management system.

Completeness3/5

The server lacks direct update and delete operations for learning entries, which are common in memory systems. While resolve_learning provides status change, editing entry content is missing. Retrieval is limited to context-based relevance, missing full listing.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

memnodeOAuth
dev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Knowledge & Memory Autonomous Agents Agent Orchestration
2
XMemo AOAuth
io.github.yonro
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
Autonomous Agents Knowledge & Memory
19212
mifactory-agent-memory C
io.github.mifactory-bot
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Knowledge & Memory Autonomous Agents Agent Orchestration
22
BrainboxOAuth
dev.thexi
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Knowledge & Memory AI & Machine Learning
2

Related MCP Servers

distillory
Knowledge & Memory Autonomous Agents
everyai-com
A
license
Not graded
quality
B
maintenance
Local-first memory engine that synthesizes entity profiles at ingestion. Enables persistent, reasoning memory for AI agents via MCP tools like add, search, and profile.
Updated 3 months ago (2026-06-20 16:58 UTC)
MIT
Cortex
Knowledge & Memory RAG Systems Vector Databases
ryanfrigo
A
license
Not graded
quality
D
maintenance
Local-first AI memory layer with hybrid retrieval and brain-inspired namespaces. Enables agents to save, search, and manage memories directly via MCP tools.
Updated 5 months ago (2026-04-07 18:08 UTC)
5
MIT
AstraMemory Local
Knowledge & Memory Search Developer Tools
astragenie
A
license
Not graded
quality
B
maintenance
Local-first memory daemon for AI coding agents that captures session transcripts, distills typed memories (decisions, facts, lessons, commands, todos), and serves them via hybrid search through MCP tools.
Updated 21 days ago (2026-08-15 23:13 UTC)
47
MIT
nuzo-memory
Knowledge & Memory Databases
fabionfsc
A
license
Not graded
quality
F
maintenance
Local-first, auditable memory for AI agents. Provides durable context for MCP hosts with SQLite storage, CLI, and MCP tools for memory management.
Updated 22 days ago (2026-08-14 21:46 UTC)
2
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mnemoq/MnemoQ'

If you have feedback or need assistance with the MCP directory API, please join our Discord server