Base de datos vectorial con alcance de proyecto para asistentes de IA, que proporciona búsqueda semántica + por palabras clave híbrida con detección automática de proyectos.
Búsqueda híbrida - Combina similitud semántica con coincidencia de palabras clave utilizando Reciprocal Rank Fusion (RRF).
Detección de proyectos - Reconocimiento automático de repositorios Git y colecciones con alcance de proyecto.
6 herramientas MCP - search, retrieve, rules, store, grep, list.
Inteligencia de código - Fragmentación semántica con Tree-sitter + integración LSP para proyectos activos.
Grafo de código - Grafo de relaciones con algoritmos (PageRank, detección de comunidades, centralidad de intermediación).
CLI de alto rendimiento - Herramienta de línea de comandos wqm basada en Rust.
Daemon en segundo plano - memexd para la supervisión y procesamiento continuo de archivos.
Related MCP server: Super-Memory-TS
Qdrant - docker run -d -p 6333:6333 -v qdrant_storage:/qdrant/storage qdrant/qdrant
Compilador C - Requerido para compilar gramáticas de Tree-sitter en el primer uso. Las gramáticas de Tree-sitter se distribuyen como código fuente C y se compilan localmente.
macOS: xcode-select --install (Herramientas de línea de comandos de Xcode)
Linux: apt install build-essential (Debian/Ubuntu) o dnf groupinstall "Development Tools" (Fedora)
Windows: Instala Visual Studio Build Tools con la carga de trabajo de C++.
Opción 1: Homebrew (Recomendado — macOS y Linux)
brew install ChrisGVE/tap/workspace-qdrant
brew services start workspace-qdrantOpción 2: Binarios precompilados
# 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 | iexInstala wqm y memexd en ~/.local/bin (Linux/macOS) o %LOCALAPPDATA%\wqm\bin (Windows).
Opción 3: Compilar desde el código fuente
git clone https://github.com/ChrisGVE/workspace-qdrant-mcp.git
cd workspace-qdrant-mcp
./install.shConsulta la Referencia de instalación para obtener instrucciones detalladas y notas específicas de la plataforma. Para Windows, consulta la Guía de instalación de 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 healthAñade lo siguiente al archivo CLAUDE.md de tu proyecto (o a tu ~/.claude/CLAUDE.md global) para que Claude Code utilice workspace-qdrant de forma proactiva:
## 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.Herramienta | Propósito |
| Búsqueda híbrida semántica + por palabras clave en el contenido indexado |
| Búsqueda directa de documentos por ID o filtro de metadatos |
| Gestionar reglas de comportamiento persistentes |
| Almacenar contenido, registrar proyectos, guardar notas |
| Búsqueda exacta de subcadenas o expresiones regulares usando FTS5 |
| Listar archivos del proyecto y estructura de carpetas |
Consulta la Referencia de herramientas MCP para ver parámetros y ejemplos.
Colección | Propósito | Aislamiento |
| Código y documentación del proyecto | Multi-inquilino por |
| Documentación de referencia (libros, artículos, docs) | Multi-inquilino por |
| Reglas de comportamiento y preferencias | Multi-inquilino por |
| Almacenamiento de trabajo temporal | Por sesión |
# 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 statisticsConsulta la Referencia de la CLI para obtener la documentación completa.
Variable | Predeterminado | Descripción |
|
| URL del servidor Qdrant |
| - | Clave de API (requerida para Qdrant Cloud) |
|
| Modelo de incrustación (embedding) |
+-----------------+
| Claude/Client |
+--------+--------+
|
+--------v--------+
| MCP Server | (TypeScript)
+--------+--------+
|
+--------------+--------------+
| |
+--------v--------+ +--------v--------+
| Rust Daemon | | Qdrant |
| (memexd) | | Vector Database |
+--------+--------+ +-----------------+
|
+--------v--------+
| File Watcher |
| Code Graph |
| Embeddings |
+-----------------+El daemon de Rust gestiona la supervisión de archivos, la generación de incrustaciones, la extracción del grafo de código y el procesamiento de colas. Todas las escrituras se dirigen a través del daemon para garantizar la consistencia.
Guías de usuario:
Inicio rápido — empieza a trabajar en 5 minutos
Manual de usuario — guía de uso completa
Integración con LLM — mejores prácticas para Claude
Referencia:
Referencia de la CLI — todos los comandos de wqm
Herramientas MCP — parámetros de herramientas y ejemplos
Configuración — todas las opciones y valores predeterminados
Arquitectura — descripción general de los componentes
Consulta el Índice de documentación para especificaciones, ADRs y recursos para desarrolladores.
# 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/memexdConsulta CONTRIBUTING.md para la configuración de desarrollo y las directrices.
Licencia MIT - consulta LICENSE para más detalles.
Inspirado en 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.
