All 15 tools have explicit schemas with type definitions and parameter constraints (Zod validation). However, descriptions are uniformly generic ('Bring Photo MCP: <tool_name>') with zero contextual value, they do not explain WHAT the tool does, WHEN to use it, or what it returns. This violates the critical pattern:tool-description rule. Parameter descriptions are present and specific (e.g., 'List identifier (non-empty string)', 'Item name (1-200 characters)'), which is a strength. Output schemas are not documented, responses are JSON-stringified text blobs with no declared structure. Error handling returns structured error objects but lacks recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (READ_ONLY, WRITE, DESTRUCTIVE). Naming is verb-first and clear (bring_list_*, bring_add_*, bring_remove_*), following conventions well.

• Replace all generic descriptions with LLM-optimized text (50 - 200 chars) explaining WHAT the tool does, WHEN to use it, and what it returns. Example: 'bring_add_item: Add a product to one or more shopping lists with optional photo, category, and duplicate handling. Use after searching the catalog or when the user specifies a product name.'
• Add tool annotations to all tools: readOnlyHint=true for bring_list_* and bring_search_*, destructiveHint=true for bring_remove_*, idempotentHint=true for bring_check_item and bring_uncheck_item (toggling is idempotent).
• Document output schemas for all tools. Example for bring_list_lists: 'Returns {lists: [{uuid: string, name: string}]}'. Include this in the tool description or a separate schema field.
• Enhance error messages with recovery guidance. Example: 'Item not found in list. Call bring_list_items(list=<list_id>) to see available items.' Use pattern:recovery-guide.
• Add pagination to bring_list_items and bring_list_categories: accept limit (1 - 50, default 20) and offset parameters; return total_count and next_offset in response.