RecallNest

by AliceLJY

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v3.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: batch storage, summarization, debugging, session management, memory lifecycle operations, and various queries. No two tools overlap in function, ensuring an agent can reliably select the correct tool.
Naming Consistency4/5
Most tool names follow the verb_noun pattern (e.g., batch_store, checkpoint_session, export_memory). A few, like memory_stats and data_checkup, use noun_noun but are still descriptive. The overall convention is consistent and predictable.
Tool Count5/5
15 tools is well-scoped for a comprehensive memory management server. It covers storage, retrieval, summarization, session state, and maintenance without being overwhelming.
Completeness4/5
The tool set covers the full memory lifecycle: store, recall, summarize, manage, and forget. A minor gap is the absence of a dedicated raw search tool (search is embedded in distill_memory) and no direct update tool, but pinning and promoting offer partial modification.
Average 4.1/5 across 14 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 196 commits in the last 12 weeks
- Last stable release on August 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it is read-only and does not modify stored memories, which is a key behavioral trait. However, without annotations, it does not disclose other behaviors like auth needs, rate limits, or output structure beyond 'structured briefing with citations'.
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 concise sentences, each adding value: purpose, usage context, and return type plus read-only nature. No fluff.
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 6 parameters (all well-described in schema) and no output schema, the description adequately covers purpose, when to use, and a key behavior (read-only). It lacks comparison to similar tools like 'brief_memory' but is otherwise 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%, so the description adds no extra meaning beyond the schema explanations for parameters like 'query', 'limit', 'scope', etc. Baseline score of 3 applies.
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 clearly states it distills retrieved memories into a compact briefing with source map, key takeaways, and reusable evidence, distinguishing it from raw search results. However, it does not explicitly differentiate from siblings like 'brief_memory' or 'distill_session'.
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 advises using this when a synthesized summary is needed rather than raw search results, but it does not explicitly name alternative tools or specify 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.
Behavior3/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 a side effect ('stores a reminder entry') and explains the auto-trigger mechanism, but lacks details on permissions, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences plus a side-effect note. It is front-loaded with the key purpose and usage, though the side-effect could be integrated more naturally.
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 lack of output schema and annotations, the description adequately explains the core functionality and trigger behavior. However, it does not describe return values or error conditions, which would be helpful for a complete 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%, so the schema already documents all parameters. The description adds no additional meaning beyond repeating 'trigger keywords' and 'action,' so baseline score of 3 applies.
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 clearly states the tool sets a prospective memory reminder that triggers automatically during search_memory calls, distinguishing it from general memory storage tools. The verb 'set' and resource 'prospective memory reminder' 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit usage guidance: 'Use when you need a future nudge tied to a specific context.' It does not mention when not to use or provide alternatives, but the context is clear enough.
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 discloses that messages are normalized and stored via the standard persistMemory pipeline, and that format auto-detection is available. This provides useful process context, though it does not address error handling or side effects, meriting a 4.
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 primary purpose and lists formats efficiently. Every sentence earns its place, with no redundant information, earning a 5.
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 no output schema, and the description does not explain return values or error scenarios, which is a notable gap for an import tool. However, the description does cover the input formats and processing pipeline, so for moderate complexity it scores a 3.
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?
The input schema already provides detailed descriptions for all three parameters, achieving 100% coverage. The description adds minimal semantic value beyond the schema, only mentioning the explicit format parameter and connector spec reference, so the baseline 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 clearly states the tool imports conversation files into memory and lists supported formats. It is specific about the resource and action, but does not explicitly differentiate from siblings like store_memory or batch_store, so it earns a 4.
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 importing conversation files in specific formats but does not explicitly state when to use this tool over alternatives or when not to use it. There are no exclusions or alternative tool mentions, so it scores a 3.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions 'durable memory' and 'reusable across future windows,' implying persistence and cross-session usage. However, it doesn't disclose behaviors like how duplicates are handled (despite canonicalKey in schema), whether the operation is idempotent, or any side effects on existing memory. This is adequate but incomplete for a mutation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and immediate usage guidance. No fluff, no repetition of schema content. Every phrase earns its place.
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 12 parameters including a nested object and enum, but the schema covers their meaning. The description provides solid when-to-use context but omits how a stored case integrates with retrieval or other sibling tools, and doesn't mention output or confirmation. For an agent to invoke correctly, the description plus schema are sufficient, but it lacks deeper system integration context.
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?
The schema has 100% description coverage with detailed parameter descriptions (e.g., scope format, debugFraming dimensions). The tool description adds no extra parameter semantics beyond naming the 'problem-and-solution pair' which maps to problem and solutionSteps. Baseline 3 is appropriate because the schema does the heavy lifting.
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 clearly states the tool stores a 'reusable case as durable memory' and provides concrete examples (debugging fix, continuity cleanup). It has a specific verb and resource, and the examples help distinguish it from vague memory tools. However, it doesn't explicitly differentiate from sibling tools like store_memory or store_workflow_pattern, which also store knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use this when you identify a concrete problem-and-solution pair worth reusing across future windows.' It lists several example scenarios. It doesn't name alternatives or say when not to use it, but the context is clear and actionable.
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?
With no annotations, the description carries the full burden. It conveys that the operation is a non-durable, session-based write, but does not detail idempotency behavior, overwrite semantics, or rate limits. The idempotencyKey parameter implies stability, but this is not described.
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 with no extraneous words. It front-loads the action and immediately follows with usage scenario. Every sentence adds value.
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?
For a tool with 11 parameters and no output schema, the description covers the core purpose and usage context but lacks details on return values, side effects, and idempotency. It is adequate 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%, so the baseline is 3. The description mentions 'decisions, open loops, and next actions' which map to parameters, but adds no significant meaning beyond the schema descriptions. It does not explain parameter relationships or required fields beyond the 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 tool stores a 'compact checkpoint of the current work state' with a specific verb and resource. It distinguishes from sibling memory tools by emphasizing 'without polluting durable memory' and targeting session-spanning use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool when a task spans windows or terminals and the session needs to recover decisions, open loops, and next actions. While it does not list alternatives or when not to use, the context is sufficiently specific to guide appropriate use.
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 are provided, so the description bears full responsibility. It mentions the side effect of writing an export artifact file, which is good, but lacks details on file overwriting, permissions, or other behavioral implications.
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?
Two sentences concisely deliver the action, format, side effect, and use case. No redundant information, perfectly 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?
Given the complexity of 7 parameters and no output schema, the description is minimal. It covers the high-level purpose but lacks explanation of what 'distilled' means or how output is structured. Schema compensates partially.
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%, with each parameter having a clear description. The tool description adds minimal extra meaning beyond 'distilled memory briefing' which is not elaborated. Baseline 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 exports a distilled memory briefing to markdown or JSON, distinguishing it from the sibling 'export_graph' which exports graph data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'when you need an offline-readable snapshot of knowledge on a topic.' It does not explicitly mention when not to use or alternatives, but the purpose is well-defined.
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 are provided, so the description carries full burden. It discloses the side effect of creating a new durable entry linked to the source, but does not detail other behaviors such as whether the original evidence is affected or permissions required.
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 concise sentences with no fluff. The purpose and usage are front-loaded, 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.
Completeness3/5
Given 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 core purpose and side effect but lacks details on return values, error conditions, or behavioral nuances for a tool with 8 parameters.
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 adds minimal extra context beyond schema, mostly restating defaults and purposes. No significant additional meaning.
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 'promote' and the resource 'evidence memory into durable memory', with a side effect. It distinguishes from sibling tools like store_memory by specifying the promotion aspect and authority upgrade.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides when to use: 'when a transcript snippet or imported artifact contains a fact worth keeping across windows'. It implies context but does not mention alternatives or when not to use, missing a point.
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?
With no annotations, the description carries the transparency burden and does disclose that memories are durable and survive future windows. However, it does not mention write semantics, return value, deduplication, overwrite behavior, or any operational effects beyond persistence.
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, front-loaded with the core purpose and immediately followed by a usage exclusion. Every sentence earns its place and there is no redundant filler.
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 schema fully documents parameters, but the description lacks behavioral completion such as return values, error conditions, or how stored memories are later surfaced. For a 13-parameter write tool with no output schema and no annotations, it gives adequate selection guidance but not full operational context.
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?
The input schema has 100% parameter coverage with detailed descriptions for every parameter, so the baseline is 3. The description adds general context about durable memory but provides no parameter-specific meaning beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stores durable memory for stable preferences, identity facts, project entities, reusable patterns, or solved cases, and explicitly contrasts it with transient task state. It is specific about the kind of content and the resource being written, and the exclusion distinguishes it from transient-state tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditions for use ('when the user shares a stable preference...') and a clear when-not ('Do not use this for transient task state'). It does not explicitly name sibling tools like store_case or store_workflow_pattern as alternatives, so the routing guidance is strong but not exhaustive.
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 the full burden. It explicitly discloses the side effect ('persists a new skill entry and indexes it') and the critical non-execution behavior (RecallNest does NOT execute skills). This addresses common misconceptions and provides useful behavioral context beyond a simple 'store' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary action, followed by side effect, usage, and a crucial warning. It is concise and readable, though the trailing version note '(v2.5 收缩，2026-05-27)' is extraneous for an agent.
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?
The tool has 10 parameters and no output schema, but the schema covers all parameters comprehensively. The description adds usage context, side effects, and a non-execution warning, making the overall tool context sufficiently complete for an agent to use it correctly. Some details like duplicate handling or return value are absent, but not critical for a store operation.
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 echoes the non-execution note already present in the implementation parameter schema, but does not add new parameter semantics beyond what the schema provides.
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 clearly states the tool stores an 'agent-readable skill runbook' with trigger conditions, instruction content, and verification steps. This specifies the resource and purpose, but does not explicitly distinguish from sibling tools like store_workflow_pattern or store_case, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear usage context: 'Use when you identify a reusable procedure worth surfacing across sessions.' It does not mention exclusions or direct alternatives, but the provided context is sufficient for an agent to decide when to invoke this tool.
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 provided, the description carries the full burden of behavioral disclosure. It clearly discloses side effects: 'may archive low-value entries and generate new insight memories.' It also signals the mutating nature of the operation through 'prune' and 'consolidate,' which is important behavioral context beyond the input schema.
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 compact: one sentence defines the operation, one sentence covers side effects and when to use it. Every sentence earns its place, and the core action is front-loaded rather than buried in a long explanation.
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?
For a memory-maintenance tool with three fully documented parameters and no output schema, the description covers the essentials: operation, workflow phases, side effects, and usage trigger. It could be more comprehensive by naming related maintenance tools or stating output/return value expectations, but it is sufficient for an agent to invoke the tool correctly.
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%, and the parameter descriptions already document force, scope, and familyMatch well. The tool description does not add additional parameter-level detail, which is acceptable because the schema carries the load, but the description itself contributes no beyond-schema value for parameters.
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 states a specific verb and resource: 'Run a full memory consolidation cycle' with named phases (Orient, Gather, Consolidate, Prune). It clearly describes what the tool does without relying on the name alone, though it does not explicitly differentiate itself from closely related sibling tools like distill_memory or memory_lint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage condition: 'Use when memory count is high and you need periodic maintenance.' This gives the agent actionable context for when to choose this tool, though it does not mention when not to use it or point to alternative lighter-weight maintenance tools such as distill_memory.
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?
With no annotations provided, the description carries the disclosure burden. It explicitly states 'Read-only,' which is a key trait, but does not mention behavior when no checkpoint exists, parameter precedence, or return format. It adds some value but remains sparse.
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?
Two sentences, front-loaded with the core action and scope, followed by a use case. No redundant information or excessive length.
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?
For a simple tool with two optional parameters and no output schema, the description covers the essentials: what it does, when to use it, and that it is read-only. Minor omissions (e.g., behavior with both parameters or no parameters) prevent a 5, but it is largely 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%, with both parameters described with examples. The description only rephrases 'session or shared scope' without adding new meaning beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.
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 states a specific verb ('Fetch'), the resource ('most recent saved checkpoint'), and scope ('for a session or shared scope'), clearly distinguishing it from siblings like checkpoint_session (saves) and resume_context (full resume). It also identifies itself as read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use when you need to inspect current work state without running a full resume_context,' which tells when to use and contrasts with the alternative. It does not detail when to use one parameter over the other, but this is a minor gap.
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?
With no annotations, the description must carry full transparency. It mentions 'durable memory' indicating persistence, but doesn't disclose merge/update behavior via canonicalKey, whether it overwrites, or any other operational details. It adds some context but not rich behavioral detail.
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?
Two sentences, both purposeful. The first explains the core function, the second provides usage context and examples. 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?
For a tool with 10 parameters and no output schema, the description gives solid context (what and when). It lacks details on return values and update semantics, but the examples and clarity make it fairly complete for an agent.
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%, with all 10 parameters having descriptions. The description doesn't add additional parameter meaning beyond what the schema already provides, so baseline 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 with a specific verb ('Store') and resource ('reusable workflow pattern as durable memory'). It differentiates from sibling tools like store_memory or store_skill by focusing on workflow patterns and provides concrete examples (startup continuity, debugging routines).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance on when to use ('when you identify a repeatable process worth reusing across fresh windows') with examples. It doesn't explicitly mention when not to use or name alternatives, but the 'when' is clear and memorable.
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?
Without annotations, the description discloses key behavioral aspects: 'Items that pass salience filtering are stored as durable memories' indicates a write side effect, and 'zero LLM calls' offers performance transparency. However, it does not elaborate on deduplication, error handling, or the impact on existing memories, which keeps it short of a 5.
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, starting with the core action and resource, then listing detected signal types, then stating the storage outcome and usage trigger. Every sentence adds value, and the key information is 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 no output schema and no annotations, so the description should cover return values and edge cases. It explains the storage side effect and usage, but does not mention what the tool returns (e.g., captured items or confirmation) nor behavior when no memory-worthy items are found.
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%, so the baseline is 3. The description's phrase 'analyze a block of conversation text' aligns with the 'text' parameter but adds no extra nuance for 'scope' or 'source' beyond what the schema already provides.
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 specific verb 'Extract' and resource 'memory-worthy items from a conversation turn', clearly stating the tool's function. It lists concrete signal types (preferences, identity facts, decisions, etc.) and highlights the zero-LLM heuristic approach, which distinguishes it from sibling tools like store_memory or distill_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use this when you want to analyze a block of conversation text and automatically capture any signals worth remembering,' providing clear usage context. However, it does not mention when not to use it, nor does it point to any alternative tools, so it lacks exclusionary guidance.
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?
Discloses deduplication and persistence limit of 20 entries. Without annotations, this is helpful. Lacks details on error handling or idempotency, but core behavioral traits are covered.
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?
Two sentences, no wasted words, front-loaded with the main action and key benefit. Ideal length for tool descriptions.
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?
Lacks explanation of return value (e.g., success confirmation or error feedback). Does not mention the required 'scope' parameter, leaving ambiguity about its purpose. For a tool with nested input, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No schema description coverage (0%) and description adds no meaning beyond the schema. Does not explain the purpose of 'scope' or 'source' or the structure of each memory object. Agents would need to infer from names.
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?
Clearly states the tool stores multiple memories with deduplication, distinguishes it from repeated store_memory calls. 'Store multiple memories in a single call' is a specific verb+resource pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'Use when you have several facts to store at once, more efficient than repeated store_memory calls.' Provides clear context and alternative.
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?
No annotations are provided, so the description carries the full burden. It explicitly discloses the side effect: 'writes a new brief asset to disk and indexes it in the vector store for future search.' This is transparent about what the tool does beyond the primary action, though it does not discuss permissions or rate limits.
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 consists of two sentences: the first defines the action and effect, the second gives usage advice and side effects. It is front-loaded with the primary purpose, contains no redundant information, and every sentence serves a clear function.
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 7 parameters, no output schema, and no annotations, the description covers purpose, usage hint, and side effects. However, it does not describe what the tool returns (e.g., asset ID or summary) nor explain interactions between parameters like scope and allScopes. This leaves gaps for an agent trying to invoke the tool correctly.
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?
The input schema has 100% coverage, with descriptions for all 7 parameters. The tool description does not add additional parameter-specific information beyond what the schema provides. According to guidelines, when coverage is >80%, baseline is 3, and the description does not improve upon that.
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 begins with 'Create a structured memory brief by retrieving and summarizing relevant memories, then persist it as a reusable asset indexed for future recall.' This clearly states the verb (create), resource (memory brief), and outcome (persisted asset). It distinguishes from siblings like search_memory (retrieve only) or store_memory (store raw) by specifying consolidation into a single retrievable document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this when you want to consolidate scattered knowledge on a topic into a single retrievable document.' This provides clear context for when to use the tool. However, it does not explicitly state when not to use it or name alternative tools, though the sibling list implies alternatives exist.
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?
No annotations are provided, so the description carries the full burden. It discloses the three-step process (microcompact, LLM summarization into 9 dimensions, extraction to RecallNest) and explicitly notes the side effect of persisting extracted memories. This goes beyond typical descriptions, though it lacks details on return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured and front-loaded with purpose, followed by a breakdown of the three layers, a usage hint, and a side effect note. It is longer than some descriptions, but every sentence adds value and is not repetitive.
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?
The description covers the tool's purpose, process, usage context, and side effects. With no output schema, it does not explain return values, but the tool's primary output is persistence, which is mentioned. It is reasonably complete for a tool of this complexity, though it could detail the 9 dimensions.
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 parameter-specific meaning beyond what the schema already explains; it references the process (e.g., microcompact) but does not elaborate on any parameter semantics.
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 'distill', the resource 'conversation session', and the outcome 'structured knowledge' with persistence to long-term memory. It distinguishes itself from sibling tools like store_memory or distill_memory by naming RecallNest and the three-layer process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage trigger: 'Use when a session is ending or context is getting large.' It does not mention alternatives or when not to use, but the context provided 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only adds 'Read-only' as behavioral context. No details about response size, performance, or idempotency. Adequate but minimal.
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?
Two sentences, front-loaded with key purpose and outputs. No extraneous information. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and a simple aggregate function, the description fully explains input, output, and usage context. Differentiates from many sibling tools effectively.
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?
No parameters exist, so schema coverage is trivially 100%. Baseline 3 is appropriate as description adds no parameter-specific meaning beyond stating the output, which is about results, not inputs.
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 shows aggregate statistics (total entries, counts by source and category). It is distinct from sibling tools like memory_drill_down or search_memory which provide detailed or filtered data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when you need an overview of memory store health or size.' It also declares read-only nature. Could be improved by mentioning limitations or alternatives.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only' and 'matching by semantic similarity,' which are critical for an agent to know the operation has no side effects and how matching works. It does not explain return format or error behavior, but the disclosed traits are essential and clear.
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 only two sentences, front-loaded with the core action, and contains no redundant phrases. Each clause contributes value: the action, the matching mechanism, the read-only safety, and the usage context.
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 no output schema, so the description should clarify what the return value looks like. It says 'skills' but does not state whether a list is returned, relevance scoring, or any result structure. While usage and purpose are well covered, this gap lowers completeness for a retrieval 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?
The input schema provides thorough descriptions for all three parameters (query, limit, scope), covering semantics, defaults, and constraints. The description adds no additional parameter-level meaning beyond the schema, so the baseline 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 specifies the tool's function: 'Retrieve executable skills matching a task description by semantic similarity.' This is a specific verb+resource+mechanism that distinguishes it from siblings like search_memory (knowledge recall) and store_skill (storing procedures). The phrase 'executable skills' and 'not just recall knowledge' further set it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use when you need a stored procedure to act on, not just recall knowledge.' This tells the agent when to use this tool and differentiates it from knowledge retrieval, though it does not name an alternative tool explicitly. It implies the alternative but lacks a direct sibling reference.
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?
The description declares 'Read-only,' which is essential for behavior understanding. It explains what aspects are analyzed (retrieval path, freshness, etc.). Without annotations, the description carries the burden, and it adequately discloses that no modifications occur. However, it could mention that the tool does not alter memory state.
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 concise sentences: the first explains purpose and output, the second provides usage guidance. Every sentence adds 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 7 parameters and good schema descriptions, the description covers purpose, usage context, and read-only nature. It mentions what the explanation includes (retrieval path, freshness, etc.), but without an output schema, it does not detail the exact return format. Still, it is largely complete for an explainer 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?
All 7 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description does not add additional meaning beyond the schema; it provides a high-level overview without elaborating on parameter interactions.
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: 'Explain why memories matched a query: retrieval path, freshness, scope, and matched terms.' The verb 'explain' and resource 'memories matched a query' are specific. It distinguishes from sibling tools like search_memory by focusing on explanation rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: 'Use when search results seem unexpected and you need to debug ranking or scope filtering.' This provides clear guidance, though it does not explicitly name alternatives or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the tool 'creates a self-contained HTML file with a force-directed visualization' and that the file can be 'opened in any browser.' This transparently conveys that the tool produces a file artifact without modifying memory. While it doesn't explicitly state it is read-only, the export nature implies non-destructiveness, which is adequate.
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, each contributing essential information: what it does, what it produces, and when to use it. There is no redundancy or filler, and the most important information is front-loaded.
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?
The description is complete for a simple export tool with two optional parameters. It covers the output format, usability in a browser, and the intended use case. It doesn't mention how the file is delivered (e.g., file path) or how scope/maxNodes affect the result, but these are covered by the schema and the tool's simple nature, so it is sufficiently 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 description coverage is 100%, with both parameters (scope and maxNodes) already described in the schema. The description adds no additional meaning about how these parameters affect the graph output, so it does not exceed the baseline. The schema already provides the necessary semantics.
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 function: 'Export memories as an interactive HTML knowledge graph.' It specifies the verb (export), resource (memories), and output format (interactive HTML graph), distinguishing it from sibling tools like export_memory. The added use case 'Use when the user wants to visualize their memory network' further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case: 'Use when the user wants to visualize their memory network.' This gives clear context for when to invoke the tool. However, it does not mention when not to use it or mention alternatives among sibling tools, such as export_memory, so it falls short of a 5.
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?
Without annotations, the description discloses key behavioral traits: permanence, cascade effects (deletion, KG removal, demotion, audit), and the confirmation requirement for durable-tier memories. It covers the essential destructive nature but omits details on error handling or idempotency.
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?
Three concise sentences with no wasted words. The action is front-loaded; the second sentence adds a critical condition; the third provides usage context. Every sentence earns its place.
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 no output schema or annotations, the description sufficiently covers the tool's purpose, cascade behavior, and usage. It lacks details on return values or failure modes, but the core functionality is well explained.
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?
All parameters are fully described in the schema (100% coverage), so the description adds no new information beyond restating the confirmation behavior for durable-tier memories already present in the 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 specifies a clear verb ('forget') and resource ('memory') with a detailed cascade of actions (delete primary entry, remove KG triples, demote related memories, log audit trail). It distinguishes itself from sibling tools like store_memory or search_memory by describing a unique destructive operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage scenarios: 'when the user explicitly requests a memory be forgotten, or to clean up sensitive/incorrect data.' While it doesn't list negative cases or alternatives, the guidance is clear and directly applicable.
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?
The description states 'Read-only,' which is a behavioral trait. Since no annotations are provided, this is helpful. However, it does not disclose other behaviors such as error handling for invalid IDs, output format details, or performance characteristics. For a simple read operation, this level is adequate but not rich.
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 concise sentences, front-loaded with the primary action and resource, then a clear usage directive. Every clause earns its place with no redundancy.
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?
The tool has no output schema, so the description carries the burden of explaining return values. It states the content level ('full or overview-level') and the context (search summaries), which is sufficient for a simple retrieval. It does not elaborate on edge cases, but for this low-complexity tool, it is adequately 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?
Schema coverage is 100% with descriptions for both 'id' and 'level'. The description adds meaning by explaining 'full' as L2 and 'overview' as L1, which maps directly to the enum values. It also clarifies the tool's purpose relative to search results, adding context beyond the 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 action (Retrieve), the resource (a single memory entry), and the scope (full or overview-level content). It also distinguishes itself from sibling tools like search_memory by explicitly noting it retrieves complete text or L1 overview rather than compact summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific use case: 'Use when search returned compact summaries and you need the complete text or L1 overview.' This gives clear context for when to invoke the tool, but it does not explicitly mention when not to use it or name alternative tools as exclusions.
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 provided, the description correctly carries the safety disclosure by stating 'Read-only.' It also discloses the high-level behavior (runs lint checks, returns a health score and actionable findings). This is adequate for a non-destructive tool, though it could detail whether findings are summaries or individual entries (the verbose parameter hints at this).
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, front-loads the action and purpose, and provides value in every clause. No padding or redundant restatement of the tool name. It earns perfect marks for conciseness.
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?
The description is complete for a simple read-only tool with no output schema: it states the return value (health score 0-100 and actionable findings) and outlines its primary use cases. It does not overspecify but covers the essentials needed for an agent to call it correctly.
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?
The input schema already provides full descriptions for both parameters (scope as an optional filter, verbose as a boolean toggling individual findings). The description does not add further semantic detail beyond the schema, so the baseline of 3 is appropriate given 100% schema coverage.
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 opens with a specific verb 'Run' and resource 'memory quality lint checks', then enumerates the exact checks (contradictions, duplicates, stale entries, orphans). This clearly distinguishes it from sibling tools like memory_stats (stats) and data_checkup (data integrity), making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use for periodic memory hygiene or before consolidation.' This tells the agent when to invoke it. It does not explicitly state when not to use it or name alternatives, but the guidance is sufficient for a focused linting tool.
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?
Discloses side effects: boosts importance to 0.95, writes pin asset file, indexes it. With no annotations, the description carries full responsibility and covers key behavioral impacts. Could mention if pinning makes a memory non-deletable, but current detail is sufficient.
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?
Two sentences, zero wasted words. First sentence defines action and side effects; second sentence states when to use. Information is front-loaded and efficient.
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?
Covers purpose, usage, and side effects. No output schema exists, but return value is not critical. Missing edge cases like memory not found or duplicate pinning, but overall adequate for agent invocation.
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% with descriptions for all 8 parameters. The tool description adds no extra meaning beyond what the schema already provides, so baseline 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 action ('Pin a retrieved memory'), the resulting state ('high-importance reusable asset'), and the specific side effects (boosts importance to 0.95, writes asset file, indexes it). It distinguishes this tool from siblings like 'list_pins' and 'store_memory' by focusing on pinning an existing memory for future recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Use when a search result is critical and should be surfaced in future recalls,' providing clear context. Does not mention when not to use or alternative tools, but guidance is direct and actionable.
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 the burden. It states 'Read-only' which discloses a key behavioral trait. No other side effects are mentioned, but for a read-only composition tool, this is adequate.
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?
Three short sentences with no fluff. Each sentence adds value: purpose, read-only flag, usage context. Front-loaded and efficient.
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?
For a tool with 7 optional parameters and no output schema, the description covers purpose and usage well. It does not describe the return format, but the tool's nature suggests a composed context summary, which is implicit.
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%, so baseline is 3. The description adds little beyond schema: it mentions components but does not elaborate on parameters like task, scope, or mode. No additional semantic value.
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 composes startup context from durable memory, patterns, cases, and checkpoint, and explicitly says it is read-only. It distinguishes from siblings by specifying its use for session recovery, not storage or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use when entering a new session and you need to recover prior decisions, open loops, and next actions,' providing clear usage context. It does not explicitly list alternatives or when not to use, but the context 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?
Declares 'Read-only' which is key for a non-destructive tool. Discloses sorting by creation date. With no annotations provided, description covers essential behavioral traits adequately, though could mention pagination or rate limits.
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?
Description is very concise with four short sentences, each adding unique value: verb+resource, read-only, usage guidance, and return fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), description fully explains what is returned (asset type, title, scope, creation date, file path) and provides usage context. No gaps.
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. Description adds context like 'recent' and 'sorted by creation date' but does not substantially add meaning beyond what the schema already provides for the 'limit' 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?
Description clearly states verb (List), resource (structured memory assets) with specific types (pinned memories and distilled briefs), and sorting order. Differentiates from sibling 'list_pins' by including both pins and distillations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: for inventory of knowledge artifacts, with example of avoiding duplicates before creating a brief. Lacks explicit when-not or alternative tool mentions, but context is clear.
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 the full burden. It explicitly states 'Read-only,' disclosing the safety profile. It also mentions the filtering behavior by tier. This is sufficient for a simple listing 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no wasted words. It efficiently conveys purpose and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers all essential aspects: purpose, read-only safety, usage context, and filtering. It is complete for the tool's complexity.
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% with the 'tier' parameter fully described (enum, default, and explanation). The description's 'filtered by tier' adds no new information beyond the schema, so baseline 3 applies.
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 'List available RecallNest tools with one-line descriptions, filtered by tier' with a specific verb and resource. It distinguishes from sibling tools like list_assets and list_pins by focusing on tools rather than other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Use when you need to discover advanced or governance tools beyond the core set.' This provides clear context on when to use the tool, though it does not explicitly name alternatives (e.g., list_assets) or list exclusions.
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 the full burden and excels: it discloses the important caveat that the score is a fused ranking score, not cosine similarity, and that the tool is read-only but may fire stored reminders as a side effect. These are non-obvious behavioral traits that materially affect interpretation and safety.
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, each earning its place: the first defines the core operation, the second clarifies output semantics, and the third covers side effects and usage timing. It is front-loaded and free of 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?
For an 18-parameter tool with no output schema, the description gives essential high-level context: hybrid retrieval, ranked results, score interpretation, side effects, and recommended usage scenarios. However, it does not describe the return format or pagination behavior, which would be helpful given the tool's complexity, but the extensive schema compensates for most gaps.
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 adds only general context about hybrid relevance and temporal filtering, but does not explain specific parameters beyond what the schema already provides. It neither detracts from nor significantly enhances the schema's parameter documentation.
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 searches indexed memories using hybrid relevance (vector + BM25 + reranking) and returns ranked results with temporal filtering. This distinguishes it from siblings like store_memory, auto_capture, and memory_drill_down by naming the specific retrieval behavior and output shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides concrete guidance on when to use the tool: proactively at task start, when debugging, writing, or when the user references past work. It does not explicitly mention when not to use it or name alternative tools, so it stops short of the full exclusionary guidance that would earn a 5.
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?
The description explicitly states 'Read-only', which is a key behavioral trait in the absence of annotations. It also mentions sorting order. While more details (e.g., pagination) could be added, the essential safety information is present.
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?
Two sentences, no redundant words, front-loads the core purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description adequately covers purpose, usage, and behavior. No missing critical information.
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?
The schema already provides comprehensive documentation for the single 'limit' parameter (description, default, min, max). The description adds no additional param-specific information, so baseline 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 verb 'list', the resource 'pinned memory assets', and includes details like sorting by creation date and displayed fields. It effectively distinguishes from sibling tools like pin_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'review high-value memories' or 'check if a topic already has a pinned reference before creating a new one.' This provides clear guidance and implicitly advises against misuse.
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 explicitly states the tool is read-only and lists the checks performed. However, it does not describe the output format or error handling, but the read-only nature is clearly communicated.
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, concise, front-loaded with the action, and contains no redundant information. Every part adds value.
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?
The description covers purpose, usage, and read-only nature. It lacks details about output format or how results are presented, but for a health-check tool with no output schema, this is acceptable. Could be slightly more 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?
The tool has no parameters, so the description naturally does not add parameter semantics. Baseline for zero-parameter tools is 4, and the description is sufficient.
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 clearly states the tool runs health checks on the memory database, listing specific aspects (vector dimensions, orphans, tier distribution, conflict backlog) and explicitly indicates it's read-only. This distinguishes it from mutation tools like batch_store or forget_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly states when to use: 'diagnosing data quality issues or before a consolidation run,' and notes it is read-only, providing clear guidance on appropriate contexts.
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:

[![recallnest MCP server](https://glama.ai/mcp/servers/AliceLJY/recallnest/badges/card.svg)](https://glama.ai/mcp/servers/AliceLJY/recallnest)

Score Badge

Copy to your README.md:

[![recallnest MCP server](https://glama.ai/mcp/servers/AliceLJY/recallnest/badges/score.svg)](https://glama.ai/mcp/servers/AliceLJY/recallnest)

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/AliceLJY/recallnest'

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