Loading ToolBench
Unified AI agent memory system with MCP + REST API + Web UI. Provides semantic search, memory consolidation, and relationship management for AI agents.
Contextify demonstrates solid tool design with consistent naming (verb_noun structure across all 13 tools), comprehensive input schemas with type definitions, and detailed parameter descriptions. All tools follow the verb-first pattern (store_, recall_, search_, get_, update_, delete_, create_, promote_, consolidate_, find_, suggest_). However, output schemas are not explicitly documented in the visible code, descriptions vary in depth, and error handling guidance is absent. Tool compositions are well-designed for memory operations (recall vs search distinction, relationship linking, consolidation). The jsonschema tags in Go structs (internal/mcp/tools.go) provide schema metadata, but output response structures are not visible. Parameter descriptions are generally 50-150 characters, meeting the production baseline. No obvious security flaws (no secrets in params), and tools follow single-responsibility principle.
Merge multiple memories into one target memory. Source memories are marked as superseded. Use when you find duplicate or overlapping memories.
Link two memories with a typed relationship (SOLVES, CAUSES, RELATED_TO, REQUIRES, ADDRESSES, SUPERSEDES).
Delete a memory and all its relationships.
Find memories similar to a given memory ID using vector similarity. Useful for detecting duplicates.
Get all important memories for a project. Use at session start to load context.
Retrieve a specific memory by its ID.
Find memories connected to a specific memory via relationships.
Output schemas not documented in visible code. Tools return results but LLMs cannot know the exact structure of response objects (e.g., fields returned by recall_memories, list format, pagination structure). This forces LLMs to infer response shapes and risks downstream tool chaining failures.
Destructive operations (delete_memory) lack explicit confirmation/dry-run pattern and error recovery guidance. Description states what it does but not how to undo it or what happens to relationships. No guidance on whether cascading deletes occur.
Error handling patterns absent. Tools lack documented error categorization (retryable vs fatal), actionable error messages, or recovery guidance. If a memory lookup fails, no guidance on what the LLM should do next (search by content? try another query?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 61 | - | v1 |
Manually promote a short-term memory to permanent long-term storage.
Recall memories using natural language semantic search. Best for fuzzy/conceptual queries.
Advanced search with filters (tags, type, scope, importance). Use for precise filtering.
Store a new memory with automatic embedding generation. Memories with importance >= 0.8 are automatically permanent.
Get server-generated suggestions for memories that should be consolidated. Returns pairs of similar memories.
Update an existing memory. Re-embeds if content changes.
Pagination not explicitly documented for list operations (recall_memories, search_memories, suggest_consolidations). Tools accept 'limit' but lack documented 'offset/cursor' behavior, total count return, or next_token guidance for large result sets.
Descriptions for deletion and promotion operations are generic (70 chars). 'Delete a memory and all its relationships' doesn't explain cascading behavior, rollback capability, or permission requirements. Descriptions should clarify irreversibility and audit implications.
No tool annotations visible in code (destructiveHint, idempotentHint, readOnlyHint). While tools have clear READ/WRITE/DESTRUCTIVE risk labels in the metadata, these should be propagated as formal MCP tool annotations for agent safety.