Loading ToolBench
MCP tool implementations for YantrikDB cognitive memory engine — provides tools for storing, retrieving, and managing semantic memories with multi-signal scoring, entity relationships, and knowledge graphs.
YantrikDB MCP server presents solid tool definitions with clear naming conventions, comprehensive parameter schemas, and well-structured output documentation. All 6 tools follow verb_noun naming (memory_record, memory_recall, memory_get, memory_forget, memory_correct). Parameter descriptions are detailed and explain constraints (e.g., importance 0.0-1.0, emotional_state labels). However, there are gaps in error handling guidance, no output schema documentation visible, and missing actionable recovery messages. The server demonstrates above-average clarity for a community MCP tool but lacks the polish expected for A-tier production systems.
Correct an existing memory with updated information. The original memory is tombstoned and a new corrected version is created, preserving the history. Entity relationships are transferred to the new memory.
Permanently forget (tombstone) a memory.
Get a specific memory by its ID.
Search memories by semantic similarity to a natural language query. Uses multi-signal scoring: vector similarity, temporal decay, recency, importance, and optional knowledge graph expansion.
Refine a previous recall with a follow-up query. Combines the original query embedding with the refinement embedding (weighted: 0.4 original + 0.6 refinement) and excludes already-seen memory IDs.
Store a new memory in the cognitive memory engine.
Output schemas not documented for any tool. LLMs cannot determine what fields to expect in responses, forcing them to make assumptions about downstream tool parameters and making response chaining fragile.
No pagination or result-limiting guidance in memory_recall despite top_k parameter. When top_k=10 is default, responses may still be large. No documentation of result format (does it include memory_id, timestamp, similarity_score for each result?).
Error handling lacks recovery guidance. No documentation of what the LLM should do if memory_get returns 'not found', if memory_recall returns zero results, or if memory_correct fails due to concurrent modification. Bare errors provide no actionable next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 72 | 2026-07-28+ | v2 |
memory_get and memory_forget descriptions are very brief (<70 chars). While clear, they lack context on prerequisites (e.g., 'You must have the exact memory ID, use memory_recall to search first if you only have keywords') or consequences.
No tool composition guidance. When an LLM has a question, should it always call memory_recall first, or is memory_get expected? When should memory_correct be used vs. memory_forget + memory_record? No documentation of intended use workflows.
memory_recall_refine's relationship to memory_recall is underdocumented. When should an LLM call refine instead of a new recall? Is refine more efficient? What if the original_query was from a different agent session? No dependency documentation.