Loading ToolBench
Official TypeScript client for Memoria — bi-temporal knowledge-graph memory for AI agents.
Memoria SDK is a TypeScript client library for a bi-temporal knowledge-graph API, not an MCP server. All 14 tools have clear verb-noun naming (remember, recall, relate, forget) and detailed descriptions (avg ~120 chars). Input schemas are fully specified with types and descriptions. However, output schemas are not documented in the source, only TypeScript interfaces exist, which are not visible to LLMs consuming the MCP protocol. Tool descriptions lack WHEN-to-use guidance and prerequisites. No error handling patterns visible (no recovery guidance, no categorization). Security: API key is a required parameter (anti-pattern; should use server-side injection). Composition is strong, tools chain well (e.g., createEntity → relate → recall). Pagination is present (k, limit, asOf params) but not consistently applied.
POST /v1/entities — pre-seed an entity before writing related episodes.
PATCH /v1/edges/:id/invalidate — mark an edge as no longer valid as of `tInvalid`. Returns the updated edge. Once invalidated, an edge cannot be invalidated again (409 `already_invalidated`).
GET /v1/edges/:id
GET /v1/entities/:id
GET /v1/entities/:id/history — timeline of edges touching the entity, ordered by `tIngested` desc and bi-temporally filtered by `asOf`. Each entry is decorated with its supersession target.
GET /v1/episodes/:id
GET /v1/episodes/:id/extraction-status — poll after `remember({ async: true })`.
API key exposed as required parameter. Should use server-side secret injection via environment variables or vault. Agent traces log all parameters, secrets in params leak into logs and prompt history.
Output schemas not documented. Only TypeScript interfaces exist in source; LLMs cannot see return types. Tools like recall return complex nested objects (edge, fromEntity, toEntity, contextEpisodes, score) but structure is invisible to the protocol layer.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
GET /v1/playbooks/:id
GET /v1/edges/:id/related — edges sharing endpoints with the seed edge.
GET /v1/playbooks
POST /v1/recall — hybrid dense + sparse + graph retrieval, sub-second p50.
POST /v1/playbooks/regenerate — run the playbook LLM pipeline against all edges in the given scope and replace (or create) the playbook for that scope. At least one scope dimension must be set.
POST /v1/edges — create a bi-temporal fact between two existing entities.
POST /v1/episodes — runs the 7-stage extraction pipeline.
Minimal descriptions on simple GET tools (getEpisode, getEntity, getEdge, listPlaybooks, getPlaybook). Descriptions are 10-20 chars, below the 34-char p10 baseline. LLMs cannot determine when to call these vs similar tools.
No error handling guidance. Tools do not document what errors are retryable, user-fixable, or fatal. No recovery hints (e.g., 'If entity not found, call createEntity first'). LLMs cannot self-correct on failures.
No confirmation or dry-run pattern for destructive operations. forget() and regeneratePlaybook() modify state irreversibly but lack a confirmation step. Agents can accidentally invalidate edges or regenerate playbooks without review.