This MCP server exposes 18 tools for codebase indexing, search, and Git analysis via an HTTP bridge. Critical gaps severely limit production readiness: (1) Most tools (15/18) lack descriptions under the 10-1024 character baseline; descriptions present are minimalist (10-40 chars), below the 194-char production average. (2) Input parameter descriptions are sparse or missing entirely, parameters like 'query', 'language', 'limit' exist but lack constraint hints (ranges, enums, format specs). (3) Output schemas are not visible in source code; no documentation of return field structure, pagination, or data types. (4) Error handling is absent, no recovery guidance, validation rules, or categorization visible. (5) Tool naming is mostly sound (verb_noun pattern), but lacks context hints for parameter relationships. (6) Security: no evidence of credential injection, audit logging, or rate limiting. The server operates 18 independent tools with no clear composition story, agents cannot chain results because output schemas are undocumented. Design is monolithic rather than user-centric: 'search' vs 'context_search' vs 'pattern_search' blur intent without clear differentiation.
Tools (18)
change_historyread only50/100
Get Git change history for a specific file or path
collection_mapread onlysource verified62/100
List all collections and their repository mappings
context_searchread onlysource verified53/100
Perform dense semantic search with optional file/symbol context
expand_queryread onlysource verified48/100
Expand a search query with related terms and variants
pattern_searchread onlysource verified58/100
Search for code patterns matching regex or AST patterns
pingread onlysource verified62/100
Health check / keep-alive tool for the MCP bridge
qdrant_indexwritesource verified52/100
Index code in a specified subdirectory of the mounted workspace
Output schemas completely undocumented. No visible return type specifications for any of 18 tools. Agents cannot infer what fields to extract, what to chain to next calls, or how to interpret results.
Tool descriptions are minimal and lack WHEN/WHY context. 'Index code in a specified subdirectory' tells agent nothing about when to prefer qdrant_index vs qdrant_index_root. Baseline is 194 chars; most here are 20-50 chars. No mention of prerequisites, side effects, or error cases.
Expand all tool descriptions to 100-250 characters following the pattern: WHAT it does, WHEN to call it vs similar tools, WHAT it returns. Example: 'Search codebase using dense vector embeddings + optional BM25 reranking. Use for semantic queries (e.g., "auth flow"). Returns ranked code snippets with file path and line numbers. Max 50 results; use limit param to control size.'
Add parameter constraint hints to every parameter description. For 'limit', state 'integer, 1-1000 (default: 20)'. For 'language', list valid enums: 'one of: python, javascript, go, typescript, rust, java, c, cpp, csharp, kotlin, ruby, php, swift'. For 'pattern', specify 'regex pattern string; PCRE syntax supported'.
Document output schema for each tool in a structured format (e.g., return type definition in comments or separate .md file). Minimally: field names, types (string, integer, object, array), and purpose. Example for 'search': 'returns array of {file: string, line_start: integer, line_end: integer, symbol: string, score: float, language: string}'.
Add error handling section to each tool description. State common failures and recovery paths: 'On collection not found, call qdrant_list() to see available collections. On index timeout, retry with smaller subdir. On permission error, check workspace path exists and is readable.'
Distinguish between overlapping search tools in descriptions. Rewrite 'search' as 'Dense vector search with optional lexical reranking, best for broad semantic queries'. Rewrite 'context_search' as 'Semantic search with symbol metadata, best when you need to know function/class names alongside snippets'. Rewrite 'pattern_search' as 'Regex or AST pattern matching, best for structural code searches (e.g., "all function calls to X")'.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained
Score history
Overall score trend
↑ 56 points across a rubric change (v1 → v2)
56/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
56
<=2025-11-25
v2
2026-03-09
F
0
-
v1
source verified
45/100
Index code from the root of the mounted workspace (/work)
qdrant_listread onlysource verified43/100
List all Qdrant collections and their metadata
qdrant_prunedestructivesource verified38/100
Remove stale points for missing files or mismatched file hashes from the collection
searchread only50/100
Search the codebase using dense vector similarity and optional lexical ranking
search_callersread only50/100
Find all functions/methods that call a given symbol
search_commitsread only50/100
Search Git commit history for messages and changes matching a query
search_configread only50/100
Search for configuration files and settings
search_importersread only50/100
Find all files that import or reference a given symbol
search_testsread only50/100
Search for test files related to a code symbol or pattern
Parameter constraints and formats not documented. 'limit' appears in 12+ tools with no min/max bounds stated (baseline: should specify 1-X range). 'language' parameter lacks enum values (python, javascript, go, rust, etc.). 'pattern' in pattern_search has no regex rules stated. LLMs will hallucinate invalid values.
No error handling guidance. Tools like qdrant_prune (DESTRUCTIVE) and qdrant_index (WRITE) lack recovery hints. No mention of what exceptions are possible, how to categorize them (retryable vs fatal), or what agent should do next on failure.
Ambiguous tool selection. Three overlapping search tools exist: 'search' (dense + lexical), 'context_search' (semantic + symbols), 'pattern_search' (regex/AST). No guidance in descriptions explaining which to use when. LLMs will waste reasoning cycles or pick wrong tool.
No pagination or result limits documented. 'search' accepts 'limit' param but no stated maximum. 'collection_map' similar. Returns could be 100s of items, blowing context window. Baseline: 20-50 item cap with pagination guidance.
Parameter relationship dependencies not documented. 'set_session_defaults' takes workspace, collection, repo_name, undocumented if these are independent or required as a group. Do subsequent tools require workspace to be set first? If so, the dependency is silent and will break agent plans.
No idempotency guarantees stated. Tools like 'qdrant_index' (WRITE) and 'qdrant_index_root' (WRITE) do not document whether they are safe to retry. If an agent retries on timeout, does indexing happen twice, creating duplicate vectors?
qdrant_indexqdrant_index_root
Add pagination guidance: 'Results capped at 50 items. To fetch more, omit limit param (will paginate automatically) or use returned next_cursor token in a follow-up call.' Document cursor field in output schema.
Document state dependencies for 'set_session_defaults'. Example: 'Sets session context for all subsequent searches. If not called, tools will use environment defaults. Once set, all qdrant_* and search_* tools will use these workspace/collection/repo settings for the duration of this session.'
Add 'idempotent: true' flag or statement to tool descriptions. For 'qdrant_index' with recreate=false, state 'Safe to retry; idempotent. Duplicate calls will skip files already indexed.' For 'qdrant_index' with recreate=true, state 'NOT idempotent; drops collection. Only call if you intend to rebuild from scratch.'
Create a tool composition guide in docs: 'Typical agent flow: (1) set_session_defaults() to configure workspace, (2) search() or context_search() to find relevant code, (3) search_callers() or search_importers() to trace dependencies, (4) change_history() to understand evolution. Do not call search_* tools before set_session_defaults(), they will fail silently.'
Consolidate similar search tools or clearly differentiate them. Consider: merge 'search' + 'context_search' into single 'search' with optional 'include_symbols' flag. Or: keep separate but rename to 'search_semantic' and 'search_with_symbols' to make intent explicit.
Add type definitions for parameters and outputs in source code (TypeScript JSDoc or similar). Example: '\n * @param {Object} opts\n * @param {string} opts.query - Search query (1-500 chars)\n * @param {string} [opts.language] - Programming language: python|javascript|go|rust (optional)\n * @param {number} [opts.limit=20] - Max results, 1-50 (optional)\n * @returns {Promise<Array<{file: string, line: number, score: number, snippet: string}>>}\n'
Add security/audit logging. Document which tools log their invocations, what PII is stripped, and how to comply with data retention policies. Mention that set_session_defaults() stores workspace paths, verify these don't leak private repo locations.