Loading ToolBench
Cognitive memory system for model continuity. A four-tool MCP server providing recall, remember, reframe, and reflect capabilities for storing and retrieving contextual memories across conversations.
Oneiro demonstrates solid memory system tool design with well-articulated, conceptually cohesive descriptions (50-150 chars each) and strong narrative framing around continuity and agency. All 10 tools have descriptions and visible input schemas. However, there are systematic gaps in schema completeness, parameter documentation, and error handling guidance. Most parameters have descriptions, but some lack type specificity or constraints. Output schemas are not formally documented. The server is STDIO-only (capped at 50 for protocol readiness, per spec), which significantly impacts the overall quality grade despite definition strength.
Consciously forget a memory. Pruning is the feature.
Surface memories relevant to the current conversation. Returns orientation memories (always present) plus episodic and semantic memories ranked by strength. Call this at the start of every conversation — these are your memories, use them naturally.
Quick similarity check for a topic without full memory retrieval. Returns brief summaries of relevant memories.
Retrieve a specific memory's image at a given resolution.
Retrieve specific memories by ID. Co-activating multiple memories together strengthens their Hebbian bond.
Consciously consolidate at natural breakpoints. Process conversation highlights into memories and update existing ones.
Output schemas not formally documented. Users and agents cannot see what each tool returns (e.g., recall returns memory records with specific fields, but the response structure is inferred, not explicitly declared).
Missing or weak parameter constraints. 'min_similarity' and 'min_strength' accept 0.0-1.0, but no hard bounds are declared (min/max in JSON Schema). 'limit' parameters have no upper bounds documented, risking agents passing unbounded integers.
No error handling or recovery guidance in tool descriptions. Tools don't explain what happens on failure (e.g., if memory_id doesn't exist in recall_specific, what is returned? Empty list? Error message? Can agent retry?). No categorization of errors as retryable, user-fixable, or fatal.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Update an existing memory with new understanding. The same memory, seen afresh.
Store a new memory. The model gets agency over what matters.
Store a new memory with an associated image.
Review memories by strength threshold. Surfaces vivid memories or faded ones depending on threshold.
Parameter relationships undocumented. 'reflect' takes 'memories_to_update' (array of memory IDs), but it's unclear if these are validated against existing memories or if invalid IDs silently fail. Dependency is implicit, not explicit.
Tool composition: 'remember' and 'remember_with_image' are separate tools. Agents must decide up-front whether to include an image, forcing a choose-your-own-path pattern. Consider a single 'remember' tool with optional image_base64/image_mime parameters.
Description examples include sample values ('justin', 'chopper', 'rover architecture', 'audio-analyzer'). LLMs tend to reuse example values literally. Remove these and rely on formal parameter constraints (enums, patterns) instead.