ต้องเขียน MCP Server เองทุกครั้งไหม หรือใช้ตัวสำเร็จรูปได้เลย

คำถามที่พบบ่อยที่สุดหลังทีมพัฒนาเข้าใจภาพรวมของ MCP แล้วคือ 'แล้ว MCP Server ต้องเขียนเองแค่ไหน' บางคนคิดว่ามันคือ REST API ที่เปลี่ยนชื่อ บางคนคิดว่าต้องเขียนใหม่ทั้งหมดตั้งแต่ศูนย์ ทั้งสองความเข้าใจไม่ตรงกับความจริงเสียทีเดียว

ความจริงคือ MCP Server ส่วนใหญ่ที่ทีมพัฒนาองค์กรเขียนกันจริง ไม่ใช่ระบบใหม่ แต่เป็น 'ชั้นครอบ' (wrapper) บาง ๆ ที่ห่อ API หรือฐานข้อมูลที่มีอยู่แล้ว ให้พูดภาษาที่ AI Agent เข้าใจ งานหลักจึงไม่ใช่การเขียน Logic ธุรกิจใหม่ แต่คือการออกแบบว่าจะเปิดอะไรให้ AI เรียกได้ และปิดอะไรไว้ไม่ให้แตะ

บทความนี้จะแยกให้ชัดว่า MCP Server คืออะไรกันแน่ในทางเทคนิค ต่างจาก REST API และ Function Calling ตรงไหน มีส่วนประกอบอะไรบ้างข้างใน และควรเริ่มเขียนอย่างไรให้ไม่ต้องรื้อทิ้งภายหลัง

MCP Server คือโปรแกรมประเภทไหนกันแน่

พูดให้ตรงที่สุด MCP Server คือโปรแกรมฝั่งเซิร์ฟเวอร์ที่ทำสามหน้าที่หลัก คือเปิด Tool ให้ AI เรียกทำงาน เปิด Resource ให้ AI อ่านเป็นบริบท และเปิด Prompt Template ให้ผู้ใช้เลือกใช้ซ้ำ โดยสื่อสารกับฝั่ง Client ผ่านรูปแบบข้อความมาตรฐานที่ MCP กำหนดไว้ ไม่ว่าจะเขียนด้วยภาษาโปรแกรมมิ่งอะไรก็ตาม

จุดที่ทำให้มันต่างจากโปรแกรม Backend ทั่วไปคือ MCP Server ไม่ได้ออกแบบมาให้มนุษย์เรียกตรง ๆ ผ่านหน้าเว็บ แต่ออกแบบมาให้ AI Agent เป็นผู้เรียก ซึ่งหมายความว่าการตั้งชื่อ Tool คำอธิบาย และรูปแบบ Input ต้องเขียนให้โมเดลภาษาเข้าใจเจตนาได้ง่าย ไม่ใช่แค่ให้ระบบ Compile ผ่าน

ต่างจาก REST API ทั่วไปตรงไหน

REST API ถูกออกแบบมาให้นักพัฒนาอ่านเอกสารก่อนแล้วเขียนโค้ดเรียก Endpoint ที่รู้ล่วงหน้าอยู่แล้วว่ามีอะไรบ้าง ส่วน MCP Server เปิดกลไก 'Discovery' ให้ AI Client ถามเองได้ว่า Server นี้มี Tool อะไรให้เรียกบ้าง โดยไม่ต้องมีใครไปอ่านเอกสารแล้วเขียนโค้ดผูกไว้ล่วงหน้า

อีกจุดต่างคือ REST API มักออกแบบตาม Resource เช่น GET /orders/123 ส่วน MCP Server ออกแบบตาม 'เจตนา' เช่น Tool ชื่อ get_order_status ที่อธิบายด้วยภาษาธรรมชาติว่าทำอะไร รับ Input แบบไหน เพราะเป้าหมายปลายทางคือให้โมเดลเลือกเรียกถูกตัวจากคำอธิบาย ไม่ใช่ให้นักพัฒนาเลือกจาก URL Pattern

