Three tools with clear naming (verb_noun pattern) and documented schemas. All tools have descriptions (10 - 200 chars, within baseline). Input schemas use Zod with type constraints and descriptions. However, output schemas are undocumented, LLMs cannot predict response structure. Error handling is minimal: no recovery guidance, no categorization of retryable vs fatal errors. parcel_add_delivery lacks idempotency guidance despite being a write operation. No pagination support despite list_deliveries potentially returning unbounded results.

• Document output schemas for all three tools. Define Carrier as {code: string, name: string}, Delivery as {carrier_code, tracking_number, status_code, events: [{event, date, location?, additional?}], ...}, and AddDeliveryResult as {success: boolean, error_message?: string}.
• Add pagination to parcel_list_deliveries: accept 'limit' (1 - 100, default 20) and 'offset' (default 0) parameters. Return {deliveries: [...], total: number, has_more: boolean}.
• Wrap API calls in try-catch. Transform HTTP errors into actionable messages: 'API key invalid. Check PARCEL_API_KEY environment variable.' or 'Carrier code not found. Call parcel_supported_carriers to list valid codes.'
• Add idempotency guidance to parcel_add_delivery description: 'This operation is not idempotent, calling twice with the same tracking number may create duplicate entries. Verify the delivery does not already exist before calling.'
• Enhance parcel_add_delivery description with a multi-step hint: 'First call parcel_supported_carriers to find the carrier code, then call this tool with the tracking number and carrier code.'