An MCP server that indexes local code into a graph database to provide context to AI assistants. Turn code repositories into a queryable graph for AI agents.
CodeGraphContext provides 14 code analysis tools with mostly clear descriptions and well-structured schemas. However, several critical gaps limit production readiness: (1) Missing output schemas documented for most tools, LLMs cannot predict response structure for downstream tool chaining; (2) Parameter descriptions lack specificity on constraints (e.g., depth range for analyze_code_relationships is stated as 1-20 but not validated in description); (3) No error handling guidance, tools do not explain failure modes or recovery steps; (4) The delete_repository tool has strong warning text but lacks a dry-run/confirmation step despite being marked DESTRUCTIVE; (5) Many optional parameters (repo_path, graph_name) lack default behavior documentation. Strengths: All 14 tools have clear action-verb naming (add_, check_, list_, find_, analyze_, execute_, delete_, calculate_, visualize_); all have substantive descriptions (100+ chars each, well above the 34-char p10 baseline); schemas are present and properly typed with enums and required fields. The analyze_code_relationships tool exemplifies good design with a constrained enum of 14 query types, clear required/optional separation, and depth bounds. However, the lack of output schema documentation and error recovery guidance prevents this from reaching A-grade status.
Performs a one-time scan of a local folder to add its code to the graph. Ideal for indexing libraries, dependencies, or projects not being actively modified. Returns a job ID for background processing.
Add a package to the graph.
Analyze code relationships like 'who calls this function' or 'class hierarchy'.
Calculate complexity of a function.
Check the status and progress of a background job.
DESTRUCTIVE AND IRREVERSIBLE. Permanently deletes a repository and every node and relationship belonging to it from the graph. There is no undo, and recovering the data requires a full re-index, which can take a long time on a large repository. Only call this when the user has explicitly asked for that repository to be removed.
Output schemas not documented for any tool. LLMs cannot predict response structure, preventing proper tool chaining and data extraction planning.
No error handling guidance. Tools do not explain failure modes (e.g., what happens if repo_path does not exist, if job_id is invalid, if Cypher query is malformed). LLMs cannot self-correct without recovery hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Run a read-only Cypher query against the code graph.
Find relevant code snippets related to a keyword (e.g., function name, class name, or content).
Find potentially unused functions.
Find most complex functions.
List all indexed repositories.
List all background jobs and their current status.
Generate a Neo4j visualization URL for a Cypher query.
Continuously monitors a directory and keeps graph updated.
delete_repository lacks confirmation/dry-run pattern despite DESTRUCTIVE risk. No way to preview what will be deleted or require user approval before irreversible action.
Parameter constraints not fully specified in descriptions. E.g., analyze_code_relationships depth is 1-20 per schema but description does not state this range; edit_distance is 0-2 but not explained in find_code description.
Optional graph_name and repo_path parameters lack default behavior documentation. Unclear what happens if omitted or what 'defaults to the server's configured graph name' means operationally.
list_jobs and list_indexed_repositories lack pagination parameters (limit, offset, next_cursor). Large result sets will exhaust context window.
find_code and analyze_code_relationships do not document result limits. If a query matches hundreds of code snippets, all are returned, wasting tokens. Should cap results and offer pagination.