Loading ToolBench
MCP server for memory management, retrieval, promotion, and context resolution with support for candidate lifecycle, circuit breakers, and feature flags
Vega-memory demonstrates solid schema discipline with Zod-based validation and explicit input schemas for all 8 tools. Tool names follow verb_noun convention (candidate_create, candidate_list, circuit_breaker_status). Descriptions are present and substantive (avg ~80 chars), explaining WHAT each tool does. However, parameter descriptions are sparse or missing context about constraints, dependencies, and error recovery. Output schemas are inferred from code but not explicitly documented in tool definitions. Error handling returns degraded states but lacks actionable recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear WRITE vs READ_ONLY risk classifications in metadata.
Create a candidate memory without promoting it into the main memories table.
Manually demote a promoted memory back into the candidate lifecycle.
Run the policy trigger against one candidate without forcing a manual promotion.
List candidate memories, optionally filtering by project, type, and candidate state.
Manually promote a candidate into the main memories table through the promotion policy engine.
Run the sweep trigger across all sweep-eligible candidates.
Parameter descriptions lack constraint details. E.g., 'actor' param has no guidance on format, length, or valid values. 'limit' in candidate_list has no min/max bounds stated in description.
Output schemas not documented in tool definitions. Code shows return types (CandidateSummary, degraded states) but tool.description does not explain what fields the LLM should expect or how to chain results to downstream tools.
Error responses return degraded states (e.g., 'candidate_store_unavailable') but lack actionable recovery guidance. LLM does not know whether to retry, escalate, or fall back to an alternative tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Reset one surface circuit breaker back to a closed state.
Inspect per-surface circuit breaker state and rolling-window diagnostics.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in metadata. WRITE tools (candidate_promote, candidate_demote, circuit_breaker_reset) should declare destructiveHint=true to signal irreversibility.
candidate_sweep lacks clear description of scope and side effects. Does it sweep all candidates globally or per-project? What triggers promotion? LLM cannot reason about when to invoke it.