Loading ToolBench
MCP server for semantic search using local Qdrant and Ollama (default) with support for OpenAI, Cohere, and Voyage AI
The Qdrant MCP server has 8 well-named tools with generally clear descriptions and complete input schemas. Naming is consistently strong (verb_noun pattern: create_collection, semantic_search, delete_collection). Descriptions are adequate (ranging 70-180 chars) and explain what the tools do. However, there are notable gaps: output schemas are not documented anywhere in the provided source, error handling guidance is absent, and parameter descriptions lack detail on constraints, formats, and dependencies. The codebase shows security awareness (path validation in indexer.ts) but lacks explicit error categorization and recovery patterns. Parameter validation happens inside tools but is not surfaced to the LLM via clear error messages or constraint documentation.
Add documents to a collection. Documents will be automatically embedded using the configured embedding provider.
Create a new vector collection in Qdrant. The collection will be configured with the embedding provider's dimensions automatically. Set enableHybrid to true to enable hybrid search combining semantic and keyword search.
Delete a vector collection from Qdrant. This operation is irreversible.
Get the status and statistics of a codebase indexing operation.
Index a codebase for semantic search. Scans files, creates semantic chunks, generates embeddings, and stores vectors in Qdrant. Supports force re-indexing.
List all available vector collections in Qdrant.
Output schemas are not documented. No tool definition includes a 'returns' or output schema description. LLMs cannot predict what fields will be available after calling these tools, forcing them to guess at downstream field names and breaking tool chaining.
Parameter constraints are not documented. Parameters like 'limit', 'scoreThreshold', 'distance' lack min/max values, ranges, or format descriptions. LLMs cannot infer valid ranges and may pass invalid values (e.g., scoreThreshold > 1 or negative limit).
delete_collection lacks a confirmation or dry-run capability. Agents can irreversibly delete collections without explicit confirmation, risking data loss. The description notes 'This operation is irreversible' but provides no guard mechanism.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Semantic search across an indexed codebase. Returns matching code chunks with location information.
Search a collection using semantic similarity. Returns the most relevant documents based on vector similarity.
Error handling guidance is missing. No tool definition explains what errors are retryable, what indicates a user error (e.g., invalid collection name), or what the LLM should do if a call fails. Source code shows error tracking (stats.errors array in indexer.ts) but no error response schema.
Parameter 'extensions' and 'ignorePatterns' in index_codebase and search_codebase lack default values and examples. LLMs do not know what formats are expected (glob patterns? regex? wildcard syntax?) and may produce invalid input.
add_documents metadata parameter is marked optional but its expected structure is not described. LLMs do not know what metadata keys are valid, what values are acceptable, or how metadata affects search.
list_collections accepts no parameters but the description does not clarify whether it returns paginated results, total count, or raw collection objects. Output schema is undocumented.
Tool descriptions do not explain dependencies between tools. For example, semantic_search requires a collection that was created by create_collection, but the description does not hint at this prerequisite. Agents may call semantic_search before creating a collection.