Azure App Service Built-in MCP: เมื่อ API เดิมกลายเป็น Tool ให้ Agent

ข่าวนี้ดูเหมือน technical มากครับ แต่จริง ๆ แล้วเป็นเรื่องใหญ่สำหรับธุรกิจที่กำลังจะทำ AI Agent

Microsoft เปิด preview ของ built-in MCP for Azure App Service ซึ่งทำให้ REST API ที่รันอยู่บน Azure App Service สามารถกลายเป็น MCP server ได้จาก OpenAPI spec โดยไม่ต้องเขียนหรือ deploy MCP server แยกเอง

ถ้ามองแบบ developer นี่คือ feature ที่ลดงาน plumbing

แต่ถ้ามองแบบเจ้าของระบบ นี่คือสัญญาณว่า API หลังบ้านของธุรกิจกำลังจะกลายเป็น “เครื่องมือของ AI” มากขึ้นเรื่อย ๆ

เกิดอะไรขึ้น

Microsoft ระบุว่า built-in MCP for Azure App Service จะอ่าน OpenAPI 3.x specification แล้วสร้าง MCP tool หนึ่งตัวต่อหนึ่ง operation จาก spec นั้น จากนั้น App Service จะ serve MCP endpoint ผ่าน streamable HTTP ที่ path ที่เรากำหนดได้ เช่น /mcp

สิ่งที่แพลตฟอร์มช่วยจัดการให้ เช่น

• MCP protocol negotiation
• tool discovery
• hot reload ของ spec เมื่อเปลี่ยน
• client cancellation
• การเชื่อมกับ App Service Authentication

พูดง่าย ๆ คือ ถ้าบริษัทมี API ที่มี schema ชัดอยู่แล้ว ก็มีทางลัดในการให้ GitHub Copilot Chat, Cursor, Windsurf, Claude Desktop หรือ MCP client อื่น ๆ มาเรียก API เหล่านั้นเป็น tool ได้

ทำไมเรื่องนี้สำคัญกว่าการ “ต่อ MCP ง่ายขึ้น”

หลายทีมเริ่มทำ AI agent จากปลายทางก่อนครับ เช่น เปิด chatbot, ต่อ tool, ให้ model เรียก API แล้วดูว่าทำงานได้ไหม

วิธีนี้เร็ว แต่มีปัญหาหนึ่งคือเราอาจลืมถามว่า API ที่เปิดให้ agent ใช้นั้นพร้อมจริงหรือยัง

เพราะสำหรับมนุษย์ API อาจเป็นแค่ endpoint หนึ่งในระบบ

แต่สำหรับ AI agent API คือ “สิทธิ์ในการลงมือทำ”

ถ้า endpoint นั้นอ่านข้อมูลลูกค้าได้ agent ก็อ่านได้ ถ้า endpoint นั้นเปลี่ยนสถานะ order ได้ agent ก็เปลี่ยนได้ ถ้า endpoint นั้นสร้างเอกสารหรือส่งข้อความได้ agent ก็เริ่ม workflow ได้

ดังนั้นการเปิด API ให้ agent ไม่ใช่แค่ integration แต่คือการย้ายบางส่วนของ workflow ไปอยู่ในมือของระบบอัตโนมัติ

Agent-ready API คืออะไร

ในความเห็นของผม คำว่า agent-ready API ไม่ได้แปลว่า “มี API ให้เรียก” เท่านั้น

แต่มันควรมีอย่างน้อย 5 อย่างนี้

1) Schema ชัด

OpenAPI spec ต้องอ่านรู้เรื่อง มี operationId ที่เป็น action จริง เช่น list_orders, get_customer_profile, create_support_ticket ไม่ใช่ชื่อกว้าง ๆ ที่ model เดาเองยาก

2) ขอบเขต tool ชัด

Microsoft Learn ระบุว่า built-in MCP มี ToolList สำหรับควบคุมว่า operation ไหนจะถูก expose เป็น tool ค่า default สามารถเปิดทุก operation ได้ แต่ในงานจริงไม่ควรเริ่มจากเปิดทั้งหมดโดยไม่ review

3) Auth ชัด

Microsoft แนะนำให้ใช้ App Service Authentication และให้ MCP requests ผ่าน identity checks เหมือน route อื่น ๆ ของ app นอกจากนี้ยังมี protected resource metadata เพื่อให้ MCP client ทำ OAuth flow ได้ถูกต้อง

ภาษาง่าย ๆ คือ agent ควรเข้าระบบด้วยสิทธิ์ที่ตรวจสอบได้ ไม่ใช่ใช้ key ก้อนเดียวที่ทำได้ทุกอย่าง

4) แยก read กับ write

tool ที่อ่านข้อมูลกับ tool ที่เปลี่ยนสถานะไม่ควรมีความเสี่ยงเท่ากัน เช่น get_invoice กับ refund_payment ไม่ควรอยู่ใน bucket เดียวกัน

สำหรับธุรกิจทั่วไป จุดเริ่มต้นที่ปลอดภัยกว่าคือเปิด read-only tools ก่อน แล้วค่อยเพิ่ม action tools ที่มี approval หรือ confirmation

5) มี audit และ rollback mindset

เมื่อ agent เรียก tool เราควรรู้ว่าใครเป็นคนสั่ง, agent ใช้ tool อะไร, input คืออะไร, output คืออะไร และผลกระทบในระบบคืออะไร

ถ้า trace ย้อนกลับไม่ได้ ต่อให้ agent ทำถูก 99 ครั้ง แต่ผิด 1 ครั้ง ทีมก็อธิบายไม่ได้ว่าพลาดตรงไหน

ตัวอย่างใกล้ตัวสำหรับ SME

