Loading ToolBench
ViloForge KnowledgeBase (vfkb) — per-project knowledge substrate for the ViloForge software factory. Provides MCP tools for searching, listing, and managing project knowledge entries.
vfkb demonstrates solid tool design with well-structured schemas and thoughtful descriptions. All 6 tools have explicit input schemas with typed parameters and enums. Descriptions are substantive (100-300+ chars) and explain WHEN/WHY to use each tool. kb_search is particularly strong with detailed trust/filtering semantics. However, output schemas are not documented in the visible code, responses are described narratively but not formally specified. Error handling guidance is minimal. Tool composition is clean (single responsibility), but no pagination/limit guidance for list operations. Naming is clear and verb-forward (kb_search, kb_add, kb_list, kb_get, kb_map, kb_context).
Add an entry. Fluid types (fact/gotcha/pattern/link) are editable; decisions are immutable (supersede to change). New decisions default to status=proposed (an RFC).
The project context document — the agent's first read. Orients you to the project: its job-to-be-done, architecture, tech profile, conventions, the load-bearing decisions, and links. Read this BEFORE acting on an unfamiliar project. Assembled from the authored context spine + the live Constitution/Map/decisions (always current).
Fetch a single entry by id (full JSON).
List entries by structural filter (no text search).
The derived Context Map — what knowledge exists and how to navigate it.
Search and filter project knowledge. Returns the freshest relevant entries (stale/superseded excluded by default). Pass verified=true to get ONLY human-verified knowledge (excludes unverified agent-authored entries) — the trust filter. An empty result is reported as an honest, cause-distinguished no-match (nothing recorded / below relevance floor / all matches filtered as stale) — it means no recorded entry was found, NOT a licence to answer from model priors as if recorded.
Output schemas not documented. Tools return structured data (entries, maps, context) but no formal schema specification visible in code. LLMs cannot plan downstream operations without knowing response field names and types.
kb_list and kb_map lack pagination/limit guidance. No mention of result caps, pagination tokens, or what happens with large knowledge bases. kb_list accepts 'limit' but no default or max stated.
Error handling is implicit. No guidance on what errors kb_search returns (e.g., 'no matches found' vs 'query syntax error'). kb_add lacks confirmation/dry-run for immutable decisions, risking accidental RFCs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
kb_map and kb_context descriptions are vague. 'The derived Context Map' and 'The project context document' assume familiarity with vfkb's domain model. Descriptions should explain what data is returned and when to call each.
kb_add 'why' parameter is optional but critical for decision rationale. No guidance on when it's required vs optional, or what happens if omitted for a decision entry.