AI Memory Hub

by vib28

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: v0.2.0
Disambiguation5/5
Each tool targets a distinct operation: policy introspection, search, file read, write/propose, update/supersede, delete, integrity audit, and index rebuild. Memory_search vs memory_read and propose vs supersede are related but clearly separated by descriptions.
Naming Consistency5/5
All tools share a consistent memory_ prefix and use clear snake_case action suffixes such as search, read, propose, supersede, forget, audit, and reindex. The pattern is predictable and uniform.
Tool Count5/5
Eight tools is well within the ideal range and appropriate for a persistent memory hub. Each tool covers a distinct lifecycle or maintenance need without unnecessary bloat.
Completeness4/5
The core memory lifecycle is well covered: policy, search, read, create/propose, update/supersede, delete, audit, and reindex. The only minor gap is that review-mode approvals/rejections have no dedicated tool, though this is likely handled outside the agent workflow.
Average 3.6/5 across 8 of 8 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 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 at all, the description carries the full burden. It does disclose the important side effects: auto mode persists the memory, review mode queues it. However, it omits details such as what validation means, what happens on invalid input, and whether the operation is idempotent or reversible.
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 very short and front-loaded, with both sentences contributing unique information. It is concise, though the extreme brevity comes at the cost of necessary behavioral and parameter context.
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 five parameters, no output schema, and no annotations, this description is not complete enough. It leaves mode selection, parameter meaning, validation behavior, and return values entirely unaddressed, requiring the agent to rely on guesses.
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 itself does not explain any of the five parameters. The agent is left to guess what 'text', 'kind', 'tag', 'subject', and 'target_path' represent, with no schema descriptions to compensate.
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 ('Validate') with a clear resource ('durable memory candidate') and adds tangible behavior: auto mode stores, review mode queues. This makes the tool's core function clear even though it does not directly contrast with sibling tools like memory_policy or memory_supersede.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions two modes but does not explain when either mode applies, how mode is chosen, or when an agent should use this tool instead of siblings like memory_read, memory_forget, or memory_supersede. There is no when-to-use guidance or exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Search persistent memory' and gives a usage preference; it does not state whether the operation is read-only, how results are ranked, how limit is applied, or what happens on no matches.
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 short, front-loaded, and free of filler. Both sentences earn their place, though the content is too sparse in behavioral and parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters, no annotations, and minimal description, the tool definition is incomplete. The output schema may cover return values, but an agent still lacks guidance on how queries are matched, how limit affects results, and when to choose memory_search over sibling tools.
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 mentions no parameters. Query and limit are left entirely to schema names and types, with no guidance on query construction, matching behavior, or limit semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Search') and resource ('persistent memory'), and the instruction to prefer it before opening files gives concrete context. It does not explicitly differentiate from sibling memory_read, but the search action is distinct enough to understand basic purpose.
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 'Prefer this before opening files' provides explicit when-to-use guidance. However, it does not mention when not to use the tool or compare it with sibling memory tools like memory_read, so it lacks full alternative routing.
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?
The description discloses an important behavioral trait: in review mode the replacement is queued for approval. With no annotations, this is valuable. However, it does not explain what happens outside review mode, whether the old memory is deleted or archived, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The key behavioral note about review mode is included without unnecessary elaboration.
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?
This is a mutation tool with no annotations, no output schema, and six parameters at zero schema coverage. The description is too sparse to guide correct invocation, especially regarding what the parameters mean and what happens outside review mode.
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 does not compensate. It hints that old_memory_id refers to an old memory and text is the replacement content, but it leaves kind, tag, subject, and target_path semantically undefined. Required parameters are not explained beyond the overall operation.
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 and resource: 'supersede an old memory'. This clearly indicates a replacement operation, which is semantically distinct from siblings like memory_forget or memory_propose. However, it does not explicitly name or contrast the sibling tools, so it lacks some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over the other memory tools. It mentions review-mode behavior but does not state when superseding is appropriate versus proposing or forgetting. No alternatives or exclusions are given.
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. 'Disposable' and 'from the Markdown vault' add useful context that the index is derived and reconstructable. However, it does not disclose whether the rebuild is destructive to the current index, whether it blocks, or any time/resource implications.
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 sentence that front-loads the action ('Rebuild') and includes the key object and source. There is no wasted wording; every phrase 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 zero-parameter maintenance tool, the description states the core purpose and data source, which is likely sufficient for selection. It omits explicit when-to-use guidance and side-effect details, though the 'disposable' qualifier partially compensates. The lack of an output schema means return values need not be described.
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 description is not required to explain parameter behavior. It does add context about the index being disposable and derived from the vault, which helps an agent understand what the tool affects. This meets the baseline for a zero-parameter tool.
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 ('Rebuild') acting on a well-defined resource ('disposable SQLite search index') with a clear source ('from the Markdown vault'). It is clearly distinct from sibling tools like memory_search or memory_read, though it does not explicitly name any alternative or differentiator.
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 the tool is for rebuilding the search index, but does not explicitly state when to use it (e.g., when the index is stale or after vault changes) or when to prefer an alternative. No exclusions or alternative tool references are given, leaving the 'when' 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?
With no annotations, the description carries the behavioral disclosure burden. It clearly states the destructive action and the target ('one persistent memory'), which is essential. But it does not disclose whether the deletion is permanent/irreversible, whether related references are affected, or any confirmation/auth requirements for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word earns its place: verb, resource, scope, and identifier type are all present and immediately readable.
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 (one parameter, no output schema, no annotations) and the description covers the essential call. However, it leaves gaps around the outcome/return value, irreversibility, and how this deletion relates to sibling operations like memory_supersede or memory_policy. A brief note on permanence would make it fully 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 schema only provides the parameter name and type for memory_id with 0% description coverage. The description adds meaningful semantics by specifying it is a 'stable memory ID' for a persistent memory, helping the agent understand what value to supply. It omits format/examples, but for a single string parameter this is 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 ('Delete'), names the resource ('persistent memory'), and identifies the exact selection criterion ('stable memory ID'). This makes the tool's purpose unmistakable and distinguishes it from sibling tools like memory_search, memory_read, and memory_supersede, which are not destructive deletion operations.
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 usage context is implied: call this tool when you have a stable memory ID and want to delete that memory. However, the description does not explicitly say when not to use it or provide alternatives, such as memory_supersede for updating/replacing a memory rather than deleting 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 provided, the description carries the behavioral transparency burden. It clearly signals a read-only introspection operation via 'Return' rather than 'set', 'update', or 'create', and it specifies the two pieces of state returned: retention policy and active write mode. This is sufficient for a zero-parameter getter.
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 contains exactly the necessary information: the action and the returned data. There is no filler, no redundancy, and no buried context.
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 no-argument, read-only policy tool with an output schema, the description is nearly complete. It could briefly explain what 'active write mode' means or note when to prefer this over memory_audit, but nothing required to invoke the tool correctly is missing.
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 no parameters and schema coverage is trivially complete, so there are no argument semantics for the description to add. The baseline of 4 for a zero-parameter tool 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 opens with a specific verb ('Return') and names a precise resource: the automatic persistent-memory retention policy and active write mode. This is distinct from the sibling memory_read, memory_search, memory_propose, and memory_audit tools, so an agent can identify what this tool is for.
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 call this tool instead of memory_read, memory_search, or memory_audit. There are no exclusions, prerequisites, or routing hints, so the intended usage context must be inferred from the tool name and description.
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 present, so the description carries the full burden of disclosing behavioral traits. It explicitly discloses non-modification and specifies the scope as file/index integrity, which is valuable safety-relevant context. It does not describe output format or error behavior, but for a zero-parameter audit the core behavioral trait is adequately disclosed.
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 compact sentence that front-loads the action and includes the key non-modification caveat. Every word earns its place, with no filler, redundancy, or unnecessary elaboration.
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 parameters, the description is nearly complete for invocation: it states what the tool checks and its side-effect profile. The main gap is the lack of detail about return values or behavior when integrity issues are found, but that is not essential for an agent to select and invoke a zero-argument audit.
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 input schema has zero properties, so there are no parameter semantics to document. Per the zero-parameter baseline, the description need not add parameter detail, and the schema description coverage is effectively complete. The description also confirms the tool requires no configuration.
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 ('Check') and resource ('file/index integrity'), and explicitly frames the operation as non-modifying. This clearly distinguishes it from sibling tools that mutate memory, such as memory_forget and memory_supersede, and from memory_read which would retrieve content rather than audit integrity. The purpose is immediately apparent.
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 use when a read-only integrity check is needed and the 'without modifying memory' qualifier suggests it is safe to run. However, it does not explicitly state when not to use it or name alternatives such as memory_reindex for repairing integrity issues or memory_read for retrieving memory content. Usage routing is left mostly to inference.
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 behavioral transparency burden. 'Read' clearly communicates a non-mutating operation, 'exactly one ... Markdown file' scopes the side-effect surface, and 'Path must be inside the vault' adds an important security boundary. It does not detail error behavior for missing or out-of-vault paths, but the output schema covers the return shape.
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 sentences carry the entire definition with no filler. The main action is front-loaded, and the critical constraint follows immediately.
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 one-parameter read tool with an output schema, the description covers the purpose, the target resource, and the critical path-boundary rule. The only visible gap is explicit sibling differentiation, which is more of a usage-guidelines issue than a completeness failure.
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 schema only provides a 'path' string with no description, so the description supplies the key semantic constraint: the path must be inside the vault and point to a memory Markdown file. It does not specify relative versus absolute path format or explicitly require a .md extension, but for a single simple parameter this is adequate compensation for the 0% 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 and resource: 'Read exactly one memory Markdown file.' It also adds a clear scope qualifier ('exactly one') and a boundary ('Path must be inside the vault'), which distinguishes it from broader search or batch operations among the 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you know a path and need to read a single memory file, use this tool. However, it does not explicitly mention alternatives such as memory_search for finding memories when the path is unknown, so the routing guidance is left to inference.
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:

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

Score Badge

Copy to your README.md:

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

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/vib28/ai-memory-hub'

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