Design graph for hexagonal-architecture codebases. Renders what a branch changed as one picture a human can confirm at a glance, and gives a coding agent boundary verdicts it can run on itself before asking for review.
Three tools with clear, domain-specific descriptions (avg 180 chars) and well-defined enum parameters. All tools are READ_ONLY and properly scoped. However, input schemas lack explicit type declarations in the visible code, parameters are documented in descriptions but not formally typed in JSON Schema. Output schemas are not documented. Tool names are verb-noun style and unambiguous. No error handling guidance or recovery paths documented.
Whether the code breaks its own architecture: cross-domain Entity access, an Entity leaked into a contract, an inbound adapter touching an Entity, an application or domain type referencing an adapter. Run this after finishing a change and before opening a PR — these are verdicts over the whole graph, so reading files will not surface them. scope 'delta' reports only what this branch introduced, including a relation that already existed but became a violation because a type moved.
How a type is wired, in either direction. 'out' = what it depends on and which methods it actually calls on each — including references held only in a local variable, whose type name never appears in the source, so grep cannot find them. 'in' = what depends on it, which of its methods each consumer uses, and which it declares that nobody calls. Use 'in' before adding a method to an existing port or use case: if the consumers already use disjoint subsets, the interface wants splitting rather than growing. Raise hops to see what a change would reach beyond the direct callers.
What this branch changed structurally against the base: types added, types whose public contract or relations changed — and for each, exactly what was added or removed. Use it before opening a PR to confirm the change matches what was agreed, and to describe it from facts rather than memory. Needs the server started with --base.
Input schemas lack explicit JSON Schema type declarations. Parameters are documented in descriptions but not formally typed (e.g., 'scope' enum, 'hops' integer constraints not visible in schema structure).
Output schemas are not documented. LLMs cannot plan downstream tool calls or extract structured data without knowing what fields each tool returns.
No error handling guidance. Tools lack recovery hints (e.g., 'If --base is missing, run with --base <ref>'). Errors will not guide LLM recovery.
Tool descriptions reference prerequisites (--base flag, type names) but do not explain how LLM should obtain them or what to do if missing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Parameter 'hops' has min/max constraints (1-4) documented in description but not formally declared in schema structure.