MCP Server คือส่วนที่เปิดเครื่องมือให้แอปผู้ช่วย AI เรียกใช้ผ่าน Model Context Protocol หรือ MCP สำหรับงานจัดส่ง เครื่องมืออาจรับข้อมูลผู้รับ น้ำหนัก และขนส่งที่เลือก แล้วส่งคำขอไปยังระบบที่รับผิดชอบงานนั้น ผู้ช่วยจึงทำได้มากกว่าร่างข้อความ แต่การเกิดรายการจริงต้องอาศัยเครื่องมือ ระบบปลายทาง และสิทธิ์ที่ถูกต้องร่วมกัน

AdapterShip อยู่ในสถานะ Preview และเสนอแนวทางให้ผู้ช่วยเรียก adaptership.create_shipment เพื่อสร้างรายการจัดส่ง ตัวอย่างบนเว็บไซต์ใช้ข้อมูลจำลอง ไม่ได้เรียกขนส่งหรือหักเงินจริง บทความนี้อธิบาย Model Context Protocol ภาษาไทยผ่านงานดังกล่าว พร้อมจุดที่ทีมพัฒนาควรตรวจ ก่อนให้บทสนทนาไปกระทบรายการและเงินของร้านค้า

แยกหน้าที่ผู้ช่วย เครื่องมือ และระบบจัดส่ง

ให้นึกถึง MCP Server เป็นผู้บอกรายการเครื่องมือที่แอปผู้ช่วยสามารถเรียกได้ แต่ละเครื่องมือมีชื่อ คำอธิบาย และรูปแบบข้อมูลที่รับ ผู้ช่วยใช้ข้อมูลเหล่านี้ประกอบการเลือกเครื่องมือและเตรียมคำขอ ส่วนแอปที่เชื่อมต่อเป็นตัวจัดการการเรียกตามสิทธิ์และเงื่อนไขที่กำหนด

สำหรับการจัดส่ง ผู้ช่วยมีหน้าที่แปลความต้องการ เช่น ใครเป็นผู้รับ ใช้ขนส่งใด และเก็บเงินเท่าไร เครื่องมือรับข้อมูลที่จัดรูปแล้ว ส่วนระบบจัดส่งต้องตรวจความถูกต้องและดำเนินงานตามกฎของบริการ ความคล่องในการสนทนาจึงไม่ได้รับประกันว่าที่อยู่ครบ หรือน้ำหนักที่ผู้ใช้บอกมีหน่วยถูกต้อง

MCP เป็นวิธีเชื่อมแอป AI เข้ากับเครื่องมือ ไม่ได้กำหนดเงื่อนไขจัดส่งแทนขนส่ง หรือทำให้คำสั่งทุกอย่างได้รับอนุญาตโดยอัตโนมัติ ทีมควรออกแบบขอบเขตของเครื่องมือให้ชัดว่าอ่านข้อมูลได้อย่างเดียว หรือสร้างรายการที่มีผลต่อยอดเงินได้ด้วย แล้วเลือกจุดตรวจทานให้เหมาะกับผลของการกระทำ

จากคำสั่งภาษาไทยสู่คำขอที่ตรวจสอบได้

ตัวอย่างตามข้อมูลในเดโมคือ “ส่งพัสดุให้คุณสมชาย ใจดี รหัสไปรษณีย์ 30000 โทร 081-234-5678 น้ำหนัก 1.5 กก. ผ่านขนส่ง A เก็บเงินปลายทาง 590 บาท” ชื่อ เบอร์โทร และข้อมูลทั้งหมดเป็นข้อมูลสมมติ ประโยคนี้บอกความต้องการได้ แต่ไม่ได้แสดงที่อยู่เต็ม จึงยังไม่ควรถูกใช้เป็นข้อมูลพร้อมจัดส่งจริง

ในแนวทางที่ควรออกแบบ ผู้ช่วยต้องแยกข้อมูลออกเป็นช่อง ตรวจสิ่งที่ขาด และขอให้ผู้ใช้เติมหรือยืนยันก่อนดำเนินงาน หากคำสั่งบอกเพียง “ส่งเหมือนครั้งก่อน” ก็ต้องระบุให้ได้ว่าหมายถึงรายการใด ไม่ควรเดาที่อยู่หรือนำยอด COD เก่ามาใช้โดยไม่มีบริบทเพียงพอ

