th-memory-mcp

Server Quality Checklist

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

Latest release: v2.2.6
Disambiguation3/5
Most tools have clear roles, but recall, search_history, and get_context overlap as retrieval/search entry points, especially since recall and get_context are both described as useful before a task. The descriptions help distinguish them, but an agent could still be uncertain which to call.
Naming Consistency4/5
The majority of tools follow a readable verb_noun pattern such as save_lesson, export_memory, update_memory, and import_memory. A few exceptions like rememper, recall, forget, and memory_stats break the pattern, but they are still predictable and intentional.
Tool Count4/5
16 tools is slightly above the ideal 3-15 range, but each tool serves a distinct part of the memory lifecycle: capture, retrieval, update, deletion, graph operations, and import/export. The count feels justified rather than bloted.
Completeness4/5
The tool surface covers create/read/update/delete for memories, plus import/export, statistics, and graph relationships, so the core domain is well covered. The main gap is the lack of a direct get-memory-by-id tool for inspecting a specific memory before update/merge/forget, though this can be worked around via recall or export.
Average 4/5 across 16 of 16 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 52 commits in the last 12 weeks
- Last stable release on August 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosure, but it only says 'create a typed relationship.' It does not reveal side effects, whether existing links are overwritten, directionality of source/target, validation behavior, or whether memories must already exist.
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 one compact sentence with the action front-loaded and the relationship types listed inline. There is no fluff or redundant commentary.
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 three-parameter tool with a fully documented schema, the description is minimally viable, but it leaves gaps: no return behavior, no effect on existing links, and no semantics for the relation types. Given the lack of annotations and output schema, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: 'between two memories' reinforces the meaning of sourceId/targetId, and the relation list mirrors the enum exactly. No additional semantic detail is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action – 'Create a typed relationship between two memories in the graph' – and enumerates the valid relationship types. This clearly distinguishes it from sibling tools like update_memory, merge_memory, or consolidate by focusing on inter-memory graph links.
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 link_memory versus alternatives such as consolidate, merge_memory, or update_memory. The description only states what it does, without exclusions, prerequisites, or an explicit 'when to use' cue.
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 present, so the description carries the full burden of behavioral disclosure. It reveals the clustering mechanism and the optional creation of derived memories, but it does not disclose whether existing memories are modified or deleted, what the tool returns, or whether the operation can be run safely without 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The core mechanism is front-loaded, and the usage guidance is placed at the end for easy scanning.
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 description gives enough to understand the main purpose and when to use it, and the schema covers all parameters. However, with no output schema and no annotations, the lack of information about return values and potential mutation of existing memories leaves important gaps for an agent deciding whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds general context about embedding similarity and derived memories, but it does not add detailed parameter-level semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (cluster similar memories), the method (via embedding similarity), and the optional outcome (create derived/consolidated memories linked via 'derived_from'). This mechanism helps distinguish it from other sibling tools like merge_memory or link_memory, even without naming them.
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 'Use during periodic consolidation,' providing clear timing/context for when to invoke the tool. It does not mention exclusions or compare directly to alternatives, so it falls slightly short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the use of hybrid retrieval, optional graph expansion, and token budgeting, but does not clarify read-only behavior, return format, or what happens when the token budget is exceeded.
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 dense sentences with no filler: the core mechanism is front-loaded, followed by a usage cue. Every 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?
Given 8 parameters, no annotations, and no output schema, the description gives a good high-level purpose but omits important operational details: what the assembled context looks like, how scoping params (userId/projectId/sessionId) interact, and how it differs from recall/search_history. The schema covers param semantics but not these behaviors.
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 88%, so the schema already documents most parameters. The description adds little beyond alluding to query via 'hybrid retrieval' and maxTokens via 'token budgeting'; it does not explain parameter interactions or the effect of includeGraph/includeHistory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (assemble), resource (relevant memories), and method (hybrid retrieval with optional memory-graph expansion and token budgeting). It clearly identifies the tool's purpose beyond the title, though it does not explicitly distinguish it from sibling retrieval tools like recall or search_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage cue: 'Use to load memory into context before a task.' This gives clear when-to-use guidance. However, it does not mention alternatives or state when not to use this tool, leaving some sibling ambiguity.
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 transparency burden. The verb 'Summarize' clearly implies a non-mutating read-style operation, but the description does not explicitly state that it makes no changes, nor does it describe any other behavioral details like cost or freshness.
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 that leads with the core action and then enumerates the exact delivered statistics. Every word adds useful information, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description serves as the sole source of return-value expectations, and it enumerates counts, totals, file size, timestamps, and profile sections. Some terms like 'profile sections' remain somewhat vague, but for a simple zero-parameter stats tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to clarify. The schema coverage is trivially 100%, and the description reasonably focuses on the output content instead.
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 ('Summarize') and identifies a clear resource (memory usage) with a detailed list of metrics included in the output. It is distinct from sibling tools in content, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving high-level memory statistics and summaries rather than detailed records or management actions. However, it provides no explicit when-to-use or when-not-to-use guidance, nor does it name 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 full behavioral burden. It does disclose important behavior: mutable fields are edited in place, and content changes create a superseding memory by default unless supersede=false. However, it omits side effects on the original memory, return values, and authorization requirements.
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 compact sentences with the core action front-loaded. Every clause adds relevant information, and there is no filler or repetition of the title.
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 description captures the main update logic and the crucial supersede behavior, but with no annotations and no output schema it leaves gaps around return data, permanence of edits, and what happens to the original memory when superseding occurs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description adds meaning beyond the schema by explaining the relationship between content and supersede and clarifying 'in place' semantics. It does not add detail for confidence and importance, but the schema covers their numeric ranges.
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 ('Update') and resource ('memory') and enumerates the mutable fields. It clearly distinguishes this tool from siblings like remember, recall, and forget by focusing on in-place modification of existing memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by framing it as updating existing memories, but it does not provide explicit guidance on when to choose this over related tools like merge_memory or consolidate, nor does it state exclusions or prerequisites.
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 present, so the description should carry the full burden. It does state the destructive effect ('Delete one memory row') and an important side effect ('sync the search index'), which is useful. However, it does not mention permanence, permission requirements, or what happens if type is omitted, leaving real 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?
Two sentences with no filler; the main action and side effect are front-loaded, and the second sentence carries the one essential disambiguation about the type parameter. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter deletion tool with no output schema and no annotations, the description covers the core operation, the side effect, and the type-origin mapping needed to avoid mistakes. It does not describe permanence or fallback behavior when type is unknown, but those are minor gaps for such a compact interface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by mapping source tools to type values ('ids from remember are preference ids, from save_lesson are lesson ids'), which is not explicit in the schema and directly improves correct parameter selection.
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 ('Delete') and names the exact resource ('memory row') plus the row kinds (preference, lesson, interaction), so an agent immediately knows what the tool does. It also adds 'sync the search index', making the scope concrete. The distinction from siblings like update_memory or merge_memory is clear without needing to inspect their schemas.
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 context for use is implied: delete a memory row when you want to remove it. The description gives parameter-level guidance ('Pass type when you know it') but never names an alternative tool or says when not to use this one, so an agent has to infer the boundary against siblings such as update_memory or import_memory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It usefully discloses output composition and limits (max 15 preferences, 5 most recent lessons) and frames the result as 'distilled', indicating it is not the full raw profile. It does not explicitly state side-effect freedom, but 'Get' and the summary-style output strongly imply a read 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, well-structured sentence that leads with the verb and resource, then packs the distinguishing output details efficiently. There is no filler or unnecessary repetition.
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 zero parameters and no output schema, the description adequately covers the tool's input and expected return shape. Terms like 'profile sections' and 'lessons' could be slightly more explicit, but the core information an agent needs to call and understand the result is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. There is no parameter meaning for the description to add beyond what an empty schema already communicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get the distilled user profile'. It goes beyond a generic getter by enumerating the exact components returned (profile sections, top preferences by confidence capped at 15, and the 5 most recent lessons), which helps distinguish it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose get_profile over related siblings like get_context, get_recent_interactions, or memory_stats. The intended use is only implied by the name and output description, with no exclusions or alternatives mentioned.
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 behavioral burden. It discloses several important behaviors: validation, deduplication, refusal to blindly overwrite active memory, and dry-run-by-default safety. It does not describe return format or failure modes, but the core safety-relevant traits are clearly conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The most important scoping information (source format) appears first, followed by safety guarantees and the activation flag. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description covers source, validation, dedupe, overwrite policy, and dry-run default. It omits specifics about the returned report and error handling, but the essential context for safe invocation is present.
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 little beyond the schema: it restates the file-location constraint and the dry-run/apply behavior already present in the parameter descriptions. It does not add new semantic detail for userId or JSON structure beyond what the schema gives.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Import memories from a JSON array or a .json file inside data/exports/.' It clearly distinguishes the tool from siblings like export_memory and merge_memory by framing it as the import path for external memory data.
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 gives operational guidance ('Dry-run by default; pass apply=true to insert') but does not explicitly say when to choose this tool over alternatives such as merge_memory or update_memory. Context implies import is for bulk ingestion, but no exclusions or alternative routing are stated.
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 behavioral disclosure burden. It does disclose that the tool searches a full-text index and returns recent matching interactions, but it does not state whether the operation is read-only, how results are ranked, or whether recent interactions are subject to the limit parameter. This is adequate for a search tool but leaves some behavioral details implicit.
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 with no filler. The core search scope is front-loaded, and the usage guidance is immediately actionable. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description covers the key elements: what is searched, the retrieval scope, and when to use it. It does not describe the exact return structure, but it gives enough context for an agent to invoke recall correctly before starting a task.
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 both 'topic' and 'limit'. The description adds minimal semantic value beyond the schema, only clarifying that the search targets preferences and lessons. Baseline 3 is appropriate given full 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 states a specific verb ('Search') and resource ('preferences + lessons via full-text index, plus recent matching interactions'), which clearly identifies what the tool does. It is specific enough to distinguish recall from siblings like search_history or get_recent_interactions, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use the tool: 'Use before starting a new task.' It does not mention alternatives or exclusions, but the timing guidance is clear and actionable for an agent deciding whether to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does supply useful behavioral context: the operation is a write ('Record') and carries a timing constraint (only after a correction). It does not disclose persistence semantics — whether the lesson is stored permanently, surfaced by recall or search_history, or deduplicated on repeated saves — which an agent would need to anticipate downstream effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both purposeful: the first defines what the record captures, the second states when to invoke the tool. No wasted words, and the most operationally important guidance ('immediately after the user corrects your work') is prominent.
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 three simple string params, full schema documentation, and no output schema, the description covers the essentials: what to record and when to call it. The only gap is explicit boundary-setting against the closely related write-siblings (remember, extract_memories, update_memory), which is implied by the correction-specific language but never stated.
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, setting the baseline at 3. The prose ('what situation, what mistake, what is the correct way') merely restates the parameter meanings rather than adding format, examples, or edge-case nuance, so the description adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Record a lesson learned from a correction') and enumerates the three captured elements ('what situation, what mistake, what is the correct way'), which map directly to the required schema parameters. This correction-specific framing clearly distinguishes it from generic memory siblings like remember and 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?
'Call immediately after the user corrects your work' provides an explicit, unambiguous trigger for invocation. However, it does not name alternatives (e.g., extract_memories or remember) or state when not to use this tool, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the filtered scope (kind='promp'), that results are timestamped, and that snippets are truncated to 200 characters. This exceeds a bare 'Search history' statement, though it stops short of noting ordering, case sensitivity, or lack of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is two efficient clauses that each add value: the first states the action and scope, and the second clarifies the return format. It is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters, full schema coverage, and no output schema, the description is complete enough for correct invocation. It explains what comes back (timestamped snippets truncated to 200 chars), and the schema covers input constraints. Missing details like ordering are minor for this simple search use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds the notion of keyword search but does not elaborate on the limit parameter or its interaction with results; the schema already documents query and limit adequately.
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 ('Search'), identifies the exact resource ('past user prompts'), and adds a distinguishing technical detail (kind='prompt'). It also describes the result shape (timestamped snippets truncated to 200 chars), making it easy to tell apart from broader memory-retrieval siblings like recall or get_recent_interactions.
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 scope is clear—use this to search past user prompts by keyword—but it is stated as a capability rather than explicit routing guidance. No when-not conditions or alternative tools are named, so an agent must infer when this should be chosen over sibling retrieval tools.
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 burden of exposing behavior. It discloses an important safety constraint ('Only writes inside that directory') and states what the tool returns (file path, size, JSON preview). It does not mention overwrite behavior or permissions, but it covers the most material side effect for an export tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the core action and target location; the second adds the safety guard and return-value summary. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description compensates by naming return values (file path, size, JSON preview). Combined with full parameter documentation in the schema and the directory-restriction detail, the agent has enough context to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both filename and includeInteractions. The description adds only the phrase 'optionally raw interactions,' which restates the includeInteractions parameter rather than adding new meaning. 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 identifies a specific action ('Export'), a concrete resource (preferences, lessons, profile, optionally raw interactions), and a target destination (JSON file under data/exports/). This clearly distinguishes it from sibling tools like import_memory or recall, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage — you would call this when you want a JSON export of memory data — but it does not explicitly state when to prefer this tool over alternatives like import_memory or get_recent_interactions. It gives clear context but no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: newest-first ordering, raw interaction scope, and the line format [id] ts [kind] content. It does not mention edge cases like empty results or pagination, but these are minor for a read-only list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The action, output format, filtering option, and use case are each covered efficiently, and the most important scoping information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a lightweight read-only tool with optional params and no output schema, the description adequately explains the return format, ordering, and purpose. The limit parameter is fully covered by the schema, leaving no critical gap, though the description could briefly note that results are capped.
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 provides 100% coverage for both parameters, including enums, defaults, and limits. The description adds only the notion of optional kind filtering, which is already present in the schema, so no significant extra meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the specific verb 'List', the resource 'recently captured raw interactions', ordering ('newest first'), and the exact output line format. This distinguishes it clearly from memory-management siblings like remember, recall, and consolidate.
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 phrase 'Use for auditing history or before distilling memory' gives clear context for when the tool is appropriate. It does not name alternative tools or state explicit exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It clearly discloses the key side effect: the source becomes superseded and provenance is recorded in metadata.merged_from. It does not mention reversibility or permissions, but the most important behavioral outcome for an agent to know is explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-formed sentence with no fluff. It front-loads the main action and then states the two important behavioral results (source supercoded, provenance recorded). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter merge tool with no annotations and no output schema, the description gives enough to call it correctly: what it does, which parameter plays which role, and the expected side effects. It could add nuances like whether the operation is reversible, but nothing essential is missing for a typical invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both sourceId and targetId clearly. The description adds context about the canonical relationship but does not add detailed parameter-level semantics beyond what the schema provides. 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 uses a specific verb ('Merge'), a clear resource ('memory'), and a precise scope ('duplicate/near-duplicate memory into a canonical one'). It distinguishes itself from sibling tools like forget, update_memory, and consolidate by clarifying that this operation is about canonicalization of near-duplicates.
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 implies when to use the tool: when a memory is a duplicate or near-duplicate of another canonical memory. It does not explicitly name alternatives or give when-not conditions, so it falls just short of a 5, but the trigger condition is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden and does it well: it explicitly discloses deterministic behavior, no LLM involvement, dry-run default, and the mutation path when apply=true. This gives an agent a reliable model of side effects before calling.
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 focused sentences front-load the core purpose and then give the key behavioral switch. Every clause earns its place; no filler or redundant restating of the schema.
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 definition is sufficient for correct invocation: purpose, defaults, mutation flag, and provenance are all covered, and the schema documents parameters. It would be slightly stronger if it described the shape of the returned memory candidates, since there is no output schema, but this is a minor gap for a proposal 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 coverage is 100%, so the schema already documents all four parameters. The description mainly restates the apply default and adds source=captured context, which is useful but does not add substantive meaning beyond the schema's own descriptions.
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 names a specific verb and resource: 'Scan recent captured interactions ... propose memory candidates'. It also differentiates from memory-write/recall siblings by emphasizing this is a deterministic scanning/proposal step, not direct storage or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly signals the intended workflow: run in dry-run to propose candidates, pass apply=true to persist with source=captured. It does not name sibling alternatives or exclusion conditions, but the use case is clear from the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It discloses the upsert semantics, the confidence increment on re-saving the same key, the 1.0 cap, and the return value (row id) needed by forget(). This is unusually transparent for a write 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?
Three tight, front-loaded sentences with no filler. Every sentence adds distinct value: what the tool does, how repeat calls behave, and what the caller receives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description covers the action, the uniqueness semantics, the confidence side effect, and the return contract. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful extra semantics by explaining that category+key together form the identity for the upsert and that re-saving the same key affects confidence, which is not captured in the schema property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Save or update a user preference' and specifies the uniqueness mechanism as 'category+key upsert'. This differentiates it from generic memory tools like update_memory and the recall/search siblings.
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 intended use case is implied: call this when you need to persist or update a user preference. However, it does not explicitly state when to prefer this over siblings like update_memory, save_lesson, or link_memory, nor does it describe exclusions.
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:

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

Score Badge

Copy to your README.md:

[![th-memory-mcp MCP server](https://glama.ai/mcp/servers/worakorn-prince/th-memory-mcp/badges/score.svg)](https://glama.ai/mcp/servers/worakorn-prince/th-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/worakorn-prince/th-memory-mcp'

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