วิศวกรที่ดูแลระบบหลังบ้านอยากรู้ว่า MCP กับ API ต่างกันตรงไหนก่อนเลือกใช้งานจริง

วิศวกรที่ดูแลระบบหลังบ้านขององค์กรหนึ่งมี REST API ที่เชื่อมกับระบบ ERP, ระบบตั๋วงาน และฐานข้อมูลลูกค้าอยู่แล้วครบทุกตัว ใช้งานมาหลายปีจนเสถียร วันหนึ่งทีมผู้บริหารอยากให้มี AI Agent มาช่วยตอบคำถามพนักงานโดยดึงข้อมูลจากระบบเหล่านี้ คำถามแรกที่วิศวกรคนนี้ถามคือ 'มี API อยู่แล้ว ทำไมต้องมี MCP อีกชั้น ให้ AI เรียก API ตรง ๆ ไม่ได้เหรอ'

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

บทความนี้อธิบายความต่างจากมุมของวิศวกรที่ต้องดูแลระบบจริง ไม่ใช่มุมทฤษฎี พร้อมตัวอย่างสถานการณ์ที่ช่วยตัดสินใจว่าโปรเจกต์ของตัวเองควรเพิ่มชั้น MCP หรือให้ Agent เรียก API เดิมตรง ๆ ก็พอ

API แบบที่วิศวกรคุ้นเคยทำงานอย่างไร

API หรือ Application Programming Interface ในความหมายที่วิศวกรใช้กันทั่วไปคือชุด Endpoint ที่ระบบหนึ่งเปิดให้ระบบอื่นเรียกใช้ตามข้อกำหนดที่ตกลงกันไว้ล่วงหน้า เช่น REST API ที่มี URL ตายตัว รับ Parameter แบบที่กำหนด และคืนค่าเป็น JSON ตามโครงสร้างที่เอกสารระบุไว้ ผู้เรียกต้องอ่านเอกสารก่อนถึงจะรู้ว่ามี Endpoint อะไรบ้างและต้องส่งอะไรไป

จุดสำคัญคือ API แบบนี้ถูกออกแบบมาให้ 'มนุษย์นักพัฒนา' เป็นคนอ่านเอกสารแล้วเขียนโค้ดเชื่อมต่อ ไม่ได้ออกแบบมาให้ระบบฝั่งเรียกค้นพบเองได้ว่ามี Endpoint อะไรบ้างโดยไม่ต้องอ่านเอกสารก่อน ซึ่งเป็นเรื่องปกติมากสำหรับการเชื่อมต่อระหว่างระบบสองระบบที่นักพัฒนาเป็นคนกำหนดการเชื่อมต่อเองตั้งแต่ต้น

MCP เพิ่มความสามารถอะไรที่ API แบบเดิมไม่มี

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

อีกความต่างที่สำคัญคือ MCP กำหนดรูปแบบการสื่อสารที่เป็นมาตรฐานเดียวกันสำหรับทุก Tool ไม่ว่า Tool นั้นจะห่อหุ้ม API ตัวไหนอยู่ข้างใน ขณะที่ API แต่ละตัวมักมีรูปแบบเฉพาะของตัวเอง ทั้งเรื่องการยืนยันตัวตน รูปแบบ Error และโครงสร้างข้อมูลที่ส่งกลับ ทำให้ AI Agent ที่ต้องเชื่อมกับ API หลายตัวพร้อมกันต้องเขียนโค้ดจัดการความต่างเหล่านี้เองถ้าไม่มี MCP มาช่วยทำให้เป็นมาตรฐานเดียว

เทียบ MCP กับ API แบบเห็นภาพรวม

สรุปความต่างในมิติที่วิศวกรมักใช้ตัดสินใจว่าจะออกแบบระบบอย่างไร:

ตัวอย่างสมมติ: ห่อหุ้ม API ระบบตั๋วงานเดิมด้วย MCP Server

สมมติวิศวกรมี REST API ของระบบตั๋วงานอยู่แล้ว มี Endpoint เช่น GET /tickets/{id} และ POST /tickets เพื่อสร้างตั๋วใหม่ (ตัวอย่างประกอบเท่านั้น ไม่ใช่ระบบจริง) แทนที่จะให้ Agent แต่ละตัวเขียนโค้ดเรียก API เหล่านี้แยกกันเอง วิศวกรสร้าง MCP Server ตัวหนึ่งที่ห่อหุ้ม API เดิมไว้ข้างใน แล้วเปิด Tool ชื่อ get_ticket_status และ create_ticket ให้ Agent เรียกผ่านมาตรฐาน MCP แทน

ผลลัพธ์คือโค้ดที่เรียก API จริงยังอยู่ที่เดิม ไม่ต้องเขียนใหม่ทั้งหมด แต่ตอนนี้ Agent ตัวไหนก็ตามที่รองรับ MCP สามารถเชื่อมเข้ามาใช้ Tool ทั้งสองตัวนี้ได้ทันที โดยไม่ต้องรู้จัก URL หรือรูปแบบ Authentication ของ API เดิมเลย MCP Server ทำหน้าที่เป็นตัวกลางที่แปลงคำขอจาก Agent ให้กลายเป็น HTTP Request ไปยัง API เดิมแทน

เมื่อไรควรให้ Agent เรียก API เดิมตรง ๆ ไม่ต้องผ่าน MCP

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

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

ขั้นตอนจริงที่วิศวกรใช้เมื่อจะห่อหุ้ม API เดิมด้วย MCP Server

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

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

มุมความปลอดภัยต่างกันอย่างไรระหว่างสองแบบ

API แบบเดิมมักมีการยืนยันตัวตนที่ผูกกับระบบเฉพาะ เช่น API Key หรือ Token ที่ออกให้กับแอปพลิเคชันที่รู้จักกันไว้ล่วงหน้า ความเสี่ยงส่วนใหญ่จึงอยู่ที่การจัดการ Credential ให้รัดกุม ส่วน MCP มีความเสี่ยงเพิ่มเติมที่มาจากตัวโมเดลเอง เพราะ AI เป็นคนตัดสินใจว่าจะเรียก Tool ไหน ไม่ใช่โค้ดที่มนุษย์เขียนไว้ตายตัว รายละเอียดเรื่องนี้อธิบายลึกไว้ใน ความเสี่ยงด้าน Security ของ MCP และ การตั้งค่า MCP OAuth

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

ทำแบบนี้แล้วพัง เพราะ… ข้อผิดพลาดที่วิศวกรเจอบ่อยตอนเปรียบเทียบสองแบบนี้

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

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

สรุป

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

คำถามที่ควรตอบก่อนตัดสินใจไม่ใช่ 'MCP ดีกว่า API ไหม' แต่คือ 'ระบบนี้ต้องการให้ AI ตัดสินใจเองว่าจะเรียก Tool ไหนหรือไม่ และมี Agent มากกว่าหนึ่งตัวที่ต้องใช้ระบบเดียวกันหรือเปล่า' ถ้าคำตอบคือใช่ทั้งสองข้อ การลงทุนเพิ่มชั้น MCP มักคุ้มค่ากับเวลาที่ประหยัดได้ในระยะยาว

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

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