Векторная база данных с привязкой к проекту для ИИ-ассистентов, обеспечивающая гибридный семантический и ключевой поиск с автоматическим обнаружением проектов.
Гибридный поиск — сочетает семантическое сходство с сопоставлением по ключевым словам с использованием Reciprocal Rank Fusion (RRF).
Обнаружение проектов — автоматическое распознавание репозиториев Git и создание коллекций с привязкой к проекту.
6 инструментов MCP — search, retrieve, rules, store, grep, list.
Интеллектуальный анализ кода — семантическая нарезка Tree-sitter + интеграция с LSP для активных проектов.
Граф кода — граф связей с алгоритмами (PageRank, обнаружение сообществ, центральность по посредничеству).
Высокопроизводительный CLI — инструмент командной строки wqm на языке Rust.
Фоновый демон — memexd для непрерывного мониторинга и обработки файлов.
Related MCP server: Super-Memory-TS
Qdrant — docker run -d -p 6333:6333 -v qdrant_storage:/qdrant/storage qdrant/qdrant
C-компилятор — необходим для компиляции грамматик Tree-sitter при первом использовании. Грамматики Tree-sitter распространяются в виде исходного кода на C и компилируются локально.
macOS: xcode-select --install (инструменты командной строки Xcode)
Linux: apt install build-essential (Debian/Ubuntu) или dnf groupinstall "Development Tools" (Fedora)
Windows: Установите Visual Studio Build Tools с рабочей нагрузкой C++.
Вариант 1: Homebrew (рекомендуется — macOS и Linux)
brew install ChrisGVE/tap/workspace-qdrant
brew services start workspace-qdrantВариант 2: Готовые бинарные файлы
# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/ChrisGVE/workspace-qdrant-mcp/main/scripts/download-install.sh | bash
# Windows (PowerShell)
irm https://raw.githubusercontent.com/ChrisGVE/workspace-qdrant-mcp/main/scripts/download-install.ps1 | iexУстанавливает wqm и memexd в ~/.local/bin (Linux/macOS) или %LOCALAPPDATA%\wqm\bin (Windows).
Вариант 3: Сборка из исходного кода
git clone https://github.com/ChrisGVE/workspace-qdrant-mcp.git
cd workspace-qdrant-mcp
./install.shПодробные инструкции и примечания для конкретных платформ см. в справочнике по установке. Для Windows см. Руководство по установке в Windows.
Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"workspace-qdrant-mcp": {
"command": "node",
"args": ["/path/to/workspace-qdrant-mcp/src/typescript/mcp-server/dist/index.js"],
"env": {
"QDRANT_URL": "http://localhost:6333"
}
}
}
}Claude Code:
claude mcp add workspace-qdrant-mcp -- node /path/to/workspace-qdrant-mcp/src/typescript/mcp-server/dist/index.jswqm --version
wqm status healthДобавьте следующее в файл CLAUDE.md вашего проекта (или в глобальный ~/.claude/CLAUDE.md), чтобы Claude Code активно использовал workspace-qdrant:
## workspace-qdrant
The `workspace-qdrant` MCP server provides codebase-aware search, a library knowledge base, a scratchpad for accumulated insights, and persistent behavioral rules. The tool schemas are self-describing; these instructions cover *when* and *how* to use them.
### Primary Search and Knowledge Base
**Use `workspace-qdrant` first whenever context is uncertain** — first session on a project, returning after a significant gap, or exploring an unfamiliar subsystem. It is faster and more accurate than walking files manually, and it retrieves findings from prior sessions that would otherwise be lost.
**Three-step protocol:**
1. **Search** with `workspace-qdrant` (`search`, `grep`, `list`, or `retrieve`)
2. **Fall back** to `Grep`, `Glob`, `WebSearch` only when workspace-qdrant is insufficient or unavailable
3. **Store** any new findings, analysis, or design rationale via `store` so they are retrievable in future sessions
When a fresh handover or strong prior context already covers what you need, skip the exploratory search — but always store new findings at the end.
**Collections and their purpose:**
- `projects` — indexed codebase; use `scope="project"` (current project) or `scope="all"` (across all projects)
- `libraries` — external reference docs, API specs, third-party documentation; add via `store` with `collection="libraries"` and search with `includeLibraries=true`
- `scratchpad` — analysis, design rationale, research transcripts, architectural insights; complements session handovers by building a growing, semantically searchable knowledge layer across sessions
- `rules` — persistent behavioral rules; load at session start via `rules` → `action="list"`
**Practical notes:**
- Use `grep` for exact strings or regex; `list` with `format="summary"` to explore project structure
- Store external docs or specs into `libraries` so they are searchable alongside code
- Use the scratchpad to record *why* decisions were made, not just *what* was done — future sessions can retrieve the reasoning
### Sub-Agents
Sub-agents start with only the prompt you give them — they have no session history or handover context. They must always use `workspace-qdrant` first for any code exploration, without exception. Include this verbatim in every agent prompt:
> "You have no prior context about this codebase. Use `workspace-qdrant` as your mandatory first tool for ALL code searches — symbols, functions, architecture, patterns, prior findings. Use `search`, `grep`, `list`, or `retrieve` before touching any file with Read/Grep/Glob. Store any new findings, analysis, or design rationale via `store` (scratchpad for insights, libraries for reference docs) so they persist for future sessions."
### Project Registration
At session start, check whether the current project is registered with workspace-qdrant. If it is not, ask the user whether they want to register it (do not register silently). Once registered, the daemon handles file watching and ingestion automatically — no further action is needed.
### Behavioral Rules
The `rules` tool manages persistent rules that are injected into context across sessions. Rules are **user-initiated only** — add rules when the user explicitly instructs you to, never autonomously. Use `action="list"` at session start to load active rules.
### Issue Reporting
workspace-qdrant is under active development. If you encounter errors, unexpected behavior, or limitations with any workspace-qdrant tool, report them as GitHub issues at https://github.com/ChrisGVE/workspace-qdrant-mcp/issues using the `gh` CLI.Инструмент | Назначение |
| Гибридный семантический поиск + поиск по ключевым словам по индексированному контенту |
| Прямой поиск документа по ID или фильтру метаданных |
| Управление постоянными правилами поведения |
| Хранение контента, регистрация проектов, сохранение заметок |
| Поиск точной подстроки или регулярного выражения с использованием FTS5 |
| Список файлов проекта и структура папок |
Параметры и примеры см. в справочнике по инструментам MCP.
Коллекция | Назначение | Изоляция |
| Код проекта и документация | Мультиарендность по |
| Справочная документация (книги, статьи, доки) | Мультиарендность по |
| Правила поведения и предпочтения | Мультиарендность по |
| Временное рабочее хранилище | Для каждой сессии |
# Service management
wqm service start # Start background daemon
wqm service status # Check daemon status
wqm status health # System health check
# Search and content
wqm search "query" # Search collections
wqm ingest file path.py # Ingest a file
wqm rules list # List behavioral rules
# Project and library
wqm project list # List registered projects
wqm project watch pause # Pause file watchers
wqm library list # List libraries
wqm tags list # List tags with counts
# Administration
wqm admin collections list # List collections
wqm admin rebuild all # Rebuild all indexes
wqm admin backup create # Backup snapshots
wqm admin stats overview # Search analytics
# Code graph
wqm graph stats --tenant <t> # Node/edge counts
wqm graph query --node-id <id> --tenant <t> --hops 2 # Related nodes
wqm graph impact --symbol <name> --tenant <t> # Impact analysis
wqm graph pagerank --tenant <t> --top-k 20 # PageRank centrality
# Setup
wqm init completions zsh # Shell completions
wqm init man install # Install man pages
wqm init hooks install # Install Claude Code hooks
# Queue and monitoring
wqm queue stats # Queue statisticsПолную документацию см. в справочнике CLI.
Переменная | По умолчанию | Описание |
|
| URL сервера Qdrant |
| - | API-ключ (требуется для Qdrant Cloud) |
|
| Модель эмбеддингов |
+-----------------+
| Claude/Client |
+--------+--------+
|
+--------v--------+
| MCP Server | (TypeScript)
+--------+--------+
|
+--------------+--------------+
| |
+--------v--------+ +--------v--------+
| Rust Daemon | | Qdrant |
| (memexd) | | Vector Database |
+--------+--------+ +-----------------+
|
+--------v--------+
| File Watcher |
| Code Graph |
| Embeddings |
+-----------------+Демон на Rust обрабатывает отслеживание файлов, генерацию эмбеддингов, извлечение графа кода и обработку очереди. Все операции записи проходят через демон для обеспечения согласованности.
Руководства пользователя:
Быстрый старт — запуск за 5 минут
Руководство пользователя — полное руководство по использованию
Интеграция с LLM — лучшие практики для Claude
Справочные материалы:
Справочник CLI — все команды wqm
Инструменты MCP — параметры инструментов и примеры
Конфигурация — все опции и значения по умолчанию
Архитектура — обзор компонентов
См. Индекс документации для спецификаций, ADR и ресурсов для разработчиков.
# TypeScript MCP server
cd src/typescript/mcp-server && npm install && npm run build && npm test
# Rust daemon and CLI (from src/rust/)
cargo build --release
cargo test
# Graph benchmarks
cargo bench --package workspace-qdrant-core --bench graph_bench
# Binaries output to:
# - target/release/wqm
# - target/release/memexdСм. CONTRIBUTING.md для настройки среды разработки и руководящих принципов.
Лицензия MIT — подробности см. в LICENSE.
Вдохновлено claude-qdrant-mcp
Search code with exact substring or regex pattern matching. Uses FTS5 trigram index for fast line-level search across indexed files.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Search pattern (exact substring or regex) | |
| regex | No | Treat pattern as regex (default: false) | |
| caseSensitive | No | Case-sensitive matching (default: true) | |
| pathGlob | No | File path glob filter (e.g., "**/*.rs", "src/**/*.ts") | |
| scope | No | Search scope: project (current) or all (default: project) | |
| contextLines | No | Lines of context before/after each match (default: 0) | |
| maxResults | No | Maximum results to return (default: 1000) | |
| branch | No | Filter by branch name | |
| projectId | No | Specific project ID to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions FTS5 trigram index for speed but does not disclose read-only nature, error conditions, or other behavioral traits. Minimal disclosure beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose clearly, second adds relevant technical detail about indexing. No redundant words, efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description is brief. It covers the core search behavior but lacks details on return format, pagination hints, or performance limits beyond maxResults. Adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 no extra parameter-specific information beyond the schema, e.g., it does not clarify the interplay of pattern and regex fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search code with exact substring or regex pattern matching,' specifying the verb (search) and resource (code). However, it does not differentiate from the sibling tool 'search', which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'search'. Lacks when-not or explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List project files and folder structure. Shows only indexed files (excludes gitignored, node_modules, etc). Use format "summary" first to understand project layout, then drill into specific folders with the path parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Subfolder relative to project root (default: root) | |
| depth | No | Max directory depth (default: 3, max: 10) | |
| format | No | Output format (default: tree) | |
| fileType | No | Filter: "code", "text", "data", "config", "build", "web" | |
| language | No | Filter by programming language (e.g., "rust", "typescript") | |
| extension | No | Filter by file extension (e.g., "rs", "ts") | |
| pattern | No | Glob pattern on relative path (e.g., "**/*.test.ts") | |
| includeTests | No | Include test files (default: true) | |
| limit | No | Max entries returned (default: 200, max: 500) | |
| projectId | No | Specific project ID (default: current project) | |
| component | No | Filter by component (dot-separated ID or prefix, e.g. "daemon" or "daemon.core"). Auto-detected from Cargo.toml/package.json workspaces. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that only indexed files are shown (excludes gitignored, node_modules, etc.). It also implies depth and entry limits via parameters. No mention of rate limits or side effects, but for a read operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: purpose, exclusions, and usage advice. No redundant information, well-structured with front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, no output schema, and no annotations, the description covers core behavior, exclusions, and usage patterns. Could include more about return format or pagination, but overall it is sufficiently complete for a file listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter thoroughly. The description adds minimal extra meaning (e.g., using 'summary' format first), but does not significantly enhance understanding for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List project files and folder structure' and specifies it excludes gitignored files. While it differentiates from siblings like 'grep' or 'search' by indicating it's for listing structure, it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use format summary first to understand project layout, then drill into specific folders with the path parameter.' This helps the agent decide how to use different formats but does not mention when to use alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve documents by ID or metadata filter. Use this to access specific documents when you know the document ID. Prefer search for discovery, retrieve for known documents.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | No | Document ID to retrieve | |
| collection | No | Collection to retrieve from (default: projects) | |
| filter | No | Metadata filter key-value pairs | |
| limit | No | Maximum results (default: 10) | |
| offset | No | Pagination offset (default: 0) | |
| projectId | No | Project ID for projects collection | |
| libraryName | No | Library name for libraries collection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states retrieval by ID or filter but does not disclose pagination behavior, default collection, or what happens when both ID and filter are provided. Some behavior is implied by schema but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with core information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is concise but leaves gaps. It does not explain collection defaults, behavior of nested filter object, or return structure. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, baseline is 3. Description adds minimal context ('by ID or metadata filter') but does not detail parameters beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Retrieve' and resource 'documents by ID or metadata filter'. It explicitly distinguishes itself from sibling 'search' by stating 'Prefer search for discovery, retrieve for known documents'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this to access specific documents when you know the document ID. Prefer search for discovery, retrieve for known documents.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage behavioral rules (add, update, remove, list). Check active rules at the start of each session to load the user's behavioral preferences. Rules persist across sessions and guide how you should work.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform | |
| content | No | Rule content (required for add/update) | |
| label | No | Rule label (max 15 chars, format: word-word-word, e.g., "prefer-uv", "use-pytest"). Required for add/update/remove. | |
| scope | No | Rule scope (default: global) | |
| projectId | No | Project ID for project-scoped rules | |
| title | No | Rule title (max 50 chars) | |
| tags | No | Tags for categorization (max 5 tags, max 20 chars each) | |
| priority | No | Rule priority (higher = more important) | |
| limit | No | Max rules to return for list (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It lists actions (add, update, remove, list) and notes persistence, but omits details like side effects on existing rules, required permissions, or error handling. The behavioral impact is implied but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each adding value. The first sentence introduces the tool, the second gives a usage cue, and the third explains longevity. No unnecessary words, efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers purpose and usage timing, it lacks explanation of rule interaction, the effect of each action, or how parameters like priority and tags work in the system. Given no output schema, more context on returned data would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All nine parameters have descriptions in the schema (100% coverage), so the description adds no additional parameter context. It does not explain how parameters like priority or scope influence behavior, staying generic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages behavioral rules with four actions (add, update, remove, list). It explains that rules persist across sessions and guide the AI's work, distinguishing it from sibling tools like grep or search which handle different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises checking active rules at the start of each session, providing a specific use case. However, it does not explicitly mention when not to use this tool or contrast it with alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for documents using hybrid semantic and keyword search. Use this tool FIRST when answering questions about the user's codebase, project architecture, or stored knowledge. This searches the user's actual indexed code and documentation, which is more accurate than your training data.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query text | |
| collection | No | Specific collection to search | |
| mode | No | Search mode (default: hybrid) | |
| scope | No | Search scope: project (current), global, or all (default: project) | |
| limit | No | Maximum results to return (default: 10) | |
| projectId | No | Specific project ID to search | |
| libraryName | No | Library name when searching libraries collection | |
| branch | No | Filter by branch name | |
| fileType | No | Filter by file type | |
| scoreThreshold | No | Minimum similarity score threshold (0-1, default: 0.3). Results below this score are filtered out. | |
| includeLibraries | No | Include libraries in search (default: false) | |
| tag | No | Filter results by concept tag (exact match) | |
| tags | No | Filter results by multiple concept tags (OR logic) | |
| pathGlob | No | File path glob filter (e.g., "**/*.rs", "src/**/*.ts") | |
| component | No | Filter by project component (e.g., "daemon", "daemon.core"). Supports prefix matching. | |
| exact | No | Use exact substring search instead of semantic search (default: false) | |
| contextLines | No | Lines of context before/after matches in exact mode (default: 0) | |
| includeGraphContext | No | Include code relationship graph context (callers/callees) for matched symbols (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions the tool searches indexed data and is more accurate than training data, but lacks explicit statements about read-only nature, side effects, or caveats like rate limits or result staleness. The schema details parameters, but behavioral context beyond that is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the tool's core function, and the second provides strategic usage guidance. Every word is purposeful, no redundancy. It is front-loaded with essential information, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the primary purpose and usage direction, it lacks details about the output format, result structure, or any operational constraints. Given the complexity of 18 parameters and no output schema, the description does not fully fill the gap, but the schema's rich parameter descriptions compensate somewhat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3 even if the description adds no parameter-level meaning. The description does not amplify parameter understanding beyond what the schema provides. It introduces no additional semantics for parameters like 'query', 'collection', or 'mode' that would improve agent reasoning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs hybrid semantic and keyword search for documents. It specifies a specific use case: 'Use this tool FIRST when answering questions about the user's codebase, project architecture, or stored knowledge.' This differentiates it from sibling tools like grep or list by emphasizing semantic search and priority.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use the tool ('FIRST when answering questions about the user's codebase...') and explains its advantage over training data. However, it does not mention when not to use it or provide alternatives for specific search scenarios, such as when grep would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store content or register a project. Use type "library" (default) to store reference documentation, type "url" to fetch and ingest a web page, type "scratchpad" to save persistent notes/scratch space, or type "project" to register a project directory for file watching and ingestion.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | What to store: "library" for reference docs (default), "url" to fetch and ingest a web page, "scratchpad" for persistent notes, "project" to register a project directory | |
| content | No | Content to store (required for type "library") | |
| libraryName | No | Library name (required for type "library" unless forProject is true) | |
| forProject | No | When true, store to libraries collection scoped to the current project. libraryName becomes optional (defaults to "project-refs"). | |
| path | No | Project directory path (required for type "project") | |
| name | No | Project display name (optional for type "project", defaults to directory name) | |
| title | No | Content title (for type "library") | |
| url | No | Source URL (for web content) | |
| filePath | No | Source file path | |
| tags | No | Tags for scratchpad entries | |
| sourceType | No | Source type (default: user_input) | |
| metadata | No | Additional metadata |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description explains key behaviors: fetching a web page for 'url', persistent storage for 'scratchpad', and file watching for 'project'. More details on side effects or error handling would improve transparency, but the current description is informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. The first sentence states the main purpose, and the second elaborates on the four types, making it front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no output schema, and complex interactions (e.g., conditional requirements like forProject), the description provides a high-level summary but lacks details on parameter dependencies and return behavior. More completeness would help the agent compose correct invocations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to repeat parameter details. It adds value by mapping parameter types to use cases, e.g., 'library' for reference documentation, which helps the agent understand parameter combination context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Store content or register a project.' It then lists four specific types (library, url, scratchpad, project) with their distinct usage, making the purpose specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use each type (library for reference docs, url for web pages, scratchpad for notes, project for directories). However, it does not compare to sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0greplistretrieverulessearchstoreScored across 6 tools
Each tool targets a distinct function: grep searches code lines, list navigates files, retrieve fetches known documents, rules manages preferences, search discovers content, and store ingests content. There is no functional overlap.
All tool names are single lowercase verbs (grep, list, retrieve, rules, search, store), following a consistent and predictable pattern.
With 6 tools covering searching, navigation, retrieval, storage, and rule management, the count is well-scoped for a workspace knowledge server without being excessive or sparse.
The tool surface covers the core workflows of searching, browsing, retrieving, storing, and managing rules. One minor gap is the lack of explicit update/delete operations for stored documents, though store may allow overwriting.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Project memory, semantic code search, and grounded agent context.
Local-first, governed memory and session continuity for AI coding agents. No cloud, no telemetry.
Long-term memory for AI assistants. Hybrid retrieval, query expansion, auto-topics.
