How do I use AIVectorMemory?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AIVectorMemory remember that we switched to PostgreSQL last week" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

AIVectorMemory

by Edlineas

Overview Schema Related Servers Score Discussions

Python

Local

Still using CLAUDE.md / MEMORY.md as memory? This Markdown-file memory approach has fatal flaws: the file keeps growing, injecting everything into every session and burning massive tokens; content only supports keyword matching — search "database timeout" and you won't find "MySQL connection pool pitfall"; sharing one file across projects causes cross-contamination; there's no task tracking, so dev progress lives entirely in your head; not to mention the 200-line truncation, manual maintenance, and inability to deduplicate or merge.
AIVectorMemory is a fundamentally different approach. Local vector database storage with semantic search for precise recall (matches even when wording differs), on-demand retrieval that loads only relevant memories (token usage drops 50%+), automatic multi-project isolation with zero interference, and built-in issue tracking + task management that lets AI fully automate your dev workflow. All data is permanently stored on your machine — zero cloud dependency, never lost when switching sessions or IDEs.

✨ Core Features

Feature	Description
🧠 Cross-Session Memory	Your AI finally remembers your project — pitfalls, decisions, conventions all persist across sessions
🔍 Hybrid Smart Search	FTS5 full-text + vector semantic dual-path search, RRF fusion ranking + composite scoring (recency × frequency × importance), far more precise than pure vector search
🐛 Issue Tracking	Built-in Issue Tracker — discover → investigate → fix → archive, full lifecycle. AI manages bugs automatically
📋 Task Management	Spec → task breakdown → nested subtasks → status sync → linked archival. AI drives the complete dev workflow
🚦 Session State	Blocking management + breakpoint resume + progress tracking, seamless handoff across sessions and context compaction
🪝 Hooks + Steering	Auto-inject workflow rules + behavior guard hooks, consistent AI behavior guaranteed — no need to repeat instructions
🧬 Memory Evolution	Contradiction detection auto-supersedes stale knowledge + short-term → long-term auto-promotion + 90-day auto-archive, self-evolving memory
📊 Desktop App + Web Dashboard	Native desktop app (macOS/Windows/Linux) + Web dashboard, 3D vector network reveals knowledge connections at a glance
💰 Save 50%+ Tokens	Stop copy-pasting project context every conversation. Semantic retrieval on demand, no more bulk injection
🏠 Fully Local	Zero cloud dependency. ONNX local inference, no API Key, data never leaves your machine
🔌 11 IDEs Covered	Cursor / Kiro / Claude Code / Windsurf / VSCode / Copilot / OpenCode / Trae / Codex / Antigravity / OpenClaw — one-click install & uninstall
📁 Multi-Project Isolation	One DB for all projects, auto-isolated with zero interference, seamless project switching
🔄 Smart Dedup	Similarity > 0.95 auto-merges updates, keeping your memory store clean — never gets messy over time
🌐 7 Languages	简体中文 / 繁體中文 / English / Español / Deutsch / Français / 日本語, full-stack i18n for dashboard + Steering rules

Related MCP server: Logica Context

🏗️ Architecture

┌─────────────────────────────────────────────────┐
│                   AI IDE                         │
│  OpenCode / Codex / Claude Code / Cursor / ...  │
└──────────────────────┬──────────────────────────┘
                       │ MCP Protocol (stdio)
┌──────────────────────▼──────────────────────────┐
│              AIVectorMemory Server               │
│                                                  │
│  ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│  │ remember │ │  recall   │ │   auto_save      │ │
│  │ forget   │ │  task     │ │   status/track   │ │
│  └────┬─────┘ └────┬─────┘ └───────┬──────────┘ │
│       │            │               │             │
│  ┌────▼────────────▼───────────────▼──────────┐  │
│  │         Embedding Engine (ONNX)            │  │
│  │      intfloat/multilingual-e5-small        │  │
│  └────────────────────┬───────────────────────┘  │
│                       │                          │
│  ┌────────────────────▼───────────────────────┐  │
│  │     SQLite + sqlite-vec (Vector Index)     │  │
│  │     ~/.aivectormemory/memory.db            │  │
│  └────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────┘

🚀 Quick Start

Option 1: pip install (Recommended)

# Install
pip install aivectormemory

# Upgrade to latest version
pip install --upgrade aivectormemory

# Navigate to your project directory, one-click IDE setup
cd /path/to/your/project
run install

