Loading ToolBench
Dairy cattle nutrition optimization via Model Context Protocol - provides diet recommendations and feed analysis using the Ration Smart Feed Library API
Server has well-structured tool definitions with complete schemas and descriptions for 4 functional tools. All parameters include type constraints and descriptions. However, the 'error' tool is a placeholder that should not be exposed as a tool. Tool naming follows verb_noun convention (evaluate_, get_, search_). Descriptions are adequate (100-200 chars) but lack dependency hints and recovery guidance. Output schemas are not explicitly documented in the source. Error handling is basic, no actionable recovery messages or error classification.
Server not configured - missing credentials
Evaluate a dairy cattle diet based on feed selection and animal characteristics. Returns comprehensive analysis including milk production, intake, cost, methane emissions, and nutrient balance.
Generate optimized least-cost diet recommendation for dairy cattle. Requires 6-10 feeds (mix of forage and concentrate types). Returns optimized feed quantities, costs, and environmental impact.
Get detailed nutritional information for a specific feed by ID. Returns complete feed composition including dry matter, crude protein, fiber, minerals, and other nutrients.
Search and filter feeds from the Ration Smart Feed Library. Can filter by country, feed type (forage/concentrate), category, and pagination. Returns list of available feeds with basic information.
The 'error' tool should not be exposed as a callable tool. It is a fallback placeholder that indicates missing credentials. Instead, return an error response at the MCP protocol level (via the transport) when credentials are absent.
Output schemas are not documented. Tool descriptions state what is returned (e.g., 'Returns comprehensive analysis including milk production, intake, cost...') but the actual JSON structure is not formally specified. LLMs cannot plan downstream calls without knowing response field names and types.
Error handling lacks actionable recovery guidance. When the API call fails, the tool should return a structured error with the failure reason and next steps (e.g., 'Feed not found. Call search_feeds() to discover available feeds.'). Currently, errors are likely caught and logged without user-facing guidance.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Tool descriptions lack dependency hints. For example, get_diet_recommendation requires 6-10 feeds but does not state 'Call search_feeds() first to discover available feeds.' This forces agents to discover the workflow through trial and error.
search_feeds accepts optional filters (country_id, feed_type, feed_category) but does not document what happens if no filters are provided. Does it return all feeds? A random sample? This ambiguity forces LLMs to guess.