Loading ToolBench
A LLM based tool to support Text2SQL, Chatbot, KubeBlocks pilot and troubleshooting with knowledge base search and web search capabilities via MCP
ApeRAG provides 5 well-documented tools for RAG operations. All tools have clear descriptions (194-340 chars, within production baselines) and comprehensive input schemas with typed parameters. However, there are notable gaps in error handling guidance, output schema documentation, and some parameter validation constraints. Tool naming follows verb_noun conventions well (list_, search_, web_). The server demonstrates good practice in separating concerns (search_collection vs search_chat_files) and providing context-aware descriptions with USE CASE sections. Major weaknesses: no visible error recovery guidance, missing output schema documentation, and lack of tool annotations (destructive/idempotent hints). Input parameters are well-typed but some lack format constraints (e.g., URLs in web_read, query strings lack regex patterns).
List all collections available to the user. Returns: List of collections with only essential information (id, title, description) for security and optimized LLM search. Note: Uses CollectionViewList view model for type-safe response parsing but filters sensitive and unnecessary information.
Search for knowledge in temporary files uploaded in the current chat session. PRIMARY USE CASE: Use this for searching chat-specific uploaded files. For permanent knowledge collections, use search_collection instead. Difference from search_collection: - search_chat_files: temporary files (chat session scope) - search_collection: permanent knowledge base (collection scope)
Search for knowledge in a persistent collection/knowledge base using vector, full-text, graph, and/or summary search. PRIMARY USE CASE: This is the main tool for searching permanent knowledge repositories. Use this for general Q&A, knowledge retrieval, and accessing organized knowledge collections. For temporary files uploaded in a chat session, use search_chat_files instead.
Read and extract content from web pages. USE CASE: Extract detailed content from specific web URLs. Use after web_search to get full content from promising URLs.
Missing output schema documentation. Tools return results but do not document the structure of returned objects (e.g., search results contain what fields? web_read returns what format?). LLMs cannot plan downstream tool calls without knowing response structure.
No error recovery guidance. Tool descriptions lack 'If X fails, try Y' recovery hints. Error responses would not guide LLMs on retry strategy, user correction, or next steps.
web_read tool accepts URLs but lacks format validation constraint. Parameter description does not specify URL format (http/https only?) or validate against malformed URLs. LLMs could pass invalid URLs without guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 75 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Perform web search using DuckDuckGo search engine. USE CASE: Search the public internet for current information, news, and web content. Use when you need up-to-date information not available in your knowledge base.
search_collection exposes 8 optional boolean flags for index selection (use_vector_index, use_fulltext_index, use_graph_index, use_summary_index, use_vision_index, rerank). No documentation of dependencies or interactions between these flags. LLMs may not understand trade-offs or preferred combinations.
Missing tool annotations. No readOnlyHint, destructiveHint, or idempotentHint attributes visible in tool definitions. These are key for MCP spec 2026-07-28 compliance and help LLMs reason about safety and retry semantics.
query parameter across search_collection and search_chat_files lacks length or format constraints. LLMs could submit extremely long or malformed queries without guidance. Recommend documenting min/max length and character restrictions.