เมื่ออธิบายการเรียก adaptership.create_shipment สามารถแสดงข้อมูลนำเข้าตามโครงสร้างเดโมได้ดังนี้ นี่เป็นตัวอย่างข้อมูลสำหรับเครื่องมือ ไม่ใช่ข้อความโปรโตคอล MCP ทั้งชุดหรือข้อกำหนดบริการจริงฉบับสมบูรณ์

{
  "carrier": "carrier_a",
  "to": {
    "name": "สมชาย ใจดี",
    "phone": "0812345678",
    "postcode": "30000"
  },
  "weight_kg": 1.5,
  "cod": 590
}

ผลตอบกลับจำลองแสดงเลขพัสดุ TH0123456789 และค่าจัดส่ง 32 บาท ค่านี้เป็นตัวอย่างจากข้อเสนอ ไม่ใช่ราคาที่คำนวณจากข้อมูลนำเข้า ผู้ช่วยในระบบจริงควรรายงานตามผลจากเครื่องมือ และแยกการสร้างรายการออกจากการที่ขนส่งรับพัสดุแล้ว ไม่เติมผลลัพธ์ที่ระบบยังไม่ได้ยืนยัน

ลองไล่ลำดับคำสั่ง ข้อมูล และคำตอบได้ที่ API Playground พร้อมตัวอย่าง MCP Server เดโมช่วยให้เห็นรูปแบบการทำงาน แต่ยังใช้ยืนยันความสามารถของระบบหลังบ้านไม่ได้ หากต้องการเข้าใจชั้นที่แปลงข้อมูลขนส่ง อ่าน API ขนส่งกลางสำหรับร้านค้าออนไลน์ ควบคู่กัน

วางเงื่อนไขก่อนให้ AI สร้างรายการ

ข้อเสนอของ AdapterShip ระบุแนวทางยืนยันตัวตนร้านค้า ชำระล่วงหน้าผ่าน Wallet ควบคุมสินค้าต้องห้าม และควบคุมการเรียก API ทีมที่นำ AI มาเกี่ยวข้องควรนำเงื่อนไขเหล่านี้ไปกำหนดการตรวจฝั่งระบบด้วย การเขียนกำชับไว้ในบทสนทนาอย่างเดียวไม่ควรเป็นกลไกอนุญาตให้สร้างรายการ

ยืนยันร้านค้าและข้อมูลที่จะใช้

ควรตรวจว่าคำขอเป็นของร้านใด ผู้ใช้นั้นมีสิทธิ์สร้างรายการหรือไม่ และข้อมูลผู้รับมาจากออเดอร์ที่เลือกจริงหรือไม่ ก่อนดำเนินงานให้แสดงสรุปผู้รับ ขนส่ง น้ำหนัก และ COD ในจุดที่ตรวจทานได้ การยืนยันนี้ควรอ้างถึงข้อมูลชุดที่จะส่ง หากแก้ข้อมูลสำคัญภายหลังควรตรวจทานใหม่

แยก Wallet ออกจากยอดเก็บเงินปลายทาง

Wallet ตามแนวคิดใช้ชำระล่วงหน้า ส่วน COD เป็นยอดที่ต้องเก็บจากผู้รับ จึงควรตรวจแยกกัน เมื่อยอดพร้อมใช้ไม่เพียงพอ ระบบที่ออกแบบควรหยุดตามเงื่อนไขที่ตกลงและแจ้งให้ผู้ดูแลจัดการ ไม่ให้ผู้ช่วยเปลี่ยนยอดหรือเติมเงินเองเพียงเพื่อทำงานต่อ ดูลำดับที่เกี่ยวข้องได้ที่ แนวทางสมัคร ยืนยันตัวตน และเติม Wallet

จำกัดคำขอและตรวจรายการซ้ำ

