Loading ToolBench
Strong tool naming (all verb-noun pattern) and comprehensive parameter descriptions. All 10 tools have clear, detailed descriptions (avg ~180 chars, within baseline 194). Input schemas present with type definitions and parameter descriptions. However, output schemas are not explicitly documented in the source code, responses are inferred from implementation. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Error handling present but recovery guidance is minimal. Missing explicit output schema documentation and per-tool error classification.
Compare what you can see as a logged-in account vs. as the anonymous public. Returns two lists: items visible only to the account, and items visible to both. Use it to understand the access control policy of the repository and to decide whether to ask the user to log in.
Extract text from a file (bitstream) in the repository. Supports PDF, Word (.doc, .docx), Excel (.xls, .xlsx), PowerPoint (.ppt, .pptx), and OpenDocument formats (.odt, .ods, .odp). Returns the text plus metadata: how much was extracted, whether it was truncated, and which pages/slides were processed.
Find which item a file belongs to — the reverse of list_bitstreams. Use it when you have a bitstream UUID (from a download URL, a search result or an earlier listing) and need the record it hangs off: its title, handle, authors and year. Also reports which bundle the file sits in, and `url` — the item's page on the repository website, which is where you send the user for anything that is not publicly downloadable.
Fetch one item by UUID, Handle or DOI. Accepts any of them, so pass whichever identifier you have: a UUID ("0f4a..."), a Handle ("123456789/4271" or "hdl:123456789/4271") or a DOI ("10.1234/abcd" or "https://doi.org/10.1234/abcd").
Get metadata about the repository: its name, available search filters, sortable fields, and access status.
Output schemas not explicitly documented. Response structures are inferred from implementation (shaping.py functions) but not formally declared in tool definitions. LLMs cannot reliably predict return fields without documented schemas.
No tool annotations despite all tools being read-only. Missing readOnlyHint annotations would help agents understand which tools are safe to call without side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
List the files attached to an item, with direct download URLs. This does not download anything: it returns names, sizes, MIME types, checksums and links. Careful with `download_url`: it works in a browser only for files that are public. Every entry also carries `item_url`, the item's page on the repository website — that is what you hand to the user when a file turns out not to be public, because they can download it there after logging in.
List the bundles attached to an item.
List collections, either of one community or of the whole repository. Collections are where items live; use a collection UUID as the `scope` argument of search_items to search inside it.
List communities — the top level of the repository's structure.
Search the repository for items (publications, theses, datasets...). Returns compact records plus `total`, the number of matching items in the whole repository. Set `limit=0` to get only that count, which is the cheap way to answer "how many items match X".
Error handling lacks recovery guidance. DSpaceError exceptions are raised (e.g., 'limit must be zero or greater') but tool descriptions do not explain what to do when errors occur or how to self-correct.
Pagination guidance incomplete. search_items accepts limit/offset but does not document the maximum result limit enforced by client.config.max_results, forcing agents to discover this constraint via trial.
extract_text max_chars parameter description references 'server's extract_max_mb setting' but does not state the actual default or maximum value, leaving agents unable to predict truncation.