Loading ToolBench
Memory-aware AI assistant with 17+ tools for enterprise deployment. Supports multiple connection methods (Stdio, HTTP REST API, Server-Sent Events, WebSocket) with Supabase integration for memory management and semantic search.
This server exhibits significant definition quality gaps across nearly all tools. While 19 tools are enumerated with schemas present in the JSON definitions, the source code provided (simple-server.cjs, simple-mcp-server.cjs) shows only stub implementations without full MCP registration logic. Many tool descriptions are generic or minimal (10-50 chars), parameter descriptions are inconsistent, and output schemas are not documented. The codebase mixes CommonJS fallback servers with TypeScript references (src/unified-mcp-server.ts, src/cli-aligned-mcp-server.ts) but the actual tool implementations are not visible in the provided source. Tools like 'get_health_status' and 'system_diagnostics' lack specificity about what metrics or diagnostics they return. Error handling patterns are absent, no recovery guidance, no error categorization. Security-sensitive operations (create_api_key, delete_api_key, delete_memory) lack permission gate descriptions. Baseline expectation: 90% of A+ tools have descriptions 50 - 200 chars with all parameters annotated; this server averages ~80 chars with many parameters undescribed in the visible code.
Create a new API key
Create a new memory entry with vector embedding for semantic search
Create a new project
Delete an API key
Delete a memory by ID through CLI-authenticated endpoints
Get API documentation and redirect to docs.lanonasis.com
Get current authentication status and configuration
Tool implementations not visible in provided source code. simple-server.cjs and simple-mcp-server.cjs contain only Express stubs and fallback servers without actual MCP tool registration, execution logic, or return schemas. Referenced TypeScript files (src/unified-mcp-server.ts, src/cli-aligned-mcp-server.ts) are not included.
Output schemas not documented for any tool. Tool definitions list input schemas but provide no description of return types, fields, or structure. LLMs cannot plan downstream calls without knowing what fields to expect (e.g., does list_memories return 'results' or 'items'? Is there a 'total_count' or 'has_more'?). Violates pattern:tool-description and mxe:strip-api-responses.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Get configuration settings
Get server health status
Retrieve a specific memory by ID through CLI-authenticated endpoints
Get organization information and limits
List all API keys
List memories with pagination through CLI-authenticated endpoints
List all projects
Rotate an existing API key
Search through memories with semantic vector search
Set configuration settings
Run system diagnostics
Update an existing memory through CLI-authenticated endpoints
Descriptions too short or generic. Tools like 'get_health_status' (34 chars), 'get_auth_status' (40 chars), 'system_diagnostics' (30 chars), and 'get_api_docs' (25 chars) lack sufficient detail. Descriptions 20 - 50 chars typically score 30 - 50. Production baseline is 50 - 200 chars with specific WHEN and WHY context (pattern:tool-description). Example: 'Get current authentication status and configuration' (34 chars) tells the agent WHAT but not WHEN to use it, should be 'Retrieve current authentication status, token expiry, and permission scopes. Use this before attempting operations that require specific access levels.'
Missing parameter descriptions in visible schemas. Input schemas define parameter names and types but omit descriptions for many fields. Example: create_api_key has 'access_level' (type: string, no enum, no description), 'expires_in_days' (no format or range constraints). LLM cannot determine valid values or constraints without parameter-level docs (review:param-validation-rules).
Destructive operations lack confirmation/dry-run patterns. delete_memory, delete_api_key, and set_config are write/destructive tools but have no mention of confirmation steps, dry-run modes, or recovery guidance. Per pattern:confirmation-request, irreversible operations should support a confirmation step to prevent agent mistakes. No error handling visible in source to guide LLM recovery.
No error handling guidance visible. Tool definitions do not describe error cases, recovery steps, or error categorization. Per pattern:recovery-guide and pattern:error-classification, error responses should tell the LLM what to do next (retry, ask user, fatal). Example: 'API key not found. Try list_api_keys() to find valid keys.' No such guidance present.
Security-sensitive operations lack permission gate descriptions. Tools like create_api_key, rotate_api_key, delete_api_key, and set_config modify permissions or secrets but do not declare required scopes or permission checks. Per pattern:permission-gate and pattern:scope-declaration, each tool should declare what permissions it requires and verify the agent has authority before execution. No mention of 'requires: admin', 'scope: api-keys:write', etc.
Pagination and result limiting not explicit. list_memories, list_api_keys, list_projects accept 'limit' and 'offset' parameters but do not document max results, total count return field, or guidance on result size. Per pattern:paginated-result and mxe:enforce-result-limits, tool descriptions should state the hard cap (e.g., 'max 50 results per call') and indicate whether 'total_count' is returned for client-side pagination.
Composition weakness: no indication of tool chaining IDs. When create_memory returns a memory_id, downstream tools (update_memory, delete_memory, get_memory) accept 'id'. However, no documentation states that create_memory returns 'id' field suitable for chaining. Per mxe:include-chaining-ids, responses must return IDs the next tools accept to enable seamless agent composition.