trae-memory

by fangxh2013

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: v2.0.0
Disambiguation2/5
log_input、log_conversation、log_chat 三个工具在功能上高度重叠，尤其后两个几乎都是记录对话内容，代理难以准确区分。context、recall、tasks 等工具边界较清晰，但日志类工具的冗余拖累了整体辨识度。
Naming Consistency3/5
大部分工具采用 log_、get_、save_ 等动词前缀，但 context、tasks、files 是纯名词形式，破坏了统一的 verb_noun 模式。log_conversation 与 log_chat 对同类操作命名也不一致，整体属于混用但尚可读的状态。
Tool Count4/5
10 个工具对于记忆管理类服务器来说数量适中，没有过度膨胀。不过由于日志记录类工具重复，实际有效工具数量略低于表面数量，存在一定冗余。
Completeness4/5
覆盖了上下文状态管理、记忆召回、对话记录、历史读取、用户设定以及任务和文件管理，基本满足记忆服务器的核心需求。缺少显式的记忆删除或更新操作，但整体不会造成严重使用阻碍。
Average 3/5 across 10 of 10 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 MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'save user settings', which implies mutation but does not disclose persistence behavior, overwrite semantics, side effects, errors, or return values. For a write operation, this is a significant gap that leaves the agent uncertain about consequences.
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 short sentence with no filler words. It is very concise and efficient, though it might border on under-specification. Every word is meaningful ('保存' = save, '用户' = user, '设定' = settings), so it earns a good score for conciseness.
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 that there are no annotations, no output schema, and only a minimal description, the tool is contextually incomplete. For a mutation tool, an agent needs to know what happens on save, whether the operation is idempotent, and what the response format is. The description and schema do not provide this, so the tool is not fully self-explanatory.
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 'key' and 'value' have descriptions ('设定键名' and '设定值'). The description itself adds no extra meaning about parameter usage, allowed values, or format beyond what the schema already provides. Since the schema is complete, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '保存用户设定' (Save user settings) clearly indicates the verb 'save' and resource 'user settings', matching the tool name closely. It is not a pure tautology but adds minimal differentiation from siblings like get_setting, which is presumed to read settings. However, it does not specify what kind of settings or scope, so it lacks the specificity needed to distinguish it from other save-like 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?
There is no guidance on when to use this tool versus alternatives. The sibling get_setting is implied as the read counterpart, but the description does not state that this tool is for writing or setting values, nor does it mention any prerequisites or conditions. The agent is left to infer usage solely from the name and schema.
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 bears the full burden of disclosing behavior. It mentions detecting expiry and handling reset, but does not clarify whether reset is destructive, what optimize does, or if there are side effects. This is a significant gap for a tool that appears to mutate state.
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 with no redundancy, yet it is more of a label than a complete explanation. It is concise in length but lacks substance, conveying only a vague sense of functionality without concretely stating what the tool does.
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 no annotations, no output schema, and an action enum with non-obvious values (check, reset, optimize), the description is incomplete for correct invocation. It does not explain what each action does, how tokenCount and maxTokens interact, or what the expected result of calling the tool is.
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 with descriptions. The tool description adds no parameter-level detail beyond the schema, so the baseline of 3 applies. It neither enhances nor conflicts with schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific function ('管理Context状态，检测过期并处理重置') with clear intent, and distinguishes itself from siblings like log_conversation and files by focusing on context state management. However, '管理' is somewhat generic, and the specific operations (check/reset/optimize) are not elaborated.
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 given on when to use this tool versus sibling tools such as log_conversation or tasks. The description only states what the tool does, not in which situations it should be invoked, nor any exclusions to avoid incorrect usage.
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 alone must disclose side effects and behavior. It only states that the tool records the full conversation, without mentioning storage, persistence, whether it appends or overwrites, required permissions, or what happens on success.
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 short sentence with no filler or repetition. It front-loads the core purpose immediately.
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 tool with four parameters, a nested metadata object, no output schema, and no annotations, the description is too minimal. It omits usage context, behavioral side effects, and any differentiation from the log_conversation sibling.
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 four parameters. The description adds no parameter-level meaning beyond the schema; it only implies that both user_input and assistant_response are part of the complete conversation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (记录/record) and resource (用户-助手对话内容) and adds 'complete' scope. However, it does not distinguish this tool from the sibling log_conversation, which appears to serve the same function by 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?
There is no guidance about when to use log_chat versus alternatives such as log_input, log_conversation, or get_history. No exclusions or selection criteria are given, leaving the choice between siblings ambiguous.
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, and the description does not disclose side effects, storage behavior, idempotency, or compatibility implications. The vague 'compatible with original version' adds little beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. While it is not bloated, it is so minimal that it borders on under-specification.
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 existence of closely related siblings and the absence of output schema or behavioral details, the description is not complete enough to confidently route an agent to the correct tool. The simple schema helps, but the ambiguity remains.
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 'user' and 'assistant' parameters described in the schema. The description itself adds no additional parameter-level meaning, so the baseline 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 states a clear verb and resource: '记录对话' (log conversation). However, it does not differentiate this tool from siblings like log_chat or log_input, so it is clear but lacks sibling differentiation.
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?
There is no guidance on when to use this tool versus alternatives like log_chat or log_input. The phrase '兼容原版本' hints at compatibility but does not explain selection criteria or exclusions.
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 present, the description is the sole source of behavioral information. It indicates a recording or logging action ('记录') and mentions 'context analysis,' but it does not disclose side effects, persistence, permissions, or whether the tool returns a value. This is minimal behavioral disclosure for a tool that presumably writes data.
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 compact sentence with no redundant words. It front-loads the action and object, though the trailing '包含上下文分析' is somewhat vague and could confuse rather than clarify.
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 full schema coverage, the description omits usage context, side effects, and expected return behavior; there is no output schema to fill these gaps. For a five-parameter tool with no annotations, this one-line description leaves an agent uncertain about invocation outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters have descriptions in the schema (100% coverage), so the description does not need to restate them. The phrase '包含上下文分析' loosely relates to the files/context fields but adds no concrete parameter-level meaning. 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 uses a specific verb '记录' (record) and target resource 'TRAE Builder的输入' (TRAE Builder input), making the core purpose clear. The appended '包含上下文分析' (includes context analysis) is slightly vague, and it does not explicitly distinguish this tool from sibling logging tools like log_conversation and log_chat, but the resource is specific 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 description provides no conditions for use, exclusions, or references to sibling tools. An agent cannot determine when to choose log_input over log_conversation, log_chat, or context from the text 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 hints at a read-like retrieval operation but does not state whether the tool only reads memory, whether it modifies or injects context, what memory sources it queries, or how '恢复' should be interpreted. The description adds too little behavioral context for a tool with no annotation safety signals.
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 short sentence with the action and target front-loaded, and it avoids verbosity. The word '智能' is somewhat vague filler, and the description is too terse to be excellent, but it is still concise and structurally clean.
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 memory-recall tool with four parameters, no annotations, and no output schema, the description should explain what is returned, what kinds of memories are searched, and how project or includeCompleted affect behavior. None of that is present, so an agent cannot fully predict the tool's behavior from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal mapping by aligning '当前上下文' with the query parameter, but it does not enrich understanding of limit, project, or includeCompleted. It neither contradicts nor meaningfully supplements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action, '恢复相关记忆' (retrieve relevant memories), qualified by '基于当前上下文', so an agent can infer it is a memory-recall tool for the current conversation. However, it does not explicitly say it searches stored memories and does not differentiate itself from siblings like get_history or context, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as context, get_history, or log_*. The phrase '基于当前上下文' only vaguely implies relevance to the current conversation, but no conditions, exclusions, or alternative recommendations are 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 only says 'manage' and 'track completion status,' which hints at read/write behavior but does not disclose side effects, permission needs, reversibility, or what happens on update/create. This is insufficient for a mutation-capable tool.
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, front-loaded sentence with no redundant wording. It is concise, but the brevity sacrifices useful detail that would improve the agent's understanding, so it does not earn a 5.
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?
With no output schema and no annotations, the description needs to explain return values, action semantics, and usage requirements. It does none of this, leaving a complex four-action tool with nested objects under-explained. The agent must infer too much from the schema alone.
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 top-level parameters, so the schema already documents the action enum, taskId, filters, and taskData. The description adds no parameter-specific meaning and does not clarify nested fields beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a clear resource ('development tasks') and a goal (tracking completion status), which distinguishes it from sibling tools like files or log management. However, the verb 'manage' is generic and does not specify the available operations (create/update/list/stats), so it is clear at a high level but lacks precision.
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?
There is no guidance on when to use this tool versus alternatives, and no mention of excluded scenarios. The description only implies that it is for task management, but it does not explicitly differentiate from siblings or provide conditions for choosing between actions.
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 behavioral disclosure burden. It only restates the high-level actions (clean, archive, optimize) without explaining effects such as whether clean deletes files permanently, whether archive moves them, what optimize does, or whether operations are reversible.
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 short sentence that front-loads the resource and names the supported operations. There is no filler or redundant repetition of schema details.
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 multiple actions with very different behaviors, no annotations, and no output schema. The description does not explain return values, destructive potential, prerequisites, or what each action actually does. This is insufficient for an agent to reliably select and invoke the correct action.
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 three parameters and their roles. The description adds no new parameter-level meaning beyond what the schema provides, 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 identifies the resource (files in the data directory) and lists supported operations (cleanup, archive, optimization). It is clear enough to distinguish this tool from the sibling context/logging/settings tools, though the verb '管理' (manage) is somewhat broad.
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?
Usage context is only implied: the tool is for managing files in the data directory, so an agent can infer when to use it. However, there is no explicit guidance about when not to use it or how it compares to alternatives, and no details on which action fits which scenario.
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 behavioral burden. The verb '读取' conveys a read-only operation and '最近的' implies recency ordering, but the description does not disclose what records are included (messages, turns, tool calls), the response structure, or whether the call could have side effects.
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, front-loaded sentence with no filler words. It is appropriately concise for a simple read tool, though it is not exemplary because it omits useful contextual detail.
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 simple read-only tool with one optional parameter, the description covers the core purpose. However, it does not disambiguate from overlapping siblings like context and recall, and with no output schema, the exact content or format of the returned history is left undefined.
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 fully documents the single limit parameter with a description and default value (5), achieving 100% schema description coverage. The tool description adds no additional meaning about the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '读取最近的对话记录' clearly states the tool's function: read recent conversation history. It uses a specific verb (读取) and resource (最近的对话记录), but it does not explicitly differentiate from siblings like recall or context, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as context or recall. No exclusions, preconditions, or alternative tool mentions are provided, leaving the agent to infer usage entirely.
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 only states that a setting is read, but does not explain error behavior, return format, whether missing keys return null, or any permission requirements.
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 short phrase with no wasted words, making it very concise. However, it is so terse that it sacrifices potentially useful context, though it still remains readable and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter getter, the description is minimally adequate. However, there is no output schema and no mention of return values or edge cases, leaving the agent to infer important runtime behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the key parameter with '设定键名'. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '读取' (read) with a clear resource '指定用户设定' (specified user setting), making the tool's purpose unambiguous. It naturally distinguishes itself from the sibling save_setting, which implies the opposing write operation.
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 given about when to use this tool versus alternatives. There is no mention of context, prerequisites, or why an agent should pick get_setting over other read-oriented siblings like context or get_history.
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:

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

Score Badge

Copy to your README.md:

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

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/fangxh2013/trae-memory'

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