Loading ToolBench
MCP server that asks six recipe sites at once, in French, English and Spanish, merges the answers, and scales quantities. No API key required.
Four tools with complete schemas and descriptions. Naming follows verb_noun pattern (search_, get_, scale_, compare_). Descriptions are adequate (50-100 chars) but lack actionable context for LLM selection. All parameters have types and descriptions. Output schemas are documented in code but not visible in the provided source. Tool annotations (readOnlyHint) present. Main gaps: descriptions don't explain WHEN to use each tool or dependencies between them; no error recovery guidance; parameter descriptions are minimal (e.g., 'Recipe identifier from search_recipes' assumes prior knowledge).
One dish, as each source writes it
Read one recipe, optionally rescaled
Scale an ingredient list, in any language it reads
Search every recipe source at once
Tool descriptions lack WHEN/WHY context. 'Search every recipe source at once' doesn't explain when to call this vs get_recipe or compare_recipes, or what the LLM should do with results.
Parameter descriptions are minimal and assume context. 'Recipe identifier from search_recipes' forces LLMs to infer that search_recipes must be called first; this dependency should be explicit in both tool descriptions.
No error handling guidance. If search_recipes returns no results, or get_recipe fails with an invalid ID, the tool descriptions don't tell the LLM what to do next (retry with different query, ask user, etc.).
Output schemas not visible in provided source code. Tool descriptions reference 'Recipe identifier' and 'scaling factor' but actual response structure (fields, types, pagination) cannot be verified.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2025-06-18+ | v2 |
No pagination or result limits documented. search_recipes and compare_recipes may return many results; descriptions don't mention limits, pagination, or how LLMs should handle large result sets.