Loading ToolBench
MCP server for LanceDB vector database operations with semantic search capabilities
This server has 2 tools with basic but incomplete definitions. Tool names follow verb_noun convention (add_memory, search_memories) which is correct. However, descriptions are minimal (15-20 chars average, below the 194 char baseline), lacking context about when to use each tool, prerequisites, and potential side effects. Input schemas are present but lack depth, parameters have descriptions but no enums, ranges, or format constraints. Output schemas are entirely undocumented (tools return free-text strings, not structured objects). No error handling guidance visible. The server lacks pagination support on search_memories despite potentially returning large result sets. No validation of input formats or length constraints.
Add a new memory to the vector database
Search memories using semantic similarity
Tool descriptions are extremely brief (15-20 characters). Guideline specifies 10-1024 chars, baseline is 194 chars. Current descriptions lack context about when to use the tool, what it returns structurally, and how it fits into agent workflows. 'Add a new memory to the vector database' and 'Search memories using semantic similarity' are incomplete, they don't explain that add_memory has side effects (is idempotent? can it fail?), or that search_memories may return empty results or large result sets.
Output schemas are entirely undocumented. Both tools return plain strings ('Added memory: {content}', 'Found these relevant memories:\n\n...'), not structured objects. Rubric requires documentation of output schema so LLMs know what fields to extract and what downstream tool calls are possible. Current string responses require the LLM to parse unstructured text, which is error-prone and wastes tokens.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 7 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
search_memories lacks pagination support. Tool accepts a 'limit' parameter (default 5) but provides no cursor, offset, or total_count to enable pagination. If results exceed the limit, the agent cannot fetch the next page. Large result sets would cause unstructured string output to bloat the context window. Rubric requires paginated results with total count or next_cursor.
No input validation or error handling guidance. The 'content' parameter in add_memory accepts any string with no length limit, format constraint, or validation. If the embedding model fails, db_connector.store_memory() will throw an unhandled exception. The catch block in find_memories() silently returns an empty list on any error, giving the agent no feedback on why the search failed (network error? timeout? invalid query?).
Parameter descriptions lack format/constraint details. The 'limit' parameter description is 'Maximum number of results to return' but does not specify the range (minimum 1? maximum 1000?). The 'content' parameter has no length limit, encoding, or format guidance. Rubric requires explicit constraints: 'limit' should specify e.g. '(minimum 1, maximum 100)', and 'content' should specify expected format and length bounds.
add_memory description does not clarify side effects or idempotence. A user/LLM should know: Is this operation idempotent? Can duplicate 'content' values be added multiple times, or does the system deduplicate? What happens if content is empty? Can the operation fail? Current description 'Add a new memory to the vector database' answers none of these questions.
No batch operations. If an agent needs to add 100 memories, it must call add_memory 100 times sequentially, wasting tokens and latency. Rubric suggests offering batch variants (e.g. add_memories accepting an array) for tools agents call in loops.