Loading ToolBench
AI Correction OS — persistent human correction memory that makes AI learn from feedback
CORREX defines 29 tools with schemas and descriptions present, but quality is inconsistent. Naming follows verb_noun convention (build_, save_, get_, list_, update_, detect_, check_, record_, evaluate_) which is good. However, descriptions are often vague and lack actionable context. Many tools lack parameter descriptions entirely or are generic ('ID of the X'). Output schemas are not documented, responses are inferred from code but not formally specified. Error handling is absent from tool definitions. The server targets a specialized domain (AI correction memory) with complex internal concepts (sublimation, ghost principles, tensions) that leak into tool names and descriptions, violating the style contract stated in SERVER_INSTRUCTIONS ('never expose internal jargon to end users'). Parameter validation rules are not documented. No tool declares permissions or scope. Composition is poor: many tools are tightly coupled to an internal maintenance pipeline (get_unprocessed_turns → update_turn_corrections → process_ingested_data → ...) rather than exposing independent, reusable operations.
Build guidance context from task title and raw text, returning applicable rules and guidance
Check the status of the narrative
Clean up ghost principles
Detect candidate tensions in the rule system
Evaluate the effectiveness of guidance rules after task completion
Get pending sublimations for processing
Get unprocessed conversation turns for maintenance pipeline
Internal jargon exposed in tool names and descriptions: 'sublimation', 'ghost_memories', 'ghost_principles', 'semanticize', 'dormancy' violate the stated style contract ('never expose internal jargon to end users'). LLMs will struggle to understand when to call these tools.
Output schemas not documented. Tool definitions specify input parameters but do not declare what fields are returned. LLMs cannot plan downstream calls or extract required data without knowing response structure.
Many parameter descriptions are missing or trivial ('ID of the X', 'The X'). Parameters lack format constraints, ranges, or validation rules. LLMs cannot infer valid input without explicit guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
List all context transitions
List all conversation turns
List all correction entries
List all meanings
List all policies in the system
List all preference rules
Get a summary of the memory system statistics
Process ingested data during maintenance pipeline
Record which guidance rules were adopted or rejected
Save a conversation turn with user feedback and extracted corrections
Save a curiosity signal when user's message contains a question
Save a completed meaningful deliverable as an episode
Save research journey after meaningful research (web, files, codebase)
Save the narrative after completing the maintenance pipeline
Save a policy during maintenance pipeline
Save a sublimation during maintenance pipeline
Save a detected tension
Scan for dormant journeys
Semanticize ghost memories
Synthesize meanings from sublimations
Synthesize principles from meanings
Update turn corrections during maintenance pipeline
Maintenance pipeline tools are tightly coupled (get_unprocessed_turns → update_turn_corrections → process_ingested_data → ...). This violates single-responsibility principle. LLMs cannot compose these independently; they must follow a rigid sequence.
No error handling guidance. Tool definitions do not specify what errors can occur, whether they are retryable, or what the LLM should do next. Agents will be unable to recover from failures.