Loading ToolBench
Native Node.js bindings for EREBYX memory SDK via napi-rs. Persistent AI memory across every AI you use. Encrypted in transit (TLS 1.3) and at rest with envelope encryption.
This is a Node.js native binding (napi-rs) to a Rust memory SDK, exposed as 5 tools via MCP STDIO. Tool definitions are visible in src/lib.rs with names, descriptions, and input schemas. However, critical gaps limit quality: (1) Descriptions are minimal (10-50 chars), below the 50-200 char baseline for LLM optimization. (2) Parameter descriptions exist but are generic ('Optional configuration', 'Optional search configuration'). (3) No output schemas documented, LLMs cannot predict what these tools return. (4) No error handling guidance, tools fail silently or with opaque errors. (5) Tool names lack clear action verbs (restoreIdentity, loadContext are vague; 'restore' and 'load' don't signal idempotency or side effects). (6) STDIO transport caps protocol readiness at 50, further limiting production viability.
Resume work context after identity
Load identity at session start
Save a memory
Find memories by meaning (the remember verb)
Create session handoff for continuity. Preserves what was built, what is next, and open threads for the next session.
No output schemas documented. LLMs cannot predict return types, forcing them to guess what fields are available for downstream tool calls or user display.
Tool descriptions are too short (10 - 50 chars). Baseline is 50 - 200 chars. Descriptions like 'Load identity at session start' and 'Resume work context after identity' lack context for when/why to call them, violating pattern:tool-description.
Parameter descriptions are generic placeholders ('Optional configuration for restoring identity', 'Optional search configuration'). LLMs cannot infer what 'options' object should contain without explicit field documentation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
Tool names lack clear action verbs. 'restoreIdentity' and 'loadContext' are vague, does 'restore' mean idempotent? Does 'load' fetch or initialize? Compare to 'get_identity' or 'fetch_context_by_anchors' which are self-documenting.
No error handling guidance. Tools have no documented error codes, recovery steps, or retryability hints. An LLM hitting a failure has no guidance on what to do next.