run install interactively guides you to select your IDE, auto-generating MCP config, Steering rules, and Hooks — no manual setup needed.

macOS users note:
If you get externally-managed-environment error, add --break-system-packages
If you get enable_load_extension error, your Python doesn't support SQLite extension loading (macOS built-in Python and python.org installers don't support it). Use Homebrew Python instead:
brew install python
/opt/homebrew/bin/python3 -m pip install aivectormemory

Option 2: uvx (zero install)

No pip install needed, run directly:

cd /path/to/your/project
uvx aivectormemory install

Requires uv to be installed. uvx auto-downloads and runs the package — no manual installation needed.

Option 3: Manual configuration

{
  "mcpServers": {
    "aivectormemory": {
      "command": "run",
      "args": ["--project-dir", "/path/to/your/project"]
    }
  }
}

IDE	Config Path
Kiro	`.kiro/settings/mcp.json`
Cursor	`.cursor/mcp.json`
Claude Code	`.mcp.json`
Windsurf	`.windsurf/mcp.json`
VSCode	`.vscode/mcp.json`
Trae	`.trae/mcp.json`
OpenCode	`opencode.json`
Codex	`.codex/config.toml`

For Codex, use project-scoped TOML instead of JSON:

[mcp_servers.aivectormemory]
command = "run"
args = ["--project-dir", "/path/to/your/project"]

Codex only loads project-scoped .codex/config.toml after the repository is marked as a trusted project.

🛠️ 9 MCP Tools

`remember` — Store a memory

content (string, required)   Memory content in Markdown format
tags    (string[], required)  Tags, e.g. ["pitfall", "python"]
scope   (string)              "project" (default) / "user" (cross-project)

Similarity > 0.95 auto-updates existing memory, no duplicates.

`recall` — Semantic search

query   (string)     Semantic search keywords
tags    (string[])   Exact tag filter
scope   (string)     "project" / "user" / "all"
top_k   (integer)    Number of results, default 5

Vector similarity matching — finds related memories even with different wording.

`forget` — Delete memories

memory_id  (string)     Single ID
memory_ids (string[])   Batch IDs

`status` — Session state

state (object, optional)   Omit to read, pass to update
  is_blocked, block_reason, current_task,
  next_step, progress[], recent_changes[], pending[]

Maintains work progress across sessions, auto-restores context in new sessions.

`track` — Issue tracking

action   (string)   "create" / "update" / "archive" / "list"
title    (string)   Issue title
issue_id (integer)  Issue ID
status   (string)   "pending" / "in_progress" / "completed"
content  (string)   Investigation content

`task` — Task management

action     (string, required)  "batch_create" / "update" / "list" / "delete" / "archive"
feature_id (string)            Linked feature identifier (required for list)
tasks      (array)             Task list (batch_create, supports subtasks)
task_id    (integer)           Task ID (update)
status     (string)            "pending" / "in_progress" / "completed" / "skipped"

Links to spec docs via feature_id. Update auto-syncs tasks.md checkboxes and linked issue status.

`readme` — README generation

action   (string)    "generate" (default) / "diff" (compare differences)
lang     (string)    Language: en / zh-TW / ja / de / fr / es
sections (string[])  Specify sections: header / tools / deps

Auto-generates README content from TOOL_DEFINITIONS / pyproject.toml, multi-language support.

`auto_save` — Auto save preferences

preferences  (string[])  User-expressed technical preferences (fixed scope=user, cross-project)
extra_tags   (string[])  Additional tags

Auto-extracts and stores user preferences at end of each conversation, smart dedup.

`graph` — Code knowledge graph

action       (string, required)  "query" / "trace" / "batch" / "add_node" / "add_edge" / "remove" / "refresh"
name         (string)            Entity name (add_node/query)
entity_type  (string)            Entity type: function/class/module/api/table/config (add_node/query)
file_path    (string)            File path, auto-converts to relative (add_node/query/refresh)
source       (string)            Source node name or ID (add_edge)
target       (string)            Target node name or ID (add_edge)
relation     (string)            Relation type: calls/imports/inherits/uses/depends_on/contains (add_edge/trace)
start        (string)            Start node name or ID (trace)
direction    (string)            Traversal direction: "up" / "down" / "both" (trace)
max_depth    (integer)           Max traversal depth, default 3 (trace)

