Ecommerce Orchestration

E-commerce Orchestration Skill

Overview

This skill demonstrates Pattern 2: Multi-MCP Orchestration by coordinating between two MCP servers:

1. task-tracker: Manages order/return tasks and workflows
2. business-rules: Provides e-commerce policies (return windows, shipping costs, discounts)

When This Skill Activates

Claude automatically uses this skill when you mention:

Return Processing:

• Processing/handling a return request
• Checking return eligibility or policies
• Customer wants to return an item
• Return evaluation or assessment
• Refund calculations or decisions

Order Processing:

• Creating or processing an order
• Applying discounts or loyalty benefits
• Calculating shipping costs
• Order fulfillment
• New customer orders or bulk orders

Policy Inquiries:

• Shipping costs for an order
• Return windows or policies
• Discount eligibility
• Restocking fees
• Business rules or policies

Multi-Server Workflows

Return Request Workflow

When processing a customer return:

Orchestration Steps:

1. Create return task (task-tracker: create_task)
   • Title: "Return: [Item] - [Price/Details]"
   • Status: "pending"
   • Include item category, purchase date, condition in description
2. Check return policy (business-rules: check_return_policy)
   • Parameters: category (clothing/electronics/books/food), days_since_purchase, opened (true/false)
3. Evaluate eligibility based on policy result
   • If eligible: calculate refund amount (original_price - restocking_fee if applied)
   • If ineligible: note reason (outside return window, condition issues, etc.)
4. Update task (task-tracker: update_task)
   • Add policy decision to task description
   • Include refund method and amount
   • Status: "in_progress" (ready for fulfillment)
5. Route to fulfillment based on eligibility status

Example: "Process a return for a laptop purchased 10 days ago"

• Step 1: Creates task "Return: Laptop - Opened - 10 days"
• Step 2: Checks policy: electronics = 14 days, opened = 15% fee
• Step 3: Evaluates: Eligible (within 14-day window), refund = original × 0.85
• Step 4: Updates task: "✓ ELIGIBLE - 15% restocking fee applies"
• Step 5: Ready for fulfillment team to process

Order Processing Workflow

When creating a new order:

Orchestration Steps:

1. Calculate discounts (business-rules: calculate_discount)
   • Parameters: customer_status (new/existing), loyalty_tier (bronze/silver/gold), num_items
   • Result: discount percentage to apply
2. Calculate shipping (business-rules: calculate_shipping_cost)
   • Parameters: order_total (after discount), shipping_type (standard/expedited/express)
   • Result: shipping cost for the selected method
3. Create order task (task-tracker: create_task)
   • Title: "Order fulfillment - [Customer] - $[Total]"
   • Status: "pending"
   • Include itemized breakdown in description
4. Update task (task-tracker: update_task) with final pricing
   • Subtotal, discount amount, shipping cost, estimated tax, final total
   • Include delivery timeline based on shipping type
5. Route to fulfillment center based on order size/priority

Example: "Create an order for a new customer buying 12 items totaling $85"

• Step 1: Calculates discounts: 10% new customer + 10% bulk (capped at 25%) = $21.25 discount
• Step 2: Calculates shipping: Free standard (order $63.75 > $50)
• Step 3: Creates task "Order fulfillment - New Customer - $63.75"
• Step 4: Updates task with breakdown: Subtotal $85 - Discount $21.25 - Shipping $0 = Total $63.75 + tax
• Step 5: Routes to fulfillment for processing

Complex Scenario: Return Evaluation

Scenario: "Evaluate a return for 3 opened books and 1 unopened laptop purchased 20 days ago for $500 each"

Orchestration Steps:

1. Create multi-item return task (task-tracker: create_task)
   • Title: "Return evaluation - 4 items - 20 days"
   • Description: List each item with category, condition, original price
2. Check each item's policy (business-rules: check_return_policy × 4 calls)
   • Books: category=books, days=20, opened=true
   • Laptop: category=electronics, days=20, opened=false
