Loading ToolBench
A local MCP server for multi-source geoscience literature search and compliant download workflows.
GeoScholar demonstrates solid definition quality with comprehensive parameter schemas, detailed descriptions, and clear tool naming. All 7 tools follow verb_noun conventions (search_, get_, queue_, download_, list_). Parameter descriptions are thorough and include usage guidance. However, output schemas are not explicitly documented in the source code, and error handling lacks recovery guidance. Tool descriptions average ~180 chars, within the 10-1024 baseline. Parameter descriptions are detailed (avg ~100 chars) with enums properly constrained. The main gaps are: (1) no visible output schema documentation for any tool, (2) error responses lack actionable recovery hints, (3) no tool annotations (readOnlyHint/destructiveHint) despite clear risk levels.
Download an article synchronously and wait for completion. This tool blocks until the download finishes or fails. Use queue_download instead if you want to download multiple articles in parallel or avoid blocking.
Retrieve full article metadata and download candidates for a known article. Use this when you already have a record id from a previous search result, or when you have a DOI or detail URL. This tool enriches the record with additional metadata and resolves all available download methods.
Check authentication status for a source. Use this to verify whether a source is configured and ready for use, or to see what authentication steps are needed.
Inspect one download job in detail. Use this to check the status, progress, and result of a specific download job by its id.
List recent download jobs. Use this to monitor the status of queued or completed downloads.
Queue an article for download. This tool creates a background download job and returns immediately with a job id. Use this to download one or more articles without blocking. Monitor the job with get_download_job or list_download_jobs.
Output schemas not documented. No visible return type definitions for any of the 7 tools. LLMs cannot plan downstream calls or extract required fields without knowing response structure.
Error handling lacks recovery guidance. No visible error responses that tell LLMs what to do next (e.g., 'Try search_literature() first' or 'Invalid source, must be one of: cnki, geophysics, ...'). Agents cannot self-correct.
Tool annotations missing. download_article and queue_download are marked WRITE risk but lack destructiveHint/idempotentHint annotations. search_literature and get_* tools lack readOnlyHint. Agents cannot reason about side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
General-purpose multi-source literature search. Use this as the default entry point when the user did not name a single source. Also use this for foreign-journal searches after the foreign single-source tools were consolidated. If the user says 'in GEOPHYSICS', 'in Journal of Geophysics and Engineering', or 'in Petrophysics', keep the topic in query and set journal to the exact journal title. If the user names a platform such as OnePetro, SPE, SPWLA, EAGE, or AAPG, set source to that platform. If the user asks for papers by a person or teacher, set mode='author'. If the user mentions an institution such as 中国石油大学 or China University of Petroleum, put that value in institution instead of mixing it into query when possible. For Chinese authors' English papers, prefer the English author name when known and let the service combine author and institution rescue. For latest or recent papers, set sortBy='published' and optionally yearFrom/yearTo.
Pagination not visible in list_download_jobs. Tool accepts 'limit' but no offset/cursor or total_count documented. Large result sets could blow context window.
search_literature has 12 parameters; no guidance on mutual exclusivity or dependencies. E.g., can both 'yearFrom' and 'sortBy=published' be used together? Does 'journal' override 'source'? Undocumented dependencies cause misuse.