Loading ToolBench
MCP server exposing a local vector store of PDF documents processed via OCR and RAG. Allows querying uploaded PDFs through a Streamlit dashboard with local LLM integration via Ollama.
Three tools with basic descriptions but significant gaps in schema completeness and parameter documentation. list_documents() has empty input schema (correct for no-arg tool). get_document() has two parameters with types and descriptions, meeting minimum standards. search_documents() has one parameter with type and description. However, NO tool documents its output schema, LLMs cannot plan downstream calls or extract structured data. Descriptions are adequate (50-150 chars) but lack WHEN-to-use guidance and error recovery hints. No error handling documented. No tool annotations (readOnlyHint present in metadata but not in schema). Naming is clear and verb-first, following pattern:tool conventions.
Search a document collection for chunks relevant to a query.
List all document collections available in the vector store.
Search the uploaded PDF for relevant information. Use when the user asks about content.
No output schemas documented for any tool. LLMs cannot infer return structure, forcing them to guess at field names and types for downstream reasoning.
Parameter descriptions lack format/constraint details. 'query' and 'document' parameters have no guidance on valid formats, length limits, or examples of expected input.
No error handling guidance. get_document() returns a string on 'not found' but LLMs cannot distinguish success from failure or know what to do next.
Tool descriptions lack WHEN-to-use context. Users/LLMs cannot distinguish when to call search_documents vs get_document, both appear to search, but one requires a collection name.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
No pagination support. list_documents() returns a bare list with no limit or offset. If hundreds of collections exist, response bloats context window.