Loading ToolBench
MCP server for the USDA NASS API providing access to agricultural data from the National Agricultural Statistics Service
The server defines a single 'query' tool with comprehensive input schemas for commodity, location, and time parameters. The tool name is clear and verb-driven ('query'). Schemas are well-structured using TypedDict with Annotated descriptions for nearly all parameters. However, the tool description is generic (28 chars), and output schema is entirely undocumented. Error handling is absent from the visible code. The server uses fastmcp with HTTP transport and appears to follow reasonable parameter organization patterns from the 54 Agentic Tool Patterns, but lacks several production-grade guardrails around error guidance, output documentation, and recovery instructions.
Query the NASS API for agricultural data
Tool description is only 28 characters ('Query the NASS API for agricultural data'). Rubric baseline requires 10-1024 chars; this is minimal. LLMs need more context on WHEN to use this tool vs. others, what it returns structurally, and any prerequisites (e.g., API key requirement).
No output schema documented. The tool returns NASS API data (CSV, JSON, or XML), but the agent has no way to know what fields, structure, or pagination to expect. Rubric requires 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.'
No error handling or recovery guidance. The server.py does not show try/catch blocks, error categorization (retryable vs. fatal), or actionable error messages. If the NASS API returns a rate limit, 404, or invalid parameter, the LLM receives a raw error with no guidance on next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 62 | - | v1 |
Parameters are optional but dependencies undocumented. The 'commodity' object requires only 'commodity_desc' but accepts 11 optional subfields (source_desc, sector_desc, etc.). The description does not explain how these filter the query, whether they are mutually exclusive, or what happens if all are omitted. Rubric: 'When one parameter's valid values depend on another... document this in both parameter descriptions. Undocumented dependencies cause silent misuse.'
No pagination, result limits, or count documentation. The tool accepts 'year', 'freq_desc', and other filters but does not constrain the result size, specify a default limit, or document how large result sets are handled. Rubric baseline: 'cap results at a reasonable limit (e.g. 20-50) and offer pagination. LLM reasoning degrades as context grows.'
API key injection via environment variable (NASS_API_KEY) is secure server-side, but the tool description does not mention this requirement or state that an API key must be configured before deployment. Agents cannot verify readiness; deployment without the key will silently fail.