A Model Context Protocol (MCP) server implementation for code understanding, storage, and retrieval that enhances Claude's code interactions. Provides tools for adding code files, searching knowledge base, managing documents, and logging operations.
CAR-LightRAG-MCP has 11 tools with complete input schemas and descriptions present. However, descriptions are generic and lack LLM-optimization guidance (e.g., 'Add a code file to the knowledge base' vs. 'Add a code file to build a searchable knowledge base for code analysis and retrieval'). Parameter descriptions are minimal, most lack format constraints, ranges, or usage context. Output schemas are not documented in the tool definitions. Error handling returns basic error objects but lacks recovery guidance or actionable next steps. Tool naming follows verb_noun convention (add_code_file, search_code_knowledge) which is good, but some names are ambiguous: 'search_code_knowledge' vs 'search_by_language' vs 'similar_code' create overlapping intent without clear differentiation. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE, DESTRUCTIVE, READ_ONLY). Composition is reasonable, tools are single-purpose, but chaining is not optimized (e.g., search results do not include document_id for immediate deletion).
Add a code file to the knowledge base
Add a single code snippet to the knowledge base
Add code blocks from markdown text to the knowledge base
Create a new log notebook
Delete code documents by file path
Delete a code document from the knowledge base
List statistics about the code knowledge base
Descriptions lack LLM-optimization guidance. Most are 20-40 chars and do not explain WHEN to use the tool or what it returns. E.g., 'Add a code file to the knowledge base' omits context about chunking, indexing, or retrieval benefits.
No output schemas documented. Tool definitions do not specify what fields are returned (e.g., search_code_knowledge returns results but structure is not declared). LLMs cannot plan downstream calls without knowing response shape.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. delete_code_document and delete_by_path are marked DESTRUCTIVE but lack confirmation or dry-run support. Agents cannot distinguish safe from irreversible operations.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | <=2025-11-25 | v2 |
List all log notebooks
Search the code knowledge base by programming language
Search the code knowledge base
Find similar code to a given code snippet
Parameter descriptions lack format constraints and ranges. 'limit' parameter has no min/max (baseline: 1 - 100). 'file_path' has no validation hint (absolute vs relative, extensions allowed). LLMs pass invalid values without guidance.
Error handling returns generic error objects without recovery guidance. E.g., 'File not found: /path/to/file' does not suggest next steps (check path, list available files, etc.). Agents cannot self-correct.