Loading ToolBench
Cross-model memory for AI agents. Local-first, works with Claude, GPT, Gemini, Cursor, Claw Code, and any MCP client
omega-memory provides four well-structured tools with comprehensive parameter documentation and clear descriptions. All tools have explicit input schemas with type definitions and detailed parameter descriptions. The tool names follow verb_noun conventions (omega_store, omega_query, context_assemble, context_packet). Descriptions are detailed (120-180+ characters) and explain WHAT, WHEN, and HOW. However, there are gaps in output schema documentation, limited error handling guidance, and no visible validation details. Tool annotations (readOnlyHint/destructiveHint) are absent despite clear read/write distinctions. The server demonstrates solid foundational quality but lacks production-grade polish in error recovery and response contracts.
Assemble OMEGA's active context as structured sections plus a pre-rendered markdown blob. Harness-agnostic; clients splice into their own system prompt. For Claude Code, omega_welcome remains the richer briefing surface.
Build a compact task-aware memory packet for the current work. Combines retrieval seeds, graph chains, safety filtering, warning receipts, and token-budgeted markdown.
Search memories. Modes: 'semantic' (default) for meaning-based search, 'phrase' for exact substring match, 'timeline' for recent memories grouped by day, 'browse' for listing by type/session/recent.
Store a memory with optional type and metadata. Use when the user says 'remember this' or for programmatic capture (decisions, lessons, errors). Defaults to type 'memory' if event_type is omitted.
No output schema documentation visible for any tool. While input schemas are complete with types and descriptions, responses lack documented structure. LLMs cannot plan downstream tool calls or extract required fields without knowing what outputs contain.
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic distinctions. omega_store is destructive (WRITE), omega_query is read-only, yet these are not machine-declarable via annotations. This forces LLMs to infer intent from descriptions alone.
Limited error handling guidance in descriptions. No examples of what errors can be returned, what they mean, or how to recover (e.g., 'If query returns no results, try broadening search or using mode=timeline'). Descriptions state WHAT the tool does but not WHEN it fails or what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Tool names 'context_assemble' and 'context_packet' use gerunds/nouns rather than action verbs. Better names would be 'assemble_context' or 'get_context_assembly', and 'build_context_packet' or 'prepare_context_packet'. Current names obscure intent: is context_assemble a noun (the assembled context) or an action (assemble the context)?
omega_query accepts 'query' parameter as optional for mode='timeline' and mode='browse', but the description does not explicitly state which modes require it vs. make it optional. Undocumented parameter dependencies force LLMs to guess or produce invalid calls.
omega_store 'items' array parameter for batch mode lacks explicit 'required' or validation constraints. Schema shows it accepts an array but does not clarify minimum/maximum batch sizes, what happens if items is empty, or retry semantics for partial failures.
context_packet 'budget_tokens' parameter has range [120, 4000] but no guidance on what happens if the context cannot fit in the budget. Is the response truncated? Sampled? Rejected? This is critical for LLMs planning token usage.