Manages function call chains, data flows, and dependency relationships. Trace upstream/downstream impact before code changes.

📊 Web Dashboard

run web --port 9080
run web --port 9080 --quiet          # Suppress request logs
run web --port 9080 --quiet --daemon  # Run in background (macOS/Linux)

Visit http://localhost:9080 in your browser. Default username admin, password admin123 (can be changed in settings after first login).

Multi-project switching, memory browse/search/edit/delete/export/import
Semantic search (vector similarity matching)
One-click project data deletion
Session status, issue tracking
Tag management (rename, merge, batch delete)
Token authentication protection
3D vector memory network visualization
🌐 Multi-language support (简体中文 / 繁體中文 / English / Español / Deutsch / Français / 日本語)

⚡ Pairing with Steering Rules

AIVectorMemory is the storage layer. Use Steering rules to tell AI when and how to call these tools.

Running run install auto-generates Steering rules and Hooks config — no manual setup needed.

IDE	Steering Location	Hooks
Kiro	`.kiro/steering/aivectormemory.md`	`.kiro/hooks/*.hook`
Cursor	`.cursor/rules/aivectormemory.md`	`.cursor/hooks.json`
Claude Code	`CLAUDE.md` (appended)	`.claude/settings.json`
Windsurf	`.windsurf/rules/aivectormemory.md`	`.windsurf/hooks.json`
VSCode	`.github/copilot-instructions.md` (appended)	`.claude/settings.json`
Trae	`.trae/rules/aivectormemory.md`	—
OpenCode	`AGENTS.md` (appended)	`.opencode/plugins/*.js`
Codex	`AGENTS.md` (appended)	—

# AIVectorMemory - Workflow Rules

## 1. New Session Startup (execute in order)

1. `recall` (tags: ["project-knowledge"], scope: "project", top_k: 100) load project knowledge
2. `recall` (tags: ["preference"], scope: "user", top_k: 20) load user preferences
3. `status` (no state param) read session state
4. Blocked → report and wait; Not blocked → enter processing flow

## 2. Message Processing Flow

- Step A: `status` read state, wait if blocked
- Step B: Classify message type (chat/correction/preference/code issue)
- Step C: `track create` record issue
- Step D: Investigate (`recall` pitfalls + read code + find root cause)
- Step E: Present plan to user, set blocked awaiting confirmation
- Step F: Modify code (`recall` pitfalls before changes)
- Step G: Run tests to verify
- Step H: Set blocked awaiting user verification
- Step I: User confirms → `track archive` + clear block

## 3. Blocking Rules

Must `status({ is_blocked: true })` when proposing plans or awaiting verification.
Only clear after explicit user confirmation. Never self-clear.

## 4-9. Issue Tracking / Code Checks / Spec Task Mgmt / Memory Quality / Tool Reference / Dev Standards

(Full rules auto-generated by `run install`)

Auto-save on session end removed. Dev workflow check (.kiro/hooks/dev-workflow-check.kiro.hook):

{
  "enabled": true,
  "name": "Dev Workflow Check",
  "version": "1",
  "when": { "type": "promptSubmit" },
  "then": {
    "type": "askAgent",
    "prompt": "Core principles: verify before acting, no blind testing, only mark done after tests pass"
  }
}

🇨🇳 Users in China

The embedding model (~200MB) is auto-downloaded on first run. If slow:

export HF_ENDPOINT=https://hf-mirror.com

Or add env to MCP config:

{
  "env": { "HF_ENDPOINT": "https://hf-mirror.com" }
}

📦 Tech Stack

Component	Technology
Runtime	Python >= 3.10
Vector DB	SQLite + sqlite-vec
Embedding	ONNX Runtime + intfloat/multilingual-e5-small
Tokenizer	HuggingFace Tokenizers
Protocol	Model Context Protocol (MCP)
Web	Native HTTPServer + Vanilla JS

📋 Changelog

v2.4.5

Patch: Hard Constraints Against Opus 4.7 Default Tendencies

