Loading ToolBench
Multi-agent crop advisory system: weather + market + agronomy agents orchestrated by an LLM, exposed as an MCP server for Claude Desktop and other MCP clients
Three well-named tools with strong, LLM-optimized descriptions (150 - 250 chars each). All parameters have types and descriptions. Tool names follow verb_noun pattern (get_*). Schemas are complete with proper JSON Schema structure. Output schemas are not explicitly documented in the source, but tool descriptions clearly state what each returns. Error handling is implicit (tools return dicts with 'error' key on failure). No critical gaps, but output structure documentation could be more explicit for downstream chaining.
The main advisory tool. Fetches the weather forecast and mandi prices for this farm, runs the deterministic agronomy rule engine over them, and returns grounded observations covering irrigation, spray windows, heat stress, disease risk, and whether to hold or sell. Every hint is derived from real data — if the data supports nothing notable, it says so. Base your advice on these hints rather than on general agronomy knowledge, and never add a chemical product or dosage recommendation.
Recent Indian mandi (wholesale) prices for a commodity, with a computed trend (rising/falling/stable) across the quotes. Source: the Agmarknet dataset on data.gov.in. Prices are INR per quintal. Descriptive only — this is not financial advice.
Daily weather forecast for a farm location: max/min temperature, rain probability and amount, wind speed, and reference evapotranspiration (ET0). Source: Open-Meteo, no API key needed. Use this for specific weather questions; for irrigation or spraying decisions call get_agronomy_hints instead, which interprets this same data through the agronomy rules.
get_agronomy_hints schema incomplete: input_schema shows empty properties and required array in TOOL_SCHEMAS, but MCP server exposes it with explicit crop/location/crop_stage/soil_type/state parameters. Mismatch between Anthropic schema and MCP registration creates ambiguity.
Output schemas not documented. Tool descriptions state what is returned (e.g. 'max/min temperature, rain probability...') but formal output schema (field names, types, structure) is not visible in source. Downstream tools cannot reliably chain on these outputs.
Error handling is implicit (tools return {'error': '...'} on failure). No guidance on error classification (retryable vs fatal) or recovery steps. LLM cannot distinguish transient failures from permanent ones.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
get_weather and get_mandi_prices accept optional parameters (days, state) with defaults, but no explicit validation constraints (e.g. days 1 - 16 is stated in description but not enforced in schema). LLM may pass invalid values.