29 tools with mostly complete schemas and descriptions, but significant gaps in parameter documentation and error guidance. Tool names follow verb_noun convention well (search_*, get_*, add_*, etc.). Descriptions range from adequate (50-150 chars) to verbose (200+ chars), but many lack actionable context about when to use each tool vs. alternatives. Parameter descriptions are present but often generic ('optional: latitude'). No visible output schema documentation. Error handling is minimal, no recovery guidance or categorization. Security concern: set_wolt_token and login_via_chrome expose authentication flows without clear secret-injection patterns.

• Expand tool descriptions to 100-200 characters. Include WHEN to use each tool (e.g., 'Use search_products to find a single ingredient across all nearby stores; use plan_cart to resolve a full recipe in one call'). Reference search_products description as a model, it explains the distinction vs. plan_cart.
• Document output schemas for all tools. For search_products, specify: returns {count, items: [{venueId, itemId, name, price, ...}], venues: {[venueId]: {slug, city, ...}}}. This enables agents to chain tools correctly (e.g., pass venueId to add_to_cart).
• Move token parameters (refresh_token, access_token) out of set_wolt_token. Instead, require the token to be set via environment variable (WOLT_REFRESH_TOKEN) or a secure config file. Document this in the server README and tool description.
• Add error recovery guidance to search and cart tools. E.g., 'If search_products returns no results, try a broader query (e.g., "oil" instead of "olive oil") or check that the location is set correctly via set_location.'
• Add destructiveHint annotations to clear_basket and remove_favorite. Implement a confirmation pattern: return {requiresConfirmation: true, action: 'clear_basket', details: '...'} and require a follow-up call with confirmed: true.