🚫 §1 added No Clarification-Style Follow-ups: forbid re-asking "phased or one-shot / full or partial / should I do X / do A first or B first" for imperative commands; under ambiguity, execute the most complete scope
🚫 §1 added No Defensive Reporting: forbid wording like "kept per instruction / marked pending / non-critical path / unnecessary sub-tests / for later iteration" as excuse for unexecuted items
📋 §1 added Report Format: forbid Phase A/B/C/D list + "Final Status" + "Not Done (Kept Per Instruction)" three-section format; when user says "do all", no "Not Done/Kept" section allowed
🎯 Root cause: counteract Opus 4.7's default "defensive reporting", "clarification follow-ups", and "structured checklist" tendencies compared to 4.6
🔄 7-language rule files (STEERING_CONTENT + DEV_WORKFLOW_PROMPT) fully synced with CLAUDE.md v2.4.5 updates

v2.4.4

Patch: Full A-I Message Processing Flow Alignment

🧩 CLAUDE.md §4 message processing B routes fully expanded: all 4 branches (casual/correction/preference/other) unified to terminate at I(user confirm & archive), eliminating incomplete "stop at F" flows
⚙️ inject-workflow-rules.sh message type judgment section fully aligned with §4 B: 4 routes with consistent granularity
🔧 Fixed 3 conflicts: route granularity inconsistency (2 vs 4 routes) / B and E responsibility mixing ("solution+block" misplaced) / G/H/I flow missing
📝 Unified violation clause: "Proceeding to C/D/E/F steps without outputting judgment result = violation"
🔄 7-language rule files (STEERING_CONTENT + DEV_WORKFLOW_PROMPT) fully synced with CLAUDE.md v2.4.4 updates

v2.4.3

Patch: Rule Enforcement & Graph Visualization

🧠 §4.B: Two-step mandatory structure (understand message → determine type), skipping = violation
📋 §8: Review + block embedded in each Spec step, skipping = violation
🧬 DEV_WORKFLOW_PROMPT: Added graph trace/batch/add_node rules for investigation and code modification
📊 Graph dashboard: Dynamic force layout scaling, edge labels hidden by default (hover to show), node label collision detection
🔧 Removed redundant "frequent violation reminders" section from DEV_WORKFLOW_PROMPT
📝 Unified §1 IDENTITY & TONE across all 7 languages (no translation)

v2.4.1

Patch: i18n Rules Sync

🔄 Synced all 7 language rule files (STEERING_CONTENT + DEV_WORKFLOW_PROMPT) with CLAUDE.md v2.4.0 updates
🧬 Added graph tool references to all steering rules (trace/batch/add_node/add_edge/remove)
✏️ Updated authority role from "Lead Architect" to "Project Owner" across all languages
📝 Added 3 new violation rules and 2 new forbidden items to all languages

v2.4.0

New: Code Knowledge Graph

🧬 graph tool — manage function call chains, data flows, and dependency relationships as a structured knowledge graph
🔍 trace action — traverse upstream/downstream call chains from any entity, assess impact scope before code changes
📊 Web dashboard graph visualization page — browse nodes, edges, and call relationships in the knowledge graph
🗃️ DB migration v15 — new graph_nodes and graph_edges tables for graph storage
🌐 All 7 language README files updated in sync

v2.3.1

Enhancement: Rule System Overhaul + OpenClaw Support

🧠 Fixed 5 missing memory system calls in AI rules: recall pitfalls before investigation (Step D), before dangerous ops (§7), before Spec writing (§8), before subtask execution (§8), and remember pitfalls after fix (Step I)
🦞 Added OpenClaw IDE support — now 11 IDEs total (MCP config merges into ~/.openclaw/openclaw.json, steering appends to AGENTS.md)
🎭 Playwright self-test rules strengthened — added ToolSearch deferred tools loading requirement, banned open command workaround
🔧 Merged v2.2.0–v2.2.6 features: hooks system (bash_guard + stop_guard + check_track), scoring engine improvements, recall optimizations, web dashboard bulk delete, desktop memory delete modal
⚠️ DEV_WORKFLOW_PROMPT: added 2 new violation reminders (recall before code change, remember after fix)
🌐 All 7 language rule files updated in sync

v2.1.1

Enhancement: AI Rule System Upgrade

📋 CLAUDE.md completion: added Identity & Tone (§1), 7 Core Principles (§3), message type judgment examples, expanded IDE safety and self-test sections
⚠️ Hook added Common Violations Reminder: ❌ negative examples reinforcing the 4 most frequently missed rules (self-test, recall, track create, IDE safety)
🌐 All 7 language rule files updated in sync (zh-CN/zh-TW/en/ja/es/de/fr)
🔢 CLAUDE.md sections renumbered to §1–§11, cross-references updated accordingly