ข้างในของ MCP Server ตัวหนึ่งประกอบด้วยอะไรบ้าง

โครงสร้างภายในของ MCP Server ที่ทีมพัฒนาส่วนใหญ่เจอมีสี่ชั้นหลัก ไล่จากชั้นสื่อสารไปจนถึงชั้น Logic ธุรกิจจริง แต่ละชั้นมีหน้าที่ชัดเจนและควรแยกออกจากกันเพื่อให้ดูแลง่าย:

ตัวอย่างสมมติ: เขียน MCP Server ครอบระบบตั๋วงานภายในทีม

สมมติทีมพัฒนาต้องการให้ AI ผู้ช่วยในเครื่องมือพัฒนาช่วยตอบว่า 'ตั๋วงานเลขที่ 4521 ใครรับผิดชอบอยู่' ได้โดยไม่ต้องสลับหน้าจอไปเปิดระบบตั๋วงาน (ชื่อระบบและตัวเลขเป็นตัวอย่างประกอบเท่านั้น) ขั้นตอนคร่าว ๆ ที่เกิดขึ้นคือ ทีมเขียน Tool ชื่อ get_ticket_detail รับ Parameter เป็นเลขตั๋ว แล้วในโค้ดจริงก็แค่เรียก API ของระบบตั๋วงานเดิมที่มีอยู่แล้ว ไม่ต้องสร้างฐานข้อมูลใหม่

จุดที่ต้องตัดสินใจคือจะเปิด Tool แค่ 'อ่าน' อย่างเดียว หรือจะเปิดให้ 'แก้ไข' สถานะตั๋วได้ด้วย ทีมส่วนใหญ่ที่เพิ่งเริ่มมักเลือกเปิดเฉพาะ Tool ที่อ่านข้อมูลก่อน เพราะควบคุมความเสี่ยงได้ง่ายกว่า แล้วค่อยขยายไปเปิด Tool ที่เขียนข้อมูลเมื่อมั่นใจในพฤติกรรมของ Agent มากขึ้น เรื่องนี้เกี่ยวโยงโดยตรงกับการออกแบบสิทธิ์ที่อธิบายไว้ใน ความเสี่ยงด้าน Security ของ MCP

เลือก Transport แบบไหน Local หรือ Remote

MCP Server แบบ Local มักรันบนเครื่องเดียวกับ Host สื่อสารผ่าน stdio เหมาะกับงานที่ต้องเข้าถึงไฟล์ในเครื่องหรือเครื่องมือพัฒนาส่วนตัว ส่วน MCP Server แบบ Remote รันอยู่บนเซิร์ฟเวอร์กลาง สื่อสารผ่าน HTTP หรือ SSE เหมาะกับงานที่ต้องให้หลายคนหรือหลาย Agent เรียกใช้ Server ตัวเดียวกันพร้อมกัน

การเลือกผิดตั้งแต่ต้นทำให้ต้องย้ายระบบทีหลังโดยไม่จำเป็น เช่น เขียนเป็น Local Server ไปก่อนแล้วพบว่าต้องเปิดให้ทีมอื่นเรียกใช้ด้วย ก็ต้องย้ายไปทำ Remote Server ที่ต้องคิดเรื่อง Authentication เพิ่มเข้ามา รายละเอียดของการตั้งค่าฝั่ง Remote อยู่ใน Remote MCP คืออะไร และเรื่อง Auth อยู่ใน MCP OAuth

ทำไม MCP Server ต้องมี Log การเรียก Tool ทุกครั้ง

จุดที่ทีมพัฒนามือใหม่มักมองข้ามคือการเก็บ Log ว่า Tool ไหนถูกเรียกเมื่อไร ด้วย Input อะไร และคืนผลลัพธ์แบบไหน เพราะตอนเขียน MCP Server ครั้งแรก โฟกัสมักอยู่ที่ทำให้ Tool ทำงานได้ก่อน แต่พอเริ่มมีผู้ใช้จริงหลายคน การไม่มี Log ทำให้ตรวจสอบปัญหาย้อนหลังแทบไม่ได้เลยว่าทำไม Agent ถึงตอบผิดหรือทำไม Tool ถึง Error

