The SendaMeal MCP server defines 4 tools with basic Zod schemas and attempt at descriptions, but falls short of production quality. Tool names are reasonably verb-based (search_*, get_*, find_*), and all tools have input schemas defined in Zod. However, descriptions are superficial (10-30 chars for tool descriptions, under 10 chars for most parameters), parameter descriptions lack actionable context, output schemas are undocumented, and error handling is generic. The server implements HTTP transport with SSE endpoints, which is current, but lacks modern MCP patterns like structured output documentation, tool annotations, and proper error recovery guidance. None of the tools document what fields they return or how their outputs chain to other tools.

• Expand each tool description to 50-200 chars explaining WHAT it does, WHEN to use it, and WHAT it returns. E.g. 'search_products: Search SendaMeal's product catalog by keyword. Returns up to 10 matching products with title, URL, and snippet. Use this for broad searches; use find_dietary_options for dietary-filtered results.'
• Document output schema for each tool. Define the structure of the returned content object (e.g. {products: [{title: string, url: string, snippet: string}], total: number, more_results: boolean}). This lets LLMs know which fields to extract and plan chaining.
• Add actionable error messages. E.g. instead of 'Error searching products: {error.message}', return structured errors like {error: 'NO_RESULTS', message: 'No products found for query. Try a broader search term or use find_dietary_options() to filter by dietary restriction.'}
• Implement result pagination. Accept offset/limit params and return a total count or next_cursor. Document the maximum result count (10-50) in the tool description.
• Add tool annotations to indicate idempotency and read-only nature. Register each tool with idempotentHint: true and readOnlyHint: true in the tool definition.
• Rewrite parameter descriptions with actionable context. E.g. 'meal_type: Optional meal category (breakfast, lunch, dinner, dessert, snack). Narrows results if provided.' Include examples only as enums, not free-form text.
• For 'preferences' parameters, define expected formats or provide enums (e.g. 'vegan', 'gluten-free', 'budget-friendly'). Free-form strings invite hallucinated values.