memos-api-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action: memory tools cover add/search/delete/update/profile, while knowledge base tools cover create/add/get/delete/remove. Even in overlapping areas like search_memory and get_user_profile, descriptions clarify complementary use.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (add_, get_, delete_, create_, remove_). Minor inconsistency exists between 'remove_knowledge_base' and 'delete_kb_documents' using different verbs, and between singular 'add_kb_document' and plural 'get_kb_documents'/'delete_kb_documents'.
Tool Count5/5
Ten tools is well-scoped for a server that manages both user memory and knowledge bases. Each tool covers an essential operation without redundancy.
Completeness4/5
Memory lifecycle is complete (create, retrieve, update, delete, profile). Knowledge base lifecycle covers create/delete, document add/delete/query, but lacks an explicit 'list all knowledge bases' or 'update knowledge base' operation, which is a minor gap.
Average 3.5/5 across 10 of 10 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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 Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says to call when deleting a knowledge base, which merely restates the tool's name and does not reveal any side effects, such as whether deletion is permanent, cascades to associated documents, or requires specific permissions. This is essentially no behavioral transparency beyond the obvious destructive implication of the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, so it is not verbose. However, it is under-specified: it reads as a usage directive ('Call when deleting a knowledge base') rather than an informative description, lacking structure or additional contextual detail. It is concise but does not earn its place as a high-quality description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no annotations, and no output schema, so the description must provide context. It fails to explain important aspects such as the effect on associated documents (since sibling tools like delete_kb_documents exist), whether the action is reversible, or what happens after deletion. This leaves clear gaps for a simple 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% for the single parameter knowledgebase_id, which is documented as '要删除的知识库 ID' (the ID of the knowledge base to delete). The description adds no additional parameter semantics, but since the schema fully covers the parameter, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for deleting a knowledge base ('删除知识库时调用' – 'Call when deleting a knowledge base'). It uses a specific verb and resource, distinguishing it from sibling tools like create_knowledge_base and get_kb_documents. However, it lacks any additional scope detail, so it's clear but not fully rich.
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 provides an implied usage context: use when deleting a knowledge base. It does not explicitly mention when not to use it or offer alternatives, such as delete_kb_documents for removing individual documents. This is a clear trigger condition but lacks exclusions or alternatives, placing it at the 'implied usage' level.
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 must carry the burden of behavioral disclosure. It merely states the action without revealing destructive nature, irreversibility, or potential errors. An agent cannot infer side effects or safety implications from this description.
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 concise sentence, which is appropriate in length and front-loaded. However, it is almost unnecessarily terse, with no additional context, but it doesn't waste words either.
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 tool with no output schema and no annotations, the description is too minimal. It fails to clarify differences from sibling tools like delete_memory or remove_knowledge_base, nor does it mention any consequences, permissions, or error behavior, leaving the agent underinformed.
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 fully describes the only parameter (file_ids) with a clear description, and the tool description adds nothing beyond that. Since schema coverage is 100%, the parameter is adequately documented, but the description doesn't enhance understanding further.
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 a specific action ('delete') and a specific resource ('knowledge base documents'), which is distinct from sibling tools like add_kb_document or remove_knowledge_base. However, it doesn't explicitly differentiate from sibling delete operations like delete_memory, though the resource name makes it clear enough.
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 phrase 'when deleting knowledge base documents' provides only an implied context, repeating the obvious from the name. It gives no guidance on when not to use it, prerequisites, or alternatives 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only states when to call the tool, not what it actually does in terms of side effects, potential failures, or requirements (e.g., whether it creates an empty knowledge base, if duplicate names cause errors, or if permissions are needed). For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, directly stated sentence with no wasted words, making it very concise. It is front-loaded with the key trigger. However, it is under-specified for the tool's complexity, though conciseness itself is a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has simple inputs and no output schema, but the description omits critical behavioral context such as what happens when the knowledge base is created, any constraints, or error conditions. An agent would know when to call it but not fully understand the outcome or potential issues, making it incomplete for confident 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% — both parameters have descriptive names and descriptions in the schema (knowledgebase_name and knowledgebase_description). The description adds no additional parameter semantics, so the baseline score of 3 applies as 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 identifies the action (create) and the resource (project/domain knowledge base), and the trigger ('when user requests') distinguishes it from sibling tools like remove_knowledge_base or add_kb_document. However, it doesn't explicitly state what creating a knowledge base entails, such as initializing a container for documents.
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 trigger: 'when the user requests to create a project/domain knowledge base.' This tells the agent exactly when to invoke the tool. It does not explicitly mention alternatives or when not to use it, but the trigger is specific enough to guide 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?
No annotations exist, so the description carries the full burden. It only mentions the query scenarios, not what the tool does, whether it is read-only, how it handles pagination, or what it returns. This is minimal behavioral guidance.
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?
Single, front-loaded sentence with no filler; every word 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?
Complexity is moderate (4 optional params, no output schema). The description clarifies usage trigger but omits return behavior and effect of flags; schema covers params. Adequate but not 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?
Input schema covers 100% of parameters with descriptions (size, current, include_preference, include_tool_memory). The description adds no param semantics, so baseline 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 specifies the exact user question types ('Who am I', 'my profile', 'what do you know about me') that trigger this tool, effectively distinguishing it from siblings like search_memory. However, it states the invocation condition rather than explicitly declaring the retrieval function; the verb+resource is implicit in the tool name.
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 when-to-use context (identity/preference questions) which clearly separates it from search_memory and other memory tools. Does not mention exclusions or alternatives, so not a 5.
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 transparency burden. It does disclose the automatic invocation behavior and the get_user_profile co-call condition, adding useful context beyond the tool name. However, it does not disclose side effects, return format, or explicitly confirm the operation is read-only, leaving meaningful 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 two short, focused sentences. The main behavior is front-loaded, and the special case about get_user_profile is delivered as a single dependent clause. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich 12-parameter schema, the description lacks orchestration details such as how the returned memory should be used, what the return payload looks like, and whether the operation is safe/read-only. With no output schema and no annotations, the tool needs more behavioral context than this brief description provides.
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 covers 100% of the parameters with detailed descriptions, so the baseline is 3. The description itself adds no parameter-level semantics beyond what the schema already provides, but it also doesn't need to since the schema is thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb '检索记忆' (retrieve memory) and clearly states the tool runs automatically before each answer, identifying it as a memory retrieval tool. It does not explicitly contrast with siblings like delete_memory or add_feedback, so sibling differentiation is limited.
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 the tool should be invoked before every answer ('每次回答前自动检索记忆') and instructs that get_user_profile should also be called when the user asks about identity/profile. This provides clear when-to-use guidance and sibling coordination, though it stops short of stating when not to use the tool.
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 burden of disclosing behavior. It does reveal that the tool records correction content and deletion intent, which is useful. However, it doesn't clarify side effects (e.g., whether the memory is actually modified), any permissions needed, or what happens after recording feedback. This leaves significant behavioral ambiguity.
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, consisting of two short clauses that immediately convey the core purposes. There is no wasted text, and it is front-loaded with the primary use case. It earns a high score for efficiency.
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 7 parameters, no output schema, and no annotations. The description mentions both use cases but does not explain what the tool returns, whether it directly modifies memory, or how it interacts with delete_memory. Given the complexity, the description is adequate but lacks crucial details about outcomes and side effects, making it a minimum viable description.
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 all 7 parameters have descriptions. The tool description adds context that feedback_content is the user's original words and conversation_first_message is used to generate a conversation_id, reinforcing schema info but not adding new meaning. The baseline for full schema coverage is 3, and the description does not significantly elevate 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 states the tool is called when modifying/correcting existing memories and after deleting a memory to record deletion intent. This clearly indicates the tool's role in managing memory feedback, though it doesn't use a direct verb like 'adds' and presents two related but distinct use cases. It distinguishes from siblings by focusing on memory correction/deletion rather than message handling or KB operations.
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 provides trigger conditions: 'when modifying/correcting existing memory' and 'after successful memory deletion'. This gives clear guidance on when to use the tool, though it does not explicitly mention alternatives or exclusions. The context is sufficient for an agent to infer appropriate invocation scenarios relative to sibling tools like delete_memory and add_message.
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. However, it only repeats schema information (e.g., local path requires mime_type, URL can be passed directly) and does not mention important side effects, permissions, idempotency, error behavior, or what happens on success. The tool is clearly a mutation (add), but the description adds little beyond the 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 a single, front-loaded sentence that captures purpose and usage in under 30 characters. It is concise and well structured, with no wasted words or redundant details beyond what adds immediate clarity.
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 relatively simple tool with two parameters and no output schema, the description covers the core purpose and input modes. However, it does not mention important contextual details such as the array limit (up to 20 files, though in schema), what the response contains, or error conditions. It is adequate but not complete for a mutation tool with no annotations.
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 thoroughly. The description's parameter guidance ('本地文件传绝对路径并带 mime_type，URL 直接传链接') is essentially a paraphrase of the schema's content and mime_type descriptions, adding little new semantic information. 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: '向知识库添加文档时调用' (call when adding documents to the knowledge base). This is a specific verb+resource pair that distinguishes it from siblings like get_kb_documents and delete_kb_documents. It also clarifies the two supported input modes (local file path with mime_type, or URL), leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool ('when adding documents to the knowledge base') and provides concrete guidance for parameter usage (absolute path with mime_type for local files, direct URL for links). It does not explicitly mention alternatives or when not to use, but the sibling tools and the 'when' clause make usage context clear.
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, but it provides none beyond the basic action. It does not mention return format, error behavior, permissions, or any side effects. For a read operation, 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 a single, front-loaded sentence that immediately conveys the purpose. It contains no filler or redundant 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 low complexity (one parameter, no nested objects) and full schema coverage, the description is adequate but minimal. It lacks any detail about the response structure or edge cases, so it is only a minimum viable description, not a complete one.
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 single parameter 'file_ids' is described as '要查询的文档 ID 列表'. The description's '按 ID' adds no extra semantic beyond what the schema already provides, so it only meets the baseline for a fully documented 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: query knowledge base document details by ID. It uses a specific verb (查询) and identifies the resource (document details). It distinguishes from sibling tools like add_kb_document and delete_kb_documents, which are write operations.
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 when to call it: when querying knowledge base document details by ID. It implies a read context relative to sibling write tools, though it does not explicitly name alternatives or exclusion criteria.
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 must disclose behavioral traits. It only mentions the call trigger and the fallback to search_memory when IDs are missing. It does not state whether deletion is permanent, what happens if IDs don't exist, or any side effects, leaving significant behavioral gaps for a destructive 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, front-loaded sentence that states the trigger condition and then provides a conditional workflow. Every word contributes essential information, with no redundancy or 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?
Given the tool's simplicity—one parameter, no output schema, no annotations—the description provides the core usage context and a fallback procedure. However, it omits important details like error handling, irreversibility, and return values, which are typically expected for a delete operation. It is adequate but with clear 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?
The sole parameter memory_ids is described in the schema as '要删除的记忆 ID 列表' (list of memory IDs to delete), achieving 100% schema coverage. The description adds minimal value by implying that if IDs are absent, one should search first, but it doesn't further elaborate on the parameter's format or use 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 explicitly states '用户要求删除记忆时调用' (call when user requests to delete memory), clearly indicating the tool's purpose of deleting memory entries. This distinguishes it from sibling tools like delete_kb_documents, which target knowledge base documents, and search_memory, which is for searching.
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?
It provides an explicit trigger condition ('when user requests to delete memory') and a concrete alternative workflow: if no ID is provided, first use search_memory to find it. This gives clear guidance on when to use this tool and how to handle missing IDs, effectively differentiating it from alternatives.
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 burden. It discloses that the tool automatically saves the conversation after each response, which is a key behavioral trait. However, it doesn't disclose side effects such as whether it appends or overwrites, or any prerequisites, making it only moderately transparent.
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, concise sentence with two clauses that directly state the purpose and usage. It is front-loaded and every word 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?
For a simple tool with two well-documented parameters and no output schema, the description provides adequate context about when to call it and its automatic behavior. It doesn't cover return values, but that's not necessary given the absence of 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 covers 100% of the parameters, so the baseline is 3. The description doesn't add any parameter-specific meaning, but the schema already provides the necessary details.
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 saves the conversation and specifies the trigger (when user requests to remember new information). It uses a specific verb 'save' and resource 'conversation', distinguishing it from sibling memory tools like search_memory and delete_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?
Provides clear when-to-use: after each response and when the user requests to remember new information. However, it doesn't explicitly mention when not to use it or name alternatives, though 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.

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:

[![memos-mcp-custom-trae MCP server](https://glama.ai/mcp/servers/shijieweb/memos-mcp-custom-trae/badges/card.svg)](https://glama.ai/mcp/servers/shijieweb/memos-mcp-custom-trae)

Score Badge

Copy to your README.md:

[![memos-mcp-custom-trae MCP server](https://glama.ai/mcp/servers/shijieweb/memos-mcp-custom-trae/badges/score.svg)](https://glama.ai/mcp/servers/shijieweb/memos-mcp-custom-trae)

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/shijieweb/memos-mcp-custom-trae'

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