Loading ToolBench
An MCP server providing vector search capabilities using sqlite-vec for RAG (Retrieval-Augmented Generation) applications. Supports both FTP and local data sources for building embedding databases from Markdown files.
Single tool 'search' with minimal Japanese description. Input schema is present and properly structured (query: string, top_k: integer with default), but descriptions lack depth for agent reasoning. Tool performs vector search (read-only, safe operation). No error guidance, no output schema documented, no parameter constraints beyond basic types. Naming is verb-appropriate (search_*) but description is only ~20 chars in English translation ('Vector search via sqlite-vec, return results'). Schemas exist but lack richness, top_k has no min/max bounds, query has no format guidance. Error handling in code returns JSON with 'error' field, but tool definition provides no guidance to LLM on error recovery. No tool annotations (readOnlyHint, idempotentHint) despite being a safe, idempotent read-only operation.
sqlite-vecによるベクトル検索を行い、結果を返します。
Description is minimal (~20 chars) and in Japanese. English translation 'Vector search via sqlite-vec, return results' lacks WHEN to call, what makes it distinct from other search tools, and expected output structure. Under 20-char rule: description score capped at 20.
Output schema is not documented in tool definition. LLM cannot infer what fields are returned. Code shows JSON with 'results' array and optional 'error' field, but this is buried in implementation, tool definition should declare return type explicitly.
No parameter constraints. 'top_k' has default=5 but no min/max bounds stated. LLM could pass top_k=10000 and cause performance issues. Query parameter has no format guidance, length limits, or language requirements (Japanese? English? both?).
No tool annotations. Despite being a safe, read-only, idempotent operation, no readOnlyHint or idempotentHint is set. This prevents agents from optimizing retry strategies and understanding call safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Error handling in implementation returns JSON with 'error' field, but tool definition provides no recovery guidance. Per pattern:recovery-guide, LLM should know: is this retryable? Should I ask the user? What's the next step? Code catches generic Exception, LLM sees no distinction between transient and fatal errors.
Query parameter lacks format/language context. sqlite-vec performs embedding, does it expect English text? Japanese text? Short keywords? Phrases? Without this guidance, LLM may construct poorly-formed queries.