ตัวอย่างสมมติ: ทีมพัฒนาเปิด Tool ชื่อ update_ticket_status ให้ AI เรียกได้ วันหนึ่งมีผู้ใช้แจ้งว่าตั๋วงานเลขที่ 9902 ถูกเปลี่ยนสถานะเป็น 'ปิดงาน' ทั้งที่ยังไม่เสร็จ ถ้า Server มี Log ทีมจะเห็นได้ทันทีว่า Agent เรียก Tool นี้เมื่อเวลาใด ด้วย Parameter ตัวไหน มาจาก Session ของใคร และสามารถสืบย้อนไปดู Prompt ที่ทำให้โมเดลตัดสินใจแบบนี้ได้ แต่ถ้าไม่มี Log เลย ทีมจะรู้แค่ว่าผลลัพธ์ผิด โดยไม่รู้ต้นเหตุ

ระดับ Log ที่ควรมีอย่างน้อยคือ ชื่อ Tool ที่ถูกเรียก เวลาเรียก Input ที่ส่งเข้ามา ผลลัพธ์หรือ Error ที่คืนกลับ และตัวตนของ Session หรือผู้ใช้ที่เกี่ยวข้อง ข้อมูลชุดนี้ไม่ได้ซับซ้อน แต่มีผลมากตอนต้องไล่ Debug ปัญหาที่เกิดจากพฤติกรรมของโมเดลซึ่งคาดเดาไม่ได้แน่นอนเหมือนโค้ดทั่วไป

เมื่อไรควรเขียนเอง เมื่อไรควรใช้ Server สำเร็จรูป

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

1. ตรวจสอบก่อนว่าระบบที่จะเชื่อมมี MCP Server สำเร็จรูปในวงการหรือยัง ถ้ามีให้ทดลองใช้ก่อนตัดสินใจเขียนเอง
2. ถ้าต้องเขียนเอง เริ่มจาก Tool เดียวที่ใช้บ่อยที่สุดก่อน ไม่ใช่พยายามครอบ API ทั้งหมดในรอบเดียว
3. เขียนคำอธิบาย Tool ให้ชัดเจนเหมือนอธิบายให้เพื่อนร่วมทีมที่ไม่เคยเห็นระบบนี้มาก่อนเข้าใจ เพราะโมเดลอ่านคำอธิบายนี้ตัดสินใจว่าจะเรียกหรือไม่เรียก
4. ทดสอบกับ MCP Client จริงก่อนปล่อยให้ทีมอื่นใช้ เพื่อดูว่าโมเดลเลือกเรียก Tool ถูกจังหวะหรือไม่

ทำไมเขียน Server ครั้งเดียวถึงคุ้มกว่า Function Calling แยกทีมโมเดล

ถ้าทีมพัฒนาเขียน Function Calling ตรง ๆ ผูกกับโมเดลเจ้าใดเจ้าหนึ่ง เมื่อวันหนึ่งอยากลองสลับไปใช้โมเดลอีกเจ้า หรือเพิ่ม Host ตัวใหม่เข้ามา ก็ต้องเขียน Integration ใหม่อีกรอบ เพราะรูปแบบ Schema ของแต่ละเจ้าไม่เหมือนกัน แต่ MCP Server ตัวเดียวที่เขียนตามสเปกกลาง ใช้ได้กับ Host ไหนก็ได้ที่มี MCP Client รองรับ ไม่ต้องแก้โค้ดฝั่ง Server เลย

