memory-garden

by drephantom

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation3/5
Most tools have clear roles, but discover_cognitive_shifts and find_change_candidates both surface 'change candidates' and could be confused; search_sources and find_interval_events also overlap in time-based retrieval. The descriptions help clarify scope, but the boundaries are not always immediately obvious.
Naming Consistency4/5
All names use lowercase snake_case and mostly follow a verb_noun pattern such as search_sources, get_topic_timeline, and find_interval_events. Minor inconsistency exists between verbs like discover, find, and search for similar retrieval actions, but the overall pattern remains predictable.
Tool Count5/5
Nine tools is a well-scoped size for a cognitive retrospection domain. Each tool contributes to a distinct stage of the workflow, from source discovery through evidence retrieval to the final ask_garden synthesis, with no obvious bloat.
Completeness4/5
The toolset covers the main cognitive backtracking pipeline: search sources, read them, build timelines, identify change candidates, find interval events, gather hypothesis evidence, and check user verdicts. A minor gap is that there is no explicit tool to record or update user confirmations/verdicts, but this may be handled outside the server.
Average 3.5/5 across 9 of 9 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI 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.
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?
With no annotations, the description must carry behavioral disclosure. It does reveal that the output is a set of candidates, not final decisions, and that user confirmation is expected ('需用户确认'). However, it does not clarify whether the operation is read-only, what the 'recent' candidate notion means behaviorally, or how the tool treats records beyond the database-wide scan.
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 short and front-loads the core purpose, which is good. However, the second clause, '较近记录只是 recent 候选，需用户确认', is awkward and ambiguous, mixing languages and leaving the exact meaning of 'recent 候选' unclear. It is concise in length but not in clarity.
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 one optional parameter and no annotations, the description is too thin. It covers the general purpose but fails to explain the meaning of 'cognitive shifts', how 'recent candidates' relate to the full-result set, when to use it over find_change_candidates, or what the 'limit' parameter controls. The output schema exists, so return-value structure does not need elaboration, but the behavioral and usage gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the only parameter, 'limit'. The tool name and phrase '全库' imply a scan, but there is no explanation that limit caps the number of returned candidates or how the default of 5 behaves. The description adds no meaning beyond the bare 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 ('discover') against a specific resource ('entire database') with a clear object ('potentially overlooked change candidates'). It gives some scoping ('全库', the whole database), which helps differentiate from sibling tools, though it never explicitly compares itself to find_change_candidates or clarifies the relationship between 'cognitive shifts' and 'change candidates'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '需用户确认' hints that results require user confirmation, but the description gives no explicit guidance on when to choose this tool over siblings like find_change_candidates or get_topic_timeline. There are no stated exclusions, prerequisites, or alternative conditions, so an agent is left to infer usage context.
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 full burden for behavioral disclosure. It adds a useful interpretive warning that temporal adjacency does not mean causation, and the word 'candidates' hints at non-definitive output. However, it does not disclose ordering, filtering behavior, or any side effects, which is acceptable given the output schema exists.
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 fluff. The core purpose is front-loaded, and the causality warning earns its place as a meaningful interpretive note. It is appropriately sized for its scope.
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 description gives only the core search action and an interpretive caveat. It does not clarify what query or limit do, what date format to use, or how this tool differs from the many siblings in the context. Given the tool has 4 parameters and a rich sibling set, more elaboration is needed for an agent to invoke it correctly in the right situation.
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 0%, so the description must compensate. It references 'two date endpoints,' which maps to date_from and date_to, but provides no meaning for query or limit. The schema's parameter names alone may be insufficient for an agent to understand how to form a query.
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 and resource: search for experience/decision/event candidates within a date interval. It clearly distinguishes itself from siblings like get_topic_timeline by focusing on event candidates rather than a timeline, though it does not explicitly name the sibling it is not.
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 prefer this tool over the listed siblings such as find_change_candidates or get_topic_timeline. The caveat about temporal adjacency not implying causality is interpretive advice, not usage context.
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 behavioral disclosure burden. It does add useful traits: the operation is local, deterministic, and returns cited structured conclusions. However, it does not disclose whether the agent performs any writes, what sources it consults, or any limitations, which leaves gaps for a complex agent tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. Every clause adds meaning: the operation, its mode, and its return format are all present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are covered by structured data. However, the description is thin for a complex 'full cognitive retrospective Agent' with several similar siblings, and lacks any context about what the agent does with the question or how it relates to the other tools.
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 0%, so the description must compensate for documenting the 'question' parameter, but it does not. It provides no guidance on question format, scope, language, or what makes a well-formed input for this agent.
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 ('run') and resource ('full cognitive retrospective Agent'), and clarifies that it returns structured conclusions with citations. It does not explicitly differentiate from siblings, but the agent-based framing is distinct from the search/read/discovery tools listed.
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 the sibling tools such as discover_cognitive_shifts, search_sources, or get_topic_timeline. The phrase 'local deterministic path' hints at a specific mode of operation but not at selection criteria.
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 at all, the description must carry the transparency burden. It does add behavioral nuance: results are time-ordered and the newest entry is only a 'recent candidate', not a final truth. It does not mention permissions, side effects, or return behavior, but this appears to be a read-only timeline tool and an output schema exists.
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 compact and front-loaded with the core behavior, followed by one interpretive caveat. It avoids unnecessary words, though the mixed-language phrase 'recent 候选' is somewhat cryptic and could be more clearly phrased.
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 two-parameter tool with an output schema, the description covers the core purpose and a key behavioral nuance. It is incomplete because the 'limit' parameter is unaddressed and the 'recent candidate' concept is left unexplained, but the output schema reduces the need to describe return values in detail.
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 0%, so the description must explain the parameters. It indirectly explains 'topic' through '同一主题', but it never explains the 'limit' parameter, its default, or how it affects the returned timeline. This leaves the optional parameter semantically undocumented.
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 and resource: it chronologically organizes the historical expressions of the same topic. This is clearly distinct from search or source-reading siblings, though it does not explicitly name any alternative or 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 chronological 'same topic' framing implies when this tool is appropriate, and the caveat about the latest item being only a 'recent candidate' hints at how to interpret results. However, it does not explicitly state when not to use it or which sibling tool to prefer instead.
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 behavioral burden. The verbs '检索' and '返回' clearly indicate a non-destructive read operation that returns candidate IDs, which is useful context. It does not disclose authentication needs, rate limits, or details such as pagination or how time-window boundaries are handled.
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?
One compact sentence conveys the action, scope, filtering dimensions, and return format with no filler. It is front-loaded with the verb and ends with the concrete return value.
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 covers the core selection criteria (keyword and time window) and return format, and an output schema exists for return values. However, with no annotations and no parameter-level docs, it leaves limit semantics and date format unspecified, so it is only minimally complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning for the main parameters: '关键词' maps to query and '时间窗' maps to date_from/date_to. It does not explain the limit parameter or the expected date string format, leaving some of the schema under-explained.
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 ('检索' / search), a resource ('用户本人的记录候选' / the user's own record candidates), and a constraint set (keyword plus time window), with an explicit return of '[A{id}]' IDs. It is clear enough to be distinguished from siblings like search_hypothesis_evidence, though it does not name those alternatives explicitly.
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 is implied: use this tool when searching the user's own record candidates by keyword and time window. However, there is no explicit guidance about when not to use it or how it compares with sibling search tools such as search_hypothesis_evidence or get_topic_timeline.
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 of behavioral disclosure. It does disclose a key interpretation rule ('wording differences do not equal change') and implies the output is a set of endpoint pairs, which gives meaningful insight into the algorithm's behavior. It does not mention whether the tool is read-only, whether it requires special permissions, or any other operational constraints, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no filler: the core purpose is front-loaded, and the caveat about wording differences follows naturally. Every clause adds value, and the structure is easy to parse quickly.
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 simple (2 params, no nested objects) and an output schema exists, so the description need not detail return formats. However, the description does not explain the 'endpoint pair' concept, clarify the 'limit' behavior, nor situate the tool among its eight siblings, leaving an agent to guess when to choose this over alternatives.
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 0%, so the description must compensate for both parameters. It adds meaning to 'topic' by specifying it should be a clear/definite theme, but 'limit' is completely unaddressed and its semantics (max number of candidates, rank ordering) must be inferred from the schema's default value. A more thorough description would explain both parameters explicitly.
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 ('提出变化候选端点对' — propose change candidate endpoint pairs) and its unique resource/format ('最早端点 × 最近端点'), which distinguishes it from siblings like find_interval_events or get_topic_timeline. It also adds a precise boundary condition ('措辞差异不等于变化'), reinforcing what counts as a change, making the purpose unambiguous.
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 phrase '围绕明确主题' (around a clear topic) implies that this tool is appropriate when the user has a well-specified theme, giving some usage context. However, it does not explicitly name alternatives or state when not to use this tool compared to the listed siblings, leaving the routing decision partially to inference.
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 carries the full behavioral burden. It clarifies this is a read operation and constraints the scope to sources discovered in the current round, but it does not describe side effects, prerequisites beyond reading, or output behavior. The output schema likely covers return values, so this is adequate but not rich.
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?
A single front-loaded sentence that states the action, target, returned data, and a critical usage requirement. 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?
For a simple tool with one required parameter and an output schema, the description is nearly complete. The main omission is explicit atom_id semantics, but the rest of the invocation context is clear enough.
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 0% and the description never mentions atom_id or how it maps to a source. The parameter name and type provide some inference, but the description adds no explicit semantic guidance beyond the tool name. This is a clear gap for a single required parameter.
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 a specific verb ('读取' / read), a specific resource ('本轮已发现来源' / sources discovered in this round), and what is returned ('原文与定位信息' / full text and location information). It also distinguishes itself from the sibling search_sources by emphasizing pre-discovered sources.
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 an explicit usage condition: '引用前必须先读' (must read before citing). It clearly signals when to use the tool, though it does not explicitly name alternatives or state when not to use it.
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 burden, and it adds value by specifying the allowed stance values and requiring both sides to be called. These are non-obvious behaviors not visible in the schema. It could be more explicit about read-only semantics, but '检索' and the search-oriented name imply a non-mutating 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 entire guidance is one compact sentence that front-loads the purpose and then packs in the stance values and the mandatory two-call pattern. There is no filler or 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?
For a simple three-parameter tool with an output schema, the description covers the core invocation details: purpose, stance values, and the requirement to call both sides. The main omission is the meaning of the optional 'query' parameter, but because it has a default and is not required, this does not block correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies that 'stance' takes either support or challenge and interprets 'hypothesis' as a causal hypothesis, which is meaningful given 0% schema description coverage. However, it does not explain the optional 'query' parameter at all, leaving one parameter semantically unaddressed.
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 searches evidence for a causal hypothesis and divides the search by stance ('support' or 'challenge'), giving a specific verb and resource. It does not explicitly compare itself to siblings such as search_sources, but the stance-based scope is enough to identify its distinct role.
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 instruction '两侧都必须调用' is an explicit, actionable usage rule: the agent must invoke the tool with both support and challenge stances. It gives clear context for how to use the tool, although it does not mention when to prefer it over sibling 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, the description carries the behavioral burden. It plainly states this is a read operation ('读取') and adds a meaningful policy: denied explanations must not be reused. This goes beyond the tool name and tells the agent a consequence of the returned verdicts.
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 short clauses, no filler. The core read action comes first, and the important reuse constraint is appended second. 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 one-parameter read tool with an output schema, the description covers the action, the target resource, and the key policy. It lacks only explicit usage guidance relative to sibling tools, but the tool is otherwise callable without further clarification.
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 0%, so the description must clarify the parameter. It does so by binding 'topic' to the subject of the verdicts ('用户对该主题此前的确认/否认判定'), which adds semantic meaning beyond the schema's bare 'Topic' label.
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 starts with a specific verb ('读取' / read) and a specific resource: the user's prior confirm/deny verdicts for the topic. This clearly differentiates it from sibling tools like search_sources or get_topic_timeline, which address different information.
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 second clause, '被否认的解释不得复用', implies the tool should be consulted before reusing an explanation, but no explicit when-to-use or when-not-to-use guidance is given. It does not name alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/drephantom/memory-garden'

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