MCP กับ Function Calling: ควรเลือกแบบไหนตอนออกแบบ Agent ตัวใหม่

ทีมพัฒนาที่เคยเขียน MCP คืออะไร อ่านจบแล้วมักถามคำถามต่อทันทีว่า แล้วมันต่างจาก Function Calling ที่ใช้อยู่แล้วตรงไหน เพราะทั้งสองอย่างพูดถึงเรื่องเดียวกันคือให้ AI เรียกใช้เครื่องมือภายนอกได้ คำถามนี้พบบ่อยมากจนกลายเป็นจุดสับสนอันดับต้น ๆ ของคนที่เพิ่งเริ่มศึกษา MCP

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

บทความนี้แยกให้เห็นความต่างในทางปฏิบัติ พร้อมตัวอย่างสถานการณ์ที่ควรใช้ Function Calling ตรง ๆ และสถานการณ์ที่ MCP คุ้มค่ากว่า เพื่อให้ตัดสินใจได้เร็วขึ้นตอนเริ่มออกแบบระบบใหม่

Function Calling แบบดั้งเดิมทำงานอย่างไร

Function Calling คือความสามารถที่ผู้ให้บริการโมเดลเปิดให้นักพัฒนาส่ง schema ของฟังก์ชันที่มีอยู่เข้าไปพร้อมกับ Prompt เมื่อโมเดลประมวลผลแล้วเห็นว่าควรเรียกฟังก์ชันใดฟังก์ชันหนึ่งเพื่อตอบคำถาม มันจะส่งกลับมาเป็นโครงสร้างข้อมูลที่บอกชื่อฟังก์ชันและ Argument ที่ควรใช้ จากนั้นตัวแอปพลิเคชันฝั่งนักพัฒนาต้องเป็นคนเรียกฟังก์ชันจริงเอง แล้วส่งผลลัพธ์กลับไปให้โมเดลอ่านต่อ

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

MCP เพิ่มอะไรเข้ามาจาก Function Calling ที่มีอยู่แล้ว

MCP ไม่ได้เปลี่ยนวิธีที่โมเดลตัดสินใจเรียกฟังก์ชัน มันยังใช้กลไก Function Calling เดิมของแต่ละโมเดลอยู่ข้างใน สิ่งที่ MCP เพิ่มเข้ามาคือชั้นมาตรฐานสำหรับ 'ห่อหุ้มและส่งต่อ' Tool เหล่านั้น ผ่านสถาปัตยกรรม MCP Server ที่เปิดให้ Client หลายตัวเชื่อมต่อได้โดยไม่ต้องรู้จัก schema เฉพาะของโมเดลแต่ละเจ้า

พูดง่าย ๆ คือ MCP ทำให้ทีมพัฒนาเขียน Tool ครั้งเดียวในรูปแบบมาตรฐาน แล้ว Host หรือ Client ตัวไหนก็ตามที่รองรับ MCP จะแปลง Tool นั้นเป็น Function Calling schema ของโมเดลที่ตัวเองใช้อยู่โดยอัตโนมัติ ทีมพัฒนาไม่ต้องเขียน schema แยกทุกครั้งที่เปลี่ยนโมเดลหรือเพิ่ม Host ใหม่

เทียบสถาปัตยกรรมแบบเห็นภาพ Function Calling ตรง ๆ กับผ่าน MCP

ความต่างที่ชัดที่สุดอยู่ที่จำนวนจุดที่ต้องเขียนโค้ดเชื่อมต่อ เมื่อจำนวนโมเดลและจำนวนระบบที่ต้องเชื่อมเพิ่มขึ้น:

เมื่อไรใช้ Function Calling ตรง ๆ ก็เพียงพอแล้ว

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

ตัวอย่างสมมติ: ทีมสร้าง Prototype ภายในสองสัปดาห์เพื่อทดสอบว่า AI ช่วยตอบคำถามพนักงานเรื่องนโยบายบริษัทได้ดีแค่ไหน มีฟังก์ชันเดียวคือค้นหาเอกสารนโยบาย กรณีนี้เขียน Function Calling ตรง ๆ เข้ากับโมเดลตัวที่ใช้อยู่ ใช้เวลาน้อยกว่าการตั้ง MCP Server แยกต่างหากมาก

เมื่อไร MCP เริ่มคุ้มค่ากว่าการเขียน Function Calling แยกทุกจุด

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

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

ใช้ทั้งสองอย่างร่วมกันได้จริงหรือไม่ ในทางปฏิบัติเป็นอย่างไร

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

สิ่งที่นักพัฒนาต้องเข้าใจคือ MCP เปลี่ยนวิธี 'จัดการและแชร์' Tool ไม่ได้เปลี่ยนวิธีที่โมเดลตัดสินใจว่าจะเรียก Tool ไหนตอนไหน การตัดสินใจนั้นยังเป็นเรื่องของความสามารถ Function Calling ของตัวโมเดลเองอยู่เหมือนเดิม

ดีบักและตรวจสอบพฤติกรรมยากขึ้นหรือง่ายขึ้นเมื่อเปลี่ยนมาใช้ MCP

อีกมิติที่ทีมพัฒนามักลืมพิจารณาก่อนตัดสินใจคือความยากง่ายในการดีบักเมื่อ Agent เรียก Tool ผิดจังหวะ ตอนใช้ Function Calling ตรง ๆ ทีมเห็นทุกจุดในโค้ดฝั่งตัวเองว่าเรียกฟังก์ชันไหนด้วย Argument อะไร เพราะทุกอย่างอยู่ในโปรเจกต์เดียวกัน การไล่ Log ย้อนหลังจึงทำได้ตรงไปตรงมา