3. Aggregate results for each item
4. Update task (task-tracker: update_task) with itemized decision
5. Calculate total refund and route for processing

Evaluation Results:

Books (3×):

• Step 2: books policy = 60-day window, no restocking fee
• Result: ✓ ELIGIBLE (within 60 days), full refund = $100 each × 3 = $300

Laptop:

• Step 2: electronics policy = 14-day window, 15% fee if opened
• Result: ✗ OUTSIDE WINDOW (20 days > 14 days), ineligible - cannot process

Total Return: $300 only (books eligible, laptop denied)

Note: This example shows how the skill evaluates each item independently and provides itemized refund decisions.

Available Operations

From task-tracker MCP:

• create_task - Create order/return task with metadata
• update_task - Update task status, add notes
• filter_tasks - Find tasks by priority, status, project
• list_tasks - List pending/completed tasks
• get_task_statistics - Get completion rates, metrics

From business-rules MCP:

• check_return_policy - Validate return eligibility
• calculate_shipping_cost - Get shipping costs by order amount
• calculate_discount - Apply customer/order discounts
• get_all_policies - View all business rules

Best Practices

1. Always check rules first: Before creating tasks, validate using business-rules to provide accurate information
2. Embed results in tasks: Include policy decisions and calculations in task descriptions for auditing
3. Use specific categories: Use exact category names (electronics, clothing, books, food) for accurate policies
4. Consider customer context: Loyalty tier, purchase history affect discounts and eligibility
5. Chain operations: Discount → Shipping → Task creation creates complete order workflows
6. Document decisions: When rules block actions, clearly state why in task notes

Example Prompts

Return Processing

• "Process a return for clothing purchased 20 days ago, unopened"
• "Evaluate return for opened electronics purchased 5 days ago"
• "Check if customer can return books purchased 45 days ago"

Order Creation

• "Create an order for a new customer buying 8 items for $65"
• "Create an order for a gold loyalty member buying 3 items for $120"
• "Process an order for 25 bulk items totaling $500 with standard shipping"

Policy Inquiries

• "What's our shipping cost for a $75 order?"
• "What discounts apply for a silver member buying 12 items?"
• "How long can customers return clothing?"

Integration Example

User: "I need to process a return for a dress. Customer bought it 20 days ago for $45, and it's unworn."

Steps:
1. task-tracker: Create task "Return: Dress - $45 - Unworn"
2. business-rules: check_return_policy("clothing", 20, opened=false)
   → {eligible: true, days_remaining: 10, restocking_fee: 0%, refund_method: "original_payment"}
3. task-tracker: Update task with "✓ ELIGIBLE - Full refund $45 via original payment method"
4. Result: Task ready for fulfillment, customer gets full refund

Token Efficiency Note

This pattern (Pattern 2) uses 2 MCP servers, which increases token usage compared to Pattern 1:

• Pattern 1 (single server): ~600-1000 tokens
• Pattern 2 (multi-server): ~1000-1500 tokens

The additional tokens are worth it because:

• Business rules are independently versioned and managed
• Rule changes don't require server restarts
• Clear separation of concerns (tasks vs. policies)
• Demonstrates real-world orchestration patterns

Implementation Requirements

This skill requires:

• task-tracker MCP server - For creating and updating return/order tasks
• business-rules MCP server - For checking policies and calculating costs/discounts

When the skill activates, it orchestrates calls to both MCP servers in sequence:

1. Create/query task-tracker to initialize tasks
2. Call business-rules to validate against policies
3. Update task-tracker with results and decisions
4. Route to appropriate fulfillment/processing workflow

Both MCP servers must be registered and running for this skill to function properly.

See Also

• PATTERNS_CATALOG.md - Pattern 2 detailed documentation
• PATTERN_2_IMPLEMENTATION.md - Implementation details