The Workspace Qdrant MCP server provides AI assistants with project-scoped vector database capabilities for hybrid semantic and keyword search, persistent knowledge storage, and code intelligence across indexed codebases.
Six MCP Tools:
search — Hybrid (semantic + keyword), semantic-only, or keyword-only search across indexed code, documentation, libraries, rules, and scratchpad collections. Supports filtering by file type, path glob, branch, component, tags, and project scope.
retrieve — Fetch specific documents by ID or metadata filter from any collection (projects, libraries, rules, scratchpad) with pagination support.
rules — Add, update, remove, and list persistent behavioral rules that guide AI assistant behavior across sessions, scoped globally or per-project with priorities and tags.
store — Store reference documentation, fetch and ingest web pages, save persistent notes/analysis (scratchpad), or register a project directory for automatic file watching and ingestion.
grep — Fast exact substring or regex pattern matching across indexed files using FTS5 trigram index, with context lines, case sensitivity, and path filtering.
list — Browse indexed project file structure in tree, summary, or flat format, with filtering by language, file type, extension, component, and glob patterns.
Additional Capabilities:
Code Intelligence: Automatic Git repository detection, Tree-sitter semantic chunking, LSP integration, and code relationship graphs with PageRank, community detection, and betweenness centrality algorithms.
Multi-Collection Storage: Four distinct collections — projects, libraries, rules, and scratchpad — with proper isolation.
Background Processing: memexd daemon for continuous file monitoring, embedding generation, and queue processing.
High-Performance CLI: Rust-based wqm tool for service management, search, and administration.
Integration: Compatible with Claude Desktop and Claude Code; available via Homebrew, pre-built binaries, or source build for macOS, Linux, and Windows.
Enables automatic project detection and repository-scoped indexing, allowing for codebase-aware semantic and keyword searches by leveraging Git repository awareness.
Project-scoped vector database for AI assistants, providing hybrid semantic + keyword search with automatic project detection.
🚧 v0.2.0 rebuild in progress
workspace-qdrant-mcp is being rebuilt from the ground up in preparation for v0.2.0 — a unified storage model, better search quality, more reliable file watching, and a cleaner architecture, with a no-re-index migration for existing users. Once the design is locked (targeted early July) we'll open the work to outside contributors. See the Roadmap for the top-line plan.
Hybrid Search - Combines semantic similarity with keyword matching using Reciprocal Rank Fusion
Project Detection - Automatic Git repository awareness and project-scoped collections
7 MCP Tools - search, retrieve, rules, store, grep, list, embedding
Code Intelligence - Tree-sitter semantic chunking + LSP integration for active projects
Code Graph - Relationship graph with algorithms (PageRank, community detection, betweenness centrality)
High-Performance CLI - Rust-based wqm command-line tool
Background Daemon - memexd for continuous file monitoring and processing
Related MCP server: Super-Memory-TS
Qdrant - docker run -d -p 6333:6333 -v qdrant_storage:/qdrant/storage qdrant/qdrant
C compiler - Required for compiling Tree-sitter grammars on first use. Tree-sitter grammars are distributed as C source and compiled locally.
macOS: xcode-select --install (Xcode Command Line Tools)
Linux: apt install build-essential (Debian/Ubuntu) or dnf groupinstall "Development Tools" (Fedora)
Windows: Install Visual Studio Build Tools with C++ workload
Clang/LLVM - Required only to build memexd from source, for the LadybugDB C++ core (the default graph backend). Pre-built binaries (Homebrew, release artifacts) do not need it.
macOS: Xcode Command Line Tools include Clang (xcode-select --install)
Linux: apt install clang libclang-dev (Debian/Ubuntu) or dnf install clang (Fedora)
Alternative: build without the C++ toolchain using the SQLite-only backend — cargo build --no-default-features --features sqlite
Option 1: Homebrew (Recommended — macOS & Linux)
brew install ChrisGVE/tap/workspace-qdrant
brew services start workspace-qdrantOption 2: Pre-built Binaries
# 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 | iexInstalls wqm, memexd, and workspace-qdrant-mcp to ~/.local/bin (Linux/macOS) or %LOCALAPPDATA%\wqm\bin (Windows).
Option 3: Build from Source
git clone https://github.com/ChrisGVE/workspace-qdrant-mcp.git
cd workspace-qdrant-mcp
./install.shSee Installation Reference for detailed instructions and platform-specific notes. For Windows, see the Windows Installation Guide.
Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"workspace-qdrant-mcp": {
"command": "workspace-qdrant-mcp",
"env": {
"QDRANT_URL": "http://localhost:6333"
}
}
}
}Claude Code:
claude mcp add workspace-qdrant-mcp -- workspace-qdrant-mcpwqm --version
wqm status healthAdd the following to your project's CLAUDE.md (or your global ~/.claude/CLAUDE.md) so Claude Code uses workspace-qdrant proactively:
## 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.Tool | Purpose |
| Hybrid semantic + keyword search across indexed content |
| Direct document lookup by ID or metadata filter |
| Manage persistent behavioral rules |
| Store content, register projects, save notes |
| Exact substring or regex search using FTS5 |
| List project files and folder structure |
See MCP Tools Reference for parameters and examples.
Collection | Purpose | Isolation |
| Project code and documentation | Multi-tenant by |
| Reference documentation (books, papers, docs) | Multi-tenant by |
| Behavioral rules and preferences | Multi-tenant by |
| Temporary working storage | Per-session |
# 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 (respects CLAUDE_CONFIG_DIR)
# Queue and monitoring
wqm queue stats # Queue statisticsSee CLI Reference for complete documentation.
Variable | Default | Description |
|
| Qdrant server URL |
| - | API key (required for Qdrant Cloud) |
|
| Embedding model |
wqm init hooks reads and writes Claude Code's settings.json. The
location is resolved from:
Variable | Default | Description |
|
| Claude Code config directory used by |
Example — Claude Code Enterprise:
export CLAUDE_CONFIG_DIR=~/.config/claude/claude-ent
wqm init hooks installThe daemon exposes metrics and traces. Both are disabled by default.
/metrics, pull)Enable via config or env var, then scrape:
# in the daemon config
observability:
telemetry:
prometheus:
enabled: true
port: 9464
bind: 0.0.0.0or:
WQM_PROMETHEUS_ENABLED=true WQM_PROMETHEUS_PORT=9464 memexd --foreground
curl http://localhost:9464/metrics | headThe --metrics-port <N> CLI flag is a shortcut that forces
enabled=true and overrides the port. See
docs/observability/prometheus-scrape-example.yaml for a
scrape_configs snippet and
docs/observability/memexd-telemetry-dashboard.json for a Grafana 10
dashboard.
#[tracing::instrument] spans on the queue processor, watcher, gRPC,
embedding, and Qdrant paths are exported over OTLP/gRPC when:
observability:
telemetry:
service_name: memexd
otlp:
enabled: true
endpoint: http://collector.example:4317
protocol: grpc # http/protobuf is also recognized (logs a warning)
sample_rate: 0.1Standard OpenTelemetry env vars are honored: OTEL_SERVICE_NAME,
OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_PROTOCOL,
OTEL_EXPORTER_OTLP_HEADERS, OTEL_TRACES_SAMPLER_ARG.
OTLP metrics export is not currently implemented — Prometheus is the canonical metrics surface.
+-----------------+
| Claude/Client |
+--------+--------+
|
+--------v--------+
| MCP Server | (TypeScript)
+--------+--------+
|
+--------------+--------------+
| |
+--------v--------+ +--------v--------+
| Rust Daemon | | Qdrant |
| (memexd) | | Vector Database |
+--------+--------+ +-----------------+
|
+--------v--------+
| File Watcher |
| Code Graph |
| Embeddings |
+-----------------+The Rust daemon handles file watching, embedding generation, code graph extraction, and queue processing. All writes route through the daemon for consistency.
User guides:
Quick Start — get running in 5 minutes
User Manual — full usage guide
LLM Integration — best practices for Claude
Reference:
CLI Reference — all wqm commands
MCP Tools — tool parameters and examples
Configuration — all options and defaults
Architecture — component overview
See the Documentation Index for specifications, ADRs, and developer resources.
# Rust daemon, CLI, and MCP server (from src/rust/)
# Builds memexd (daemon), wqm (CLI), and workspace-qdrant-mcp (MCP server)
cargo build --release
cargo test
# Graph benchmarks
cargo bench --package workspace-qdrant-core --bench graph_bench
# Binaries output to:
# - target/release/wqm
# - target/release/memexdSee CONTRIBUTING.md for development setup and guidelines.
Apache License 2.0 - see LICENSE for details.
Inspired by 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. Dates show when Glama detected each change.
v1.0.0greplistretrieverulessearchstoreEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Project memory, semantic code search, and grounded agent context.
Long-term memory for AI assistants. Hybrid retrieval, query expansion, auto-topics.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ChrisGVE/workspace-qdrant-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
