Loading ToolBench
Self-hosted MCP memory server backed by Oracle Autonomous DB 23ai native AI Vector Search. Local-first, no cloud memory API.
memory-core-mcp has well-structured tool definitions with clear naming (verb_noun pattern) and comprehensive parameter schemas. All 6 tools are explicitly registered with FastMCP and include type hints. However, descriptions lack depth for LLM optimization, most are 50-150 chars, below the 194-char baseline for A+ tools. Parameter descriptions are present but generic (e.g., 'Optional scope filter'). Output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages. The memory_search tool has sophisticated shaping logic (ZMEM-Q1) but this is buried in the description rather than surfaced as clear parameter constraints. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles (memory_add and memory_link are WRITE operations).
Persist a memory. kind: capture|decision|fact|reference|project.
Fetch one memory by id, including its outgoing graph links.
Create a typed graph edge between two memories (idempotent).
List most-recently updated memories.
Semantic search across memories (cosine over in-DB embeddings). Falls back to keyword match if the embedding model is not yet loaded. Optional shaping (ZMEM-Q1): max_tokens caps the total body budget (overflowing record is tail-truncated with truncated=true), chunk_size splits bodies into paragraph-aligned chunks with source#cN references, fields projects each record to the given keys. Omit all three for the unchanged legacy response.
Counts by scope/kind and whether semantic search is active.
Output schemas not documented. LLMs cannot infer what fields memory_search, memory_get, memory_recent, and memory_stats return. This forces agents to guess at response structure and risks failed downstream tool chaining.
Tool descriptions are too brief (50-70 chars) and lack LLM-optimization guidance. 'Persist a memory' does not explain WHEN to use memory_add vs updating an existing memory, or what 'kind' values mean in practice. Baseline is 194 chars.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). memory_add and memory_link are destructive WRITE operations; memory_search, memory_get, memory_recent, memory_stats are READ_ONLY. Annotations enable agents to reason about side effects and retry safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Parameter descriptions are generic ('Optional scope filter', 'Optional kind filter'). No guidance on valid values, constraints, or dependencies. 'kind' accepts capture|decision|fact|reference|project but this is only stated in memory_add description, not in memory_search or memory_recent where kind is also a parameter.
No error handling or recovery guidance. If memory_search fails due to embedding model not loaded, or memory_add fails due to database constraint, the agent receives no actionable next step. Fallback to keyword search is mentioned in description but not exposed as a tool option.