Loading ToolBench
A memory management system for AI companions that handles memory ingestion, recall, diary generation, and gateway routing for chat completions and message protocols
This server exposes 31 HTTP handlers as MCP tools, but lacks fundamental definition quality. Most tools have generic descriptions (e.g., 'Handle memory API endpoints') that do not explain WHAT the tool does, WHEN to use it, or what it returns. Only 3 tools (handleDiaryAdmin, handleDiaryRewriteAdmin, handleWeeklyRollupAdmin) show partial input schemas; the remaining 28 have no visible schema definitions. Tool names use 'handle' prefix (handleMemories, handleGateway) rather than action verbs (get_, create_, update_). No output schemas are documented. Error handling is not visible in the provided code. The server appears to be a Cloudflare Workers HTTP proxy wrapping internal memory/gateway APIs, not a properly structured MCP tool server with explicit tool registration.
Serve admin dashboard UI
Admin endpoint to view daily and weekly diary logs
Retrieve and manage diary entries
Admin endpoint to rewrite diary entries for a specific date
Harvest and display dream processing results
Manually trigger dream processing run
Get current dream processing status
Main gateway handler for chat completions and message protocols with memory injection
28 of 31 tools have NO visible input schema definitions. This prevents LLMs from understanding parameter types, constraints, and required fields.
All tool names use 'handle' prefix (handleMemories, handleGateway) instead of action verbs (get_, create_, update_, search_). LLMs rely on verb-first naming to infer intent before reading descriptions. This violates the verb_noun convention used by 90% of production tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | 2026-07-28+ | v2 |
Admin endpoint to view and edit gateway configuration
Retrieve current gateway environment configuration
Manage glossary terms and definitions
Chat completions endpoint for GuideDog model
Health check endpoint for system status
Ingest messages into the memory system
Handle longtail memory storage for edge cases
MCP protocol handler for memory operations
Handle memory API endpoints for CRUD operations on memories
Bootstrap memory system with initial data
Handle memory candidate review and approval workflow
List available models for a given identity
Admin endpoint to run monthly rollup of weekly logs into monthly impressions
Manage precious memories (high-value, pinned records)
Retrieve recall history and decision logs
Retrieve memory relations graph for visualization
Search memories using vector and lexical retrieval
Serve memory starmap visualization UI
Diagnose and repair vector database inconsistencies
Check vector database health status
Trigger vector database reindexing
Admin endpoint to approve and finalize weekly rollup by deleting source daily logs
Admin endpoint to run weekly rollup of daily logs into weekly summaries
Most tool descriptions are generic and under 50 characters (e.g., 'Handle memory API endpoints', 'Serve admin dashboard UI'). These do not explain WHAT the tool does, WHEN to use it, or what it returns. LLMs cannot select tools based on vague descriptions.
No output schemas are documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., IDs for chaining) without knowing the response structure. This violates the pattern:tool requirement for documented return types.
No error handling guidance visible. Error responses should tell LLMs what to do next (retry, ask user, or fail). Without error classification and recovery hints, agents cannot self-correct or escalate appropriately.