สมมติธุรกิจมีระบบหลังบ้านสำหรับ order และ support อยู่แล้ว

ถ้าจะให้ AI agent ช่วยทีม customer service เราอาจอยากให้มันทำงานแบบนี้

1. ลูกค้าถามสถานะ order
2. agent เรียก get_order_status
3. ถ้ามีปัญหาการจัดส่ง agent เปิด ticket ด้วย create_support_ticket
4. ถ้าต้องเปลี่ยนที่อยู่หรือคืนเงิน agent ส่งต่อให้คน approve ก่อน

นี่คือ workflow ที่ดี เพราะ agent ไม่ได้มีสิทธิ์เท่าคนทั้งหมด

มันอ่านข้อมูลที่จำเป็นได้ เปิดงานที่ปลอดภัยได้ และหยุดตรงจุดที่มีความเสี่ยง เช่น เงิน, ข้อมูลส่วนตัว, policy หรือการตัดสินใจแทนมนุษย์

ข้อควรระวังของ built-in MCP

เพราะ feature นี้ยังเป็น preview จึงมีข้อจำกัดที่ควรรู้ก่อนเอาไปวางแผนจริง

จาก Microsoft Learn ระบุว่า preview รองรับ MCP server ได้ 1 ตัวต่อ app, ใช้ streamable HTTP, ต้องมี App Service บน dedicated pricing tier Basic หรือสูงกว่า และไม่รองรับ Free, Shared, Consumption หรือ Flex Consumption plans

อีกจุดที่สำคัญคือ built-in MCP เหมาะกับกรณีที่ tool map กับ REST operation ได้ค่อนข้างตรง

ถ้า workflow ต้องทำหลาย step, รวมข้อมูลใน memory, มี MCP resources หรือ prompts, หรือมี logic เฉพาะที่ไม่ควรเป็น endpoint ตรง ๆ การเขียน custom MCP server ด้วย SDK ยังเหมาะกว่า

บทเรียนสำหรับทีมที่ยังไม่ได้ใช้ Azure

ประเด็นของข่าวนี้ไม่ได้แปลว่าทุกทีมต้องย้ายไป Azure App Service ครับ

บทเรียนที่ใหญ่กว่าคือ cloud platform เริ่มทำให้ “API เดิมกลายเป็น tool ของ agent” ง่ายขึ้นเรื่อย ๆ

ดังนั้นต่อให้คุณใช้ stack อื่น คำถามที่ควรถามตอนนี้คือ

• API ของเรามี OpenAPI spec ที่อัปเดตจริงไหม
• endpoint ไหนควรเปิดให้ agent เห็น
• endpoint ไหนควรซ่อนจาก agent แม้คนในทีมจะเรียกได้
• tool ไหนต้องมี human approval
• log ของ agent tool call เก็บอยู่ตรงไหน
• ถ้า prompt injection ทำให้ agent พยายามเรียก tool แปลก ๆ ระบบ block ได้ไหม

ถ้าตอบคำถามพวกนี้ไม่ได้ การต่อ MCP ให้เร็วขึ้นอาจทำให้ความเสี่ยงวิ่งเร็วขึ้นด้วย

Checklist: ก่อนเปิด API ให้ Agent

ผมแนะนำให้ทีมลองใช้ checklist สั้น ๆ นี้ก่อนครับ

1) เริ่มจาก read-only ก่อน

ให้ agent อ่านข้อมูลเพื่อช่วยตอบหรือสรุปก่อน อย่าเริ่มจาก action ที่เปลี่ยนสถานะทันที

2) ตั้งชื่อ operation ให้คนและ model เข้าใจ

ชื่อ tool ควรสื่อ intent ชัด ไม่ต้องให้ model เดาว่า endpoint นี้เอาไว้ทำอะไร

3) Filter tool list

อย่า expose ทุก endpoint เพียงเพราะทำได้ เลือกเฉพาะ operation ที่จำเป็นต่อ workflow แรก

4) แยก permission ตามความเสี่ยง

ข้อมูลลูกค้า, order, payment, HR, contract และ system admin ไม่ควรอยู่ใน permission ก้อนเดียวกัน

5) บังคับ approval ในจุดที่แตะเงินหรือข้อมูลสำคัญ

ให้ AI เตรียม draft, summary หรือ recommendation ได้ แต่ action สุดท้ายควรมีคน approve ในช่วงแรก

6) เก็บ proof หลังทำงาน

ทุก tool call ควรมี trace พอให้ทีมตอบได้ว่าเกิดอะไรขึ้น และใครควรแก้ตรงไหน

สรุป

ในความเห็นของผม built-in MCP for Azure App Service เป็นข่าวที่น่าสนใจมาก เพราะมันทำให้เราเห็นทิศทางชัดขึ้นว่า AI agent จะไม่ได้อยู่แค่ในหน้าต่างแชต แต่จะเริ่มเดินเข้าไปหา API หลังบ้านของธุรกิจโดยตรง

ข่าวดีคือ ธุรกิจที่มี API ดีอยู่แล้วจะ agent-ready เร็วขึ้น

ข่าวที่ต้องระวังคือ ธุรกิจที่ API และ permission ยังไม่เรียบร้อย ก็อาจเปิดประตูให้ agent แตะระบบจริงเร็วเกินไปเหมือนกัน

สุดท้าย AI Agent ที่ใช้ได้จริงไม่ใช่ตัวที่ต่อ tool ได้เยอะที่สุดครับ

แต่คือตัวที่เรียก tool ได้ถูกสิทธิ์ ถูกเวลา มีขอบเขต และมีหลักฐานให้ตรวจหลังทำงานจบ