Loading ToolBench
Proof-aware codebase intelligence - smarter context, fewer tokens. MCP server for AI-driven code understanding with wiki-based documentation, call graph analysis, dead code detection, and architectural decision records.
Provenant has 7 tools with complete input schemas and descriptions. Naming is verb-forward (provenant_*) and mostly clear. Descriptions are substantive (100-300 chars), explaining WHAT and WHEN. However, parameter descriptions lack depth, many omit format constraints, valid ranges, or dependency hints. Output schemas are not documented in the visible code. Error handling is minimal; tools return status/message but lack recovery guidance. Tool composition is sound (each does one thing), but some tools like provenant_context and provenant_dead_code have many optional parameters that could benefit from clearer grouping and defaults.
Attach human-authored notes to a file's wiki page. Notes persist across re-indexing — use them for rationale, known issues, or context that the LLM shouldn't overwrite. Pass an empty string to clear existing notes.
RAG-style synthesis over the wiki layer. Single-call retrieval + LLM synthesis that returns synthesized answer, citations, confidence level, fallback targets for verification, and raw retrieval hits with snippets. Degrades to retrieval-only mode when no LLM provider is configured.
Find who calls a symbol and what it calls. Also works for class hierarchy queries. Use direction="callers" to find what calls/extends this symbol. Use edge_types=["extends","implements"] for class hierarchy queries. Default edge_types is ["calls"].
Show the architectural community/cluster a file belongs to. Returns community label, cohesion score, members, and neighboring communities. Useful for understanding module boundaries and refactoring safety.
The workhorse tool for files, modules, or symbols. Absorbs functionality from former get_symbol, get_callers_callees, get_graph_metrics, and get_community tools via the include parameter. Returns file/module/symbol context with optional source code, callers, callees, graph metrics, and community information.
Output schemas not documented. Tools return dicts but LLMs cannot infer field structure, types, or required vs optional fields. Agents cannot plan downstream calls or extract data reliably.
Parameter descriptions lack format constraints and valid ranges. E.g., 'direction' accepts 'callers, callees, or both' but no enum constraint; 'limit' has default 20 but no min/max bounds; 'min_confidence' has default 0.5 but no range stated.
Error handling is minimal. Tools return {status: 'error', message: '...'} but do not guide recovery. E.g., provenant_annotate returns 'No wiki page found' but does not suggest 'Run provenant init first' as a recovery action.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
Get a tiered refactor plan for dead and unused code. Returns findings organized into confidence tiers (high/medium/low), with per-directory rollups, ownership hotspots, and impact estimates so you can prioritize cleanup. Use group_by="directory" for directory-level overview, or group_by="owner" to see who owns the most dead code.
Create, update, or manage architectural decision records. Six actions: create (record new decision), update (update content fields), update_status (change status), delete (remove decision), list (list decisions with filters), get (get single decision by ID).
provenant_dead_code has 13 optional parameters with complex interdependencies (kind, tier, directory, owner, group_by, include_internals, etc.). No documentation of which combinations are valid or recommended. LLMs will struggle to compose valid calls.
provenant_decisions action parameter accepts 6 values (create, update, update_status, delete, list, get) but no enum constraint in schema. Parameter descriptions do not clarify which other params are required/forbidden per action.