Local-only code intelligence tool for CLI agents. SQLite-backed repository indexing and code search via MCP.
KotaDB presents a well-structured MCP server with 18 tools for code intelligence. Most tools have descriptions and documented schemas, but quality varies significantly across tools. Strengths: comprehensive parameter documentation with constraints (enums, limits), clear output guidance, and verb-noun naming. Weaknesses: several tools combine multiple responsibilities (e.g., search with 5 scopes), some descriptions lack actionable guidance, and error handling patterns are not explicitly visible in definitions. The server demonstrates good intent but inconsistent execution across the tool suite. Average tool score: 72.
Analyze the impact of proposed changes on the codebase by examining file dependencies, affected tests, and architectural implications.
Find all usages of a specific symbol (function, class, variable, etc.) across the codebase.
Generate comprehensive context for LLM task execution by analyzing dependencies, symbols, and patterns relevant to a specific goal.
Get the most-depended-on files (key files) for a specific domain or feature area, useful for understanding core abstractions.
Get statistics about indexed repositories including file counts, symbol statistics, and last indexing time.
Get recently observed code patterns from the patterns table.
search tool combines 5 distinct scopes (code, symbols, decisions, patterns, failures) in a single tool, violating single-responsibility principle. LLM must reason about scope selection before calling.
kota_sync_export and kota_sync_import use opaque naming (kota_sync_*) instead of standard verb_noun convention (export_repository, import_repository). LLM cannot infer action from name alone.
validate_expertise and sync_expertise lack clear descriptions of 'expertise' file format, schema, and purpose. LLM cannot determine when to use these tools or what to pass.
Most tools lack explicit output schema documentation. LLMs must infer what fields to expect, risking wrong downstream tool selections and lost context.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Index a git repository by cloning/updating it and extracting code files. Performs synchronous indexing and returns immediately with status 'completed' and full indexing stats.
Export indexed repository data to JSONL format for external processing, backup, or synchronization.
Import indexed repository data from JSONL format, merging with existing data in SQLite.
List recently indexed files, ordered by indexing timestamp. Useful for seeing what code is available.
Record an architectural decision, pattern, or implementation choice for future reference and AI context.
Record a failed approach, attempted solution, or debugging path to help avoid repeating failed strategies.
Record a session insight, observation, or useful finding for future reference.
Search indexed code, symbols, decisions, patterns, and failures. OUTPUT MODES: - 'paths': File paths only (~100 bytes/result) - 'compact': Summary info (~200 bytes/result) - DEFAULT for code scope - 'snippet': Matching lines with context (~2KB/result) - 'full': Complete content (~100KB/result) - Use with caution for code scope TIPS: - Use 'snippet' for code exploration (shows matches in context) - Use 'compact' for quick file discovery - Use 'full' only for small result sets (symbols, decisions, etc.) Supports multiple search scopes simultaneously with scope-specific filters.
Search the dependency graph to find files that depend on (dependents) or are depended on by (dependencies) a target file. Useful for impact analysis before refactoring, test scope discovery, and circular dependency detection.
Synchronize pattern definitions from expertise.yaml into the patterns table for integrated code context.
Validate expertise.yaml pattern definitions against the indexed codebase to ensure patterns are accurate and findable.
Validate an implementation specification against the indexed codebase for feasibility, conflicts, and alignment with existing patterns.
No error handling guidance visible in tool descriptions. Descriptions do not indicate recovery paths if repository is not found, indexing fails, or validation detects conflicts.
record_insight, validate_expertise, and sync_expertise descriptions are vague about their intended use. No examples or clarification of when LLM should invoke them.
Pagination not explicitly documented for list-returning tools (list_recent_files, search with limit). No indication of total count, next_cursor, or max page size.