Loading ToolBench
MCP server for searching and retrieving metadata from Library of Congress digital collections
This server has 6 tools with significant quality gaps. Four tools (search_items, get_item_details, search_collections, format_search) have reasonable descriptions and parameter schemas. However, tool naming lacks clarity, 'get_item_details' uses a generic noun rather than describing the action; 'format_search' is ambiguous (does it format or search?). Parameter descriptions are minimal or missing entirely. Output schemas are not documented anywhere, tools return raw API responses or side effects without specifying their structure. get_item_details mutates filesystem state (writes JSON files) as a side effect, violating single responsibility. The prompt tool 'generate_search_prompt' is registered as a tool but appears to be a prompt template generator, not a traditional tool, its classification is unclear. Error handling is absent; network failures will expose raw exception traces. Security issues: no rate limiting, no permission checks, no audit logging. The average tool score is 48, placing this in the poor-to-fair range typical of early-stage community servers.
Search for items from the Library of Congress collections by both keyword and format.
Generate a prompt to find and summarize LOC items related to a specific query.
Get the metadata details for a single item from the Library of Congress collections.
Get trending content from the Library of Congress.
Search for collections in the Library of Congress by keyword.
Search for items in the Library of Congress digital collections and store their information.
Output schemas are not documented. Tools return raw API responses or internal structures without specifying which fields are returned or their types. LLMs cannot plan downstream tool calls or extract required data reliably.
get_item_details mutates filesystem state (creates directories, writes JSON files). This violates single responsibility, the tool should either fetch metadata OR persist it, not both. Side effects make the tool non-idempotent and unpredictable in agent contexts.
No error handling or recovery guidance. Network failures, API errors, and missing resources will expose raw exceptions. Error messages do not guide the agent toward recovery (e.g., 'Item not found. Try search_items() to find a valid ID').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
get_trending_content has minimal description (under 30 chars). No parameter descriptions. Return type is unclear (appears to return a Response object, not structured data).
Parameter constraints are informal. format_search documents valid formats in a docstring comment, but not as a schema enum. Invalid formats will be silently passed to the API, causing failures. search_items and format_search accept max_results but do not specify min/max bounds, an agent could pass 0 or 10000.
Tool naming ambiguity: 'format_search' conflates two concerns, does it search by format or format results? Naming should clarify intent. 'search_by_format' or 'search_filtered_by_format' would be clearer.
generate_search_prompt is registered as a tool but semantically appears to be a prompt template generator (returns a string prompt, not tool output). This blurs the line between tool and prompt, clarify whether this should be a prompt or a tool.
No pagination support. search_items and search_collections accept max_results but return all results without offset/page/cursor. If an API returns 1000 results and max_results=5 is set, the behavior is unclear, does it return 5 or all?
No security controls. No rate limiting to prevent runaway agents. No permission checks. No audit logging. Credentials are implicit in the server (requests.get calls bare URLs), verify that no API keys are embedded in the code.