velesdb-memory

Server Quality Checklist

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

Latest release: v5.2.0
Disambiguation4/5
Tools have distinct purposes (store, retrieve, delete, link, explain, extract), but recall_fused and recall_where both extend recall in different ways, which could cause slight confusion. Why also overlaps somewhat with graph search. Overall mostly clear.
Naming Consistency5/5
All tool names use lowercase with underscores for compound names (e.g., recall_fused, remember_extracted). A single word is used for basic operations (relate, forget, recall, remember, why). Naming is consistent and predictable.
Tool Count5/5
8 tools cover core memory operations (store, retrieve variants, delete, link, explain, extraction) without being excessive. The count is well-scoped for the server's purpose.
Completeness3/5
Missing a direct 'get memory by id' tool; retrieval relies on vector search or filters. No tool to list all links/edges. Core workflows are present but have notable gaps for precise retrieval.
Average 4/5 across 8 of 8 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1136 commits in the last 12 weeks
- Last stable release on September 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
This repository includes a glama.json configuration file.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not disclose whether the operation is destructive, if duplicate links are allowed, or if permissions are needed. The only behavioral hint is that it returns an edge ID.
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 exceptionally concise: two sentences with no superfluous content. Every word adds value.
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?
Despite having an output schema, the description lacks context about the nature of typed links, constraints, or the response format. It is insufficient for a tool with three fully required parameters and no annotations.
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 parameters are already documented. The description adds no extra meaning beyond 'typed link', and does not explain the 'relation' parameter or the expected format of links.
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 creates a typed link between two memories and returns the edge ID, which is a specific verb-resource pair. It distinguishes from siblings like recall, forget, and remember, which are unrelated operations.
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 on when to use this tool versus alternatives, or when not to use it. The description only says what it does, but provides no context about prerequisites or exclusions.
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 provided, so description carries full burden. It mentions ordering and optional filter but lacks disclosure of idempotency, side effects, performance, or behavior on no results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given schema coverage is full and output schema exists, description is largely complete. Minor missing detail (e.g., no results handling) but acceptable for a simple recall 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 baseline 3. Description adds 'most similar first' and explains filter is exact-match metadata, adding minimal value beyond 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?
Description clearly states verb 'Recall' and resource 'memories semantically similar to a query (vector)' with ordering. It's specific but does not explicitly differentiate from sibling tools like recall_fused or recall_where.
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?
Implies usage for semantic similarity recall with optional metadata filter, but no explicit guidance on when to use this vs alternatives, nor exclusions.
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?
Basic action is clear but no details about side effects (e.g., permanence, permissions) or consequences beyond deletion; no annotations to supplement.
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?
Extremely concise single sentence with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple deletion tool with an output schema; could include whether deletion is irreversible or requires confirmation.
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 single parameter 'id' is already well-described in the schema; the description adds no further semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a memory by id.' uses a specific verb and resource, clearly distinguishing it from sibling tools like recall, remember, or relate.
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?
Usage is implied as a deletion operation but no explicit guidance on when to use it vs. alternatives or prerequisites.
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 full burden. It discloses the extraction process, graph building, and return of fact IDs. It mentions prerequisites but does not detail potential side effects like overwriting or merging.
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, no redundant words, front-loaded with purpose and benefit. The prerequisite and return values are efficiently stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and presence of an output schema, the description covers inputs, process, prerequisites, and output. It could mention idempotency or duplicate handling, but is fairly complete.
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 baseline is 3. The description adds minimal value beyond schema descriptions; for 'text' it is nearly identical, and for 'metadata' it adds no extra context. No meaningful enhancement.
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 explicitly states the tool stores raw text by extracting atomic facts and building a fact-to-topic graph, differentiating it from sibling tools like `remember` and linking to `why`. The verb 'store' and resource 'passage of raw text' are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites (server started with extraction backend) and implies the tool is for automatic fact extraction and linking. It does not explicitly state when not to use or list alternatives, but context is clear enough.
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 full burden. It transparently describes the tool's behavior: finding the best-matching memory optionally scoped by a filter, and returning a connected subgraph through typed links with configurable max_hops. It does not disclose potential side effects or permissions, but for a read-like tool this is acceptable.
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 front-loads the purpose and efficiently conveys the tool's unique value proposition without 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?
Given the tool's complexity (graph traversal, fusing search methods) and the presence of an output schema, the description is fairly complete. It explains the process and result, though it could elaborate on the nature of 'typed links' or the subgraph structure.
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 mentions optional filter scoping and max_hops implicitly via 'reachable through typed links', but does not add significant new meaning beyond what the schema already provides for the parameters.
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 it explains a decision by finding a best-matching memory and returning a connected subgraph of related memories via typed links. It distinguishes itself from siblings like 'recall' by highlighting the fusion of vector, ColumnStore, and graph search to surface context beyond plain similarity.
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 usage when a plain similarity search is insufficient, providing context for when the tool is most valuable. However, it does not explicitly state when not to use it or directly compare with sibling tools like 'recall_where' or 'recall_fused'.
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 provided, so description bears full burden. Discloses non-destructive behavior, effect of graph walking, tuning parameters, and temporal timeline addition. Mentions noise from higher hops.
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?
Compact but informative; front-loaded with key concept. Every sentence adds value, though slightly dense. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (multi-hop, temporal, filtering, tuning) and presence of output schema, description covers all essential aspects. Could mention default limit more explicitly, but still 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?
Schema coverage 100%, baseline 3. Description adds significant value: explains defaults, interaction between hops and graph_boost, why larger limit benefits multi-hop, and how date_field enables timeline.
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?
Clearly states it's a fused vector+graph recall, distinguishes from siblings like `recall` and `recall_where`, and explains the tri-engine ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (multi-hop reasoning, temporal chains) and when to omit parameters for defaults. Does not mention when not to use, but provides enough context.
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 full burden for behavioral traits. It explains the fused nature (vector + ColumnStore predicates), the filter format, and result ordering ('Most similar first'). It does not explicitly state it is a read-only operation or mention pagination, but the core behavior is transparent enough for an agent.
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 extremely concise: three sentences that front-load the key concept ('Fused recall'), immediately followed by filter format and usage example. Every sentence is informative with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (vector + structured constraints) and that an output schema exists, the description is reasonably complete. It explains the AND combining logic, gives a concrete example, and mentions ordering. It does not detail response format (covered by output schema) or edge cases, but covers the essential context for selection and invocation.
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 description coverage is 100%, so baseline is 3. The description adds meaning by explaining the filter structure as {field, op, value} with supported ops and an example date window, which is more intuitive than the formal schema definition. This enriches the agent's understanding beyond the parameter 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 clearly states it performs 'fused recall' combining vector semantic search with structured metadata predicates, explicitly mentioning support for ranges and comparisons beyond equality. It distinguishes from sibling 'recall' by specifying the structured filter capability, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use for time-windowed or numeric-scoped recall' with an example (facts about a topic with `ts` in a date range). It implies that for equality-only filters, a simpler tool like 'recall' might be appropriate, but does not explicitly exclude other scenarios or compare to all siblings like 'recall_fused'.
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 full burden. It discloses that storage is durable, TTL survives restarts, and returns a stable id. However, it does not mention behavior on duplicates or potential 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 three sentences, front-loaded with the core action, and every sentence adds value. It is efficient and well-structured.
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?
With 4 parameters, full schema coverage, and an output schema (not shown), the description covers purpose, all parameter behaviors, and the return value (stable id). It is complete for a store operation.
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%, but the description adds meaning: explains TTL_seconds' durable nature and default fallback, links as typed relations, and metadata for filtering. This adds 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 clearly states the primary action: 'Store a fact in durable local memory.' It distinguishes from siblings by mentioning optional linking and metadata tagging, which are unique features of this tool.
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 context on when to use optional parameters like links and metadata for later filtering, and explains TTL behavior. It does not explicitly mention when not to use this tool, but the context is sufficient.
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:

[![VelesDB MCP server](https://glama.ai/mcp/servers/cyberlife-coder/VelesDB/badges/card.svg)](https://glama.ai/mcp/servers/cyberlife-coder/VelesDB)

Score Badge

Copy to your README.md:

[![VelesDB MCP server](https://glama.ai/mcp/servers/cyberlife-coder/VelesDB/badges/score.svg)](https://glama.ai/mcp/servers/cyberlife-coder/VelesDB)

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/cyberlife-coder/VelesDB'

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