Loading ToolBench
Single tool with minimal definition quality. Tool name 'read_pdf' is appropriately verb-prefixed and clear. Description is adequate (54 chars, within 10-1024 range) but lacks context on when to use it vs the resource interface. Input schema is present with proper type and description for the single parameter. However, NO output schema is documented, LLMs cannot predict what fields to expect from the response. Parameter description is minimal (18 chars). No error handling guidance provided. Tool lacks idempotency hints, permission declarations, or security context. Overall definition is functional but sparse.
Reads the text content of a PDF file
No output schema documented. LLMs cannot predict response structure (fields, types, nesting). Breaks downstream tool chaining and forces LLMs to guess at field names.
Parameter description is too brief (18 chars: 'Path to the PDF file'). Does not specify format constraints, path type (absolute/relative), or error cases (file not found, invalid PDF).
Tool description lacks context on when to use read_pdf vs the resource interface (pdf:// URI). Both expose the same functionality, ambiguity forces LLM to reason about which to call.
No error handling guidance. Error responses return raw error messages ('Error reading PDF file: ...') without recovery hints. LLM cannot determine if error is retryable, user-fixable, or fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
No security or permission context. Tool accepts arbitrary file paths, no indication of path traversal guards, allowed directories, or permission checks. Potential security risk if agent is compromised.