Loading ToolBench
A comprehensive suite of MCP servers for accessing critical minerals and materials data from multiple sources including ArXiv, BGS World Mineral Statistics, CLAIMM (NETL EDX), OSTI, UN Comtrade, Google Scholar, and a unified REST API.
This is a multi-server suite (5 independent MCP servers) with 13 tools total. Tool naming is consistent with action verbs (search_, get_, list_, detect_), and all tools have descriptions. However, parameter descriptions are often generic or incomplete, output schemas are not explicitly documented in the source, and error handling guidance is absent. The descriptions are adequate (100-250 chars typically) but lack the LLM-optimization detail needed for production use. Parameter validation rules and constraints are largely missing, e.g., search_arxiv accepts max_results up to 100 but does not state bounds in the description. Most tools are read-only (good for risk), but the composition and chaining between servers is unclear. Without seeing explicit schema definitions in the source for outputs, and given the scattered architecture across 5 repos, this lands in the 'fair to poor' range typical of community academic/data tools.
Detect schemas for all tabular files in a dataset. Analyzes CSV and Excel files to extract column headers and data types.
Detect column headers and data types from a CSV or Excel file without downloading the entire file. Uses HTTP Range requests to fetch only the first portion.
Get top producing countries for a commodity in a specific year.
Get detailed information about a specific ArXiv paper.
Get historical time series data for a commodity.
List available datasets in CLAIMM with search and filtering capabilities.
Output schemas are not explicitly documented in source code. While input parameters have JSON Schema definitions with types and descriptions, return types are not defined. This forces LLMs to infer structure from descriptions alone, risking misinterpretation of nested objects, lists, and field names.
Parameter descriptions lack explicit constraints. E.g., search_arxiv's max_results states '(default: 10, max: 100)' but does not document minimum bound or what happens if exceeded. Descriptions should state: 'Integer 1 - 100, default 10. Values >100 are clamped to 100.' This prevents LLMs from passing invalid values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
List all available mineral commodities in the BGS database.
List all countries with mineral production data.
Search ArXiv for papers matching a query. This tool searches the ArXiv repository for academic papers matching the provided query string. It returns paper metadata including title, authors, abstract, and PDF links.
Search CLAIMM data using natural language. The query is interpreted by AI to find relevant datasets about critical minerals, mine waste, and related topics.
Search for mineral production or trade data.
Search Google Scholar for papers, proceedings, and preprints.
Summarize an ArXiv paper using a commercial LLM (via official SDKs).
No error handling guidance. Tools document normal operation but not failure modes. E.g., search_arxiv does not state what happens if the query is malformed, if ArXiv is unreachable, or if no results match. Error responses should include recovery hints: 'No results found for query "xyz". Try broadening your search with fewer keywords or searching across multiple years.'
Abbreviated parameter descriptions. get_paper_details has only 'The ArXiv ID (e.g., "2301.07041")', no mention of format (7 digits after period?), whether leading zeros matter, or what happens if the ID does not exist. Descriptions under 50 chars lack actionable detail.
Tool composition clarity is unclear. E.g., search_claimm_data returns datasets but does not explicitly state whether results include dataset_id, which would be required to call detect_dataset_schemas. Without documented field names in responses, tool chaining requires the LLM to guess parameter names.
Cross-server parameter naming inconsistency. BGS uses 'commodity' and 'country'; CLAIMM uses 'query'; ArXiv uses 'query'. No unified parameter naming guide means agents must learn separate conventions for each server, increasing error rate when switching contexts.
No pagination or result limiting for list_ and search_ tools. search_production has a limit parameter, but search_arxiv (max_results up to 100), search_claimm_data (max 10 default), and search_scholar (max 20) lack explicit documentation of pagination cursors. Large result sets risk context window exhaustion.
Vague parameter semantics. search_production's 'statistic_type' defaults to 'Production' but does not state whether it accepts 'Production' or 'production' (case sensitivity). summarize_paper's 'llm_provider' accepts 'openai' or 'anthropic' but does not document what credentials/API keys are required or how they are configured.