v2.1.0

New: Smart Memory Engine + Uninstall

🧠 FTS5 full-text search with Chinese tokenization (jieba) — keyword search now actually works for CJK content
🔀 Hybrid retrieval: vector + FTS5 dual-path with RRF (Reciprocal Rank Fusion) merging
📊 Composite scoring: results ranked by similarity × 0.5 + recency × 0.3 + frequency × 0.2, weighted by importance
⚡ Conflict detection: similar memories (0.85–0.95) auto-superseded, old facts fade automatically
📦 Memory tiers: frequently accessed memories auto-promote to long_term and get searched first
🗑️ Auto-archive: stale short_term memories (90 days inactive + low importance) cleaned up automatically
🔗 Relation expansion: tag overlap ≥ 2 builds related links, 1-hop expansion surfaces connected memories
📝 Auto-summary: long memories (>500 chars) get summaries, brief mode returns summaries to save tokens
🧹 Code cleanup: removed 15 dead code items, refactored 7 duplicate patterns into shared utilities
❌ run uninstall — cleanly removes all IDE configurations (MCP, steering, hooks, permissions) while preserving memory data

v2.0.9

Enhancement: Security & Rule Optimization

🔒 Fixed SQL injection, command injection, and path traversal vulnerabilities
🛡️ Added transaction protection for data integrity (archive, insert, update operations)
🧠 Unified similarity formula across all search paths
📏 Compressed AI workflow rules by 38% (219→136 lines) with zero process removal
🧹 v12 migration cleans up legacy garbage memories automatically
🌐 All 7 languages synchronized

v2.0.8

New: Playwright Browser Testing Built-in

🎭 run install now automatically configures Playwright browser testing — AI can open a real browser to verify frontend changes instead of guessing
🎭 Uses a dedicated test browser (Chrome for Testing) that won't interfere with your personal browser tabs
🔑 Simplified permission setup — no more manual permission popups for common tools
📏 Updated AI rules across all 7 languages to enforce proper browser testing behavior

v2.0.7

Enhancement: More IDE Support

🖥️ Added support for Antigravity and GitHub Copilot IDEs
🔑 run install now auto-configures tool permissions, reducing manual setup
📏 Streamlined AI self-testing rules

v2.0.6

Enhancement: Faster Startup

⚡ Optimized memory loading on session start — loads faster with less context usage
🔑 Auto-configures Claude Code permissions during installation
🌐 All 7 languages synchronized

v2.0.5

Enhancement: Simpler Rules

📏 AI workflow rules restructured for clarity and reduced token usage
💾 AI now automatically saves your preferences at the end of each session
🌐 All 7 languages synchronized

v2.0.4

Fix: Tool Reliability

🔧 Comprehensive audit and fix of all MCP tool parameters — improved reliability across all IDEs

v2.0.3

Enhancement: Better Search & Safety

🔍 Memory search now combines semantic and keyword matching for more accurate recall
🛡️ Added cross-project protection — AI won't accidentally modify files in other projects

v2.0.2

Enhancement: Rule Generalization & Desktop Version Fix

📏 Added "recall before asking user" rule — AI must query memory system before asking user for project information (server address, passwords, deploy config, etc.)
📏 Generalized pre-operation check rule — removed specific examples to apply to all operation scenarios
🖥️ Fixed desktop app settings page showing hardcoded version "1.0.0" instead of actual app version
🌐 All 7 language i18n steering rules and workflow prompts synchronized

v2.0.1

Fix: Hook Cross-Project Compatibility

🔧 check_track.sh now derives project path from script location instead of $(pwd), fixing track detection failure when Claude Code runs hooks from non-root working directory
🔧 compact-recovery.sh now uses relative path derivation instead of hardcoded absolute paths, ensuring correct behavior when installed to any project
🔧 Removed redundant CLAUDE.md re-injection from compact-recovery (already auto-loaded by Claude Code)
🔧 install.py template synchronized with all hook fixes
🌐 All 7 language i18n compact-recovery hints updated

v2.0

Performance: ONNX INT8 Quantization

⚡ Embedding model auto-quantized from FP32 to INT8 on first load, model file from 448MB down to 113MB
⚡ MCP Server memory usage reduced from ~1.6GB to ~768MB (50%+ reduction)
⚡ Quantization is transparent to users — automatic on first use, cached for subsequent loads, falls back to FP32 on failure

