Loading ToolBench
A lightweight sidecar for AI coding agents providing persistent codebase index (AST-aware code search via FTS5), intent tracking (dependency graph of tasks), and evaluation scoring (golden set quality checks)
HIEF demonstrates solid foundational quality with 15 well-named tools, comprehensive parameter schemas, and structured output types. However, descriptions are inconsistent in depth and actionability. Most tools have descriptions (13/15), but several lack guidance on when to use them vs. similar tools, and error handling lacks recovery hints. Parameter descriptions are present but often generic. The server correctly uses enums for constrained inputs (kind, priority, status) and validates paths/top_k. Output schemas are documented via JsonSchema derives. Main gaps: descriptions under 100 chars lack context; no error recovery guidance; some parameters (e.g., session_id) appear in multiple tools without clear dependency documentation.
Create a new intent (task) with kind, title, description, priority, dependencies, and optional skill association
Execute a dynamically loaded skill with arbitrary parameters
Get evaluation scores for a golden set with optional limit on recent entries
Get current project context including index stats, active intents, and ready intents
Get context for an MCP session including related file suggestions
Get a specific skill definition by name
Get git blame information for a file range
execute_dynamic_skill lacks specificity: description is vague ('Execute a dynamically loaded skill with arbitrary parameters'), schema shows only skill_name parameter but no guidance on what 'arbitrary parameters' means or how they map to skill definitions. LLM cannot determine valid inputs.
reload_skills and run_evaluation lack context on when to call them vs. alternatives. reload_skills description (55 chars) does not explain whether it's automatic or manual, or what triggers a reload. run_evaluation (60 chars) does not clarify what 'golden sets' are or how they relate to project evaluation.
session_id parameter appears in search_code, structural_search, semantic_search, and get_session_context without clear dependency documentation. LLM cannot infer whether session_id is required, optional, or auto-populated. No guidance on how to obtain a session_id or what happens if omitted.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
List intents with optional filtering by status and kind
Find files related to a given file based on dependency and usage patterns
Reload skill definitions from disk and register their tool handlers
Run evaluation against golden sets with optional filtering by specific golden set name
Search the code index using FTS5 syntax with optional language and symbol kind filters, with cognitive memory boost capability
Search code using natural language queries with vector embeddings (requires vectors.enabled in config)
Search code using ast-grep patterns for structural code matching across supported languages
Update an intent's status and assignment
Error handling lacks recovery guidance. No tool description includes 'If X fails, try Y' or categorizes errors as retryable vs. user-fixable. Code shows validate_* helpers but no error response examples in tool definitions.
Destructive operations (create_intent, update_intent, reload_skills) lack confirmation or dry-run support. No tool description warns that these modify state or suggests a preview step before execution.