Server has 6 well-named, read-only tools with complete JSON schemas and descriptions. All tools follow verb_noun naming (get_, search_, list_, browse_). Schemas include proper types and required fields. However, parameter descriptions are minimal (10-30 chars), lacking context on format, constraints, or when to use each tool. Output schemas are not documented in the source. Error handling is absent, no recovery guidance or actionable error messages visible. Tool descriptions are adequate (30-80 chars) but could better explain when to call each tool vs. alternatives (e.g., search_recipes vs. browse_recipes distinction).

• Expand parameter descriptions to 50-100 chars. For 'id' in get_recipe, write: 'The numeric recipe identifier (e.g., 12345). Find IDs via search_recipes or browse_recipes.' For 'query' in search_recipes, write: 'Free-text search term (e.g., 'coq au vin', 'beef'). Partial matches supported.'
• Document output schemas for all tools. Add a comment block in src/server.ts or a separate schema file showing: get_recipe returns {id, name, servings, ingredients[], instructions, prepTime, cookTime}; search_recipes returns {recipes: [{id, name, servings}], totalCount, page, pageSize}.
• Add error handling with recovery hints. Wrap tool implementations with try-catch that returns: {error: 'Recipe not found (ID: 12345). Try search_recipes() with a partial name or browse_recipes() by category.'}
• Clarify search_recipes vs. browse_recipes in tool descriptions. search_recipes: 'Full-text search across all recipes by name or ingredient. Use when you know what dish the user wants.' browse_recipes: 'Browse recipes by category. Use when the user wants to explore a cuisine or dish type.'
• Add pagination constraints to descriptions. For 'page' param: 'Page number (1-indexed, default 1). Max 100 results per page. Check totalCount in response to determine available pages.'

Inferred effective spec: 2025-06-18+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry