Loading ToolBench
MCP server exposing CodeEraser's code quality and entropy analysis tools: clone detection, deduplication, dead code analysis, documentation duplication, structure judgment, and erase planning
CodeEraser exposes 16 read-only analysis tools with consistent naming (verb_noun pattern: scan, check, erase, etc.) and detailed descriptions (avg ~120 chars). All tools have documented input schemas with type declarations and parameter descriptions. However, output schemas are referenced by name only (e.g., 'ce.scan-report schema') without inline documentation of the actual fields LLMs will receive. Error handling is minimal, no recovery guidance, no actionable error messages, no categorization of retryable vs fatal failures. Parameter descriptions are adequate but lack examples of valid ranges or constraints. No tool annotations (readOnlyHint, destructiveHint) despite all tools being read-only by design. The 'erase' tool is marked READ_ONLY but its description implies it produces a plan for human application, the boundary between dry-run and execution is clear in intent but not formalized in the schema.
ADR-006 baseline judgment: score, ratchet and axes (report only — this surface never writes a baseline).
Verified T1/T2 clone blocks (ce.dedup-report schema).
Append-vs-rewrite and co-change over a git window (ce.churn-report schema).
T3 near-miss clone judgment (ce.clone-report schema); `units` lists the cached unit universe instead.
Liveness verdicts over the reference graph, plus the symbol-level advisory of declarations no other file spells — never a verdict (ce.deadcode-report schema).
Documentation-duplication judgment (ce.docdup-report schema).
This machine's state (ce.doctor-report schema): ce-core handshake, guard tier, index freshness, daemon, degraded-run counter. The daemon is asked without being started.
Output schemas referenced by name only (e.g., 'ce.scan-report schema') without inline field documentation. LLMs cannot infer what fields to extract or how to chain results to downstream tools.
No error handling guidance. Tools lack recovery hints, error categorization (retryable vs fatal), or actionable error messages. If a tool fails, the LLM has no guidance on what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
The deterministic erase PLAN (ce.erase-plan schema) — dry-run by construction: this surface reaches the plan and nothing else, and applying it is a human act at the CLI or the GUI.
The applied-erase audit trail (ce.erase-trail-report schema): every record `ce erase --apply` or the GUI appended to .ce/erase-log.ndjson, with the lines the reader could not parse named by number. Read-only — nothing here can apply or append.
Reference sites, resolution-free (the ce graph --sites rows).
Three-signal join: similarity, graph position, churn (ce.join-report schema).
Size/complexity/readability metrics report (ce.scan-report schema).
The same-role advisor (ce.similar-report schema): the units most like one unit or a text, in the core's order with its role bit and a six-channel evidence row; `widen` adds the PPMI associative view. Advisory — never a verdict.
Tree-scale structure judgment, eight axes (ce.structure-report schema).
Score trajectory over mainline git history (ce.trend-report schema; points cache in the index, rebuildable from history).
Whether a newer CodeEraser release exists (ce.update-report schema): the latest tag, that tag's committed SHA256 pins, and the one action for this install. Reads the release index over the network; places nothing — applying is a human act at the CLI or the GUI.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 16 tools are read-only by design, but this is not formally declared in the schema. LLMs cannot infer safety properties.
Parameter descriptions lack constraint details. E.g., 'days' parameter has no min/max bounds; 'min_tokens' and 'min_distinct' lack guidance on typical ranges. LLMs may pass invalid values.
Tool 'erase' description states it produces a 'dry-run' plan, but the schema does not distinguish between planning and execution modes. The boundary between what erase returns and what erase_log audits is implicit, not explicit.