Memory MCP Server

by win10ogod

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific memory types (long-term vs. short-term) or operations (add, delete, search, backup), but some overlap exists: 'search_memories' and 'search_short_term_memories' could be confused, and 'get_metrics' and 'health_check' both relate to performance monitoring. Descriptions help clarify, but boundaries are not perfectly clear.
Naming Consistency3/5
The naming is mixed with no consistent pattern: some use verb_noun (e.g., 'add_long_term_memory', 'delete_short_term_memories'), others use noun_verb (e.g., 'health_check'), and there's a mix of English and Chinese names. While readable, the conventions vary significantly across the tool set.
Tool Count4/5
With 21 tools, the count is slightly high but reasonable for a memory management server covering operations like CRUD, search, backup, and analytics. It feels comprehensive without being overly bloated, though it could be streamlined by merging some overlapping tools.
Completeness5/5
The tool set provides complete coverage for memory management: CRUD operations for both long-term and short-term memories, search functionalities, backup/restore, cleanup, and analytics (e.g., stats, patterns). No obvious gaps exist; agents can handle the full lifecycle of memories effectively.
Average 3/5 across 21 of 21 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under BSD 3-Clause.
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.
Add a glama.json file to provide metadata about your server.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the trigger mechanism and available context/functions, which is helpful. However, it doesn't address critical behavioral aspects: whether this operation is idempotent, what permissions are required, how errors are handled, or what happens on success (e.g., confirmation message). For a creation tool with zero annotation coverage, this leaves significant gaps.
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 appropriately concise with two sentences. The first sentence states the core purpose, and the second provides technical details about the trigger. There's no wasted text, though it could be slightly more front-loaded with key behavioral information given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creating a persistent memory with custom JavaScript triggers), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how to verify success, error conditions, or the implications of adding a memory (e.g., storage limits, trigger evaluation frequency). For a 6-parameter creation tool with behavioral nuances, this is inadequate.
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 6 parameters thoroughly. The description adds minimal value beyond the schema: it mentions the trigger is 'JavaScript code' and lists available context/functions, which the schema's trigger description also covers with an example. This meets the baseline of 3 when 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's purpose: 'Add a new long-term memory with a trigger condition.' It specifies the verb ('Add'), resource ('long-term memory'), and key mechanism ('trigger condition'), distinguishing it from siblings like 'update_long_term_memory' or 'delete_long_term_memory'. However, it doesn't explicitly differentiate from 'add_short_term_memory' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the trigger condition but doesn't explain when to choose long-term over short-term memory, when to use this versus 'update_long_term_memory', or any prerequisites. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions providing 'statistical information and insights', but doesn't specify what kind of statistics (e.g., frequency, trends), how insights are generated, whether it's a read-only operation, potential performance impacts, or error conditions. For an analysis tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: a single sentence in Chinese that directly states the tool's function. There's no wasted verbiage or unnecessary elaboration, making it efficient and easy to parse. Every word contributes to understanding the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analyzing memory patterns with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like read/write nature, return format, or error handling, and it fails to differentiate from similar sibling tools. For a tool that likely provides detailed analysis results, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters (conversation_id, memory_type, top_keywords) with descriptions and defaults. The description adds no additional meaning beyond the schema, such as explaining the purpose of analyzing patterns or how parameters affect the analysis. Baseline 3 is appropriate when the schema handles parameter documentation adequately.
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's purpose: '分析記憶使用模式，提供統計信息和洞察' (analyze memory usage patterns, provide statistical information and insights). It specifies the verb 'analyze' and the resource 'memory usage patterns', which is distinct from sibling tools that focus on adding, deleting, searching, or managing memories. However, it doesn't explicitly differentiate from similar analysis tools like 'get_memory_stats' or 'get_metrics', which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_memory_stats', 'get_metrics', and 'get_cache_stats' that might overlap in functionality, there's no indication of specific contexts, prerequisites, or exclusions. Usage is implied only by the tool's name and description, lacking explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While '刪除' clearly indicates a destructive operation, it doesn't specify whether the deletion is permanent or reversible, what permissions are required, whether there are confirmation prompts, or what happens on success/failure. For a destructive tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core action and resource, making it efficient and easy to parse.
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?
For a destructive operation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, what errors might occur, or important behavioral aspects like whether deletions are permanent. Given the complexity and risk profile of a delete operation, more context is needed.
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 description coverage is 100%, with the single parameter 'backup_path' clearly documented in the schema as '備份文件路徑' (backup file path). The description adds no additional semantic context about the parameter beyond what's already in the schema, so it meets the baseline score of 3 when schema coverage is high.
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 action ('刪除' meaning delete) and the resource ('指定的備份文件' meaning specified backup file), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'delete_long_term_memory' or 'delete_short_term_memories', which also perform deletion operations on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing to identify a backup first), when not to use it, or how it relates to sibling tools like 'list_backups' (to find backups) or 'restore_memories' (which might involve backups).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a memory, implying a destructive operation, but doesn't cover critical aspects like whether deletion is permanent, requires specific permissions, has side effects (e.g., on related data), or returns confirmation details. This leaves significant gaps 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?
The description is a single, direct sentence with zero wasted words, making it highly efficient and front-loaded. Every word contributes to the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a destructive operation with no annotations and no output schema, the description is insufficient. It doesn't explain the deletion behavior (e.g., permanence, effects), return values, or error handling, leaving the agent with incomplete information for safe and effective use.
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 fully documents both parameters ('name' and 'conversation_id') with clear descriptions. The description adds no additional semantic context beyond implying the 'name' parameter is used for deletion, which is already covered by the schema. This meets the baseline for high schema coverage.
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 action ('Delete') and resource ('a long-term memory by name'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'delete_short_term_memories' or 'cleanup_memories', which would require mentioning the specific memory type or deletion method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'delete_short_term_memories' or 'cleanup_memories'. It lacks context about prerequisites, such as needing the memory name, or exclusions, like whether it works for all memory types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the deletion action but doesn't cover important aspects like whether deletion is permanent/reversible, what permissions are required, rate limits, or what happens to matched memories. The description is minimal and lacks behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized for a simple deletion operation and front-loads the essential information.
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?
For a destructive deletion tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'short-term memories' are in this context, what the deletion consequences are, or what the tool returns. The description leaves too many open questions about this potentially destructive 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 schema already fully documents both parameters. The description mentions 'keyword or regex pattern' which aligns with the schema's pattern parameter description, but adds no additional semantic context beyond what's already in the structured schema fields.
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 action (delete) and resource (short-term memories) with the specific matching mechanism (keyword or regex pattern). It distinguishes from siblings like 'delete_long_term_memory' by specifying the memory type, though it doesn't explicitly contrast with other deletion tools like 'cleanup_memories' or 'delete_backup'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when deletion is appropriate, what happens after deletion, or how it differs from similar tools like 'cleanup_memories' or 'delete_long_term_memory' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While '獲取' (get) implies a read operation, the description doesn't specify whether this requires special permissions, whether it returns real-time or historical data, what format the statistics come in, or whether there are rate limits. For a statistical retrieval tool with zero annotation coverage, this represents significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase that communicates the core function without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information. Every character earns its place in this minimal but complete phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's statistical nature and lack of both annotations and output schema, the description is insufficiently complete. It doesn't explain what kind of statistics are returned (hit rates, size, eviction metrics), whether the data is aggregated or detailed, or what format the output takes. For a statistical tool in a memory/cache system context, more detail about the nature of the statistics would be helpful.
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 zero parameters, and schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to explain any parameters, and the baseline for zero-parameter tools is 4. The description appropriately doesn't mention parameters since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '獲取查詢緩存統計信息' (Get query cache statistics) clearly states the verb ('獲取' - get) and resource ('查詢緩存統計信息' - query cache statistics), establishing the tool's basic purpose. However, it doesn't differentiate from sibling tools like 'get_memory_stats' or 'get_metrics' that also retrieve statistical information, leaving ambiguity about when this specific cache-focused tool should be used versus other stat-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that retrieve statistics (get_memory_stats, get_metrics), there's no indication of what makes this cache-specific tool distinct or when it should be preferred over other statistical retrieval tools. The description offers only the basic function without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool retrieves context (creation and update details), implying a read-only operation, but doesn't disclose critical behavioral traits such as authentication requirements, rate limits, error conditions, or what 'context' entails (e.g., timestamps, metadata). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('Get') and resource, making it easy to parse. Every part of the sentence earns its place by conveying essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of memory management tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'context' includes (e.g., timestamps, user info), how results are formatted, or potential errors. For a tool in a rich sibling set with no structured behavioral data, more detail is needed to ensure the agent can use 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 has 100% description coverage, with clear documentation for both parameters ('name' and 'conversation_id'). The description doesn't add any additional meaning beyond the schema, such as explaining parameter interactions or constraints. According to the rules, with high schema coverage (>80%), the baseline is 3 even without extra param info in the description, which fits here.
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's purpose: 'Get the creation and update context of a specific long-term memory.' It specifies the verb ('Get') and resource ('creation and update context of a specific long-term memory'), which is clear and actionable. However, it doesn't explicitly differentiate from sibling tools like 'get_memory_stats' or 'list_long_term_memories', which could provide overlapping or related information, so it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_long_term_memories' for browsing memories or 'search_long_term_memories' for finding memories by criteria, nor does it specify prerequisites or exclusions. This lack of context leaves the agent to infer usage, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool retrieves statistical information, implying a read-only operation, but doesn't specify what statistics are included, format of return data, performance characteristics, or any side effects. For a stats tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by clearly stating the action and target, making it easy to parse quickly. There is no redundancy or structural issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns complex statistical data. It doesn't explain what statistics are provided, their format, or how the optional parameter affects results. For a stats tool in a memory management context with many siblings, more detail is needed to ensure proper use without confusion.
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% description coverage, with the single parameter 'conversation_id' documented as optional for context. The description adds no additional parameter information beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 verb ('Get') and resource ('statistical information about short-term memories'), making the purpose immediately understandable. It distinguishes from siblings like 'get_cache_stats' or 'get_metrics' by specifying the memory type. However, it doesn't explicitly differentiate from 'analyze_memory_patterns' which might also involve statistics, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_cache_stats', 'get_metrics', and 'analyze_memory_patterns' that might overlap in statistical reporting, there is no indication of context, prerequisites, or exclusions. The optional 'conversation_id' parameter hints at filtering but offers no usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While '獲取' (get) implies a read operation, it doesn't disclose important behavioral aspects: whether this requires authentication, what format the metrics are returned in, if there are rate limits, whether it's real-time or historical data, or what happens if the server is unavailable. For a monitoring tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase that communicates the core purpose without unnecessary words. It's appropriately sized for a simple tool and front-loads the essential information. Every character earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a performance monitoring tool with no annotations and no output schema, the description is incomplete. It doesn't explain what metrics are returned, in what format, or how to interpret them. With 18 sibling tools including similar 'get_' operations, more context about this tool's specific domain (server vs memory vs cache metrics) would be helpful for an agent to use it correctly.
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 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to explain parameters since none exist, and it correctly doesn't mention any. This meets expectations for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '獲取服務器性能指標' (Get server performance metrics) states a clear verb ('獲取' - get) and resource ('服務器性能指標' - server performance metrics), but it's vague about scope and doesn't differentiate from sibling tools like 'get_cache_stats' or 'get_memory_stats'. It provides basic purpose but lacks specificity about what metrics are included or how this differs from other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that retrieve different types of data (cache stats, memory stats, health check), there's no indication of when server performance metrics are appropriate versus other monitoring tools. No prerequisites, exclusions, or complementary tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states what the tool does but doesn't describe behavioral traits such as whether it's read-only, requires authentication, has rate limits, what the output format looks like, or any side effects. For a monitoring tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence in Chinese that directly states the tool's purpose without any fluff. It's front-loaded with the core functionality and wastes no words. Every part of the sentence earns its place by specifying what is being retrieved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a health check tool (which could involve various metrics and states), the description is incomplete. There's no output schema, and the description doesn't explain what health status or performance metrics are returned, their format, or any behavioral context. Without annotations and with only a basic parameter, the description should do more to guide usage and expectations.
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% description coverage (the 'detailed' parameter is fully documented in the schema with type, default, and description). The description doesn't add any parameter semantics beyond what the schema provides, but since schema coverage is high, the baseline score of 3 is appropriate. The description doesn't compensate for any gaps because there are none.
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's purpose: '獲取服務器健康狀態和性能指標' (Get server health status and performance metrics). It specifies the verb ('獲取' - get) and resource ('服務器健康狀態和性能指標' - server health status and performance metrics). However, it doesn't explicitly differentiate from sibling tools like 'get_metrics' or 'get_cache_stats', which appear related but may have different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are several sibling tools that seem related (e.g., 'get_metrics', 'get_cache_stats'), but the description doesn't indicate whether this is for general server health, specific subsystems, or how it differs from other monitoring tools. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool lists backup files but doesn't describe the return format (e.g., list structure, file details), pagination, error handling, or any constraints like rate limits or permissions. This leaves significant gaps for a tool that likely interacts with file systems.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('列出可用的備份文件') that directly states the tool's purpose. It's front-loaded with no wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'available backup files' means in practice (e.g., format, metadata), how results are returned, or any behavioral nuances. For a tool with two parameters and no structured output, more context is needed to guide effective use.
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 ('backup_dir' and 'conversation_id') well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
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 action (list) and resource (backup files) in Chinese. It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'backup_memories' or 'restore_memories' beyond the basic verb-noun pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'delete_backup' or 'restore_memories', nor does it specify prerequisites or contexts for usage. The agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'List all' implies a read-only operation, it doesn't specify whether this tool is paginated, what 'basic information' includes, or any performance characteristics like rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the tool's purpose without unnecessary words. It's appropriately sized for a simple list operation and front-loads the essential information, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context about what 'basic information' includes and the tool's behavior. For a list operation among many memory-related tools, this minimal description leaves the agent with insufficient information to understand the full context of use.
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% description coverage, with the single parameter 'conversation_id' clearly documented in the schema. The description doesn't add any parameter semantics beyond what the schema already provides, so it meets the baseline score of 3 for adequate but not additive parameter information.
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 action ('List') and resource ('long-term memory names and their basic information'), making the tool's purpose immediately understandable. However, it doesn't differentiate itself from sibling tools like 'search_long_term_memories' or 'list_backups', which reduces its effectiveness in helping an agent choose between similar list/search operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_long_term_memories' or 'list_backups'. It doesn't mention any prerequisites, constraints, or typical use cases, leaving the agent with insufficient context to make an informed selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns activated memories (whose triggers evaluated to true) and random memories for serendipity,' which provides some insight into the return behavior. However, it doesn't address important aspects like whether this is a read-only operation, potential side effects, performance characteristics, or error conditions. For a search tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two clear sentences. The first sentence states the core functionality, and the second explains the return behavior. There's no unnecessary verbiage, and the information is front-loaded with the primary purpose stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of memory search operations, no annotations, and no output schema, the description is incomplete. It doesn't explain what format the memories are returned in, how many memories are returned, whether there's pagination, or what constitutes 'relevant' versus 'random' memories. For a tool with 3 parameters (including a nested object) and no structured output documentation, the description should provide more 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 description provides no information about parameters beyond what's already in the schema. Since schema description coverage is 100% (all parameters have descriptions), the baseline score is 3. The description doesn't add any additional context about how parameters should be used or their significance in the search process.
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's purpose: 'Search and activate relevant long-term memories based on current conversation context.' It specifies the verb ('search and activate'), resource ('long-term memories'), and context ('current conversation context'). However, it doesn't explicitly differentiate from sibling tools like 'search_memories' or 'search_short_term_memories', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling search tools (search_memories, search_short_term_memories), there's no indication of when this specific long-term memory search is appropriate versus other search options. The description only states what the tool does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering capabilities but doesn't describe important behavioral aspects like whether this is a read-only operation, what permissions are required, how results are returned (format, pagination), or any rate limits. The phrase '高级过滤条件' (advanced filtering conditions) is vague and doesn't provide concrete behavioral information.
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 a single, efficient sentence that states the core purpose and mentions key filtering capabilities. It's appropriately concise and front-loaded with the main function. However, it could be slightly more structured by explicitly listing the main filter types rather than using '等' (etc.).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no annotations, no output schema) and the presence of similar sibling tools, the description is insufficient. It doesn't explain how this tool differs from search_long_term_memories and search_short_term_memories, doesn't describe the return format or behavior, and provides minimal guidance for a tool with many filtering options. For a search tool with this many parameters, more context is needed.
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 description mentions '关键词、时间范围、分数过滤等' (keywords, time range, score filtering, etc.), which maps to some parameters (query/keywords, date_from/date_to, min_score/max_score). However, with 100% schema description coverage, the schema already documents all 11 parameters thoroughly. The description adds minimal value beyond what's already in the schema, meeting the baseline for high schema coverage.
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's purpose: '搜索记忆' (search memories) with '高级过滤条件' (advanced filtering conditions). It specifies the action (search) and resource (memories) but doesn't explicitly differentiate from sibling tools like search_long_term_memories or search_short_term_memories, which appear to be more specific versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions '支持关键词、时间范围、分数过滤等' (supports keywords, time range, score filtering, etc.), which implies some usage context but doesn't provide explicit guidance on when to use this tool versus the more specific sibling tools (search_long_term_memories, search_short_term_memories). No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but lacks details on permissions, side effects, error conditions, or response format. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and lists updatable elements without unnecessary words. Every part earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks behavioral context (e.g., what happens on success/failure), usage prerequisites, and differentiation from siblings, making it inadequate for safe and effective tool 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 description coverage is 100%, so the schema fully documents all 6 parameters. The description mentions 'trigger condition, prompt content, or add update context,' which loosely maps to parameters like 'trigger,' 'prompt,' and 'updatedContext,' but adds no significant meaning beyond what the schema already 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 action ('Update') and resource ('existing long-term memory'), and specifies what can be updated (trigger condition, prompt content, or context). However, it doesn't explicitly differentiate from sibling tools like 'add_long_term_memory' or 'delete_long_term_memory' beyond the update action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing memory), exclusions, or comparisons to siblings like 'add_long_term_memory' for creation or 'delete_long_term_memory' for removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that memories are 'indexed by keywords and scored based on relevance over time,' which adds some context about processing behavior. However, it fails to address critical aspects such as whether this is a read-only or mutative operation, potential side effects, error conditions, or how the memory is stored and accessed. For a tool that likely involves data creation with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured in two sentences. The first sentence clearly states the purpose, and the second adds useful behavioral context without redundancy. Every sentence earns its place, making it efficient and front-loaded with essential information.
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 tool's complexity (involving memory creation with multiple parameters and no output schema), the description is moderately complete. It covers the basic purpose and some processing behavior but lacks details on usage guidelines, error handling, and output expectations. Without annotations or an output schema, the description should do more to compensate, but it provides a minimal viable explanation.
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% description coverage, providing clear documentation for all parameters. The description adds minimal value beyond the schema, as it only implies that 'messages' are used to 'create memory' without detailing how parameters interact or their semantic roles. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
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's purpose: 'Add a new short-term memory entry from recent conversation messages.' It specifies the verb ('Add') and resource ('short-term memory entry'), and distinguishes it from siblings like 'add_long_term_memory' by specifying 'short-term.' However, it doesn't explicitly differentiate from other memory-related tools like 'search_short_term_memories' or 'delete_short_term_memories,' which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'add_short_term_memory' over 'add_long_term_memory' or other sibling tools, nor does it specify prerequisites or exclusions. This lack of contextual usage advice limits its effectiveness for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states what the tool does but lacks critical details: it doesn't specify if this is a read-only operation (likely, but not confirmed), how it determines frequency (e.g., based on memory content or metadata), what happens if no conversations exist (e.g., returns null or error), or any rate limits. The description is minimal and leaves behavioral traits ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with no wasted words. It is appropriately sized for a simple tool and front-loaded with the core functionality. Every part of the sentence earns its place by specifying the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple query) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the return value is (e.g., a single ID, a list with counts, or an error message), how frequency is calculated, or any dependencies on memory state. For a tool with no structured output documentation, the description should provide more context about the result.
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 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. No additional parameter context is required or provided.
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's purpose: 'Get the most frequently mentioned conversation ID in memories.' It specifies the verb ('Get') and resource ('conversation ID'), and distinguishes it from siblings by focusing on frequency analysis rather than listing, searching, or managing memories. However, it doesn't explicitly differentiate from all siblings (e.g., 'analyze_memory_patterns' might overlap in analysis).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing existing memories), exclusions (e.g., when no conversations exist), or comparisons to siblings like 'get_memory_stats' or 'analyze_memory_patterns'. Usage is implied only by the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions the return structure ('top relevant, next relevant, and random flashback memories') which is helpful, but doesn't disclose behavioral traits like whether this is a read-only operation, performance characteristics, error conditions, or how relevance is determined. The description adds some value but leaves significant gaps.
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 efficiently structured in two sentences that cover purpose and return values. It's appropriately sized without unnecessary elaboration, though it could be slightly more specific about the search mechanism.
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 search tool with 3 parameters, no annotations, and no output schema, the description provides basic purpose and return structure but lacks details about behavioral traits, parameter interactions, and error handling. The return format description is helpful but incomplete without an output schema.
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 67% (2 of 3 parameters have descriptions). The description doesn't add any parameter-specific information beyond what's in the schema. It mentions the search context but doesn't explain how parameters like 'roleWeights' affect the search. Baseline 3 is appropriate given moderate schema coverage.
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 verb ('search and retrieve') and resource ('short-term memories'), and specifies the context ('based on recent conversation context'). It distinguishes from some siblings like 'search_long_term_memories' by specifying the memory type, but doesn't differentiate from 'search_memories' which could be ambiguous.
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 context ('based on recent conversation context') but doesn't explicitly state when to use this tool versus alternatives like 'search_long_term_memories' or 'search_memories'. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions the tool '支持導出短期和長期記憶，包含完整的元數據和時間戳' (supports exporting short-term and long-term memories, including complete metadata and timestamps), which adds some behavioral context about what gets exported. However, it doesn't disclose critical traits like whether this is a read-only operation, what permissions are needed, whether it overwrites existing files, or what the output format is (e.g., JSON, CSV). For a backup tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('將指定對話的所有記憶備份到文件') and follows with supporting details about memory types and metadata. Every part earns its place with no redundant or vague language, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a backup operation with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., file overwriting, permissions), output details (e.g., file format, success indicators), and usage constraints. While the schema covers parameters well, the description doesn't compensate for missing annotations or output schema, leaving the agent with insufficient context for safe and effective use.
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 5 parameters thoroughly. The description adds minimal value beyond the schema by mentioning '短期和長期記憶' (short-term and long-term memories), which aligns with the include_short_term and include_long_term parameters, but doesn't provide additional syntax, format, or usage details. This meets the baseline of 3 when 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 clearly states the specific action ('備份到文件' - backup to file) and resource ('指定對話的所有記憶' - all memories of a specified conversation). It distinguishes itself from sibling tools by focusing on backup/export functionality rather than memory manipulation, analysis, or retrieval operations found in tools like add_long_term_memory, analyze_memory_patterns, or list_backups.
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 context through '將指定對話的所有記憶備份到文件' (backup all memories of a specified conversation to a file), suggesting this tool is for creating backups rather than other memory operations. However, it doesn't explicitly state when to use this versus alternatives like list_backups (which likely lists existing backups) or restore_memories (which likely restores from backups), nor does it mention any prerequisites or exclusions.
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 full burden. It discloses that the tool performs a destructive action ('removes memories') and specifies behavioral traits like cleanup criteria and retention rules. However, it lacks details on permissions, rate limits, or what happens if the conversation_id is invalid, leaving some behavioral aspects unclear.
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 front-loaded with the core purpose in the first sentence, followed by specific behavioral details in the second sentence. It is appropriately sized with zero wasted words, making it efficient and easy to parse.
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 tool's complexity (destructive cleanup operation), lack of annotations, and no output schema, the description is moderately complete. It covers the what and how of cleanup but misses contextual details like error handling, confirmation prompts, or side effects, which are important for a mutation tool with no structured safety hints.
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 the 'conversation_id' parameter. The description does not add any additional meaning or context about this parameter beyond what the schema provides, such as how it affects the cleanup process. Baseline 3 is appropriate as the schema handles the parameter documentation.
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 action ('manually trigger cleanup') and resource ('old or low-relevance short-term memories'), with specific criteria for removal (older than 1 year or low relevance scores) and a retention minimum (keeping at least 512 memories). However, it does not explicitly differentiate from siblings like 'delete_short_term_memories', which might handle more targeted deletions.
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 maintenance purposes ('manually trigger cleanup') and specifies criteria (age and relevance), but does not provide explicit guidance on when to use this tool versus alternatives like 'delete_short_term_memories' or 'backup_memories', nor does it mention prerequisites or 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 carries the full burden of behavioral disclosure. It successfully warns about the destructive overwrite behavior ('這將覆蓋當前對話的所有記憶'), which is crucial for a mutation tool. However, it doesn't mention authentication requirements, rate limits, error conditions, or what happens when the backup file is invalid or missing.
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 perfectly concise with just two sentences. The first sentence states the core purpose, and the second provides a critical warning. Every word earns its place, and the warning is appropriately front-loaded for a destructive operation.
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 mutation tool with no annotations and no output schema, the description does the minimum by stating the purpose and warning about destructive behavior. However, it doesn't explain what the tool returns (success/failure indicators), doesn't mention error conditions, and doesn't provide guidance on backup file format or location requirements. Given the complexity of a restore operation, more context would be helpful.
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 description coverage is 100%, providing complete documentation for all 5 parameters. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline of 3. It doesn't explain parameter interactions or provide usage examples.
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 specific action ('從備份文件還原記憶' - restore memories from backup files) and the resource (memories). It distinguishes itself from siblings like 'backup_memories' (which creates backups) and 'list_backups' (which lists available backups) by focusing on restoration from existing backups.
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 clear context about when to use this tool ('從備份文件還原記憶') and includes a warning about its destructive nature ('這將覆蓋當前對話的所有記憶' - this will overwrite all current conversation memories). However, it doesn't explicitly mention when NOT to use it or name specific alternatives like 'merge' operations (though the merge parameter is documented in the schema).
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:

[![memory-mcp-server MCP server](https://glama.ai/mcp/servers/win10ogod/memory-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/win10ogod/memory-mcp-server)

Score Badge

Copy to your README.md:

[![memory-mcp-server MCP server](https://glama.ai/mcp/servers/win10ogod/memory-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/win10ogod/memory-mcp-server)

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/win10ogod/memory-mcp-server'

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