ข้อดีนี้ยิ่งเห็นชัดขึ้นเมื่อองค์กรมีมากกว่าหนึ่งทีมที่อยากใช้ AI เข้าถึงระบบเดียวกัน เช่น ทีมขายอยากให้ AI ช่วยเช็คสต็อกสินค้า ทีมบัญชีอยากให้ AI ช่วยเช็คยอดค้างชำระ ถ้าทั้งสองทีมเรียก MCP Server ตัวเดียวกันที่ครอบระบบ ERP ไว้ ก็ไม่ต้องมีใครเขียน Integration ซ้ำ เพียงแค่ตั้งค่าสิทธิ์การเข้าถึงให้เหมาะกับแต่ละทีม

ทำแบบนี้แล้วพัง เพราะ… ข้อผิดพลาดตอนเขียน MCP Server ครั้งแรก

ทีมที่เขียน MCP Server ตัวแรกมักเจอปัญหาคล้ายกันไม่กี่แบบ เพราะยังไม่คุ้นกับการออกแบบที่ต้องคิดถึงมุมมองของโมเดล ไม่ใช่แค่มุมมองของนักพัฒนา

• ตั้งชื่อ Tool กำกวมเกินไป เช่นตั้งว่า process_data โดยไม่บอกว่าประมวลผลอะไร ทำแบบนี้แล้วพัง เพราะโมเดลแยกไม่ออกว่าควรเรียก Tool นี้เมื่อไร ควรตั้งชื่อให้สื่อเจตนาตรงตัว เช่น get_order_status หรือ create_support_ticket
• คืนค่า Error แบบข้อความคลุมเครือ เช่นแค่ 'เกิดข้อผิดพลาด' โดยไม่บอกสาเหตุ ทำแบบนี้แล้วพัง เพราะโมเดลไม่รู้จะแก้ไขหรืออธิบายให้ผู้ใช้ยังไง ควรคืนโครงสร้าง Error ที่ระบุสาเหตุชัดเจนพอให้โมเดลตัดสินใจขั้นต่อไปได้
• ไม่จำกัดขนาดข้อมูลที่คืนกลับ เช่น Tool ค้นหาคืนรายการนับพันแถวในครั้งเดียว ทำแบบนี้แล้วพัง เพราะกิน Context ของโมเดลจนตอบช้าหรือหลุดประเด็น ควรใส่ Pagination หรือจำกัดจำนวนผลลัพธ์ตั้งแต่ในโค้ด Server
• ผสม Business Logic กับ Protocol Handler ไว้ในไฟล์เดียว ทำแบบนี้แล้วพัง เพราะพอสเปก MCP อัปเดตเวอร์ชัน การแก้โค้ดจะกระทบ Logic ธุรกิจที่ไม่เกี่ยวข้องไปด้วย ควรแยกชั้น Business Logic ออกจากชั้น Protocol ตั้งแต่ต้น

สรุป

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

ทีมที่เพิ่งเริ่มควรเลือกระบบเสี่ยงต่ำและ Tool น้อยตัวก่อน ทดสอบให้มั่นใจว่าโมเดลเรียกใช้ถูกจังหวะ ก่อนขยายไปยังระบบที่มีข้อมูลสำคัญกว่า และควรแยกชั้น Protocol กับชั้น Business Logic ออกจากกันตั้งแต่แรกเพื่อให้ดูแลง่ายในระยะยาว

• MCP Server คือฝั่งที่เปิด Tool/Resource/Prompt ให้ AI Agent เรียกผ่านโปรโตคอลมาตรฐาน ไม่ใช่ REST API ที่เปลี่ยนชื่อ
• ส่วนใหญ่เป็นชั้นครอบระบบเดิมที่มีอยู่แล้ว ไม่ใช่การสร้างระบบใหม่ทั้งหมด
• ก่อนเขียนเอง ควรเช็คว่ามี Server สำเร็จรูปสำหรับระบบนั้นอยู่แล้วหรือไม่
• แยกชั้น Transport, Protocol Handler และ Business Logic ออกจากกันเพื่อดูแลง่ายเมื่อสเปกอัปเดต

คำถามที่พบบ่อย