Plug-and-play MCP memory server for AI agents — powered by ManasDB polyglot storage (MongoDB, PostgreSQL, and more)
ManasDB MCP server provides three well-named tools with clear, action-oriented naming (memorize, recall, forget). All tools have descriptions and input schemas present. However, parameter descriptions are minimal (under 30 chars in most cases), and output schemas are not documented. Error handling exists but lacks recovery guidance. Tool naming follows verb_noun convention well, but descriptions could be more comprehensive about when to use each tool and what the LLM should expect.
Permanently delete a memory from all ManasDB databases using its contentId. The contentId is returned when memorize is called. Use recall first to find the contentId of what you want to forget.
Absorb and store new information into ManasDB memory
Recall related context from ManasDB memory (deduplicated across configured providers)
Output schemas not documented. LLMs cannot plan downstream operations or extract relevant fields without knowing result structure.
Destructive operation (forget) lacks confirmation/dry-run capability. Agents make mistakes, a confirm_before_execute pattern prevents catastrophic errors.' No protection against accidental deletions.
Parameter descriptions are minimal (10-30 chars). Rubric baseline: 'Average param annotation length: 72 chars' and '100% of A+ tool params have descriptions.' Current descriptions lack context about format, constraints, or when to use. E.g., 'The exact contentId' doesn't explain what contentId looks like or how to obtain it beyond 'use recall first.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-04-20 | F | 24 | - | v1 |
No pagination or result limits documented for recall(). Rubric: 'Even if the API allows returning thousands of items, cap results at a reasonable limit (e.g. 20-50) and offer pagination. LLM reasoning degrades as context grows.' recall() may return many results; no limit or pagination guidance provided.
Error responses return isError flag but lack actionable recovery guidance. Rubric: 'Error responses must tell the LLM what to do next: "User not found. Try search_users() with a partial name." A raw error code or stack trace gives the agent nothing to act on.' Current error: 'Partial or complete failure during memorize: {error.message}', no guidance.
No error classification (retryable, user-fixable, fatal). Rubric: 'Categorize errors as retryable, user-fixable, or fatal. An LLM should know: can I retry? Should I ask the user? Or is this unrecoverable?' Database errors are caught but not categorized.