พอเปลี่ยนมาใช้ MCP การเรียก Tool จะผ่าน Client และ Server แยกกันคนละ Process หรือบางกรณีแยกคนละเครื่องเลย ทำให้ต้องมีเครื่องมือหรือ Log แยกต่างหากที่ฝั่ง Server เพื่อดูว่า Request ที่เข้ามาจริงคืออะไร ทีมที่ยังไม่ได้เตรียม Log ฝั่ง Server ให้ละเอียดพอ มักเจอปัญหาดีบักยากขึ้นในช่วงแรกที่ย้ายมาใช้ MCP เมื่อเทียบกับตอนที่ทุกอย่างอยู่ในโค้ดชุดเดียว

ข้อดีที่แลกมาคือเมื่อ Log ฝั่ง Server ถูกวางไว้ดีตั้งแต่ต้น ทีมจะเห็นภาพการเรียก Tool จากทุก Host ที่เชื่อมเข้ามาในที่เดียวกัน ต่างจาก Function Calling ที่ Log กระจายอยู่คนละโปรเจกต์ตามแต่ละ Agent ที่เขียนแยกกัน การรวมศูนย์ Log แบบนี้ช่วยได้มากเมื่อมี Host หลายตัวที่ต้องดูแลพร้อมกัน แม้จะต้องลงทุนตั้งค่าระบบ Log เพิ่มตั้งแต่ต้นก็ตาม

ถ้ามี Function Calling อยู่แล้ว ควรย้ายมาใช้ MCP ไหมและต้องระวังอะไร

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

1. ไล่ดูว่าฟังก์ชันไหนถูกเรียกซ้ำจากมากกว่าหนึ่ง Agent หรือ Host แล้วเริ่มย้ายเฉพาะกลุ่มนั้นก่อน ไม่ต้องย้ายทั้งระบบพร้อมกัน
2. ทดสอบว่า Tool ที่ย้ายมาเป็น MCP Server แล้วยังทำงานเหมือนเดิมทุกกรณี ก่อนปิดของเดิมที่ใช้อยู่
3. เก็บ Function Calling แบบเดิมไว้สำหรับ Use Case เฉพาะกิจที่ไม่ได้แชร์กับใคร ไม่ต้องบังคับทุกอย่างเข้า MCP

ทำแบบนี้แล้วพัง เพราะ… ความเข้าใจผิดที่พบบ่อยระหว่างสองแนวคิดนี้

หลายทีมตัดสินใจผิดเพราะเข้าใจความสัมพันธ์ระหว่าง MCP กับ Function Calling ไม่ครบ ต่อไปนี้คือความเข้าใจผิดที่พบบ่อยที่สุด

• คิดว่าต้องเลือกอย่างใดอย่างหนึ่ง ทำแบบนี้แล้วพัง เพราะเสียเวลาถกเถียงกันในทีมโดยไม่จำเป็น ทั้งที่ MCP ใช้ Function Calling อยู่ข้างในอยู่แล้ว ไม่ใช่คู่แข่งกัน
• ตั้ง MCP Server สำหรับ Agent เดี่ยวที่ไม่มีแผนขยาย ทำแบบนี้แล้วพัง เพราะแบกภาระดูแลโปรโตคอลเพิ่มโดยไม่ได้ประโยชน์จากการแชร์ Tool ข้าม Host เลย
• ย้ายทุกฟังก์ชันเข้า MCP พร้อมกันทีเดียวโดยไม่ทดสอบทีละกลุ่ม ทำแบบนี้แล้วพัง เพราะถ้ามีจุดที่พฤติกรรมเปลี่ยนไปหลังย้าย จะหาสาเหตุยากเนื่องจากเปลี่ยนพร้อมกันหมดทุกจุด
• คิดว่าเปลี่ยนมาใช้ MCP แล้วโมเดลจะเรียก Tool แม่นขึ้นเอง ทำแบบนี้แล้วพัง เพราะความแม่นในการเลือก Tool ยังขึ้นกับความสามารถ Function Calling ของโมเดลเหมือนเดิม MCP แค่ช่วยเรื่องการจัดการและแชร์ Tool เท่านั้น

สรุป

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

ก่อนตัดสินใจ ควรนับดูก่อนว่ามีกี่ Agent และกี่ Host ที่ต้องเชื่อมกับระบบเดียวกันจริง ถ้ามีมากกว่าหนึ่งคู่ที่ซ้ำกัน MCP มักคุ้มค่ากับเวลาที่ลงทุนตั้งค่าเพิ่ม ถ้ามีจุดเดียวการเขียน Function Calling ตรง ๆ ยังเป็นทางเลือกที่เร็วและง่ายกว่า

• Function Calling คือกลไกที่โมเดลใช้ตัดสินใจเรียกฟังก์ชัน MCP คือมาตรฐานที่ครอบอยู่บนกลไกนี้เพื่อจัดการและแชร์ Tool
• MCP คุ้มค่าเมื่อมีมากกว่าหนึ่ง Agent หรือ Host ที่ต้องเชื่อมระบบเดียวกัน โปรเจกต์เดี่ยวเล็ก ๆ ใช้ Function Calling ตรง ๆ ได้เร็วกว่า
• ทั้งสองอย่างทำงานร่วมกันเสมอในทางปฏิบัติ ไม่ใช่ต้องเลือกอย่างใดอย่างหนึ่งแล้วทิ้งอีกอย่าง
• ย้ายจาก Function Calling ไป MCP ควรทำทีละกลุ่มตามจุดที่มีการเรียกซ้ำจริง ไม่ต้องย้ายทั้งระบบพร้อมกัน

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