Loading ToolBench
Model Context Protocol server that exposes BrainCell's persistent memory functionality for semantic search, storage, and retrieval of conversations, design decisions, architecture notes, code snippets, and context snapshots
Server has 6 tools with basic descriptions and partial schemas. However, critical gaps undermine quality: (1) Tool definitions are inferred from FastAPI route handlers rather than explicit MCP tool registration, no visible Tool objects with name/description/inputSchema triplets. (2) Input schemas are not formally declared in JSON Schema format; parameters are FastAPI function arguments without type annotations visible in the provided code. (3) Descriptions exist but are generic and lack actionable guidance (e.g., 'Save a design decision to memory' does not explain WHEN to use it vs. get_relevant_context). (4) No output schemas documented, responses are ToolResult objects with generic 'data' fields, forcing LLMs to infer structure. (5) No error handling guidance; errors return raw exception strings. (6) Missing tool: save_conversation is implemented but not listed in the 6-tool inventory, suggesting incomplete tool catalog visibility.
Get relevant context for a task from memory. Performs semantic search to find related decisions and provides recent active design decisions that might inform the current task.
List stored memories by type. Retrieves all stored memories (decisions, code snippets, architecture notes) with optional filtering by type.
Save architecture or design notes to memory
Save a reusable code pattern to memory
Save a design decision to memory for future reference
Semantic search across all memory using natural language. Searches through design decisions, code snippets, and architecture notes to find relevant information based on the provided query.
Tool definitions are inferred from FastAPI routes, not explicitly registered as MCP Tool objects with formal name/description/inputSchema. Code shows @mcp_app.post('/tools/search_memory') but no visible Tool(name='search_memory', description='...', input_schema={...}) registration.
Input schemas not formally declared in JSON Schema. FastAPI function parameters (query: str, memory_type: Optional[str]) lack explicit type/description metadata visible in MCP protocol. No JSON Schema objects with 'type', 'description', 'properties' structure.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
Output schemas undocumented. Tools return ToolResult(success, data, error, message) with generic 'data: Any' field. LLMs cannot infer what fields to expect in results (e.g., does search_memory return 'results' array? What fields per result?). No structured response documentation.
Descriptions lack actionable guidance. 'Save a design decision to memory for future reference' does not explain WHEN to call save_decision vs. get_relevant_context, what impact field should contain, or how decisions are indexed. Descriptions average ~50 chars; baseline for A+ is 50-200 chars with WHEN/WHY context.
Error handling returns raw exception strings ('Search memory failed: {str(e)}') with no recovery guidance. LLMs cannot determine if error is retryable, user-fixable, or fatal. No error classification or actionable next steps.