Loading ToolBench
Document knowledge store powered by PageIndex. Workflow: list_documents -> search_documents -> get_document_tree -> get_page_text
Server has 7 tools with basic descriptions and input schemas. Naming follows verb_noun convention (add_document, search_documents, list_documents, etc.). However, descriptions are inconsistent in depth, some lack actionable context for LLM selection. Parameter descriptions exist but are minimal (10-50 chars). Output schemas are not documented. Error handling is present in code but not surfaced in tool definitions. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Schemas use proper JSON types but lack constraints (enums, ranges). The 'name_or_id' pattern across multiple tools is good for usability but not explicitly documented as accepting both forms.
Add a PDF or Markdown document to the knowledge store. Copies the file, runs PageIndex to build a hierarchical index, and registers it in the manifest. Args: file_path: Absolute path to a .pdf, .md, or .markdown file. If PAGEINDEX_IMPORT_DIR is set, the path must resolve inside it.
Add multiple PDF or Markdown documents to the knowledge store in parallel.
Get the hierarchical structure (tree) of a document.
Get the text content of a specific page or section from a document.
List all documents in the knowledge store.
Remove a document from the knowledge store by name or ID.
Output schemas not documented. Tools return structured data (document trees, search results, page text) but LLMs cannot see what fields to expect. This forces agents to guess field names and risks extraction errors.
Tool annotations missing. remove_document is DESTRUCTIVE and add_document is WRITE, but no destructiveHint or readOnlyHint annotations present. LLMs cannot distinguish safe reads from dangerous mutations without explicit hints.
Parameter descriptions are minimal (10-50 chars). 'doc_name_or_id' is described as 'Document name or ID to remove' but does not explain the lookup behavior, whether both forms are truly accepted, or what happens if both match. LLMs need explicit guidance on parameter semantics.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
Search documents by keyword or semantic query.
add_documents lacks pagination/batch result documentation. Tool accepts a list but does not document per-item success/failure, partial failure handling, or result structure. If one file fails, does the entire batch fail or return mixed results?
Error recovery guidance absent from tool descriptions. Code shows validation (file not found, unsupported extension, path traversal checks) but tool descriptions do not tell LLMs what to do on failure. E.g., add_document should hint: 'If file not found, verify the path or check PAGEINDEX_IMPORT_DIR.'