Loading ToolBench
Machine Consumable Provider (MCP) for searching the Israeli National Library (NLI). Provides search, image, manifest, and streaming endpoints for accessing library resources.
Single tool 'search_nli' has a detailed input schema with 10 parameters covering search, filtering, and pagination concerns. However, the tool description is moderate length (89 chars) and lacks critical detail about when to use it versus alternatives, what the response structure contains, and how to interpret results. Parameter descriptions vary in quality: some are clear (e.g., 'Main search query in field,operator,value format'), others are terse (e.g., 'Sort results by this field' lacks guidance on valid field names). The output schema is entirely undocumented, SearchResponse is defined in code but never exposed to LLMs, forcing them to guess what 'total_results' and 'items' contain. No error handling guidance, no documentation of failure modes, and no actionable recovery steps. The tool is read-only, which is good for safety, but the definition quality falls short of production standards.
Search the National Library of Israel catalog using structured query parameters.
Output schema not documented. SearchResponse (Pydantic model with 'total_results' and 'items' fields) exists in code but is never exposed to the MCP tool definition. LLMs cannot predict what the response structure looks like, forcing them to guess or fail on downstream parsing.
Tool description is brief (89 chars) and lacks guidance on when/why to use it. Does not explain the 'field,operator,value' query format clearly enough for LLMs to construct valid queries without trial-and-error. Missing examples of valid field names (any, title, desc, creator, subject, dr_s, dr_e) and operators (contains, exact).
Parameter 'sortField' description is vague ('Sort results by this field') and does not enumerate valid field names. Agents cannot know which fields support sorting and will guess or pass invalid values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 38 | <=2025-11-25 | v2 |
Parameter 'materialType' is documented as 'Filter by material type (books, articles, images, etc.)' but the system instructions elsewhere state the exact enum: 'books, articles, images, audio, videos, maps, journals, manuscripts, rareBooks'. This enum is NOT reflected in the tool schema, so LLMs cannot see valid options.
No error handling guidance. Tool definition provides no information about what happens on invalid queries, network failures, API authentication errors, or empty result sets. Agents have no recovery path if a call fails.
Parameter 'offset' and 'limit' combine for pagination, but no guidance on maximum result count, whether the API enforces a ceiling on offset, or what happens at end-of-results. Agents may attempt invalid pagination offsets without knowing the total count structure.
Parameter 'q' requires format 'field,operator,value' but this is difficult for LLMs to reliably construct. No validation, no clear examples tied to real use cases. The system instructions contain extensive query processing logic that should be reflected in the tool description and parameter constraints.
Tool name 'search_nli' uses a domain-specific acronym (NLI = National Library of Israel) that may not be obvious to agents unfamiliar with the library. A more descriptive name like 'search_library_catalog' or 'search_national_library_catalog' would be clearer.