Four tools with complete input schemas and descriptions. Naming follows verb_noun pattern (esim_search_plans, esim_get_plan, esim_create_order, esim_check_order). Descriptions are detailed (150-350 chars) and explain WHAT, WHEN, and WHAT-RETURNS. All parameters have type definitions and descriptions. However, output schemas are not documented, LLMs cannot see what fields to expect from responses. Error handling guidance is minimal (only btc_unavailable mentioned in esim_create_order). No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles (3 READ_ONLY, 1 WRITE). Parameter descriptions are strong but lack explicit constraints (e.g., email format, variation_id range). Missing pagination guidance for esim_search_plans despite limit parameter.

• Document output schemas for all four tools. Example: esim_search_plans returns {plans: [{slug, display_name, variations: [{id, duration_days, data_gb, price}]}], total_count}. This enables agents to chain calls correctly.
• Add tool annotations to inputSchema: readOnlyHint: true for esim_search_plans, esim_get_plan, esim_check_order; destructiveHint: true for esim_create_order. Agents will know which tools are safe to retry.
• Expand error handling in descriptions. Example for esim_create_order: 'Returns btc_unavailable if BTC fees spike; offer card instead. Returns invalid_variation_id if variation no longer in stock; call esim_get_plan to refresh.'
• Add format/enum constraints to parameters. email: 'Valid email address (RFC 5322)'. country: enum ['JP', 'ES', 'US', ...] or pattern '^[A-Z]{2}$|^(spain|japan|europe|global)$'. variation_id: 'Positive integer from esim_search_plans or esim_get_plan response.'
• Document pagination for esim_search_plans. Add offset/cursor parameter and return total_count. Example: 'Returns up to 20 plans; use offset to fetch next batch. total_count tells agent how many plans match filters.'