nMEMORY
Server Quality Checklist
Latest release: v0.3.0
- Disambiguation4/5
Tools have distinct purposes, but memory_ingest and memory_classify both can persist classification sidecars, causing minor ambiguity. Overall, descriptions are thorough and roles are clear.
Naming Consistency4/5All tools use 'memory_' prefix with snake_case. While not strictly verb_noun (e.g., outcome, vector, visual are nouns/adjectives), the pattern is consistent and predictable.
Tool Count5/522 tools cover a comprehensive memory management lifecycle including CRUD, import/export, session management, relations, and advisory features. Each tool earns its place without bloat.
Completeness4/5Covers most operations but lacks a direct content-update tool; modification requires forget+re-ingest. Metadata updates exist via classify, pin, etc. Minor gap for full CRUD parity.
Average 4.5/5 across 22 of 22 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 39 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully shoulders the transparency burden. It meticulously details behaviors: count semantics (live/superseded/tombstoned), cap mechanics, cycle detection (fail-closed/open), advisory nature, and error conditions. Every edge case is articulated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is an excessively long, unstructured wall of text. It lacks paragraphs or headings, making it arduous for an AI agent to parse. Every sentence is dense with detail, many of which are implementation internals rather than user-facing guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite its poor structure, the description covers every component of the digest (capsules, handoffs, dag, mission, etc.) thoroughly. With no output schema, this is necessary. However, the lack of organization hinders quick comprehension, earning a deduction from perfect completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial value: it clarifies that 'headlines' caps all id lists, not just headlines, and explains that 'project_prefix' only fences capsule sections, not global ones. This context is critical for correct parameter use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Compact store projection sized for session-start injection,' giving a clear use case. It distinguishes from siblings like memory_get (for details) and memory_retrieve (for search). However, the core purpose is buried in a dense wall of text, reducing immediate clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it's for session start but doesn't compare to siblings like memory_list or memory_get. The agent must infer usage from the tool's name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully shoulders the transparency burden. It exhaustively discloses behavioral traits: persistence behavior, advisory-only mode, monotone taint, epistemic sidecar conditions, derivation rules, error cases (underivable, teaching error), and drift detection. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and includes numerous details and edge cases, which is valuable but reduces conciseness. It is front-loaded with the core action but quickly expands into complex rules. More structure (e.g., bullet points or clearer separation of concerns) could improve quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema), the description covers most key aspects: input semantics, defaults, side effects, error conditions, cross-tool references (memory_extract, memory_get), and partial return value description. It lacks explicit output structure but provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant value beyond the schema by explaining parameter interactions (e.g., origin default scope, epistemic field requirements, kind carry-forward rule, taint monotonicity). This enriches semantic understanding for effective tool usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool classifies content into specific kinds, scopes, and other attributes. It provides an enumeration of possible outputs and mentions relationship with memory_extract. However, it does not explicitly distinguish this tool from all sibling tools, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers some guidance, such as when to pass kind (carrying forward from memory_extract) vs. omitting it for derivation, and conditions for using capsule_id. However, it lacks explicit when-to-use vs. alternatives guidance, leaving the agent to infer context from the detailed rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: file location probing, split rules, taint marking (born tainted), anchor provenance, outcome types (imported/absent/rejected), stale import supersession, and the fence (manual edges protected). It is exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with excessive detail, making it not concise. It front-loads the purpose but then dives into split rules, supersession, and fence details that could be abbreviated or structured better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no output schema), the description comprehensively covers all aspects: source selection, split logic, taint, anchors, outcomes, supersession, and fence. Nothing essential is missing for an AI to understand how to invoke and what happens.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context for source behavior (e.g., directory probing) but does not significantly enhance parameter understanding beyond the schema's descriptions. It mentions base override and dir requirement but that's already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Import memories from ONE closed native source' and lists the specific sources (user-claude-md, project-claude-md, etc.), providing a specific verb and resource. It distinguishes from siblings like memory_ingest by emphasizing the closed native source set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for importing from these specific sources but does not explicitly state when to use this tool versus alternatives like memory_ingest or memory_export. It lacks when-not-to guidance or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: read-only, markdown structure, sha256 coverage, stamp effect, and warnings about extraction. It explicitly states 'Read-only, ADVISORY_NOT_AUTHORITY' and explains the deterministic nature and tamper detection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long (multiple paragraphs) and could be more concise. While it front-loads the core purpose and structures details with sections, it contains excessive explanatory text that could be condensed, reducing efficiency for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and lack of output schema, the description covers all necessary aspects: output format, markdown structure, hashing details, stamp behavior, and extraction warnings. It is comprehensive enough for an agent to understand tool usage and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'stamp' has schema description coverage at 100% with detailed documentation. The description adds value by explaining its effect on byte-identical regenerations and the stable-diff use case, enriching the schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it renders the whole store as a deterministic markdown INDEX view and returns it as a string under the 'markdown' key. This is a specific verb-resource combination, and while it doesn't explicitly compare to siblings, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (e.g., 'the caller saves it where it wants' and discussion of stamp for byte-identical output), but it does not explicitly state when to use this tool versus alternatives like memory_get or memory_list. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description extensively discloses response structure, tombstone behavior, error handling, field meanings (e.g., expiry, taint findings, last_mutation), and sidecar behavior, providing full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely long and dense single paragraph; while informative, it is not concise and would benefit from better structure (e.g., bullet points) for agent consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the response, including all fields, edge cases (tombstone, unknown ID), and sidecar behaviors, leaving no gaps for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (id) with 100% schema coverage; the description adds little beyond the schema's own description, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies that the tool fetches ONE full capsule by exact store id, and positions it as an expansion step after retrieve/digest/list, clearly distinguishing its role from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it ('after retrieve/digest/list returned a headline') and describes error responses for forgotten and unknown IDs, but does not mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses deterministic ID generation and auditing, but does not discuss permissions, side effects, idempotency, or concurrency. Adequate but incomplete for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Purpose, ID format, linking instructions, and audit note all delivered efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, description covers the key aspects: what the tool does, how ID is returned, how to use with related tools, and audit. Could mention session limits or reliability, but overall complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (schema is empty). Baseline 4 applies as description does not need to add parameter info. Succinct and sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb ('Open') and resource ('session bracket'), details return value format ('sess-<n>'), and explicitly distinguishes from siblings (memory_ingest, memory_session_finish). No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly explains when to use (to start a session), how to link captures and close, and mentions auditing. Lacks explicit when-not-to-use or alternatives, but given the narrow scope with related siblings, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses idempotent behavior, origin marking, and constraints (both endpoints stored, self-relations rejected). It explains that only 'falsifies' fences recall, and edges are history. It does not mention auth or rate limits, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy and dense, packing many details. While front-loaded with purpose, it could be trimmed for conciseness without losing essential information. Some redundancy exists across kind descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 relation kinds, unique behaviors per kind), the description is remarkably complete. It explains each kind, constraints, idempotency, origin field, and links to memory_digest. No output schema, but response fields are mentioned. Perfectly adequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (3 params). The description adds significant meaning beyond the schema: detailed definitions for each relation kind, constraints on endpoints, and idempotent behavior. This enriches the agent's understanding of how to use the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Record ONE directed, typed relation edge from --kind--> to.' It specifies the action (record a relation edge) and the resource (relation edges between capsules). With multiple relation kinds detailed, it distinguishes itself from sibling tools like memory_forget or memory_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context on when to use each relation kind, e.g., 'falsifies' is the only way to fence a capsule from recall. It also mentions idempotency and constraints (self-relations rejected). However, it does not directly compare to sibling tools, but the distinct purpose makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses numerous behavioral traits: mandatory provenance, batch error handling per-item, idempotency via content hash, smart defaults, dedup_hint and siblings computation, fact-time handling, session linking, supersede support, taint scanning, and project derivation. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely long (over 700 words) and lacks structure like paragraphs or sections. It is a dense wall of text that could be streamlined or organized with bullet points or subsections. While detailed, it sacrifices conciseness for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, no output schema, and numerous edge cases, the description is highly complete. It covers error handling (shape-broken, semantic rejections), idempotency, dedup hints, siblings, fact-time, epistemic sidecars, supersedes, taint scanning, and project derivation. Very thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds value beyond the schema by explaining overarching behaviors like the project_id derivation logic, default confidence of 0.6, and how dedup_hint interacts with siblings. It enriches understanding of parameter contexts, though the schema already has good descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures memories with mandatory provenance. It specifies the core action and resource, and distinguishes from siblings by emphasizing that provenance is required, contrasting with other memory tools. The verb 'capture' and resource 'memories' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance on when to use the tool, including batch vs single item, idempotency behavior, smart defaults, and dedup hints. It implicitly distinguishes from alternatives like memory_import or memory_classify. However, it lacks explicit 'when not to use' statements, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits: handoff capture before closure, dedup, taint scan, response fields, error types with structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long and dense, with many technical details included in a single paragraph. It could be broken into more digestible sentences or bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains return values (handoff_capsule, handoff_deduped) and error types with structured data. It covers all necessary behavioral aspects for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value beyond the schema by explaining that handoff is distilled and goes through audit/dedup, and that summary is optional. This goes well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool closes an open session bracket with optional summary and handoff. It uses specific verbs ('Close', 'captured', 'finish') and distinguishes from siblings like memory_session_start by focusing on closing behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (to close a session with optional handoff) and when not to (unknown or already finished sessions). It does not explicitly compare to alternatives, but the context of sibling tools implies this is the only close tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It extensively details behavioral traits: secure delete, tombstone marker, HMAC fingerprint, effect on memory_get/memory_list/retrieve, re-ingestion rejection, dag repair, and error codes. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very detailed but quite lengthy and dense as a single paragraph. While thoroughness is justified for a destructive operation, it could be more structured (e.g., using bullet points) to improve readability for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of this irreversible operation with two modes and side effects on multiple subsystems, and no output schema, the description is highly complete. It covers all important behavioral aspects and error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining the purpose of each parameter and elaborating on the mode parameter's consequences (e.g., 'Both destroy the content bytes'). This extra context justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Forget a capsule's content IRREVERSIBLY' with a mandatory reason. It distinguishes from sibling tools like memory_get (retrieve) and memory_ingest (create) by specifying irreversible deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (irreversible deletion) and explains the two modes (purged vs redacted) with their implications. It also mentions when re-ingestion is rejected and that forgetting again produces an error, but does not explicitly name alternative tools for non-destructive operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It exhaustively details internal processes: ranking formulas, exclusion mechanics, honest outcomes ('grounded', 'missing_evidence', 'abstain'), and handling of edge cases (CJK scripts, diacritics, forbidden parameters). This level of transparency is exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely verbose (well over 1000 words), containing every conceivable detail. While front-loaded with the purpose, the density of information makes it hard to parse quickly. Conciseness is sacrificed for completeness; a more structured approach (e.g., bullet points) would improve usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (14 parameters, no output schema, multiple edge cases), the description is remarkably thorough. It covers ranking, exclusion, token budgets, and return envelope fields. However, the lack of an output schema means the description must describe results inline, which it does adequately but could be more organized. The overall completeness is high but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds immense value beyond the schema. For example, the 'terms' parameter explains expansion, OR/AND matching, and rejection of punctuation-only terms. 'time_window' pre-ranking behavior, 'weight_blend' re-ranking details, and 'outcome' semantics are all elaborated. The description compensates fully for any schema brevity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Recall stored memories,' a specific verb+resource statement that immediately clarifies the tool's core purpose. It further distinguishes itself from siblings like memory_get (single capsule retrieval) and memory_list (listing) by detailing multi-faceted recall with lanes, fences, and ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance on when to use this tool, including lane selection (auto, term, vector, fused), term expansion strategies, and scope fences (project, session, effort). While it implies alternatives (e.g., memory_get for a single capsule), it does not explicitly contrast with all sibling tools, leaving some ambiguity. Overall, the usage context is clear but could be more comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses normalization, one-way direction, symmetric recall requirement, listing behavior, re-adding as observable no-op, error conditions, and audited nature. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with core purpose, then systematically covers normalization, direction, symmetric recall, listing, errors, and audit. All sentences are informative, though slightly verbose; could tighten without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a tool with no output schema: explains return values (recorded, already_recorded, list rows), all behavioral nuances, and error conditions. No gaps given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with basic descriptions, but the tool description adds critical semantics: normalization, optionality for listing vs recording, non-empty and non-self requirements, and directionality. Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool teaches a synonym pair (term + alias) with normalization, one-way direction, and symmetric recall requirement. It distinguishes from siblings like memory_retrieve (uses aliases) and memory_relate (relations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to record (pass both fields) and when to list (omit both). Describes the one-way direction and need for reverse pair for symmetric recall. Does not explicitly state when not to use but implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: determinism, ranking via terms, capping with exact totals, budget contract with floors, trimming and priority order, and the advisory nature of data. It leaves no major behavioral trait unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is nearly 500 words, making it verbose despite being well-organized into a summary followed by numbered details. It could be shortened while retaining clarity, but the front-loaded purpose and structured sections help readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description compensates thoroughly. It explains all behavioral details, parameter nuances, and edge cases (e.g., token_budget 0, empty sections, budget floors) for a complex tool, making it fully contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description enriches each parameter with precise semantics beyond schema: terms re-rank but never filter, token_budget is a contract with floors and priorities, project_prefix explains hierarchy matching, and project_id is exact fence. This adds substantial value for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a deterministic cold-start pack for a fresh agent, the 'PULL half of the recall loop', and explicitly distinguishes from memory_retrieve. It specifies the five sections in fixed order with clear semantics, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use (before acting, cold-start) and contrasts with memory_retrieve. However, it does not explicitly mention when not to use it versus other siblings like memory_digest or memory_list, which would further strengthen selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavior: it explains deterministic heuristics, verbatim substrings, segmentation rules, noise filters (entity gate, code skipping), kind assignment, and explicitly states nothing is stored. The 'ADVISORY only' note is critical for safe agent use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long (multiple paragraphs) and contains extensive algorithmic details. While necessary for a complex tool, it could be more concise. The front-loading of purpose and key behavior is good, but overall verbosity reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns (candidates with kind and cue) and that 0 candidates is an honest answer. It also covers edge cases (other languages, imperative vs declarative precedence). The tool is well-contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both content and text described). The description adds meaning by explaining that content is the primary blob and text is an alias, and it provides context on how the blob is processed (line-based segmentation, etc.), which goes beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool mines a free-text blob for memory candidates, using a specific verb ('Mine') and resource ('free-text blob'). It distinguishes itself from sibling tools by emphasizing it does not store anything, leaving capture to memory_ingest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (to extract candidates) and directs the caller to memory_ingest for storage. It also notes language limitations (English/Portuguese cues only), but does not explicitly list when not to use or alternative tools beyond ingest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: read-only source access, atomic transaction, dedup by content hash, forget-wins with secure delete, trust handling, and return summary. No contradictions or hidden behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: first sentence provides purpose, then detailed behavioral sections. Every sentence adds value, though slight consolidation could improve conciseness without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers all necessary aspects: parameter, behavior, edge cases, return format, and error conditions. It is fully complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'from' is fully explained in the schema (100% coverage), and the description adds significant meaning: constraints (must exist, schema version), error handling, and read-only guarantee beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool merges a second nMEMORY store into the current one, functioning as an offline-first sync. It specifies the verb 'reconcile' and resource, and implicitly distinguishes from siblings like memory_import or memory_fetch by emphasizing the local store-to-store nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use this tool (merging local stores) and alternatives (separate tool for fetching remote). It also includes prerequisites (source must exist and be at current schema) and error handling guidance (migrate older stores first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: decay exemption, archive skip, ranking behavior, append-only audit, error codes, and the pin flag's visibility on other tools. It explains side effects (state is latest event, no separate delete) and invariants (pin never mutates confidence, never launder taint). The description is exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and front-loaded with the core purpose. While it is lengthy, each sentence provides unique value. Minor redundancy (e.g., 'pin is a WITNESSED, audited act' and later 'Audited (hash-chained journal)') could be tightened, but overall it is well-structured for comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 required params, no output schema, no annotations, 19 siblings), the description is remarkably complete. It covers error responses, interactions with other tools (memory_get/list/digest, memory_retrieve, memory_consolidate), and edge cases (taint, superseded capsules). No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant context: id format ('cap-<n>'), reason must be non-empty and audited, and the pinned parameter's semantic meaning beyond boolean (e.g., 'pin is NEVER eligibility'). This enriches the agent's understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: pin or unpin a capsule to prevent decay and archive, with a specific verb ('Pin') and resource ('ONE capsule'). It distinguishes from siblings like memory_forget and memory_consolidate by explaining what pin does and does not do (e.g., not eligibility). The scope and effect are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool, including constraints like pin never resurrecting fenced capsules and taint dominating pin. It mentions error conditions (unknown id, tombstoned id, empty reason) and the append-only nature. However, it does not explicitly name alternative tools for when pin is inappropriate, though the sibling list implies them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: append-only nature, record mode returns a row with minted id pref-<n>, list mode lists all in append order, audit trail via hash-chained journal, error handling for unknown ids and self-pairs, and advisory nature of responses. All relevant behaviors are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, starting with the core action and then explaining constraints and modes. Every sentence adds value, though the overall length may be slightly more than minimal. The use of ALL CAPS for key points (e.g., PAIRWISE ONLY, APPEND-ONLY) helps highlight important caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose and the absence of an output schema, the description covers all essential aspects: purpose, modes, input requirements, error cases, return values, audit trail, and advisory nature. It is self-contained enough for an AI agent to correctly invoke the tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant context beyond individual parameter descriptions. It clarifies that all four parameters are mandatory together in record mode, that ids must reference existing capsules (with specific error codes), that a self-pair is invalid, and how omission errors are handled. This greatly aids the agent in correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: recording or listing a single pairwise preference-evidence datum. It specifies the verb 'record (or list)' and resource 'pairwise preference-evidence datum'. It explicitly distinguishes from sibling tools by emphasizing 'PAIRWISE ONLY — no score, no ranking, no aggregation beyond the list count' and noting that it is 'EVIDENCE SUBSTRATE' not consumed by recall or ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly defines two modes (record and list) and explains when to use each. It provides context that the tool is for future use ('nothing in nmemory consumes it yet') and that it is append-only with no update/delete. However, it does not directly compare to sibling tools to explicitly guide the agent on when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: deterministic generation, no timestamp, syntax safety, node id handling, read-only advisory nature, and failure modes. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with purpose, but the length is justified given the complexity. Every sentence provides important detail, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, no output schema, and no annotations, the description covers all aspects: view behaviors, parameter constraints, failure modes, determinism, and safety. It leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning: it explains how project_prefix works, allowed views, and edge cases (rejection of invalid prefixes). This enriches understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it renders the store as a deterministic Mermaid diagram, listing four distinct views (dag, relations, tiers, sessions) with specific behaviors. This differentiates it from siblings like memory_digest or memory_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each view and explicitly states that project_prefix only applies to tiers and is rejected for others. It also mentions fail-closed behavior for cycles, but lacks explicit guidance on choosing this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: dry-run default, advisory nature, never auto-teaches, tier moves only applied if explicitly requested, and observable effects on read surfaces. No contradictions; transparency is high.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very verbose and dense, containing multiple long sentences without breaks or lists. While detailed, it could be more concise and structured for easier parsing by an AI agent. It earns its place but at the cost of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (four plan types, taint/expiry rules, interactions with memory_retrieve and memory_alias), the description covers all necessary information, including edge cases like skipping alias teaching for terms with existing taught aliases. It is complete despite lacking an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (apply_tiers). The description adds value by explaining that even when true, merges and dupe repairs remain proposals, which is beyond the schema's boolean description. Rich context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a deterministic consolidation planner over the live store and returns a full plan with four components (exact_dupes, merge_proposals, tier_moves, alias_proposals). It distinguishes from siblings by clarifying that alias proposals are for calling memory_alias, making the purpose very specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states default is dry-run, apply_tiers executes only tier_moves, and merges/dupe repairs are never executed. Provides when-not-to-use (e.g., never auto-teaches aliases) and references memory_alias as the appropriate tool for teaching. Offers clear context on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: returns compact entries, append order, filter effects, project_prefix substring matching with examples, rejection of empty/terminated prefixes, no tombstoned capsules, and advisory data status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded with the core purpose. It packs many details into a single paragraph with parentheticals, making it thorough but slightly hard to scan. Could be broken into clearer sections, but every sentence adds value given complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 optional parameters, no output schema, and no annotations, the description is exceptionally complete. It covers all filters, edge cases (empty prefix rejected), data volume (advisory), and return field semantics. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds significant meaning beyond schema: explains by-kind view for 'kind', subtree matching for 'project_prefix' with edge cases, and composition of filters. However, some schema descriptions already cover the basics, so not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb ('list') and resource ('capsules as compact entries'), detailing the fields returned and the append order. It clearly distinguishes from sibling tools like memory_get (full capsules) and others like memory_digest for tier counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (listing with filters) and when not (tombstoned capsules never appear, use memory_get for full detail). Mentions specific use cases like 'list my open tasks' with kind filter, and explains filter composition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses append-only nature, auditing, advisory authority limitation, mandatory parameter combinations, soft pointer behavior, scoring mechanism with EMA, and error responses. With no annotations, description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but overly verbose; multiple sentences could be combined or shortened. Front-loads main purpose but details could be more tightly organized. Not concise for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completeness is high despite missing output schema: describes return values (minted ID, weight echoes), error cases (missing field, unknown IDs), and the scoring consumption by memory_retrieve. Covers all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds crucial context: mandatory pairs (actor/description, receipt_id/score), 'soft pointer' nature of capsule_id, and return format including minted IDs and weight updates. Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records or lists advisory outcome-observation records. It distinguishes itself from witnessed closes and explains it does not change recall eligibility, differentiating from sibling tools like memory_relate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use record mode vs list mode, warns against using for witnessed closes, and advises using memory_relate for falsifying. Provides clear when-to-use and 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears behavioral disclosure. It details that nmemory computes no embedding, stores one per capsule with replace-on-write, rejects invalid vectors, uses bit-exact storage, and describes error codes. It also explains how vectors interact with retrieval and fences, and that embeddings are advisory, not authority.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but efficiently organized: starts with core purpose, then details put/list, then retrieval interaction, then fences and advisory nature. Every sentence adds value for a complex tool, though some sections could be slightly more compact. Still, it is very well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and high complexity, the description covers all necessary aspects: input semantics, validation, error conditions, behavior under concurrent access, and integration with memory_retrieve. It explains both put and list modes thoroughly, making the tool fully understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning beyond the schema. It explains the alias relationship between id and capsule_id, the mandatory nature of model_tag on put, the meaning of omitting all fields for list, and validates constraints. This enriches the schema substantially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool attaches or lists a caller-fed embedding, clearly distinguishing it from other memory operations by emphasizing that nmemory computes no embedding and that this is a pure sidecar. It explicitly contrasts with memory_retrieve usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (to attach embeddings for vector retrieval), when not to (if no embedding needed), and alternatives (e.g., explicit term ignores stored vectors). It explains the one-embedder-per-store rule, serial requirement for order-sensitive flows, and how retrieval uses stored vectors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/menot-you/n-memory'
If you have feedback or need assistance with the MCP directory API, please join our Discord server