tdai-memory-mcp

by tinhien11

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: v0.5.17
Disambiguation4/5
Most tools have clearly distinct purposes: recall for broad context, search for specific facts, capture for saving, resolve for conflicts, forget for deletion, handoff for session transfer, and adr for architecture decisions. The main overlap is between recall and search, but their descriptions clarify the difference (broad versus specific).
Naming Consistency4/5
Tool names are mostly single-word lowercase verbs (recall, capture, search, resolve, forget), which forms a predictable pattern. However, 'handoff' is a noun/phrasal verb and 'adr' is an acronym, creating minor deviations from the otherwise consistent verb style.
Tool Count5/5
With 7 tools, the set is well-scoped for a memory-management server. Each tool serves a distinct memory lifecycle function without unnecessary bloat or overlap.
Completeness4/5
The tool surface covers core memory operations: store (capture), retrieve (recall/search), delete (forget), conflict handling (resolve), plus specialized features (handoff, adr). A missing explicit 'update memory' tool is a minor gap, but capture can serve that role implicitly.
Average 4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that search is by keyword or semantic similarity, which is useful. However, it doesn't mention the default hybrid mode, whether results are paginated with a limit, or what the return format looks like. Since search is inherently read-only, that isn't a concern, but more behavioral detail would be beneficial.
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 highly concise: two sentences that state the core function and provide usage guidance. No wasted words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no annotations and no output schema, the description is adequate but sparse. It explains the primary purpose and when to use it, but omits mention of available filters, limits, and mode options. Given the moderate complexity of the input schema, a bit more context would make the description more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description adds no parameter guidance. It doesn't explain the 'mode' enum, 'limit', or 'filters' object. While the schema has some descriptions for 'query' and 'mode', parameters like 'limit' and many filter fields lack descriptions. The tool description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search memory by keyword or by semantic similarity.' It uses a specific verb and resource, and it distinguishes from recall by indicating when this tool should be preferred ('when recall is too broad and you need specific facts'). This effectively differentiates from the likely sibling 'recall'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this tool when recall is too broad and you need specific facts.' It implies that recall is for broad queries and that this tool is for targeted fact-finding. It does not explicitly list alternatives or exclusions beyond this, but the context is clear enough for a search tool.
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 behavioral burden. It only says 'Delete specific memory entries' and 'Do not auto-forget'; it fails to mention that deletion is permanent, requires confirm=true, or that reject mode creates a tombstone. This is a significant gap for a destructive 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 three short, front-loaded sentences with no filler. It delivers the core action and usage constraint efficiently.
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 is complex with nested filters, reject/confirm semantics, and no output schema. The description is minimally viable but omits critical distinctions like delete vs reject and the permanent/destructive nature. The schema helps, but the description alone would not fully orient an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% and each parameter already has a detailed description (id, filter, reason, reject, confirm). The description adds no extra parameter semantics, so a baseline score of 3 is appropriate given the schema already 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 tool deletes specific memory entries, providing a specific verb and resource. This distinguishes it from sibling tools like recall, search, and knowledge_delete.
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?
The description explicitly states when to use this tool ('only when the user requests a deletion') and when not to ('Do not auto-forget'). This is strong, unambiguous usage guidance even though it doesn't name specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It indicates a non-destructive read operation via 'Retrieve' and adds a useful behavioral hint about calling it before answering. However, it does not detail potential side effects, authentication needs, or how results are shaped beyond what the schema already implies.
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 composed of three short, purposeful sentences: it states the core function, provides an invocation directive, and lists two use cases. There is no redundancy or fluff; each sentence 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?
For a tool with 10 parameters, no output schema, and no annotations, this description is minimal. It covers primary use cases and timing but does not describe the return format, potential edge cases, or limitations. The detailed schema mitigates some gaps, yet a more complete description would be helpful for such a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 10 parameters clearly explained in the input schema. The description itself does not elaborate on any specific parameters, adding only generic context like 'past work' and 'project context' rather than clarifying parameters such as session_key or task_id. This meets the baseline without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Retrieve relevant past memory,' which clearly specifies the action (retrieve) and resource (past memory). It distinguishes itself from sibling tools like capture and forget by focusing on retrieval rather than creation or deletion, and the phrase 'relevant' implies context-based recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use: 'Call this tool before you answer the user' and 'Use it when the user references past work or when the task needs project context.' This gives clear context and conditions, though it does not explicitly state when not to use it or mention alternative tools such as search.
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 explaining behavior. It discloses that the ADR is 'stored as a structured capture and can be recalled by any agent working on the same project,' which gives persistence and visibility. However, it omits other behavioral nuances like return values, immutability, or potential side effects, leaving some gaps for an agent relying solely on 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—two sentences—and front-loaded with the core action. Each sentence adds value: the first states the purpose and trigger, the second explains the storage and recall behavior. No filler or redundant content.
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 write tool with 11 parameters and no output schema, the description covers the essential context: what to record, when to use it, and what happens to the record. The schema handles parameter specifics, so the description does not need to repeat them. It might be slightly stronger if it mentioned return behavior, but overall it is reasonably complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 11 parameters with detailed descriptions (100% coverage), so the baseline is 3. The tool description adds no extra parameter-level meaning beyond the schema, but it also does not need to since the schema is self-sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Record' and a well-defined resource 'Architecture Decision Record (ADR)', clearly distinguishing it from generic capture tools. It also states the scope ('technical decision that future agents should know about'), making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: 'Use this tool when you make a technical decision that future agents should know about.' This provides a clear trigger condition, though it does not mention when not to use it or alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It states the tool 'Save[s]... to memory' and mentions both single-text and message-list capture modes, but it doesn't describe side effects (e.g., superseding marks old captures stale) or return values. The minimal disclosure is viable but not rich, relying on the schema for deeper details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and each sentence earns its place. It states what the tool does, when to use it, and the input modes without redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 13 parameters and no output schema, but the comprehensive schema covers parameter meaning. The description supplies the crucial 'when to call' context and high-level input options. It doesn't state return values, but for a memory-capture tool this gap is acceptable given the schema's richness and the clear distinction from sibling tools.
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 13 parameters. The description adds conceptual grouping ('decision, learning, task outcome' align with the type enum and the content vs messages distinction) but doesn't introduce syntax or format details beyond the schema. This matches the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Save a decision, a learning, or a task outcome to memory,' which is a specific verb (Save) plus resource (memory). It clearly distinguishes the tool from sibling read/delete tools like recall, search, and forget, and enumerates concrete use cases for when to capture, such as after a non-trivial task or bug fix.
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?
'Call this tool after you complete a non-trivial task, make a decision, or fix a bug with a known root cause' provides explicit when-to-use triggers. It doesn't list alternatives or exclusions, but the context of sibling tools (recall/search/forget) makes the usage unambiguous, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states that it writes a packet and claims token savings, but does not mention whether it overwrites an existing handoff, storage behavior, or any side effects. No contradiction with annotations since none are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and resource, then usage timing and benefit. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters and no output schema, the description provides the key context (what, when, why, and the recall workflow). Complete enough given the schema covers all parameters, though it doesn't mention overwriting or retention behavior explicitly.
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 parameters are already well-documented. The description does not add extra detail beyond the schema, which is acceptable but not additive. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Write a structured handoff packet for the next agent session.' It distinguishes from sibling tools by specifying the purpose (session handoff) and referencing 'recall' as the counterpart that loads the packet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call: 'at the end of a session, or before you switch to a different agent.' It also explains the benefit and the relationship with 'recall.' However, it doesn't explicitly list when not to use or contrast with other sibling tools like 'capture.'
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 disclosing behavior. It clearly states the state changes: one capture becomes the winner (stays active) and the other becomes stale. It does not mention return values or reversibility, but for a simple state-changing tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose and the second gives usage guidance. It is front-loaded, efficient, and contains zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and complete schema, the description covers the essential aspects: what it does, when to call it, and the effect. The lack of an output schema is a minor gap because the description doesn't mention return values, but for this simple action it is likely not 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 input schema provides 100% coverage with descriptions for all three parameters (winner, loser, reason), so the description doesn't need to repeat them. The main description adds no parameter-specific meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: resolving a conflict between two captures by marking a winner and a loser as stale. It uses specific verbs and domain terms, and distinguishes itself from sibling tools like capture, search, and forget by focusing specifically on conflict resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use the tool: 'Call this tool when capture reports a conflict between two memories.' This provides a clear trigger condition, though it does not mention when not to use it or mention alternatives. The guidance is sufficient for a focused tool.
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:

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

Score Badge

Copy to your README.md:

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

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/tinhien11/tdai-memory-mcp'

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