Loading ToolBench
A Python MCP server for persistent memory management using hypergraph storage with PENMAN notation support. Enables remember, recall, consolidate, and forget operations for AI agents.
Hypabase Memory provides 4 tools with PENMAN notation for storing and retrieving semantic memories. While the tools have clear, descriptive names and detailed descriptions (220-290 chars each, within baseline 194 avg), the implementation has significant gaps in schema completeness, parameter documentation, error handling, and response structure definition. The `remember` tool stands out with well-defined input parameters and detailed role documentation, but the other three tools lack actionable error guidance and output schema documentation. The server is transport-limited (STDIO only), which combined with schema gaps yields a below-average score for production readiness.
Merge similar entities and compress memories. Reduces entity fragmentation by finding semantically similar names and consolidating them into canonical forms.
Clean up old memories by expiring edges older than a specified number of days. Implements memory decay and active forgetting.
Search and retrieve memories by semantic similarity or entity. Returns matching memories with relevance scores.
Store memories as PENMAN atoms: (verb :role entity ...) FORMAT ------ Each memory is a verb with participants in role slots: (verb :role "entity" :role "entity" ...) ROLES (fill in what applies, skip what doesn't) ----- :subject who or what it's about :object what is acted on :recipient who receives or benefits :instrument tool, method, or means used :origin where it came from, previous state :locus where, when, or in what context :attribute a named property or dimension :value the specific value of that property MODIFIERS (metadata about the fact) --------- :tense past, present, future :mood actual (default), planned, uncertain, normative, conditional :negated true or false :memory_type episodic (events), semantic (facts), procedural (how-to) :importance 0.0 to 1.0 CONTEXT (why, for what, under what condition -- can be nested) ------- :cause why it happened :purpose what for :condition if/when/unless NESTING ------- Any slot can hold a nested atom instead of a string: (believes :subject Alice :object (is :subject deadline :value Friday))
No documented output/response schemas for any tool. LLMs cannot infer what fields will be returned or plan downstream operations. Pattern D (SCHEMAS & OUTPUT) explicitly requires documenting return types.
No error handling guidance in any tool description. Tools like `forget` (irreversible deletion) and `consolidate` (destructive merge) lack recovery instructions. Pattern E (ERROR HANDLING) requires categorizing errors as retryable, user-fixable, or fatal.
Parameter descriptions for `recall` and `consolidate` are too generic. `recall`'s `query` parameter lacks guidance on expected format or semantic search behavior. `consolidate`'s `min_similarity` lacks context on why 0.8 is default or impact of different thresholds.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
`recall` accepts both `query` and `entity` but lacks documentation on mutual exclusivity or priority. Can both be provided? Does one override the other? Pattern C (PARAMETERS) explicitly requires documenting dependencies.
No validation constraints documented for numeric parameters. `consolidate`'s `min_similarity` accepts 0.0-1.0 (good), but lacks guidance on reasonable ranges. `recall`'s `limit` (max 50 default) lacks min/max constraints in description.
`forget` tool performs irreversible deletion (IRREVERSIBLE risk designation) but lacks dry-run or confirmation step. Pattern E requires confirmation steps for destructive operations.