Tool Calling และ MCP คืออะไร? ให้ Chatbot เรียก API อย่างปลอดภัย

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

ข้อสำคัญที่สุดสำหรับผู้พัฒนาคือ โมเดลไม่ได้รับสิทธิ์เรียกทุก API เพียงเพราะสร้างข้อความ Tool Call ได้ โปรแกรม Backend ต้องตัดสินใจว่าจะให้รันหรือไม่ ตรวจประเภทและขอบเขต Argument ยืนยันตัวตน และบันทึกผลลัพธ์จริง

หน้านี้เน้นกลไกเชื่อมต่อเครื่องมือ หากสนใจว่า Chatbot กับ Agent ต่างกันอย่างไร อ่าน Chatbot vs AI Agent และถ้าต้องวางระบบทั้งหมด อ่าน Chatbot Architecture

Function Calling ส่ง Arguments และรับผลอย่างไร

ตัวอย่างสมมติ: ลูกค้าถาม “สถานะคำสั่งซื้อของฉันเป็นอย่างไร” แอปประกาศ Tool getOrderStatus พร้อม Input Schema ที่ระบุช่องข้อมูลที่ต้องใช้ โมเดลอาจตอบเป็นคำขอเรียก Tool แทนการสร้างคำตอบสุดท้าย

กระบวนการโดยย่อ:

1. แอปส่งข้อความผู้ใช้พร้อมคำอธิบายเครื่องมือที่อนุญาตไปให้โมเดล
2. โมเดลอาจเลือกเสนอ getOrderStatus({ orderId: "ORD-DEMO" }) พร้อม Arguments ตามรูปแบบที่กำหนด
3. Backend ตรวจสิทธิ์ลูกค้า ว่าเป็นเจ้าของ Order และตรวจรูปแบบ ID ก่อนเรียก API จริง
4. API คืนสถานะที่ตรวจสอบได้ หรือเหตุผลที่อ่านไม่ได้
5. แอปส่งผล Tool กลับไปให้โมเดลช่วยสรุป โดยแยกให้ชัดว่าดำเนินการสำเร็จหรือไม่

ลูกค้า → Chat UI → Backend → Model
                           |
                     Tool-call proposal
                           |
Backend: Validate + Authorize + Execute → Business API
                           |
                      Tool result
                           |
                        Model → คำตอบที่แสดง

แผนภาพนี้เป็นแนวคิด ไม่ใช่ตัวอย่างระบบ Production ที่เชื่อม Order จริง

ตาม OpenAI Function Calling โปรแกรมต้องจัดการวงจรของ Tool Call และผลลัพธ์อย่างถูกต้อง รวมถึงข้อกำหนดรูปแบบของ API ที่ใช้งานในเวอร์ชันนั้น

ทำไม JSON Schema อย่างเดียวไม่เพียงพอ

Schema ช่วยตรวจว่า Argument เป็นชนิดและรูปแบบที่คาดหวัง เช่น orderId ต้องเป็นข้อความ ไม่ใช่ Array และไม่มีฟิลด์ส่วนเกิน แต่มันไม่ตอบว่า ผู้ใช้คนนี้มีสิทธิ์อ่าน Order นั้นหรือไม่

สมมติผู้ใช้ส่ง ID ของคนอื่น แม้จะผ่าน Schema ทุกเงื่อนไข Backend ก็ต้องปฏิเสธตาม Authorization ที่ตรวจจาก Session/Token จริง และห้ามให้โมเดลตัดสินสิทธิ์จากข้อความ “ฉันเป็นเจ้าของรายการนี้”

จุดตรวจ	ตรวจอะไร	ความเสี่ยงถ้าขาด
Parameter schema	ชนิด ค่าที่อนุญาต และความยาว	เรียก API ด้วยข้อมูลผิดรูป
Authentication	ใครกำลังร้องขอ	ไม่รู้เจ้าของคำขอ
Authorization	เข้าถึง Resource ใดได้	อ่าน/แก้ข้อมูลของคนอื่น
Business rules	ต้องผ่านเงื่อนไขใดก่อนลงมือ	ยกเลิก/ชำระเงินผิดเงื่อนไข
Human approval	ใครยืนยันรายการที่มีผลจริง	โมเดลตัดสินใจเกินหน้าที่
Result validation	ผลจาก Tool สำเร็จหรือผิดพลาด	แจ้งผู้ใช้ว่างานสำเร็จทั้งที่ล้มเหลว

Strict Structured Output ช่วยให้รูปแบบของ Argument คาดการณ์ได้ขึ้น แต่ไม่ได้ทดแทน Permission Checks และไม่ทำให้ข้อมูลที่โมเดลได้รับเชื่อถือได้ทั้งหมด

MCP เป็นมาตรฐานอะไร และไม่ใช่อะไร

MCP ช่วยจัดวิธีที่แอป/Client ติดต่อ Server ที่เปิดข้อมูลหรือเครื่องมือบางอย่าง เช่น ขอรายการ Tools และส่งคำขอเรียก Tool ตามสัญญาที่ตกลงกันไว้ จึงช่วยลดการเขียน Adapter เฉพาะทางซ้ำ แต่ไม่ได้หมายความว่าทุก MCP Server ปลอดภัยหรือควรเชื่อถือโดยอัตโนมัติ

ภาพรวมเชิงแนวคิด:

