Loading ToolBench
PostgreSQL-backed MCP memory server with hybrid search and hierarchical summaries
opencode-mem is a specialized memory/knowledge management MCP server with 20 tools spanning observations (search, retrieval, storage), knowledge base operations, and hierarchical timeline drilling. While schema definitions are present and mostly well-structured, the tool set suffers from significant naming clarity issues, missing parameter descriptions, and undocumented output schemas. The unusual '__IMPORTANT' tool with empty schema is a red flag. The composition is verbose with overlapping tools (search vs memory_hybrid_search vs memory_semantic_search) that LLMs will struggle to disambiguate. Error handling and recovery guidance are absent. Descriptions exist but often lack WHEN-to-use context and are sometimes redundant. STDIO transport caps protocol readiness. Overall quality is below median for production MCP servers.
3-LAYER WORKFLOW (ALWAYS FOLLOW): 1. search(query) → Get index with IDs (~50-100 tokens/result) 2. timeline(from/to) → Get context around interesting results 3. get_observations([IDs]) → Fetch full details ONLY for filtered IDs NEVER fetch full details without filtering first. 10x token savings.
Step 3: Fetch full details for filtered IDs. Always batch multiple IDs.
Drill down to day-level summaries
Drill down to hour-level summaries
Expand a summary to see its child events. Drills down from any summary level to raw events.
Search for entities across infinite memory
__IMPORTANT tool has no input schema (empty properties object with no required array), making it unexecutable. This appears to be an instruction document masquerading as a tool. Remove it from tool registration or implement it as documentation.
Three overlapping search tools (search, memory_hybrid_search, memory_semantic_search) with nearly identical parameters but subtle semantic differences. LLMs cannot disambiguate which to call. Consolidate into single search_observations tool with a 'method' enum (semantic|hybrid|text) to clarify the distinction.
Tool descriptions lack WHEN-to-use context and error recovery guidance. Examples: 'Get chronological context' (timeline) doesn't explain when timeline is preferable to search. 'Drill down to day-level summaries' (infinite_drill_day) assumes users understand the infinite hierarchy pattern. Add intent-matching text: 'Use when you need context around specific dates' or 'Use after infinite_expand returns summary IDs to see details.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Get events within a time range. Returns raw events or summaries depending on granularity.
Delete knowledge entry by ID
Get knowledge entry by ID
List knowledge entries, optionally filtered by type
Save new knowledge entry
Search global knowledge base for skills, patterns, gotchas
Delete an observation by ID. Cascading: removes embedding and unlinks from knowledge entries.
Get full observation details by ID
Hybrid search combining FTS and keyword matching
Get recent observations
Smart search with semantic understanding when embeddings available, falls back to hybrid FTS+keyword search otherwise. Best for finding conceptually related content.
Save memory directly without LLM compression
Step 1: Search memory. Returns index with IDs. Uses semantic search when available, falls back to text search. Params: query (required), limit, project, type, from, to
Step 2: Get chronological context. Params: from, to, limit
No output schemas documented. Tools return data but LLMs don't know what fields to expect. For example, search returns 'index with IDs (~50-100 tokens/result)' but the actual JSON structure is not specified, are results an array? Objects with what keys? Do they include timestamps, project names? Add return type documentation for every tool.
Parameter descriptions are minimal or missing constraint details. Examples: 'type' in search is undescribed ('Filter by observation type', what are valid values?). Dates use 'ISO 8601' description but no format specification. Add enums, regex patterns, ranges: 'type: one of [event, note, decision, action]', 'date: ISO 8601 string (YYYY-MM-DD), must be ≤ today'.
No error handling or recovery guidance. Tools return errors but LLMs have no context on what to do: if search returns no results, should the agent retry with different keywords, call timeline instead, or ask the user? Add error codes and recovery hints: 'No results found. Try broadening your query or using timeline() to see what exists in this date range.'
Destructive tools (memory_delete, knowledge_delete) lack confirmation/dry-run support. Agents can irreversibly delete data with no recovery path. Implement a two-step pattern: add a 'dry_run' parameter or split into preview_delete + confirm_delete to prevent accidental destruction.
Naming ambiguity in infinite_* tools. 'infinite_drill_day', 'infinite_drill_hour', 'infinite_expand' are vague, what is 'infinite'? These names don't convey the hierarchical time-series pattern. Rename to: timeline_expand_summary, timeline_drill_by_date, timeline_drill_by_hour to clarify they operate on timeline hierarchies.
Many tools accept a 'limit' parameter with no stated range. LLMs could request limit=10000 or limit=0, causing timeouts or empty results. Add constraint: 'limit: integer, 1 - 100, default 10'.
Tools returning lists (memory_recent, knowledge_list, etc.) lack pagination support. A limit alone doesn't indicate whether there are more results or how to fetch them. Add 'has_more' boolean or 'next_cursor' to support iteration without context explosion.