Three tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (get_, add_). Descriptions exist but are minimal (10-50 chars, below the 50-200 char LLM-optimized baseline). Parameters lack detailed constraints and format guidance. No documented output schemas. Error handling is present but generic. The add-tracking tool accepts optional parameters without documenting mutual exclusivity or dependencies. Overall structure is functional but falls short of production-grade quality.

• Expand tool descriptions to 50-200 characters. Example: 'get-order-details: Retrieve full order details including line items, fulfillments, and pricing. Use this to inspect a specific order before taking action. Accepts order number (#1001), numeric ID (1001), or Shopify gid. Returns order status, items, fulfillment tracking, and totals.'
• Document output schemas explicitly. Define what fields each tool returns (e.g., get-order-details returns {id, name, status, lineItems[], fulfillments[], totalPrice}). This enables agents to plan chaining and extract required IDs.
• Add format and constraint guidance to parameters. Example: 'orderId: The order ID in one of three formats: (1) order number with # prefix (#1001), (2) numeric order number (1001), or (3) full Shopify GraphQL ID (gid://shopify/Order/...). The tool auto-detects the format.'
• Enhance error messages with recovery hints. When an order is not found, return: 'Order #1001 not found. Call get-active-orders to see available orders, or verify the order number format (e.g., #1001 or 1001).'
• Add tool annotations to the server.tool() calls. Mark get-order-details and get-active-orders with readOnlyHint: true. Mark add-tracking with destructiveHint: true to signal state modification and retry constraints.