Loading ToolBench
Local REST and MCP server for the RAI memory and reasoning layer. Stores facts, recalls them by meaning, and reports confidence. Provides both REST API and Model Context Protocol (MCP) interfaces for memory management.
RAI Server defines 8 tools with complete JSON schemas and descriptions. All tools have proper input schemas with type constraints (minLength, maxLength, minItems, maxItems). Descriptions are present and substantive (100-250 chars), explaining what each tool does and its limitations. However, naming lacks action verbs (rai_store, rai_recall, rai_forget use domain-specific prefixes rather than verb_noun patterns like store_fact, recall_memory, forget_memory). Parameter descriptions are minimal, most just restate the parameter name without explaining format, constraints, or when to use the tool. Output schemas are not documented; LLMs cannot predict what fields to expect from responses. Error handling is not visible in the tool definitions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE, DESTRUCTIVE, READ_ONLY). Composition is sound, each tool has one responsibility, but descriptions lack dependency hints (e.g., 'Call rai_recall first to find a memory before calling rai_forget').
Report which stored memories the candidate fact would crowd — existing items whose addresses it lands close enough to that recall could confuse them. This measures address-space geometry only, not meaning: two facts can contradict from far-apart addresses. Do not treat an empty report as evidence that the fact is consistent with memory.
Return the retrieval score for a query and the tier it falls in. These values are heuristic and should not be treated as calibrated confidence.
Remove a stored memory whose text exactly matches `content`. Returns whether anything was removed. Exact match only — this tool never guesses at a nearby memory.
Experimental concept composition: normalize the average of the concept address vectors, then return the nearest stored memory.
Get system diagnostics: number of stored memories, mean residual norm, and capacity utilization.
Tool names lack action verbs. All 8 tools use domain-specific prefixes (rai_*) rather than verb_noun patterns (store_fact, recall_memory, forget_memory). LLMs infer intent from names, generic prefixes force reliance on descriptions and increase selection errors.
Output schemas not documented. Tool descriptions explain what each tool does but do not specify what fields the response contains. LLMs cannot plan downstream calls or extract required data without knowing response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | <=2025-11-25 | v2 |
Retrieve the stored memory whose address has the highest cosine similarity to the query. Confidence labels are experimental score tiers, not calibrated probabilities.
Store a fact in RAI memory. Returns a report of how crowded the stored address space became; it does not check the fact against existing memories for contradiction.
Return the residual between a candidate value and the value of the nearest stored key. The score is a heuristic, not a calibrated novelty measurement.
No tool annotations despite explicit risk levels. Tools marked WRITE, DESTRUCTIVE, READ_ONLY in metadata but no readOnlyHint, destructiveHint, or idempotentHint in schema. Agents cannot distinguish safe from unsafe operations without annotations.
Parameter descriptions are minimal and lack format/constraint guidance. 'The fact or knowledge to store' does not explain what constitutes a valid fact, how to structure multi-part knowledge, or when to use rai_intersect vs rai_store. Descriptions should guide LLM selection and usage.
No error handling guidance in tool descriptions. rai_forget states 'Exact match only' but does not explain what happens if no match is found or how to recover. rai_recall mentions 'confidence labels are experimental' but does not guide interpretation or fallback behavior.