MCP server exposing projectmind tools to LLM agents (Claude Code, etc.) for architecture analysis, code navigation, and visualization of software repositories.
ProjectMind MCP server has well-structured tool definitions with complete JSON schemas and clear naming conventions. All 8 tools follow verb_noun patterns (open_repo, show_class, list_classes, etc.). Descriptions are present and moderately detailed (avg ~120 chars), meeting baseline minimums. However, parameter descriptions are sparse or missing for many fields, particularly in complex tools like walkthrough_step. Output schemas are not documented, forcing LLMs to infer response structure. Error handling guidance is absent. The server demonstrates solid foundational quality but lacks the polish and LLM-optimization needed for A-grade production use.
Get the outline/structure of a class
Generate a diagram of the specified type
Retrieve documentation for a class
Search for classes by name using fuzzy matching
List classes in the repository, optionally filtered by stereotype
Open a repository for analysis
Display a class with optional line highlighting
walkthrough_step has deeply nested, underdocumented schema. The 'target' object contains 15+ conditional fields (kind, fqn, path, anchor, id, ref, diagram, from, to, show, pattern, scope, view, module, highlight_fqns, focus, highlight) with minimal per-field descriptions. LLMs cannot reason about which fields apply to which 'kind' values without explicit dependency documentation.
No output schemas documented for any tool. LLMs must infer response structure (e.g., does find_class return {results: [...], total: N} or just an array?). This forces agents to guess field names and risks chaining failures when passing results to downstream tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Create a walkthrough step with target rendering and narration
Parameter descriptions are minimal or absent. 'stereotype' in list_classes has a description but no guidance on valid values. 'highlight' arrays in show_class and walkthrough_step lack explanation of what 'from' and 'to' represent (line numbers? character offsets?). 'diagram' enum values are self-explanatory but lack context on when to use each.
No error handling guidance. Tools lack descriptions of failure modes (e.g., what if open_repo receives an invalid path? What if find_class query matches nothing?). Agents have no recovery path when calls fail.
diagram tool description is vague ('Generate a diagram of the specified type'). No guidance on prerequisites (must open_repo first?), output format (SVG? JSON? Mermaid?), or when to use each diagram type. LLMs cannot reason about tool selection.