Loading ToolBench
An MCP server providing local RAG (Retrieval Augmented Generation) and Google Search tools for an agentic system that follows a Planner-Executor-Synthesizer pattern. Integrates with ChromaDB vector store for local document retrieval and Google Search API for web results.
This server has two tools with incomplete definitions that fall well below production quality. Both tools lack input parameter descriptions, have vague descriptions that don't follow LLM-optimized guidance, no documented output schemas, and minimal error handling. The descriptions are generic and do not clearly explain WHEN to use each tool or what the agent should expect. No tool annotations present. The naming is acceptable (verb_noun pattern), but the overall structure is incomplete.
Perform a Google Search when the user query is related to a general fact and not present in the local knowledge base, and return the top 5 results formatted with title, snippet, and URL.
Perform a local retrieval augmented generation (RAG) using a vector store retriever, if the user query is related to personal choices, preferences or specific knowledge related to movies, technical concepts technical concepts related to computer science, technology, software engineering etc. and return the top 3 relevant documents with formatted results.
Input parameters lack descriptions. The 'query' parameter in both tools has only a generic description ('The user query to search for in the local vector store' / 'The search query to submit to Google Search'). No explanation of format, length constraints, special characters, or examples of good vs bad queries.
Output schemas are not documented. Both tools return unstructured strings without formal schema declarations. LLMs cannot plan downstream operations or extract structured fields. The code shows formatting (e.g., '[LOCAL RAG]\n' prefix) but this is implicit, not documented in the tool definition.
Tool descriptions are too generic and do not follow LLM-optimized guidelines. Descriptions exceed 100 characters but lack clarity on WHEN to invoke each tool vs the other, what prerequisites exist (e.g., does Chroma DB need to be pre-populated?), and what the LLM should do if no results are returned. The local_rag description contains duplicated text ('technical concepts technical concepts').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Error messages are user-facing strings, not structured error classifications. Both tools catch exceptions and return formatted error strings (e.g., '[LOCAL RAG ERROR]' + exception). LLMs cannot distinguish retryable errors from fatal ones or know what to try next. No guidance on recovery steps.
No tool annotations present. Tools lack readOnlyHint, destructiveHint, or idempotentHint. Both tools are read-only (safe to retry) but this is not declared in the schema, forcing LLMs to infer safety.
Parameter constraints are missing. The 'query' parameter has no validation rules: no length limits, no character restrictions, no guidance on multi-word vs single-word queries. LLMs may pass very long queries that exceed embedding model context limits or truncate results unexpectedly.
No pagination support. google_search returns a fixed 5 results hardcoded; local_rag returns k=3. If an agent needs to iterate through results or a user asks 'show me more', there is no mechanism to fetch the next page. This violates paginated-result pattern.
Composition problem: no tool exists to manage the Chroma knowledge base (add documents, delete, refresh). The local_rag tool is read-only. An agent cannot update the RAG corpus, making it static and unmaintainable in production.