Loading ToolBench
Progressive deep research engine with knowledge graph, trust scoring, and self-regulation. MCP server for Claude Code, OpenClaw, or any MCP client.
Cascade-engine has 19 well-named tools with consistent verb_noun patterns (store_*, get_*, add_*, update_*, search_*). All tools have descriptions (avg ~120 chars, within 10-1024 range). Input schemas are present and mostly complete with type definitions and constraints (enums, maxLength, min/max for numbers). However, output schemas are NOT documented, LLMs cannot predict response structure for downstream chaining. Parameter descriptions are present but often terse (avg ~40 chars); many lack actionable format guidance. Error handling is minimal, no recovery hints, no categorization of retryable vs fatal errors. Security concerns: no visible permission gates, audit logging, or secret injection patterns despite tools like 'halt' and 'steer' being sensitive. Composition is strong (single responsibility per tool, good naming), but missing batch variants and some tools lack clear prerequisites.
Add an entity to the knowledge graph. Upserts on (name, entity_type).
Add a relationship edge between two entities in the knowledge graph.
Apply a steering intervention to the cascade (internal tool for processing steer actions).
Create a note in the associative memory (amem) graph for knowledge synthesis.
Retrieve the action audit log for safety and compliance tracking.
Get a human-readable dashboard of cascade progress, findings, and interventions.
Query stored findings using full-text search and/or filters.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination) for downstream tool chaining. Tools like get_findings, get_dashboard, get_audit_log return complex objects but no schema is visible in source.
No error handling guidance. Tools lack recovery hints, error categorization (retryable vs fatal), or actionable error messages. E.g., 'Invalid cascade_id' should suggest 'Call get_status() first to verify cascade exists.'
Sensitive operations (halt, steer, apply_steer) lack permission gates and audit logging patterns. No visible authorization checks or compliance tracking despite 'AFR-20 safety mechanism' claim.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Get pending human-in-the-loop interventions for the cascade.
Get current cascade status, round progress, and metrics.
Engage the kill-switch to halt all cascade operations immediately (AFR-20 safety mechanism).
Record a custom metric for the cascade (entropy, coverage, depth, etc.).
Clear the kill-switch and resume cascade operations.
Search notes in the associative memory graph.
Human-in-the-loop steering: redirect research direction, adjust parameters, or inject guidance.
Save a cascade state checkpoint for crash recovery and resumption.
Store a research finding. Generates content-addressable ID. Trust scoring applied automatically.
Store a research hypothesis with affinity maturation tracking.
Save an immutable research plan for a cascade. Locks questions and criteria at round start to prevent HARKing.
Update cascade status (active, paused, stalled, complete).
Parameter descriptions are terse (avg 40 chars). Many lack format guidance, constraints, or dependency hints. E.g., 'state_snapshot' says 'JSON snapshot' but doesn't specify schema or size limits beyond maxLength.
apply_steer appears to be an internal tool (description: 'internal tool for processing steer actions'). Internal tools should not be exposed to LLMs, they create confusion and duplicate functionality with steer().