Loading ToolBench
ARIA MCP server and estate management system — a polyglot monorepo (Swift + Rust + Python) providing memory management, semantic recall, and AI context orchestration through the Model Context Protocol
18 tools with significant quality gaps. All tools have descriptions (10-100 chars, mostly 50-90 chars), but descriptions are generic and lack actionable context. Input schemas present for all tools with basic type declarations, but lack enums, constraints, ranges, and format specifications. No output schemas documented. Parameter descriptions are minimal (10-30 chars) and do not explain expected formats, constraints, or dependencies. No error handling guidance. Tools like 'dispatch_tool' and 'estate_provision' expose dangerous flexibility without validation hints. Naming is inconsistent: 'moot_vault_read/write' vs 'memory_read/write' (same concept, different names). No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Missing composition guidance, unclear which tools chain together or what IDs downstream tools expect.
Report on the current state of the Autonomic Governor and system health metrics
Set the primary backend for memory operations in the moot-bridge memory server
Dispatch a tool call to the ARIA engine with structured parameters
Start a dreaming session for the specified estate to perform background learning
Capture context frames into the estate with optional BM25 indexing
Destroy an estate and clean up all associated resources
Drain an estate to finalize pending operations before destruction
Provision a new estate with specified configuration and corpus
dispatch_tool accepts arbitrary 'tool_name' and 'parameters' object with no validation, enum, or constraint guidance. LLM cannot infer valid tool names or parameter shapes. Violates constrained-input pattern.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required IDs (e.g., estate_id from estate_provision). Violates response-shaper and tool-chain patterns.
Destructive tools (estate_destroy, memory_delete) lack confirmation/dry-run support and error recovery guidance. No actionable error messages. Violates confirmation-request and recovery-guide patterns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Quiesce an estate to prepare for shutdown or maintenance
Recall context from the estate using semantic or BM25 search
Delete memory content from the moot-memory adapter backend
List all memory keys in the moot-memory adapter backend
Read memory content from the moot-memory adapter backend
Write memory content to the moot-memory adapter backend
Capture a moment snapshot of the current context state
Query temporal patterns and rhythms in the captured context history
Read encrypted vault content from the estate
Write encrypted content to the estate vault
Parameter descriptions are 10-30 chars and lack format/constraint details. 'embedding_provider' has no enum (encoder vs openai?). 'mode' parameters lack valid options. Violates tool-description pattern.
Naming inconsistency: moot_vault_read/write vs memory_read/write operate on same concept but use different prefixes. LLM cannot reliably distinguish or compose them. Violates naming clarity baseline.