Pi-agent wrapper around codebase-memory-mcp: derived code knowledge (call graphs, blast radius) over a harness-owned trust boundary
pi-codegraph wraps codebase-memory-mcp via STDIO. Tool definitions are visible in src/cli.js with names, descriptions, and input schemas. However, critical gaps undermine quality: (1) descriptions are terse (10-50 chars), below the 50-200 char LLM-optimized baseline; (2) parameter descriptions are minimal or absent (e.g., 'depth' in trace_path lacks guidance on valid range); (3) no output schemas documented, LLMs cannot predict response structure; (4) no error handling guidance, failures offer no recovery path; (5) no parameter constraints (enums, ranges, patterns) despite tools accepting free-form strings like 'query' in search_graph. The tool names follow verb_noun convention (get_, search_, trace_, detect_, list_) which is good, but descriptions fail to explain WHEN to use each tool or what distinguishes similar ones (e.g., search_graph vs get_code_snippet). No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. index_repository is marked WRITE but has no confirmation or dry-run pattern.
Detect changes and blast radius
Codebase overview
Get code snippet for a qualified name
Node/edge counts
Index the trusted repo into the knowledge graph (must run before any query)
List indexed projects
Search the code graph
No output schemas documented. LLMs cannot predict response structure or plan downstream tool calls. E.g., get_architecture returns 'Codebase overview' but no field list.
Parameter descriptions are minimal or absent. 'depth' in trace_path lacks range guidance; 'query' in search_graph has no format constraints; 'limit' in search_graph has no min/max bounds.
Tool descriptions are too terse (10-50 chars vs. 50-200 char baseline). Descriptions lack WHEN to use, dependencies, or prerequisites. E.g., 'Codebase overview' does not explain when to call get_architecture vs search_graph.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
Who calls a function
No error handling guidance. Failures (e.g., project not found, repo not indexed) offer no recovery path or actionable next steps for the LLM.
index_repository (WRITE risk) lacks confirmation or dry-run pattern. No guidance on idempotency or side effects. Agents may accidentally re-index without understanding consequences.