ส่วน	หน้าที่
MCP Host/Client	แอป AI ที่เลือกเชื่อม Server ตามสิทธิ์ผู้ใช้/ระบบ
MCP Server	เปิด Resources หรือ Tools ที่เจ้าของ Server อนุญาต
Transport/Auth	ช่องทางสื่อสารและการตรวจสิทธิ์ตามประเภทการเชื่อมต่อ
Application Policy	กติกาว่าจะเรียก Tool ใด ใช้กับข้อมูลใด และต้องยืนยันเมื่อใด

รายละเอียดความสามารถ เวอร์ชัน Specification และการยืนยันตัวตนของ MCP เปลี่ยนได้ จึงควรดูเอกสารทางการล่าสุดที่ Model Context Protocol และเลือกใช้ SDK/Transport ให้ตรงกับ Server จริง แทนการลอกตัวอย่างเวอร์ชันเก่าไปใช้ใน Production

MCP ไม่ได้แปลว่า Agent: Chatbot ที่ใช้ MCP อาจยังมี Workflow ตายตัว ส่วน AI Agent อาจเรียก API ผ่าน Function Calling โดยไม่ใช้ MCP เลย

Read-only Tool กับ Write Action ต้องแยกสิทธิ์

การอ่านเวลาทำการจาก API สาธารณะมีผลกระทบต่ำกว่าการเปลี่ยนที่อยู่จัดส่งหรืออนุมัติคืนเงิน จึงควรออกแบบสิทธิ์ Tool แยกเป็น Read และ Write ไม่ตั้ง Credential เดียวที่อ่าน/แก้ได้ทุกเรื่อง

ตัวอย่างจำลอง:

• getOrderStatus ทำงาน Read-only โดย Backend ตรวจว่าลูกค้ามีสิทธิ์ดูรายการ
• proposeDeliveryChange สร้าง ร่างคำขอ เปลี่ยนที่อยู่ แต่ยังไม่แก้ Order
• confirmDeliveryChange ต้องได้การยืนยันที่เหมาะสมจากผู้มีสิทธิ์ พร้อมตรวจสถานะรายการอีกครั้งก่อนเขียนข้อมูล

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

Tool Result เป็นข้อมูลที่เชื่อถือไม่ได้โดยปริยาย

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

อย่านำข้อความใน Tool Result ไปยกระดับเป็น System Instruction และอย่าให้โมเดลเรียก Tool ระดับสูงกว่าเพราะเอกสาร/ข้อมูลที่ค้นมาบอกว่า “ได้รับอนุญาตแล้ว” จุดตัดสินสิทธิ์ต้องอยู่ที่โค้ดและแหล่ง Identity ที่เชื่อถือได้

หลักการนี้เกี่ยวข้องกับ Prompt Injection, Data Exfiltration และ Excessive Agency ซึ่งเป็นประเด็นที่ต้องประเมินในระบบ AI ตาม OWASP GenAI LLM Top 10 2026 อ่านต่อใน Chatbot Security

ตัวอย่าง Checklist สำหรับการต่อ API

ก่อนอนุญาตให้ Bot เชื่อม Tool ที่มีผลต่อระบบจริง ให้เตรียมข้อมูลขั้นต่ำดังนี้

1. รายการ Tools ที่เปิดจริง และเจ้าของ Tool แต่ละตัว
2. Scope และ Permission ของบัญชี/ผู้ใช้ที่ใช้เรียก API
3. Schema ของ Input/Output และ Validation ทั้งก่อน/หลังเรียก
4. Timeouts, Retries, Rate Limits และการจัดการคำขอซ้ำ (Idempotency)
5. Approval Gate และเหตุการณ์ที่ต้องส่งเจ้าหน้าที่
6. Audit Log ที่ไม่เปิดเผยข้อมูลส่วนบุคคลหรือ Secret เกินจำเป็น
7. Test Cases สำหรับ API Fail, Permission Denied และผลลัพธ์กำกวม

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

ควรใช้ MCP เมื่อใด

พิจารณา MCP เมื่อมีเครื่องมือหลายตัวที่ต้องเชื่อมกับหลาย AI Client และประโยชน์ด้านมาตรฐาน/การดูแลร่วมกันชัดเจน แต่ถ้าระบบมี API ภายในเพียงตัวเดียว การเรียก Function โดยตรงอาจลดส่วนประกอบและง่ายต่อการตรวจสอบกว่า

ไม่ว่าทางใด ความปลอดภัยขึ้นอยู่กับสิทธิ์และกระบวนการของแอปจริง ไม่ใช่เลือกคำว่า MCP, Agent หรือ Function Calling แล้วจะทำงานถูกต้องอัตโนมัติ

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

Function Calling ทำให้ AI รันโค้ดได้เองไหม

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

MCP กับ API ต่างกันอย่างไร

API เป็นช่องทางให้ระบบหนึ่งเรียกความสามารถของอีกระบบ ส่วน MCP เป็นมาตรฐานที่จัดวิธีเชื่อม AI Client กับ Tools/Resources บางประเภท การใช้ MCP ยังคงต้องคุมสิทธิ์ API ปลายทาง

ใช้ Schema ครบแล้วต้องมี Approval ไหม

ยังต้องพิจารณาตามผลกระทบ Schema ตรวจรูปแบบข้อมูล แต่ไม่ได้ตรวจเจตนา สิทธิ์ หรือกติกาทางธุรกิจ

แหล่งอ้างอิง

• OpenAI Developers — Function calling
• OpenAI Developers — Using tools
• Model Context Protocol — Introduction
• OWASP GenAI — LLM Top 10 2026

ตรวจหลักการ: 2 พฤศจิกายน 2026; ลำดับ Tool Call เป็นโฟลว์จำลอง รายละเอียด API, SDK และสิทธิ์ต้องตรวจตามระบบที่ใช้งานจริง