Loading ToolBench
Personal MCP-powered digital hub - private data center with AI integration for memory, notes, and personal knowledge management
SelfHub defines 9 tools with complete input schemas and descriptions. Naming follows verb_noun conventions well (store_, retrieve_, list_, search_, delete_, create_, activate_). Descriptions are present and contextual (avg ~60 chars), meeting baseline minimums. However, several critical gaps reduce quality: (1) output schemas are entirely undocumented, the source shows tool definitions but zero documentation of what each tool returns; (2) no error handling guidance in descriptions; (3) parameter descriptions lack actionable constraints (e.g., 'importance' accepts 1-5 but no guidance on what these levels mean); (4) no pagination strategy documented despite list_memories and search_memories accepting limit/offset; (5) no discussion of idempotency or retry semantics for write operations; (6) missing field-naming consistency checks between related tools. The schemas themselves are well-formed (proper enums, required fields, type annotations), but the lack of output documentation and error recovery patterns represents a significant production-readiness gap.
Activate a context and load its memories
Create a new context for organizing memories
Delete a memory by ID
Get usage statistics about your memory hub
List all contexts with optional filtering
List memories with optional filtering
Retrieve a specific memory by ID
NO OUTPUT SCHEMAS DOCUMENTED for any of 9 tools. LLMs cannot plan downstream tool chains or extract structured data without knowing what fields to expect. This is a critical production gap.
Parameter descriptions lack actionable constraints. E.g., 'importance' accepts 1-5 with no explanation of what each level means (critical vs low priority?). 'category' enum includes 'custom' but no guidance on how to define custom categories. These omissions force LLMs to guess.
Pagination strategy not explicitly documented. list_memories and search_memories accept limit/offset but lack schema constraints (minima/maxima, defaults enforcement), total count return behavior, or cursor-based alternatives. Default '50' for list_memories is stated in description but not enforced in schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 11 | - | v1 |
Search memories using text query
Store a new piece of information in your memory hub
Destructive operation (delete_memory) lacks confirmation pattern. No mention of dry-run, undo capability, or recovery tools. Agents can accidentally delete memories without explicit user approval.
activate_context description does not explain scope or side effects. Does activating a context change the behavior of list_memories or search_memories? Is activation global or per-request? Missing dependency hints break tool composition.
No error handling guidance. Descriptions do not explain what happens on failure (e.g., 'ID not found', 'duplicate name', 'permission denied'). LLMs cannot recover from errors without explicit guidance.
Idempotency and retry semantics not specified. store_memory and create_context are writes, do they tolerate retries? Are they idempotent if called twice with the same inputs? Not documented.
get_stats description is vague. Does not enumerate which statistics are returned or their meaning. A tool named 'get_stats' should explicitly describe 'total memories', 'memories by type', 'storage usage', 'last accessed', etc. forcing LLMs to discover via trial.
Field naming consistency between tools not verified. E.g., if create_context returns 'context_id', does activate_context require 'context_id' or 'id'? If list_contexts returns 'type', does create_context param also use 'type'? Naming mismatches force LLM field mapping.