การจัดการข้อผิดพลาดของ MCP Server: สิ่งที่ผมได้เรียนรู้
ผมคิดว่าผมทำสำเร็จแล้วหลังจากที่ MCP server ของผมรันได้เป็นครั้งแรก มันส่งรายการเครื่องมือ (tool list) กลับมา มันเรียกใช้เครื่องมือได้ ผมรู้สึกว่าตัวเองทำสำเร็จแล้ว
แต่ผมคิดผิด
การรัน MCP server ในสภาพแวดล้อมจริง (production) สอนให้ผมรู้ว่าบทเรียนส่วนใหญ่มักจะเน้นไปที่ "happy path" (เส้นทางที่ทุกอย่างราบรื่น) แต่พวกเขามักจะมองข้ามสิ่งที่เกิดขึ้นเมื่อมีบางอย่างผิดพลาด นี่คือสิ่งที่ผมได้เรียนรู้ระหว่างการสร้าง server สำหรับฐานความรู้ (knowledge base) ขนาด 1,800 ชั่วโมงของผม
ส่งเนื้อหากลับเสมอแม้ผลลัพธ์จะว่างเปล่า Client ส่วนใหญ่มักจะค้างเมื่อได้รับคำตอบที่ว่างเปล่า หากการค้นหาของคุณไม่พบอะไรเลย อย่าส่งค่าว่างกลับไป แต่ให้ส่งข้อความตัวอักษรแทน บอกผู้ใช้ว่าทำไมถึงไม่มีผลลัพธ์ และมีข้อมูลอยู่กี่รายการในฐานข้อมูลของคุณ
จัดการกับการเริ่มต้นการเชื่อมต่อที่ล่าช้า ผมโฮสต์บน free tier ที่มีระบบ sleep เมื่อมันตื่นขึ้นมาต้องใช้เวลาถึง 15 วินาที ซึ่ง MCP client หลายตัวมักจะหมดเวลา (timeout) ไปก่อนหน้านั้น • ส่ง header ล่วงหน้าเพื่อรักษาการเชื่อมต่อให้ยังคงอยู่ (keep the connection alive) • กำหนดขีดจำกัดของขนาดการตอบกลับ (response size) ให้ชัดเจน ตัดทอนผลลัพธ์ที่มีขนาดใหญ่เกินไปเพื่อไม่ให้เกิดปัญหา timeout
เลิกสร้าง JSON ด้วยตัวเอง แค่เครื่องหมายอัญประกาศคู่ (double quote) ที่ไม่ได้ทำ escaping เพียงตัวเดียวในชื่อหัวข้อ ก็ทำให้ JSON response ทั้งหมดพังได้ และ client ก็ตัดการเชื่อมต่อโดยไม่มีการแจ้งข้อผิดพลาดใดๆ ควรใช้ framework อย่าง Jackson ในการจัดการ serialization และปล่อยให้ library จัดการเรื่องการ escaping ให้คุณ
เตรียมรับมือกับการยืนยันตัวตน (authentication) ที่ไม่เหมือนกัน Client แต่ละตัวจัดการ API key ต่างกัน บางตัวใช้ headers บางตัวใช้ query parameters และบางตัวก็ไม่ใช้เลย • รองรับวิธีการส่ง key หลายรูปแบบ • ส่ง JSON error body ที่ถูกต้องเสมอหากการยืนยันตัวตนล้มเหลว
กำหนด Content-Length ให้ชัดเจน Client บางตัวมีปัญหากับ chunked encoding หากการตอบกลับของคุณถูกตัดทอน ให้หยุดใช้การบีบอัดข้อมูล (compression) แล้วคำนวณขนาดการตอบกลับล่วงหน้าและกำหนด header Content-Length ให้ชัดเจน
ข้อดี: • ความเป็นส่วนตัว: ส่งเฉพาะข้อมูลส่วนที่เกี่ยวข้องไปยัง AI เท่านั้น • การทำงานร่วมกัน: Server สามารถทำงานร่วมกับ client ที่หลากหลายได้ • ความเรียบง่าย: Server ของผมมีโค้ดเพียง 150 บรรทัดเท่านั้น
ข้อเสีย: • ระบบนิเวศที่ยังใหม่: เอกสารประกอบยังขาดข้อมูลในกรณีพิเศษ (edge cases) มากมาย • การโฮสต์: คุณต้องจัดการ endpoint และปัญหา cold starts ด้วยตัวเอง • การพัฒนา: โปรโตคอลมีการเปลี่ยนแปลงบ่อยครั้ง
MCP เปลี่ยนโน้ตที่ไม่ได้ใช้งานของผมให้กลายเป็นเครื่องมือที่มีประโยชน์ มันทำให้ข้อมูลของผมพร้อมใช้งาน เพื่อให้ AI สามารถจัดการงานหนักๆ แทนได้
คุณเคยสร้าง MCP server บ้างไหม? คุณพบข้อผิดพลาดอะไรบ้าง? บอกผมได้ในคอมเมนต์นะครับ
Optional learning community: https://t.me/GyaanSetuAi