Two tools with complete input schemas and reasonable descriptions. Both tools have proper JSON Schema definitions with typed parameters and descriptions. However, descriptions lack depth on WHEN to use each tool and what distinguishes them. Output schemas are not documented, LLMs cannot plan downstream calls or know what fields to expect. Parameter descriptions are adequate but generic. No error recovery guidance. No tool annotations (readOnlyHint). Missing pagination guidance for rates (could return many carriers). easypost_rates description includes example values (94105, 10001) which LLMs may reuse literally.

• Document output schemas for both tools. Example for easypost_rates: 'Returns { rates: [{ carrier: string, service: string, rate: string, currency: string, delivery_days: number|null, est_delivery_date: string|null }] }'. Example for easypost_track: 'Returns { status: string, carrier: string, tracking_code: string, est_delivery_date: string|null, events: [{ timestamp: string, status: string, location: string }] }'.
• Remove example values from descriptions. Replace 'from_zip: "94105"' with 'from_zip: string (5-digit US ZIP code or international postal code)'. Use parameter constraints (minLength, pattern) instead.
• Add readOnlyHint: true to both tool definitions to signal they are safe to call without user confirmation.
• Enhance error messages with recovery guidance. E.g., 'EasyPost auth failed (HTTP 401), verify your API key at easypost.com/account or generate a new one.' For network errors: 'EasyPost API timeout, retry in 30 seconds or check service status at status.easypost.com'.
• Cap easypost_rates results at 20 carriers and document in description: 'Returns up to 20 shipping rates sorted by price (lowest first). If more carriers are available, use the limit parameter to adjust.'.