Loading ToolBench
FastMCP interface to a CookCLI recipe server. Wraps the HTTP API of `cook server` so an agent can browse, read, write and delete Cooklang recipes as MCP tools.
Server has 7 tools with clear verb-noun naming (list_, read_, write_, delete_, search_, collection_). All tools have descriptions (avg 120 chars, within baseline 34-392). Input schemas are present with type definitions for all parameters. However, parameter descriptions are minimal or missing context about constraints, formats, and error recovery. Output schemas are undocumented, LLMs cannot predict return structure. No error handling guidance. No pagination support despite search_recipes returning potentially large lists. Missing tool annotations (readOnlyHint, destructiveHint). Composition is sound (single responsibility per tool), but chaining support is weak due to undocumented output fields.
Return collection counts (recipe_count, menu_count, pantry_* counts).
Permanently delete a recipe file. There is no undo and no trash.
Return the full recipe tree: folders and .cook / .menu files. Every node has children, name, path, recipe. `recipe` is null for a directory and non-null for a file.
Read one recipe parsed into ingredients, cookware, timers and steps. path: recipe path relative to the recipe directory, e.g. "Dolci/bunet-piemontese" (the .cook extension is optional). scale: multiply quantities by this factor during parsing.
Return the raw Cooklang source text of a recipe, frontmatter included.
Full-text search over recipe names and content. Returns name + path.
Output schemas completely undocumented. LLMs cannot predict return structure (e.g., list_recipes returns 'children', 'name', 'path', 'recipe' fields, not visible in tool definition). Breaks downstream tool chaining and forces LLMs to guess field names.
search_recipes lacks pagination (limit, offset, page_size parameters and total_count in response). Full-text search over recipes could return hundreds of results, blowing context window. No guidance on result limits.
No error handling guidance. Tools call raise_for_status() but provide no recovery hints. E.g., if write_recipe fails because parent folder doesn't exist, LLM gets HTTP error with no suggestion to create folder first.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Create or overwrite a recipe. `source` is raw Cooklang text. The parent folder must already exist. A missing .cook extension is added automatically. Writes are atomic (temp file + rename).
Destructive operations (delete_recipe) lack confirmation/dry-run support. No idempotent or destructive hints in tool annotations. Agents can permanently delete recipes without safeguards.
Parameter descriptions lack constraint details. 'scale' parameter has no bounds (min/max). 'path' parameter has no format guidance (relative vs absolute, extension handling). 'query' in search_recipes has no length or syntax constraints.