ข้อเสนอมีแนวทางจำกัดปริมาณคำขอและจัดเก็บสถานะตามข้อตกลงกับขนส่ง แต่ยังไม่มีค่า rate limit ตายตัว ทีมควรกำหนดวิธีหยุดรอและตรวจผลเดิมเมื่อการเรียกติดขัด โดยเฉพาะคำขอที่อาจสร้างรายการสำเร็จแล้วแต่คำตอบขาดหาย การสั่งให้ AI ลองใหม่ทันทีอาจทำให้เกิดรายการซ้ำ จึงต้องยืนยันกลไกป้องกันก่อนเชื่อมต่อจริง

เลือก MCP หรือ REST API ตามรูปแบบงาน

MCP เหมาะเป็นแนวทางเมื่อจุดเริ่มต้นของงานอยู่ในบทสนทนา เช่น ผู้ใช้ต้องอธิบายข้อมูลและให้ผู้ช่วยถามกลับก่อนเตรียมรายการ ประโยชน์อยู่ที่การเชื่อมความต้องการภาษาคนเข้ากับเครื่องมือที่กำหนดขอบเขตแล้ว โดยยังต้องออกแบบหน้าตรวจทานและการจัดการข้อผิดพลาด

REST API เหมาะกว่าเมื่อข้อมูลออเดอร์อยู่ในระบบครบและมีเงื่อนไขเริ่มงานแน่นอน เช่น พนักงานยืนยันแพ็กเสร็จแล้วให้ระบบส่งข้อมูลจากออเดอร์ที่เลือก นักพัฒนาสามารถกำหนดฟิลด์และลำดับการเรียกตรง ๆ โดยไม่ต้องให้โมเดลตีความคำสั่งทุกครั้ง ทั้งสองแนวทางควรใช้กฎตรวจข้อมูลเดียวกัน

หากทีมดูแล POS/ERP หลายร้าน ควรกำหนดบัญชีและสิทธิ์ก่อนเลือกช่องทางเรียก อ่าน เช็กลิสต์ POS/ERP สำหรับที่อยู่ สถานะ และ Wallet แล้วเทียบกับ แนวทางบัญชีหลักและความร่วมมือกับขนส่ง รูปแบบ sub-account ต้องตกลงกับขนส่ง ไม่ควรถือว่าเพิ่มเครื่องมือให้ AI แล้วจะเข้าถึงได้ทุกร้าน

ทดลองขอบเขตให้ครบก่อนวางงานอัตโนมัติ

เริ่มด้วยข้อมูลสมมติที่ครบหนึ่งรายการ แล้วลองตัดเบอร์โทร เปลี่ยนหน่วยน้ำหนัก หรือใช้ข้อความกำกวม ผลที่ต้องการตรวจคือผู้ช่วยรู้ว่าต้องถามอะไร และระบบปฏิเสธข้อมูลที่ไม่ผ่านได้อย่างชัดเจน จากนั้นลองกรณีผู้ใช้เปลี่ยนใจก่อนยืนยัน เพื่อดูว่าคำขอที่ส่งยังตรงกับความตั้งใจล่าสุดหรือไม่

เมื่อเครื่องมือไม่ตอบกลับ ผู้ช่วยควรแจ้งว่ายังไม่ทราบผลและเก็บเลขอ้างอิงให้ผู้ดูแลตามต่อได้ โดยลดข้อมูลผู้รับในบันทึกให้เหลือเท่าที่ใช้แก้ปัญหา

ก่อนประเมินต้นทุน ให้ตรวจ รายละเอียดแพ็กเกจตามข้อเสนอ โดยอัตราค่าบริการต่อรายการยังไม่ได้ระบุ และการทดลองใน Preview ไม่ใช่หลักฐานว่าระบบพร้อมรับคำขอจริง

สรุป

  • MCP Server เปิดเครื่องมือให้แอปผู้ช่วย AI เรียกใช้ โดยระบบปลายทางยังต้องตรวจข้อมูลและสิทธิ์ก่อนสร้างรายการ
  • ใช้ตัวอย่างภาษาไทยเพื่อไล่การแปลงข้อมูล พร้อมตรวจ Wallet ตัวตนร้านค้า ขอบเขตคำขอ และผลที่ยังไม่แน่นอน
  • เลือก MCP เมื่องานเริ่มจากบทสนทนา และพิจารณา REST API เมื่อต้นทางมีข้อมูลกับลำดับงานที่กำหนดไว้แล้ว