Five tools with basic verb-noun naming (get_*, check_*) and present descriptions. However, descriptions are minimal (10-50 chars), lack context on WHEN to use each tool, and omit dependency hints. All tools have simple string/list input schemas with parameter descriptions, but output schemas are undocumented, LLMs cannot plan downstream calls. No error handling guidance, no pagination for list-returning tools, no idempotency markers. Tools are read-only (good), but composition is weak: get_customer_ids_by_name + get_orders_by_customer_id requires two calls where a single 'get_orders_by_customer_name' would be more efficient. Baseline: avg tool description ~30 chars (p10=34, p90=392 for A+ tools); these are well below median.

• Expand tool descriptions to 100-200 chars. Include WHEN to use (e.g., 'Use this to fetch a single order by ID. For all orders by a customer, use get_orders_by_customer_id instead.'), what it returns, and any prerequisites.
• Document output schemas explicitly. For get_order_details, specify: returns {order_id: string, customer_id: string, date: string (ISO 8601), status: string, total: number, items: string[]}. For get_orders_by_customer_id, specify the dict structure and field types.
• Add error recovery guidance. Instead of 'Customer not found', return 'Customer not found. Try get_customer_ids_by_name(customer_name) to search by name, or list all customers with list_customers().'
• Consolidate get_customer_ids_by_name + get_orders_by_customer_id into a single 'get_orders_by_customer_name' tool to reduce multi-step planning and latency.
• Add pagination to get_orders_by_customer_id: accept limit (default 20, max 100) and offset parameters; return {orders: [...], total: number, has_more: boolean}. Cap results at 50 items per call.