MCP server that builds code graphs to provide rich context to LLMs
The server defines 10 tools with explicit registration and schema declarations. Most tools have descriptions and basic input schemas with type information. However, there are significant gaps: (1) output schemas are completely undocumented, no tool documents what it returns, forcing LLMs to guess at response structure; (2) many parameter descriptions are minimal or missing entirely (e.g., check_parse_status has only 1 param with a basic 1-line description); (3) tool naming is inconsistent, some follow verb_noun (detect_dead_code, list_projects) but others use underscores that blur intent (ingest_cursordiff_session vs ingest_deliberate_session are confusingly similar); (4) error handling is not visible in the tool implementations shown, and recovery guidance is absent; (5) parameter documentation lacks format constraints, ranges, and dependency hints that would help LLMs use tools correctly. The server does NOT expose secrets as parameters (good), but lacks permission gates and audit trail declarations. The tools cover a reasonable domain (code graph analysis, dead code detection, impact analysis) but need substantial refinement to meet production quality standards.
Check Parse Status Tool - Returns the status of an async parsing job
Detect Dead Code Tool - Identifies potentially unused code in the codebase
Detect Duplicate Code Tool - Identifies duplicate code using structural (AST hash) and semantic (embedding similarity) analysis
Hello Tool - Simple test tool to verify MCP connection
Impact Analysis Tool - Analyzes what would be affected if a node is modified
ingest_cursordiff_session MCP tool - Ingests cursordiff JSONL rows into the graph database in one-shot or watch mode
ingest_deliberate_session MCP tool - Ingests deliberation JSONL rows into the graph database in one-shot or watch mode
NO OUTPUT SCHEMAS DOCUMENTED (critical). All 10 tools lack documented return types, forcing LLMs to infer response structure by reading code or guessing. This violates pattern:tool and increases hallucination risk.
INCONSISTENT PARAMETER DESCRIPTIONS. Many parameters have terse, generic, or domain-jargon descriptions that lack actionable guidance. E.g., 'Minimum confidence threshold' (detect_dead_code) does not explain when to use LOW vs. MEDIUM vs. HIGH. 'Vector neighbors per node' (detect_duplicate_code) lacks latency/thoroughness tradeoff guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
list_ingest_cursordiff_watchers MCP tool - Returns all active cursordiff fs-watch sessions with health observability fields
list_ingest_deliberate_watchers MCP tool - Returns all active deliberation fs-watch sessions with health observability fields
List Projects Tool - Lists all parsed projects in the database
WRITE OPERATIONS NOT EXPLICITLY DOCUMENTED. ingest_cursordiff_session and ingest_deliberate_session have Risk=WRITE but tool descriptions do not explicitly state 'This tool modifies the database' or list what side effects occur. Agents need to know which calls are safe to retry and which are irreversible.
PARAMETER RELATIONSHIPS UNDOCUMENTED. impact_analysis has nodeId and filePath marked optional with vague 'Alternatively' language, should explicitly state 'mutually exclusive; provide exactly one' or 'if nodeId is absent, filePath must be provided'.
DOMAIN-SPECIFIC JARGON WITHOUT EXPLANATION. Tool names like 'ingest_cursordiff_session', 'cursordiff', 'deliberate', and parameters like 'frameworkConfig' assume domain knowledge. New LLMs or agents unfamiliar with this codebase will struggle to infer when/why to call these tools.
NO ERROR RECOVERY GUIDANCE. Tool implementations (shown in check-parse-status.tool.ts) return error strings but do not guide the LLM on what to do next. E.g., 'Job not found' does not suggest 'use check_parse_status with a valid jobId' or 'call parse_typescript_project to start a new job'.
MISSING TOOL ANNOTATIONS. The server does not declare readOnlyHint, destructiveHint, or idempotentHint annotations on tools. Even though Risk tags are assigned (e.g., Risk=WRITE for ingest_* tools), these are not surfaced as formal MCP tool annotations that LLMs can parse.
NO PAGINATION GUIDANCE FOR LIST TOOLS. list_projects and watcher list tools do not declare pagination parameters (offset, limit) or total count fields, yet they are discovery tools that may return many results. Response bloat risks context exhaustion.