mcp-pantry defines 6 recipe-discovery tools with complete input schemas and reasonable descriptions. All tools are READ_ONLY and follow verb_noun naming (find_, search_, get_, list_). Descriptions are present (avg ~100 chars) but lack actionable detail on when to use each tool vs. alternatives, and parameter descriptions are entirely absent. Output schemas are not documented, LLMs cannot predict response structure for chaining. Error handling is basic (HTTP errors, missing recipes) with no recovery guidance. No tool annotations (readOnlyHint, idempotentHint) despite all being read-only. Composition is sound: tools are single-purpose and chainable (e.g., search_recipe → recipe_details). Security is adequate for a read-only, keyless API.

• Add descriptions to all parameters. E.g., 'ingredients: Array of ingredient names (1 - 10 items). E.g., ["chicken", "garlic"]. Searches TheMealDB for recipes containing ALL of these.' and 'limit: Maximum number of recipes to return (1 - 50, default 15).'
• Document output schemas in tool descriptions or as a separate schema field. E.g., 'Returns {recipes: [{id, name, thumbnail}], match_count: number, shown: number}' so LLMs know what fields to expect.
• Add readOnlyHint: true and idempotentHint: true to all tool definitions (via tool annotations in the TOOLS array or server capabilities) to signal safety to LLMs.
• Enhance tool descriptions with disambiguation. E.g., 'Use find_by_ingredients when you have specific ingredients on hand. Use recipes_by_category to browse a cuisine type (e.g., Vegetarian, Dessert).'
• Improve error messages with recovery hints. E.g., 'No recipes match ALL of those ingredients. Try: (1) fewer ingredients, (2) recipes_by_category for a broader search, or (3) random_recipe for inspiration.'