Memory Vault

by MihaiBuilds

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.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: recall for searching, remember for storing, forget for soft-deleting, purge_forgotten for permanent cleanup, move_memory for relocating, and memory_status for health checks. There is no meaningful overlap or ambiguity between any pair of tools.
Naming Consistency4/5
Most tool names follow a verb-first pattern (recall, remember, forget, purge_forgotten, move_memory), which is predictable and readable. memory_status breaks the pattern slightly by being noun-first, but the naming is still clear and consistent in style overall.
Tool Count5/5
Six tools is a well-scoped size for a memory vault server, covering querying, writing, deletion, recovery/cleanup, organization, and monitoring without redundancy. Each tool earns its place and there is no sense of bloat or thinness.
Completeness4/5
The core memory lifecycle is well covered: store, search, soft-delete, permanent purge, move between spaces, and inspect status. Minor gaps exist, such as updating or editing an existing memory's content and creating spaces directly through the server, but these are workable limitations rather than fatal dead ends.
Average 4.6/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 28 of 28 community issues answered or closed in the last 6 months
- 101 commits in the last 12 weeks
- Last stable release on August 23, 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.
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 provided, the description carries the full burden of behavioral disclosure. It does add useful detail by saying 'The text is embedded and stored as a searchable chunk,' which explains the storage behavior beyond a bare 'store' verb. However, it does not mention potential side effects, failure conditions, deduplication behavior, or what happens after storage, leaving some uncertainty for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise and front-loaded with the primary purpose. The Args section is compact and necessary given the schema's lack of descriptions. The sentence 'Use this to save important information...' is slightly redundant with the opening line but does not meaningfully hurt readability.
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 description covers the tool's purpose, storage behavior, and all parameter meanings, and an output schema exists so return-value details are not required. It does not enumerate valid memory spaces or relate this tool explicitly to recall, forget, and other siblings, but for a straightforward write operation it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must fully document parameters. It does so clearly, defining text, space, source, and speaker, including all defaults and the allowed speaker values ('human' or 'assistant'). This fully compensates for the bare 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 opens with 'Store a new memory in the system,' naming a specific verb and resource. It clearly distinguishes this as the write operation among siblings like recall and forget, and adds 'Use this to save important information, decisions, or knowledge' to reinforce the intended use.
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 clear usage context: 'Use this to save important information, decisions, or knowledge.' It does not explicitly name alternatives or state when not to use the tool, but the sibling set is intuitive enough that an agent can infer this is the right tool for storing rather than retrieving or deleting memories.
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 full behavioral burden and does well: it discloses that the chunk is removed from search results, persists in the database, has importance set to 0, and gets marked in metadata. This goes well beyond a generic 'delete' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with the key action front-loaded and each subsequent sentence adding meaningful detail. The Args block is clean and immediately useful.
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 one-parameter tool with an output schema present, the description is complete: it explains the operation, its effects, and the only input. No critical behavioral or usage detail is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by defining chunk_id as 'The UUID of the chunk to forget.' This adds meaning beyond the schema's bare type and title.
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: 'Soft-delete a memory chunk by ID.' The soft-delete framing clearly distinguishes it from the sibling tool purge_forgotten, which implies permanent deletion.
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 this tool by explaining the soft-delete behavior: the chunk is removed from search results but remains recoverable. However, it does not explicitly name alternatives or state when not to use it, so the usage guidance is inferred rather than direct.
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. 'Get' and 'Returns' clearly imply a read-only, non-destructive operation, and the listed return categories describe observable behavior. It does not discuss auth or side effects, but for a zero-parameter status endpoint this is a minor gap.
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 only two short sentences, with the primary action front-loaded and the return payload summarized immediately. Every sentence adds useful information and there is no filler or redundancy.
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 no-argument introspection tool with an output schema, the description covers the purpose and the categories of returned data. An agent has everything needed to select and 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?
The tool has zero parameters, so the baseline is 4 and no parameter-level documentation is needed. The description adds no parameter semantics, but none are required.
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 the specific verb 'Get' with a clear resource ('current status of the memory system') and enumerates exactly what is returned (database health, chunk counts, embedding model info). This clearly differentiates it from the mutation-oriented sibling tools recall/remember/forget/purge_forgotten/move_memory.
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 intended use is obvious: call this when you need the memory system's current health and statistics. It does not explicitly name alternatives or when-not-to-use conditions, but the sibling tools are all memory operations, so the context makes the choice unambiguous.
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 carries the full behavioral burden, and it delivers: it explains hybrid search (vector + full-text + RRF), query enrichment, relevance ranking, token budgeting to avoid context flooding, and the trade-off of raising ef_search. This gives the agent a strong model of what happens when the tool is invoked.
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 well organized with a brief behavioral overview followed by a clear Args list. Every sentence adds useful information, and the ef_search guidance is valuable rather than filler. The structure is front-loaded and scannable.
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 six parameters, no annotations, and no inline schema descriptions, the description covers all necessary invocation details: defaults, formats, filtering, and tuning behavior. The output schema exists, so not detailing return values is acceptable. The description is complete enough for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 document every parameter, and it does. It explains query, spaces, since with ISO example, limit and max_tokens with defaults, and ef_search with a concrete tuning recommendation. This fully compensates for the absent schema 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 opens with 'Search your memories for information relevant to a query,' which clearly states a specific verb, resource, and intent. The sibling tools are all memory management operations (remember, forget, move), so this retrieval-focused description immediately distinguishes recall from 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 makes clear this tool is for searching and retrieving memory, and it gives specific guidance on when to increase ef_search. However, it does not explicitly state when to use this tool instead of the sibling tools, nor does it mention alternatives or exclusions. Usage context is implied rather than spelled out.
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 carries the full burden of behavioral disclosure. It explains that the memory retains its content and embedding, that only its space membership changes, and that knowledge-graph entries are rebuilt in the target space so graph and search agree. This reveals important side effects beyond the tool name.
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 tight and well-structured: purpose, behavioral effect, prerequisite, then arguments. Every sentence earns its place, and no redundant or vague filler is present.
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 two-parameter mutation tool with an output schema, the description covers the operation, side effects, prerequisites, and parameter meanings. Nothing critical is missing, and return-value details are handled by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the Args section must compensate. It does: chunk_id is defined as the UUID of the chunk to move, and target_space is defined as the name of the destination space. This adds real meaning beyond the bare schema titles.
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: 'Move a stored memory into a different space.' It clarifies what changes (space) and what stays the same (content and embedding), making the tool's purpose distinct from siblings like recall, remember, and forget.
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 clearly states the use case and an important prerequisite: the target space must already exist, and it points the user to the dashboard or API to create one. It does not explicitly call out alternatives or when-not-to-use scenarios, but the usage context is unambiguous.
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 carries the full burden of behavioral disclosure, and it does so thoroughly. It states the operation is permanent and irreversible, explains that it is never automatic, and reassures that it only touches forgotten memories. It also includes the default retention period as a safety behavior, which is valuable context for an agent deciding to invoke 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 front-loaded with the primary action and then uses compact paragraphs for contrast, safety guarantees, and parameter semantics. Each sentence earns its place: even the 'dead row' background explains why the tool exists and supports the usage decision. It is detailed without being bloated.
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 destructive one-parameter tool with an output schema present, the description is complete. It covers what the tool does, when to use it, how the parameter behaves, the safety default, and the boundary conditions. No essential information for invoking it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It fully explains `older_than_days`: only forgotten memories at least that many days old are purged, the default preserves a month of recovery, and passing 0 purges all forgotten memories regardless of age. This is exactly the semantic detail the schema lacks.
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: 'Permanently delete memories that were forgotten a while ago.' It clearly distinguishes itself from `forget`, which it explicitly identifies as a soft delete, and marks this tool as the irreversible counterpart. An agent can tell exactly what this tool does and how it differs from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with `forget`, explaining that `forget` keeps the row for recovery while this tool is the 'deliberate, irreversible half.' It also clarifies when it is appropriate: only for memories already marked forgotten, never active ones, and never automatically. This gives an agent clear guidance on when to choose this tool over alternatives.
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-vault MCP server](https://glama.ai/mcp/servers/MihaiBuilds/memory-vault/badges/card.svg)](https://glama.ai/mcp/servers/MihaiBuilds/memory-vault)

Score Badge

Copy to your README.md:

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

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/MihaiBuilds/memory-vault'

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