Loading ToolBench
Model Context Protocol server for AI agent memory management, providing tools for storing, recalling, and managing agent memories with vector search and knowledge graph capabilities
Dakera MCP server demonstrates solid tool definitions with comprehensive parameter schemas and mostly good descriptions. 12 tools cover a coherent memory-management domain. However, descriptions lack LLM optimization guidance (several exceed 200 chars), output schemas are entirely undocumented, error handling is absent from definitions, and tool annotations (readOnlyHint/destructiveHint) are missing. The server exhibits intermediate quality, better than median community servers but falls short of production-grade documentation standards expected at 70+.
Paginate through all memories belonging to an agent, ordered by recency. Use for inspection or bulk operations — for semantic retrieval use dakera_recall; for filter-based listing use dakera_batch_recall. limit defaults to 50 (max 1000).
List all sessions (active and closed) for an agent with timestamps and summaries. Use to find a session_id for dakera_session_memories.
Return an agent's memory footprint: count, session count, approximate storage, and top tags. Use to monitor memory growth or compare agents.
Query the audit log of memory lifecycle events with optional filters by agent, event type, and time range (Unix ms). Requires Admin scope. Limit defaults to 100 (max 10000).
Return AutoPilot configuration and last-cycle stats (memories deduped, consolidated, timestamps). Requires Admin scope.
Output schemas are entirely undocumented. None of the 12 tools include return type definitions or expected response field structures. LLMs cannot predict what fields to extract or plan downstream tool chains without knowing response shape.
Tool annotations missing. No readOnlyHint, destructiveHint, or idempotentHint attributes in any tool definition. Agents cannot distinguish read-only tools from write operations, blocking safe retry strategies and multi-step planning. This is a current protocol feature (2026-07-28) that should be present for production tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | <=2025-11-25 | v2 |
Trigger an AutoPilot cycle immediately. action: dedup|consolidate|all. Requires Admin scope.
Read global memory-decay config: strategy, half-life hours, and minimum importance threshold. Requires Admin scope.
Update memory-decay parameters at runtime without restarting the server. Changes take effect on the next decay cycle. All fields are optional — omit fields you do not want to change. Requires Admin scope. Use to extend half_life_hours if important memories are being dropped too aggressively.
Return cumulative decay stats: memories decayed/deleted, cycle count, and last-cycle timestamp. Requires Admin scope.
Search the Dakera tool catalog by keyword or tier (core/power/admin/meta) and return names and one-line summaries without loading full schemas. Call this first to find relevant tools, then use dakera_load_tools to fetch only the schemas you need — avoids loading the full catalog upfront.
Rotate the AES-256-GCM key for memory content at rest, re-encrypting all memories atomically with zero downtime. new_key: 64-char hex or passphrase (PBKDF2-HMAC-SHA256). Optionally scope to one namespace. Requires SuperAdmin scope.
Fetch the full inputSchema for one or more named tools. Use after dakera_discover_tools. Returns schemas for found tools and a not_found list for unrecognized names.
Error handling guidance is absent from all tool definitions. No descriptions explain what to do on failure, which errors are retryable, or what recovery steps exist. E.g., dakera_audit_query requires Admin scope but provides no error message guidance for insufficient permissions.
Descriptions exceed LLM-optimized length in 7 tools. dakera_agent_memories (196 chars), dakera_decrypt_config_set (244 chars), dakera_discover_tools (238 chars), dakera_encryption_rotate_key (156 chars) are in range but others like dakera_autopilot_trigger (141 chars) and dakera_decay_config_set (244 chars) approach or exceed the 200-char sweet spot. Longer descriptions waste tokens without proportional clarity gain.
Permission requirements (Admin, SuperAdmin scope) are mentioned in descriptions but not formalized as tool metadata. Agents have no structured way to know upfront which tools require elevated permissions, leading to unnecessary failed calls and token waste.
Parameter descriptions for complex fields lack constraint clarity. E.g., dakera_decay_config_set's half_life_hours says 'must be > 0' in natural language but the schema has no minimum constraint. Similar issues with min_importance (0.0 - 1.0 mentioned only in text, not min/max). Constraints should be in schema AND description.
Pagination support is inconsistent. dakera_agent_memories and dakera_audit_query support limit/offset, but return type (is there a 'total' field?) is undocumented. Tools should declare whether they support cursor-based or offset-based pagination and what metadata they return.