Loading ToolBench
Inked is a lightweight memory management server with 2 tools. Both tools have schemas and descriptions present, but several quality gaps emerge. Tool names follow verb_noun convention (read, write) but 'write' is overloaded for two distinct operations (NEW vs DELETE). Descriptions are present but lack guidance on when to use each tool vs alternatives, and do not explain the semantic search capabilities clearly. Parameter descriptions are adequate but inconsistent, some params have constraints (topr: 1-5) while others (search, content) lack detail on expected formats or valid values. The write tool's use of 'sTool' as a sub-tool selector is unconventional and creates a confusing interface where a single tool does two completely different things (add vs delete). Error handling is present in code but responses are generic text rather than structured recovery guidance. No tool annotations (readOnlyHint, destructiveHint) despite clear semantic differences between tools.
Search and retrieve memories using powerful semantic search. Use 'ALL' to get all memories, or search terms for intelligent matching including synonyms, fuzzy matching, and context understanding.
Add new memories or delete existing ones. Use sTool="NEW" to add, sTool="DELETE" to remove. Memories can be any format - structured notes, preferences, facts, or simple thoughts.
Tool 'write' violates single-responsibility principle. Uses 'sTool' enum (NEW|DELETE) to switch between two completely different operations (add memory vs delete memory). This should be split into separate 'create_memory' and 'delete_memory' tools.
Parameter 'sTool' is non-standard. LLMs expect parameters to directly represent inputs, not sub-tool selectors. Renaming to a standard enum parameter or splitting tools would improve clarity.
Missing tool annotations. The 'read' tool has readOnlyHint semantics (does not modify state), and 'write' with sTool='DELETE' has destructiveHint semantics. Explicit annotations via MCP tool metadata would help clients understand safety guarantees.
Tool descriptions do not explain when to use 'read' vs 'write', or the difference between 'NEW' and 'DELETE' modes. Descriptions lack guidance on tool selection strategy, e.g., 'read' supports semantic search with synonyms/fuzzy matching but this advantage is not contextualized against simple string matching.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Parameter 'content' in write tool is ambiguous when sTool='DELETE'. For NEW, it is memory content; for DELETE, it is a search query. The description does not clarify this dual semantic, forcing LLMs to infer based on context.
Parameter 'search' in read tool does not specify expected format or length constraints. Documentation mentions 'ALL' as a magic string but does not explain fallback behavior if 'ALL' fails or how semantic search differs from keyword matching.
Error responses in tools.ts return free-text error messages (isError: true, text: '...') rather than structured error codes or recovery guidance. E.g., 'Error searching memories: <raw error message>' does not tell the LLM what to do next.
No output schema documentation. The tools return content arrays with text, but no formal schema describes the response structure, relevance scores, match types, or how pagination works (if 'topr' param is insufficient).
Write tool's 'id' parameter for DELETE is optional with unclear semantics. If both 'id' and 'content' are provided, which takes precedence? Description does not resolve this ambiguity.