AIVectorMemory

by Edlineas

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.4.5
Disambiguation5/5
Each tool has a clear, distinct purpose: memory storage/retrieval/deletion, code knowledge graph, README generation, session status, task management, and issue tracking. No two tools overlap significantly in functionality.
Naming Consistency4/5
All tool names use lowercase with underscores where needed, but they mix verb forms (forget, recall, remember) and noun forms (graph, readme, status, task, track). While consistent in style, the pattern is not strictly verb_noun, causing minor inconsistency.
Tool Count5/5
9 tools is well-scoped for a memory/vector database server that also handles code knowledge, tasks, issues, and session status. Each tool earns its place without redundancy.
Completeness4/5
The tool set covers core CRUD operations for memories, tasks, issues, and graph management. Minor gaps exist, such as lacking a bulk memory recall or listing all memories, but the overall surface is sufficient for the domain.
Average 3.4/5 across 9 of 9 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 7 of 9 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits like permanence, reversibility, authentication needs, or side effects. It only states 'delete' with no further context.
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 a single sentence, which is concise but sacrifices completeness. It is front-loaded but lacks sufficient detail to be maximally useful.
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 6 parameters (many aliases) and no output schema, the description is inadequate. It does not explain how to use tags for batch deletion, the scope parameter, or the alias relationships.
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 no additional meaning beyond the schema, not explaining relationships between id, memory_id, ids, or tags. Aliases are noted in schema but not in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除一条或多条记忆。' states the verb (delete) and resource (memories), but lacks specificity about which memory system or context. It does not distinguish from sibling tools like 'remember' or 'recall'.
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 vs alternatives like 'remember' for creating or 'recall' for retrieving. No indication of prerequisites or when not to use.
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 must disclose behavioral traits. It mentions supported operations but doesn't cover mutation consequences, permissions, or performance characteristics.
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 concise, consisting of two sentences that cover the main purpose. However, given the tool's complexity, it could be better structured.
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 19 parameters and no output schema, the description is insufficient. It mentions CRUD and traversal but lacks details on return values, error handling, or prerequisites.
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 does not add additional meaning beyond what the input schema already provides for each parameter.
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 that the tool manages a code knowledge graph with operations like CRUD for nodes/edges, multi-hop traversal, and expiration detection. It distinguishes itself from sibling tools which are about memory management, not graph 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 explicit guidance on when to use this tool vs alternatives or when not to use it. Given the complexity and many parameters, the description lacks usage 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 present, and the description does not disclose behavioral traits such as side effects, idempotency, permissions, or error handling. For a tool with multiple mutating actions, this is insufficient.
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, clear sentence that efficiently conveys the tool's purpose without any unnecessary words. It is well-structured and front-loaded.
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?
Given the tool has 17 parameters, no output schema, and no explanation of return values or pagination behavior (e.g., 'list' returns abstract by default), the description is too minimal to provide complete context for effective 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?
Schema description coverage is high (88%), so the schema already explains most parameters. The tool description adds minimal additional meaning beyond listing action names, but does not enhance understanding of how parameters interact.
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 is for issue tracking and lists the five supported actions (create, update, archive, delete, list), making the purpose clear and distinct from siblings like 'task' or 'remember'.
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 provided on when this tool should be used versus alternatives such as 'task' or 'recall'. The description only lists actions without contextual usage hints.
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 is the sole source of behavioral disclosure. It reveals significant side effects: update syncs all IDE tasks.md checkboxes and linked issue statuses; archive moves all tasks from a feature group to an archive table. However, it omits behaviors for delete (cascade/soft), batch_create (duplicate handling), and list (pagination/ordering), leaving gaps.
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 (two sentences) and front-loads the actions, but the second sentence is dense with Chinese conditionals. It could be slightly more structured (e.g., bullet actions) but is efficient for its content.
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?
Given the tool has 6 parameters, 5 actions, and missing output schema, the description lacks sufficient detail. It does not explain return values, error handling, or action-specific requirements beyond the brief mentions. The agent would need to infer or test behaviors for delete and batch_create.
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 high (83%), so the description adds limited param-specific value. It provides context for 'update' action (sync behavior) and 'archive' action (moves to archive table), but does not elaborate on the 'tasks' array structure or nesting of 'children' objects. Most param meaning is already conveyed by the 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 clearly states the tool is for task management with explicit actions (batch_create, update, list, delete, archive). It distinguishes from sibling tools like auto_save, forget, graph, etc., as those do not overlap in function. However, it lacks a formal 'resource' identifier beyond '任务' and could be more explicit.
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 outlines when to use each action (update syncs tasks.md, archive moves tasks), but does not provide explicit guidance on when to prefer this tool over others, nor does it mention prerequisites or when not to use it. Since siblings are unrelated, usage is somewhat implied but not formally guided.
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. It mentions input sources and capabilities but omits critical behavioral details such as whether the tool modifies files, what happens on missing input, or what the output format is. The safety and side effects are unclear.
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 conveys the core functionality efficiently. It is front-loaded with the main purpose and includes key details (source files, multi-language, diff) without unnecessary words.
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 three optional parameters and no output schema, the description partially covers the needed context. It explains the input sources and general capability but does not specify the return format, behavior of the 'diff' action, or how optional sections are used. More detail would be beneficial.
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?
All three parameters are described in the schema (100% coverage). The description adds value by revealing the source files and the fact that the tool generates content, which is not in the schema. It provides context that helps understand the tool's purpose 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 that the tool generates README content from specific files (TOOL_DEFINITIONS/pyproject.toml/STEERING_CONTENT) and supports multi-language and diff comparison. It uses a specific verb 'generate' and identifies the resource 'README', differentiating it from siblings like 'auto_save' or 'graph'.
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 provided on when to use this tool over alternatives. The description does not explain the difference between 'generate' and 'diff' actions or when each is appropriate. There is no mention of prerequisites or context for usage.
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 the key behavior of vector similarity matching, but with no annotations provided, it omits important traits like nondestructive nature, rate limits, or output details. It partially compensates by mentioning the core algorithm.
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 with two sentences, front-loading the core purpose. Every word is necessary and adds value, leaving no redundancy.
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?
With 10 parameters and no output schema, the description does not explain return format or provide usage context for advanced options like 'expand_relations' or 'exclude_superseded'. It is adequate for basic understanding but incomplete for full tool utilization.
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 90%, so the schema already documents most parameters. The description adds no additional parameter meaning beyond the schema's descriptions, which are detailed. The brief description does not repeat parameter info but also does not enhance it.
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 performs semantic search on memories using vector similarity, making its purpose specific and distinguishable from storage or retrieval tools like 'remember' or 'readme'. However, it could be more explicit about the resource being searched.
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?
No explicit guidance on when to use this tool versus alternatives like 'graph' or 'remember'. The semantic search capability implies use for fuzzy matching, but the description lacks contrast with siblings or conditions for non-use.
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?
With no annotations provided, the description must fully disclose behavioral traits. It merely states 'automatically save' without detailing what happens to existing preferences (overwrite? merge?), whether the operation is reversible, or what side effects occur. The lack of depth leaves agents uncertain about the action's impact.
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 a single sentence, which is concise and contains the key instruction. However, it lacks structure (e.g., no separate sections or bullet points) that could improve readability for an AI agent.
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 no output schema and no annotations, the description provides the essential context: when to call and what it does. But it does not explain the consequences of not calling it or how parameters affect behavior, leaving gaps for an agent to reason about.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100%, with each parameter having a description in the schema (e.g., '额外标签' for extra_tags). The tool description adds no new meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
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 automatically saves user preferences ('自动保存用户偏好'), and includes an explicit timing requirement ('每次对话结束前必须调用'). This gives a specific verb and resource, but it does not differentiate from sibling tools like 'remember' or 'recall' that might also handle memory.
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 instructs 'Must be called before the end of each conversation' ('每次对话结束前必须调用'), providing clear when-to-use guidance. This is a strong directive that leaves no ambiguity about the tool's necessity.
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 provided, so description must cover behavioral traits. It mentions automatic deduplication with similarity threshold, which is useful, but lacks details on error handling, permissions, or return values.
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, front-loaded sentences with no waste. Efficiently conveys main purpose and key behavioral detail.
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 3 parameters and no output schema, the description covers the core functionality and the unique deduplication behavior, leaving only minor gaps (e.g., return value).
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%, and description adds no new per-parameter details beyond the schema. The dedup note is tool-level behavior, not parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stores a memory and specifies two scopes (user-level and project-level), distinguishing it from siblings like 'forget' and 'recall'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for storing memories with scoping) but does not explicitly state when not to use or provide alternatives among 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?
No annotations provided, but the description discloses both modes, read-only nature of progress, auto-aggregation, and the clear_fields workaround. It doesn't mention return format but covers key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences, no redundancy. Front-loaded with purpose, then mode conditions, then behavioral notes.
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?
Covers main behaviors comprehensively for a 2-param tool. Missing return details but no output schema exists. The description is sufficient for typical use.
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%, baseline 3. Description adds meaning by explaining update is partial, progress is read-only, and clear_fields solves IDE issues, raising it above baseline.
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 reads or updates session state (verb+resource). It distinguishes from siblings like readme, recall, task by being the sole session state 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 explains when to use each mode (read vs update) and how to clear list fields. It lacks explicit exclusions or alternatives but usage is clear given sibling context.
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:

[![aivectormemory MCP server](https://glama.ai/mcp/servers/Edlineas/aivectormemory/badges/card.svg)](https://glama.ai/mcp/servers/Edlineas/aivectormemory)

Score Badge

Copy to your README.md:

[![aivectormemory MCP server](https://glama.ai/mcp/servers/Edlineas/aivectormemory/badges/score.svg)](https://glama.ai/mcp/servers/Edlineas/aivectormemory)

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/Edlineas/aivectormemory'

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