Azure Functions ทำ MCP server แบบ serverless ได้แล้ว — เพิ่ม resource/prompt triggers, MCP Apps คืน UI ได้ และ auth ในตัวตามสเปก MCP

เทรนด์ของสัปดาห์นี้ชัดเจน: MCP กำลังกลายเป็น “ปลั๊กมาตรฐาน” ที่ทุก agent คาดหวังว่าจะเสียบเข้าได้ — แต่คำถามที่ทีมส่วนใหญ่ติดอยู่คือ “แล้วฝั่ง server ของ MCP เราจะโฮสต์มันยังไงให้ดูแลง่ายและสเกลได้?” เมื่อ 24 มิถุนายน 2026 Microsoft ตอบฝั่งนี้ด้วยการอัปเดตใหญ่ของ Azure Functions MCP extension ที่ทำให้สร้างและโฮสต์ remote MCP server แบบ serverless ได้เต็มรูปแบบ — ไม่ต้องไปนั่งจัดการรายละเอียดของโปรโตคอลเอง แค่เขียนเป็น “ฟังก์ชัน” ตามโมเดล triggers/bindings ที่ Azure Functions ใช้อยู่แล้ว

จุดสำคัญคือมันลดงานสองอย่างที่เจ็บที่สุดของการทำ MCP server โปรดักชัน — การ implement สเปกโปรโตคอลให้ถูก และ การจัดการ auth/สเกล — ให้เหลือแค่เขียน business logic แล้วปล่อยให้แพลตฟอร์มจัดการที่เหลือ

ครบสาม MCP primitives ในโมเดล trigger เดียว

เดิม extension รองรับแค่ tool trigger ตัวเดียว รอบนี้ขยายครบทั้งสามชนิดที่สเปก MCP กำหนด:

• Tool triggers — เปิดฟังก์ชันให้ agent เรียกเป็น “ทูล” ได้ (ของเดิม)
• Resource triggers — เสิร์ฟฟังก์ชันเป็น resource ที่ป้อนบริบทให้โมเดล เช่น ไฟล์ สคีมา หรือคอมโพเนนต์ UI
• Prompt triggers — ให้ไคลเอนต์ขอ prompt template แบบมีโครงสร้างกลับไปได้

แปลว่า MCP server หนึ่งตัวบน Azure Functions ทำได้ทั้งสามบทบาท — ให้ทูลทำงาน, ป้อน context และส่ง prompt สำเร็จรูป — ในโปรเจกต์เดียว และยังควบคุม input/output schema ได้ (WithInputSchema / WithOutputSchema ฝั่ง .NET) เพื่อบังคับรูปแบบข้อมูลเข้า-ออกให้ agent เรียกได้แม่นขึ้น

MCP Apps: ฟังก์ชันคืน “หน้าจอ” ไม่ใช่แค่ข้อความ

ของที่น่าสนใจที่สุดคือ MCP Apps — ด้วยการผสม tool trigger กับ resource trigger เข้าด้วยกัน ฟังก์ชันสามารถคืน UI โต้ตอบ กลับไปยังไคลเอนต์ได้ แทนที่จะตอบเป็นข้อความล้วน ฝั่ง .NET มี fluent builder API ให้ประกอบ MCP primitives แบบ declarative และยังรองรับ content หลายชนิด — ข้อความ รูป เสียง และ resource link — พร้อม structured content ที่แนบ JSON metadata อ่านด้วยเครื่องได้

นี่คือก้าวที่ทำให้ “ทูล” ของ agent ไม่จำเป็นต้องเป็นกล่องข้อความตอบกลับเสมอไป — มันเริ่มมีหน้าตาและองค์ประกอบโต้ตอบได้ ซึ่งเปลี่ยนวิธีออกแบบประสบการณ์ของ agent พอสมควร

Auth ในตัว — จุดที่ทำให้เอาขึ้นโปรดักชันได้จริง

สิ่งที่แยก demo ออกจากของใช้จริงคือ authentication และรอบนี้ extension ใส่มาให้ในตัว ตามสเปก auth ของ MCP โดยตรง รองรับ Microsoft Entra ID และมีฟีเจอร์ระดับพรีวิวที่น่าสนใจสองอย่าง:

• ตั้งค่าแบบคลิกเดียวบน Azure portal — ลดงาน config ที่มักพังเงียบ ๆ
• On-Behalf-Of (OBO) token exchange — ให้ MCP server แลก token เพื่อเรียก API ปลายทาง ในนามผู้ใช้ได้อย่างถูกต้อง ซึ่งเป็นหัวใจของ agent องค์กรที่ต้องเข้าถึงข้อมูลตามสิทธิ์ของผู้ใช้แต่ละคน

รองรับภาษา .NET, Java, Python, TypeScript และ JavaScript ทำให้ทีมเลือก stack เดิมได้โดยไม่ต้องเปลี่ยนภาษาเพื่อทำ MCP server

มุมมอง AI Curator

ถ้าสังเกตข่าวช่วงสองสัปดาห์นี้ของบล็อกเรา — Mistral ออกชั้นคุม MCP connectors, Copilot CLI ฝัง MCP Registry, Sentry เตือน agentjacking ผ่าน MCP — จะเห็นว่า “ฝั่งไคลเอนต์/การกำกับ” ของ MCP โตเร็วมาก ข่าวนี้เติมอีกด้านที่ขาด: ฝั่ง server ที่โฮสต์ง่ายและสเกลเองได้ การยก MCP server มาอยู่บน serverless model ของ Azure Functions แปลว่าทีมไม่ต้องดูแล container/VM เอง จ่ายตามการใช้งานจริง และได้ auth ระดับองค์กร (Entra ID + OBO) มาฟรีในแพลตฟอร์ม — นี่คือสิ่งที่ทำให้ MCP server ขยับจาก “ของเล่นบนเครื่อง dev” ไปเป็น “บริการที่อยู่หลัง agent องค์กรได้จริง”

สำหรับทีมไทยและ SEA ที่ส่วนใหญ่อยู่บนคลาวด์อยู่แล้ว จุดที่ควรจับตาคือ OBO — มันคือคำตอบของปัญหาที่หลายทีมเจอเวลาทำ agent ภายในองค์กร: agent ต้องเข้าถึงข้อมูลตามสิทธิ์ของ “ผู้ใช้ที่กำลังคุยด้วย” ไม่ใช่สิทธิ์ของ service account ตัวเดียวที่กว้างเกินไป (ช่องโหว่คลาสสิกแบบเดียวกับที่ Mistral พยายามอุดด้วย scoped API key) แต่ก็ต้องไม่ลืมว่าการ deploy MCP server ที่เข้าถึงข้อมูลภายในย่อมขยายพื้นที่โจมตี — บทเรียน agentjacking ยังใช้ได้: จำกัด scope ของทูลให้แคบ ตรวจ input และอย่าวางใจสิ่งที่ agent ส่งเข้ามาโดยอัตโนมัติ MCP ที่ “ต่อง่าย” ต้องมาคู่กับ MCP ที่ “คุมแน่น” เสมอ

แหล่งข่าว:

• Azure Functions MCP Extension: What’s New at Build 2026 — Microsoft Azure SDK Blog
• Model Context Protocol — specification
• Azure Functions documentation — Microsoft Learn