Loading ToolBench
Memento MCP has 16 tools with complete schemas and descriptions, but quality is inconsistent. All tools have input schemas with proper JSON Schema structure and type definitions, which is excellent. However, descriptions vary significantly in quality and informativeness. Many descriptions are minimal (10-50 chars) and lack LLM-optimization guidance on WHEN to use each tool or prerequisites. Error handling is generic ('Unknown tool call', 'Error handling tool call') rather than actionable recovery paths. Tool naming follows verb_noun convention well (create_, delete_, get_, search_), but composition has issues: multiple tools operating on similar concerns (get_entity_history / get_relation_history / get_graph_at_time / get_decayed_graph) lack clear differentiation. Parameter descriptions are present but often cursory. Output schemas are not formally documented in tool definitions, responses are constructed inline in handlers without schema declarations. Tools return JSON strings rather than structured typed responses.
Add new observations to existing entities in your Memento MCP knowledge graph memory
Create multiple new entities in your Memento MCP knowledge graph memory system
Create multiple new relations between entities in your Memento MCP knowledge graph memory. Relations should be in active voice
Delete multiple entities and their associated relations from your Memento MCP knowledge graph memory
Delete specific observations from entities in your Memento MCP knowledge graph memory
Delete multiple relations from your Memento MCP knowledge graph memory
Output schemas not documented. Tool handlers return JSON strings via inline response construction (e.g., JSON.stringify in callToolHandler.ts) rather than declaring formal output schemas. LLMs cannot plan downstream calls without knowing what fields will be returned.
Multiple READ tools (get_entity_history, get_relation_history, get_graph_at_time, get_decayed_graph) lack clear differentiation. Descriptions do not explain WHEN to use each variant or how they differ. LLMs cannot decide which to call without external knowledge.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 28 | - | v1 |
Force generation of semantic embedding for an entity
Get the knowledge graph with decay applied based on observation recency
Get the history of changes for a specific entity
Get the state of the knowledge graph at a specific point in time
Get a specific relation with its enhanced properties from your Memento MCP knowledge graph memory
Get the history of changes for a specific relation
Open and retrieve detailed information for specific nodes
Read the knowledge graph and return all entities and relations
Search for nodes in the knowledge graph by query string
Update an existing relation with enhanced properties in your Memento MCP knowledge graph memory
Minimal descriptions on several tools. read_graph ('Read the knowledge graph and return all entities and relations', 52 chars), open_nodes ('Open and retrieve detailed information for specific nodes', 56 chars), and others are below the 10-200 char LLM-optimized baseline. They lack guidance on prerequisites, use cases, or when NOT to call the tool.
Generic error handling. callToolHandler.ts returns { error: 'Unknown tool call: ...' } and { error: 'Error handling tool call: ...' } with no guidance on recovery. LLMs receive no actionable next steps when a tool fails.
Destructive operations (delete_entities, delete_observations, delete_relations) lack confirmation or dry-run support. No indication in tool descriptions that these are irreversible. Agents risk permanent data loss without protective patterns.
update_relation input schema is incomplete. The 'relation' parameter's nested properties (from, to, relationType) are defined, but no description states what fields can be updated or what constraints apply. Parameter naming is ambiguous, does 'relation' accept partial updates or require all fields?
Parameter descriptions lack format/range guidance. 'strength' (0.0 - 1.0), 'confidence' (0.0 - 1.0), and 'timestamp' (Unix time?) lack explicit ranges or format specs in descriptions. LLMs may pass invalid values (e.g., strength=5 or timestamp='2024-01-01T00:00:00Z') that fail validation.
No documented limits on result sizes. read_graph ('return all entities and relations') could produce massive output (unbounded context loss). No pagination parameters, no mention of result caps. LLMs cannot plan for oversized responses.
Tool composition risk: create_entities, create_relations, add_observations produce IDs/references that are not explicitly documented as being usable in subsequent calls. No guarantee that entity names returned by search_nodes or open_nodes are the same format accepted by other tools.