Grocer defines 9 tools with clear action verbs and reasonable descriptions (avg ~100 chars). All tools have input schemas with typed parameters. However, parameter descriptions are sparse or missing context about dependencies and constraints. Output schemas are not documented. Error handling is present but generic (returns success/error dicts without recovery guidance). Tool composition is sound, each tool has one responsibility, but descriptions lack the LLM-optimization depth needed for confident tool selection in ambiguous scenarios.

• Document output schemas for all tools. For search_products, explicitly define: { success: bool, query?: string, count?: int, products?: [{ product_id, brand, name, variants: [{ spin_id, sku_id, name, pack_size, price, mrp, formatted_price, savings, in_stock }] }], error?: string }. This lets LLMs understand what data is available after a call.
• Add min/max constraints to numeric parameters. E.g., 'quantity: integer, minimum 1, maximum 999' and 'page_size: integer, minimum 1, maximum 100'. Include these in parameter descriptions, not just JSON Schema.
• Enhance error responses with recovery guidance. Instead of { success: false, error: 'AUTH_EXPIRED' }, return { success: false, error_code: 'AUTH_EXPIRED', message: 'Authentication token expired. Please re-authenticate and retry.', retryable: true }. Categorize all errors as retryable, user_fixable, or fatal.
• Add confirmation step for destructive operations. place_order should require explicit user confirmation before executing. Consider a dry_run parameter or a separate confirm_order tool that validates the order before submission.
• Clarify tool dependencies in descriptions. E.g., 'search_products: Use this to find items. Requires address_id, call get_saved_addresses first if you don't have one.' This guides multi-step planning and reduces wasted calls.

Inferred effective spec: <=2025-11-25.

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