Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
kdex provides 4 well-named read-only tools with clear descriptions and structured input/output schemas. All tools follow verb-noun naming convention (search, list, get) and are appropriately scoped. However, output schemas are not explicitly documented in the source code excerpt provided, parameter descriptions lack constraint details (ranges, formats, allowed values), and error handling guidance is absent. The descriptions are adequate but could be more actionable (e.g., typical use cases, when to prefer one tool over another). No parameter validation rules are visible in the code snippet, and no guidance on failure modes or recovery paths.
Tools (4)
get_contextread onlysource verified75/100
Get lines of context around a specific line number in a file
get_fileread onlysource verified73/100
Get the full content of a specific file from the index
list_reposread onlysource verified72/100
List all indexed repositories with their status and file counts
searchread onlysource verified77/100
Search indexed code and knowledge repositories for relevant content. Supports lexical (default), semantic (vector), or hybrid search modes.
Output schemas not documented in source. Tool descriptions state what is returned (e.g., 'search results with snippet', 'file content'), but no explicit JSON schema for response objects is visible. LLMs need documented output fields to plan downstream operations and extract data reliably.
Parameter constraints missing. 'limit' (u32, default 10, max 50) and 'max_chars' (u32, default 50000) lack explicit min/max constraints in descriptions. 'context_lines' lacks bounds. LLMs cannot parse schema-level constraints from Rust type annotations, they rely on descriptions to understand valid ranges.
Error handling guidance absent. No mention of what happens if a file path is invalid, if a repository is not indexed, or if a search times out. Tool descriptions do not indicate failure modes or suggest recovery steps.
searchlist_repos
Recommendations
Document output schemas explicitly. For 'search', define McpSearchResponse fields: results (array of {file: string, repo: string, snippet: string, score: float, mode: string}), total (integer), query (string), mode (string), truncated (boolean), hint (string|null). For 'list_repos', specify returned fields (repo_name, file_count, status, last_indexed). For 'get_file', clarify whether it returns {content: string, path: string, size: integer} or just the raw content. For 'get_context', specify {path: string, line_start: integer, line_end: integer, lines: array of {line_number: integer, content: string}}.
Add constraint details to parameter descriptions. Rewrite search 'limit' as 'Maximum number of results to return (default: 10, range: 1-50)'. Rewrite 'max_chars' as 'Maximum characters to return (default: 50000, range: 1-1000000)'. Rewrite 'context_lines' as 'Number of context lines before and after the target line (default: 10, range: 1-100)'. Use 'must be', 'range', and explicit numbers, LLMs parse these patterns reliably.
Formalize the 'mode' parameter as an enum. Instead of 'Search mode: lexical (default), semantic, or hybrid', use JSON Schema enum: ["lexical", "semantic", "hybrid"] with description 'Search mode: lexical (keyword-based, fast, default), semantic (embedding-based, slower, better for intent), or hybrid (combines both).'
Add error handling guidance. For all tools, document failure modes: 'If a file path is invalid, returns error code FILE_NOT_FOUND with message "File not found at <path>. Ensure path is absolute and file is indexed." Try list_repos() to see indexed files.' For search, add 'Timeouts return SEARCH_TIMEOUT after 30 seconds; consider reducing limit or adding more specific repo filters. Semantic mode may timeout on large indices, try lexical mode instead.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Search mode parameter lacks enum constraint in description. 'mode' accepts 'lexical', 'semantic', or 'hybrid', but this is stated as a string description, not a formal enum. LLMs may hallucinate invalid mode names like 'fuzzy' or 'exact'.
Tool composition opportunities missed. 'search' + 'get_file' is a common two-step pattern (find file, then retrieve full content). No batch variant for searching multiple files or retrieving context for multiple line ranges. Agents will make repeated sequential calls.
Descriptions lack actionability hints. 'search' does not mention when to use semantic vs lexical mode, or what 'hybrid' mode does. 'get_context' does not explain what line numbering scheme is used (1-indexed? 0-indexed?). 'repo' filter in search does not clarify whether it accepts full paths or short names.
searchlist_reposget_context
Clarify tool differences and use cases. Add to search description: 'Use lexical search for specific keywords or code patterns; use semantic search when the query intent is more important than exact keywords (e.g., "how do we handle errors?"). Hybrid combines both, slower but finds more relevant results.' Add to get_file vs get_context: 'Use get_file to retrieve complete file content; use get_context to efficiently extract code snippets around a specific line number (cheaper than loading the entire file).'
Specify line numbering convention. Update get_context description: 'Line number is 1-indexed (first line = 1). Returns context_lines lines before and after, capped at file bounds (no wrapping).' For get_file, add 'Returns file content as UTF-8 string with lines delimited by \n; truncated at max_chars boundary (may cut mid-line).'
Clarify repo parameter behavior. Update search description: 'repo filters by repository name (short name, not full path, e.g., "my-project", not "/home/user/repos/my-project"). Leave blank to search all indexed repos. Use list_repos() to discover available repository names.'
Add chaining guidance. After search, the response should include repo name alongside file path, so get_file can be called immediately. Update search output documentation to confirm {file: "path/to/file.rs", repo: "repo-name", ...} are both present. After list_repos, ensure output includes file paths or a reference the agent can pass to get_file.
Avoid free-form file_type filter. Currently 'file_type: string' with example 'rust', 'markdown', 'python'. Formalize as enum or document allowed values explicitly. Add: 'file_type filters by file extension or language (e.g., "rust", "py", "md", "json"). Leave blank to search all types. Use list_repos() to see indexed file types.'
Add pagination hint to search. If results exceed limit, specify whether truncated flag indicates more results exist. Document next cursor or offset pattern if search supports pagination: 'If truncated=true, call search again with an offset parameter (not yet shown but planned) to fetch the next batch.' This prevents agents from assuming they have complete results.