New: Remember Password

🔐 Login page on both desktop and web dashboard now has a "Remember password" checkbox
🔐 When checked, credentials are saved to localStorage and auto-filled on next login; when unchecked, saved credentials are cleared
🔐 Checkbox is hidden in registration mode

Enhancement: Steering Rules

📝 IDENTITY & TONE section strengthened with more specific constraints (no pleasantries, no translating user messages, etc.)
📝 Self-testing requirements now distinguish between backend-only, MCP Server, and frontend-visible changes (Playwright required for frontend)
📝 Development rules now mandate self-testing after completing development
📝 All 7 language versions synchronized

v1.0.11

🐛 Desktop app version comparison switched to semantic versioning, fixing false upgrade prompts when local version is higher
🐛 Health check page field names aligned with backend, fixing consistency status always showing Mismatch
🔧 check_track.sh hook adds Python fallback, resolving silent hook failure when system sqlite3 is unavailable (#4)

v1.0.10

🖥️ Desktop app one-click install + upgrade detection
🖥️ Auto-detect Python and aivectormemory installation status on startup
🖥️ Show one-click install button when not installed, check PyPI and desktop new versions when installed
🐛 Installation detection switched to importlib.metadata.version() for accurate package version

v1.0.8

🔧 Fix PyPI package size anomaly (sdist from 32MB down to 230KB), excluded accidentally packaged dev files

v1.0.6

New: Native Desktop App

🖥️ Native desktop client supporting macOS (ARM64), Windows (x64), Linux (x64)
🖥️ Desktop app shares the same database as Web dashboard, fully feature-equivalent
🖥️ Dark/light theme switching, Glass frosted visual style
🖥️ Login auth, project selection, stats overview, memory management, issue tracking, task management, tag management, settings, data maintenance — full feature coverage
📦 Auto-published installers via GitHub Releases, download and use

New: CI/CD Auto Build

🔄 GitHub Actions auto-builds desktop installers for all 3 platforms
🔄 Push a tag to trigger the full compile, package, and release pipeline

Fixes

🐛 Windows platform compatibility fixes
🐛 sqlite-vec extension download URL fix

v1.0.5

Optimization: Token Usage Reduction

⚡ Steering rules changed from per-message dynamic injection to static loading, reducing repeated token consumption
⚡ Greatest impact for Claude Code users — ~2K fewer tokens per message

v1.0.4

New: Full-Stack i18n (7 Languages)

🌐 Web dashboard + desktop UI fully supports 7 languages: 简体中文 / 繁體中文 / English / Español / Deutsch / Français / 日本語
🌐 One-click language switch in settings page, takes effect immediately
🌐 MCP tool responses follow language setting, AI replies automatically use the corresponding language
🌐 Switching language auto-regenerates steering rules for all installed projects

New: Web Dashboard Settings Page

⚙️ Language switch, theme settings, system info display
⚙️ Database health check, repair, backup and other maintenance tools

v1.0.3

Optimization: Memory Search

🔍 recall search supports OR/AND tag matching modes, fixing missed results with multi-tag searches
🔍 Semantic search + tag filter defaults to OR matching (broader), tags-only browsing keeps AND matching (more precise)

See CHANGELOG-archive.md

License

Apache-2.0

Available Tools

9 tools

auto_saveA

【每次对话结束前必须调用】自动保存用户偏好。

ParametersJSON Schema

Name	Required	Description	Default
`extra_tags`	No	额外标签
`preferences`	No	用户表达的技术偏好（固定 scope=user，跨项目通用）

TDQS

A3.6/5.0

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.

forgetC

删除一条或多条记忆。

ParametersJSON Schema

Name	Required	Description	Default
`id`	No	单个记忆 ID（memory_id 的别名）
`ids`	No	多个记忆 ID（memory_ids 的别名）
`tags`	No	按标签批量删除，删除所有匹配标签的记忆
`scope`	No	配合 tags 使用，限定删除范围	all
`memory_id`	No	单个记忆 ID（别名 id）
`memory_ids`	No	多个记忆 ID（别名 ids）

TDQS

C2.5/5.0

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.

graphC

代码知识图谱：管理函数调用链、数据流、依赖关系等结构化代码知识。支持节点/边 CRUD、多跳遍历、过期检测。

ParametersJSON Schema

Name	Required	Description	Default
`name`	No	实体名称（add_node/query）
`edges`	No	批量边（batch）
`label`	No	边标签（add_edge）
`nodes`	No	批量节点（batch）
`start`	No	起始节点名称或 ID（trace）
`action`	Yes	操作类型
`source`	No	起点节点名称或 ID（add_edge）
`target`	No	终点节点名称或 ID（add_edge）
`edge_id`	No	边 ID（remove）
`node_id`	No	节点 ID（remove）
`relation`	No	关系类型（add_edge/trace）
`direction`	No	遍历方向（trace）	down
`file_path`	No	文件路径，自动转相对路径（add_node/query/refresh）
`max_depth`	No	最大深度（trace）
`memory_id`	No	关联记忆 ID（add_node）
`description`	No	描述（add_node）
`entity_type`	No	实体类型（add_node/query）
`line_number`	No	行号（add_node）
`cross_project`	No	跨项目遍历（trace）

TDQS

C2.9/5.0

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.

readmeA

README 生成工具：从 TOOL_DEFINITIONS/pyproject.toml/STEERING_CONTENT 自动生成 README 内容，支持多语言和差异对比。

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	语言：en/zh-TW/ja/de/fr/es	en
`action`	No	generate=生成内容, diff=对比差异	generate
`sections`	No	指定生成的章节（可选）：header/tools/deps

TDQS

A3.5/5.0

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.

recallA

语义搜索回忆记忆。通过向量相似度匹配，即使用词不同也能找到相关记忆。

ParametersJSON Schema

Name	Required	Description	Default
`tags`	No	按标签过滤。query+tags 时默认 OR 匹配（任一标签命中即可），仅 tags 时默认 AND 匹配（精确分类浏览）
`tier`	No	只搜索指定层级的记忆
`brief`	No	精简模式：true 时只返回 content 和 tags，省略 id/session_id/created_at 等元数据，适合启动加载场景节省上下文
`query`	No	搜索内容（语义搜索，可选）
`scope`	No		all
`top_k`	No	返回结果数量
`source`	No	按来源过滤：manual=项目知识, experience=归档经验。不传则不过滤
`tags_mode`	No	标签匹配模式：any=任一匹配，all=全部匹配。默认智能选择（query+tags→any，仅tags→all）
`expand_relations`	No	沿 related 关系扩展 1 跳查找相关记忆
`exclude_superseded`	No	排除已被替代的记忆（已弃用，被替代的记忆现在通过 importance 降权自然排序，不再硬过滤）

TDQS

A3.5/5.0

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.

rememberA

存入一条记忆。支持用户级（跨项目）和项目级存储，自动去重（相似度>0.95则更新）。

ParametersJSON Schema

Name	Required	Description	Default
`tags`	Yes	标签列表（数组或逗号分隔字符串）
`scope`	No	作用域	project
`content`	Yes	记忆内容，Markdown 格式。命令类须含完整可执行命令，流程类须含具体步骤，禁止模糊缩写

TDQS

A3.8/5.0

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.

statusA

读取或更新会话状态（阻塞状态、当前任务、进度等）。不传 state 参数则读取，传则部分更新。progress 为只读计算字段，自动从 track 活跃问题 + task 未完成任务聚合生成，无需手动写入。清空列表字段时使用 clear_fields 参数（因部分 IDE 会过滤空数组）。

ParametersJSON Schema

Name	Required	Description	Default
`state`	No	要更新的字段（部分更新）。progress 为只读字段，传入会被忽略。
`clear_fields`	No	要清空的列表字段名。用于绕过部分 IDE 过滤空数组的问题，例如传 ["pending"] 等同于 state.pending=[]。

TDQS

A4.4/5.0

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.

taskB

任务管理：batch_create/update/list/delete/archive。update 更新状态后自动同步所有 IDE 的 tasks.md checkbox，并联动同步关联问题状态。archive 将指定功能组的所有任务移入归档表。

ParametersJSON Schema

Name	Required	Description
`tasks`	No	任务列表（batch_create）
`title`	No	任务标题（update 时可选修改）
`action`	Yes
`status`	No	任务状态
`task_id`	No	任务 ID（update/delete 时使用，即 list 返回的 task_id）
`feature_id`	No	关联的功能标识（list/archive 时必填）

TDQS

B3.3/5.0

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.

trackB

问题跟踪：create/update/archive/delete/list 五个 action。

ParametersJSON Schema

Name	Required	Description
`date`	No	日期 YYYY-MM-DD
`brief`	No	list 时是否只返回摘要（issue_id/title/status/date），默认 true。需要详情用 issue_id 查单条
`limit`	No	list 时返回条数上限，默认 50
`notes`	No	注意事项
`title`	No	问题标题（create）
`action`	Yes
`status`	No
`content`	No	问题描述（create 时必填，简述问题现象和背景）
`issue_id`	No	问题编号（即 list 返回的 issue_id），update/archive/delete/list 单条查询时使用
`solution`	No	解决方案
`parent_id`	No	父问题 ID（create，可选，默认 0）
`feature_id`	No	关联功能标识
`root_cause`	No	根本原因
`description`	No	问题描述
`test_result`	No	自测结果
`files_changed`	No	修改文件清单（JSON 数组）
`investigation`	No	排查过程（逐步记录）

TDQS

B3.2/5.0

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

9 tool updatesv2.4.5Jul 12, 2026
- First observedauto_save
- First observedforget
- First observedgraph
- First observedreadme
- First observedrecall
- First observedremember
- First observedstatus
- First observedtask
- First observedtrack

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

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.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ContextStream BOAuth
io.contextstream
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
Knowledge & Memory Developer Tools
30241
WorkingMemory A
ai.workingmemory
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
Knowledge & Memory Search
42
mcpOAuth
ai.butlerbrain
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
Knowledge & Memory RAG Systems Workplace & Productivity
2
MemoryRouter A
ai.memoryrouter
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Knowledge & Memory Search
101

Related MCP Servers

Mono Memory MCP
Knowledge & Memory Developer Tools Databases
potato-castle
A
license
Not graded
quality
D
maintenance
A self-hosted MCP server that provides AI assistants with a shared, persistent SQLite-backed memory for storing and retrieving project context, decisions, and discoveries. It enables cross-session continuity and team-wide knowledge sharing to keep AI coding tools aligned and informed.
Updated 6 months ago (2026-03-05 08:17 UTC)
3
MIT
Logica Context
Knowledge & Memory Developer Tools RAG Systems
Rovemark
A
license
Not graded
quality
D
maintenance
An MCP server that provides persistent, cross-session memory and team knowledge sharing for AI development workflows. It enables project DNA scanning, semantic search, context budgeting, and git-aware indexing to prevent AI context loss between sessions.
Updated 3 months ago (2026-06-04 01:13 UTC)
19
MIT
myBrAIn
Knowledge & Memory Developer Tools
lilium360
A
license
Not graded
quality
D
maintenance
MCP server that provides persistent memory and contextual awareness to language models, enabling project onboarding, recall of architectural rules, and code consistency across sessions.
Updated 7 months ago (2026-02-17 08:39 UTC)
32
MIT
memory-bank-mcp
Knowledge & Memory Vector Databases Code Analysis
gcorroto
A
license
A
quality
D
maintenance
MCP server for semantic code indexing using vector embeddings, enabling AI agents to maintain persistent memory of codebases through natural language queries and intelligent chunking.
Updated 7 months ago (2026-01-28 21:32 UTC)
19
76
4
MIT

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

✨ Core Features

🏗️ Architecture

🚀 Quick Start

Option 1: pip install (Recommended)

Option 2: uvx (zero install)

Option 3: Manual configuration

🛠️ 9 MCP Tools

remember — Store a memory

recall — Semantic search

forget — Delete memories

status — Session state

track — Issue tracking

task — Task management

readme — README generation

auto_save — Auto save preferences

graph — Code knowledge graph

📊 Web Dashboard

⚡ Pairing with Steering Rules

🇨🇳 Users in China

📦 Tech Stack

📋 Changelog

v2.4.5

v2.4.4

v2.4.3

v2.4.1

v2.4.0

v2.3.1

v2.1.1

v2.1.0

v2.0.9

v2.0.8

v2.0.7

v2.0.6

v2.0.5

v2.0.4

v2.0.3

v2.0.2

v2.0.1

v2.0

v1.0.11

v1.0.10

v1.0.8

v1.0.6

v1.0.5

v1.0.4

v1.0.3

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`remember` — Store a memory

`recall` — Semantic search

`forget` — Delete memories

`status` — Session state

`track` — Issue tracking

`task` — Task management

`readme` — README generation

`auto_save` — Auto save preferences

`graph` — Code knowledge graph