MCP ออกสเปกใหม่ 28 ก.ค. 2026: ตัด session ทิ้งทั้งระบบ

วันที่ 28 กรกฎาคม 2026 คณะทำงาน Model Context Protocol (MCP) ปล่อยสเปกเวอร์ชัน 2026-07-28 ออกมา และมันคือการแก้สเปกครั้งที่ 5 ที่ต่างจาก 4 ครั้งก่อนอย่างสิ้นเชิง เพราะครั้งนี้ไม่ได้เพิ่มว่า “MCP ทำอะไรได้” แต่ รื้อวิธีที่เซิร์ฟเวอร์ MCP ถูกติดตั้งใหม่ทั้งหมด ของที่ถูกตัดทิ้งคือ session, ขั้นตอน initialize handshake และการที่ฝั่งเซิร์ฟเวอร์ยิงคำขอกลับมาเองได้ ผลคือทุกคำขอกลายเป็นชิ้นที่เลี้ยงตัวเองได้ และเซิร์ฟเวอร์ MCP ก็วางหลัง load balancer แบบวนรอบธรรมดาได้เหมือนเว็บแอปทั่วไป

สำหรับคนที่เขียนเซิร์ฟเวอร์ MCP ไว้ใช้เองหรือให้ลูกค้าใช้ นี่คือ breaking change ที่ต้องแก้โค้ดจริง ไม่ใช่การอัปเวอร์ชันแล้วจบ ส่วนคนที่เป็นผู้ใช้ปลายทาง (เสียบ MCP server เข้ากับผู้ช่วยเขียนโค้ดหรือ IDE) แทบไม่ต้องทำอะไร แต่ควรรู้ว่าเครื่องมือที่ใช้อยู่กำลังจะเข้าสู่ช่วงเปลี่ยนผ่าน 12 เดือน

สรุปสั้น ๆ: สเปก MCP 2026-07-28 แทนที่ 2025-11-25 โดยเปลี่ยนโปรโตคอลจาก stateful เป็น stateless ทุกคำขอพา identity/เวอร์ชัน/capability ไปในฟิลด์ _meta เอง · ของใหม่ที่สำคัญ 5 อย่าง: stateless core, Multi Round-Trip Requests, routing ด้วย HTTP header, cache รายการเครื่องมือได้ (ttlMs), และการยืนยันตัวตนที่เข้มขึ้น · ของที่ประกาศเลิกใช้ 5 อย่าง (Roots, Sampling, Logging, Dynamic Client Registration, HTTP+SSE) ถอดออกได้เร็วสุด 28 ก.ค. 2027 · SDK หลักทั้ง TypeScript, Python, Go และ C# รองรับแล้ววันแรก (Rust อยู่ในเบต้า) · ฝ่ายความปลอดภัยเตือนทันทีว่ามีพื้นที่โจมตีใหม่ 3 จุดที่ย้ายจากโปรโตคอลมาอยู่บนบ่าคนเขียนเซิร์ฟเวอร์

MCP คืออะไร และทำไมสเปกรอบนี้เป็นเรื่องใหญ่

MCP คือมาตรฐานเปิดที่ทำให้ผู้ช่วย AI เสียบเข้ากับเครื่องมือและข้อมูลภายนอกได้ด้วยวิธีเดียวกันหมด (ฐานข้อมูล, ระบบไฟล์, Jira, ระบบภายในบริษัท) แทนที่ทุกเจ้าจะต้องเขียนตัวเชื่อมของตัวเอง Anthropic เปิดโปรโตคอลนี้ปลายปี 2024 แล้ว เดือนธันวาคม 2025 ยกให้ Agentic AI Foundation (AAIF) ใต้ Linux Foundation ดูแล โดยมี Anthropic, Block และ OpenAI ร่วมก่อตั้ง และมี Google, Microsoft, AWS, Cloudflare, Bloomberg หนุนอยู่ ทีมดูแลด้านเทคนิคของ MCP ยังเป็นชุดเดิมและตัดสินใจเองได้เหมือนเดิม

ตัวเลขการใช้งานจากบล็อกทางการรอบนี้บอกว่า SDK หลัก (Tier 1) รวมกันมีการดาวน์โหลด เกือบ 500 ล้านครั้งต่อเดือน และตัว TypeScript กับ Python ทะลุหลัก 1,000 ล้านครั้งสะสม ไปแล้วทั้งคู่ พูดง่าย ๆ คือของที่กำลังถูกรื้อไม่ใช่โปรเจกต์ทดลอง แต่เป็นชิ้นส่วนที่ระบบ agent ของแทบทุกค่ายวางทับอยู่

เหตุผลที่ต้องรื้อมาจากที่มาของ MCP เอง มันถูกออกแบบตอนที่ทุกอย่างรันบนเครื่องเดียว โปรแกรมผู้ช่วยเปิดเซิร์ฟเวอร์ MCP ขึ้นมาเป็นโปรเซสลูก คุยกันสองทางตลอดเวลา การมี session จึงไม่มีต้นทุนอะไร แต่พอ MCP ย้ายขึ้นไปเป็นบริการบน HTTP ที่มีคนใช้พร้อมกันหลายพันคน session กลายเป็นภาระทันที ผู้ดูแลระบบต้องบังคับให้คำขอของผู้ใช้คนเดิมวิ่งกลับไปที่เครื่องเดิมเสมอ (sticky session) ต้องมีที่เก็บสถานะกลางอย่าง Redis และ gateway ที่หน้าบ้านต้องแกะ JSON ข้างในดูก่อนว่าจะส่งไปทางไหน ทีมดูแลสเปกระบุเองว่า การขอให้ตัดสถานะทิ้งเป็นหนึ่งในคำขอที่ถูกเรียกร้องมากที่สุด จากคนที่เอา MCP ไปรันจริง

ของใหม่ข้อที่ 1: ทุกคำขอเลี้ยงตัวเองได้

หัวใจของสเปกนี้อยู่ที่การตัด initialize กับ initialized และเลข session ออกไปทั้งหมด ข้อมูลที่เคยตกลงกันครั้งเดียวตอนเริ่มเชื่อมต่อ (เวอร์ชันโปรโตคอล, ตัวตนของไคลเอนต์, ความสามารถที่รองรับ) ตอนนี้ถูกแนบไปกับ ทุก คำขอในฟิลด์ _meta แทน

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

สำหรับงานที่ต้อง “จำ” อะไรข้ามหลายคำสั่งจริง ๆ (เช่นตะกร้าสินค้า หรือขั้นตอนงานที่ทำต่อเนื่องกัน) สเปกไม่ได้ห้ามจำ แต่ย้ายให้เป็นหน้าที่ของเราออกแบบเอง วิธีที่คู่มือย้ายระบบแนะนำคือให้เซิร์ฟเวอร์ ออกรหัสอ้างอิง (handle) ของตัวเอง เช่น basket_id หรือ workflow_id แล้วคืนไปกับผลลัพธ์ ให้ไคลเอนต์ส่งกลับมาในคำสั่งถัดไป ส่วนไคลเอนต์ที่อยากรู้ความสามารถของเซิร์ฟเวอร์ก่อนยิงงานจริง มีเมธอด server/discover ให้เรียกได้ แต่เป็นทางเลือก ไม่ใช่ข้อบังคับเหมือน handshake เดิม

ของใหม่ข้อที่ 2: ถามกลางทางได้โดยไม่ต้องเปิดสายค้างไว้

ปัญหาที่ตามมาทันทีเมื่อตัดการเชื่อมต่อสองทางออกคือ ถ้าเซิร์ฟเวอร์ต้องถามอะไรกลางทางจะทำยังไง เช่น “ยืนยันว่าจะลบจริงไหม” หรือ “ขอรหัสยืนยันอีกชั้น” สเปกใหม่ตอบด้วยกลไกชื่อ Multi Round-Trip Requests (MRTR) คือเซิร์ฟเวอร์ตอบกลับด้วย resultType: "input_required" พร้อมบอกว่าต้องการอะไร แล้วไคลเอนต์ยิงคำขอเดิมซ้ำโดยแนบคำตอบมาใน inputResponses

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

ของใหม่ข้อที่ 3: routing ด้วย header และ cache รายการเครื่องมือ

คำขอ HTTP ตอนนี้พา header Mcp-Method และ Mcp-Name มาด้วย แปลว่า gateway, ตัวจำกัดอัตราการเรียก และระบบตรวจสิทธิ์ที่หน้าบ้าน ตัดสินใจได้จาก header โดยไม่ต้องแกะ JSON ข้างใน ซึ่งเป็นเรื่องที่คนดูแล infra ขอมานาน เพราะการแกะ body ทุกคำขอทั้งช้าและเปราะ

อีกอย่างที่ช่วยลดภาระคือรายการเครื่องมือ (tools), prompts และ resources ที่เซิร์ฟเวอร์ตอบกลับ ตอนนี้พา ttlMs และ cacheScope มาด้วย ไคลเอนต์จึงเก็บรายการไว้ใช้ซ้ำได้ตามอายุที่เซิร์ฟเวอร์กำหนด ไม่ต้องถามรายการเครื่องมือใหม่ทุกครั้งที่เริ่มงาน

ของใหม่ข้อที่ 4: การยืนยันตัวตนเข้มขึ้น

ฝั่งความปลอดภัยของการเชื่อมต่อถูกรัดน็อตเพิ่มสามจุด

• ตรวจผู้ออกโทเคนตาม RFC 9207 ป้องกันการนำโทเคนจากผู้ออกรายหนึ่งไปใช้กับอีกที่
• เลิกใช้ Dynamic Client Registration (DCR) เปลี่ยนไปใช้ Client ID Metadata Documents (CIMD) ซึ่งประกาศตัวตนของไคลเอนต์ไว้ล่วงหน้าเป็นเอกสารที่ตรวจได้
• ผูกข้อมูลรับรองไว้กับผู้ออก ห้ามเอาไปใช้ข้ามเซิร์ฟเวอร์

ของใหม่ข้อที่ 5: extension ทางการ 3 ตัว

สเปกนี้เพิ่มกรอบ extension อย่างเป็นทางการ (ของที่ไม่ใช่แกนกลางแต่มีมาตรฐานกลางให้ทำตาม) โดยมี 3 ตัวแรกออกมาพร้อมกัน

• Tasks (io.modelcontextprotocol/tasks) เลื่อนสถานะจากของทดลองในแกนกลางมาเป็น extension ทางการ ใช้กับงานที่ใช้เวลานาน เปลี่ยนจากการรอ notification แบบ push มาเป็นการ poll ถามสถานะ จึงทนกับสายที่หลุดกลางทางได้ (งานแบบ CI/CD หรือ batch ที่รันเป็นชั่วโมง)
• MCP Apps (SEP-1865) ให้เซิร์ฟเวอร์ส่งหน้าจอ HTML ที่กดได้มา render ใน iframe ในหน้าแชทหรือ IDE เลย แทนที่ไคลเอนต์ทุกตัวต้องเขียน UI ของตัวเอง
• Enterprise-Managed Authorization (EMA) ให้ฝ่ายไอทีขององค์กรจัดสิทธิ์การเข้าถึงเซิร์ฟเวอร์ MCP จากศูนย์กลางได้ แทนที่พนักงานแต่ละคนจะไปกดอนุญาตกันเอง

ของที่ประกาศเลิกใช้ และเส้นตายจริง

สเปกประกาศเลิกใช้ของเดิม 5 อย่าง โดยยืนยันว่า ของที่ถูกประกาศเลิกต้องยังใช้งานได้อีกอย่างน้อย 12 เดือน จึงถอดออกได้เร็วสุด 28 กรกฎาคม 2027

• Roots (กลไกจำกัดว่าเซิร์ฟเวอร์แตะโฟลเดอร์ไหนได้) ให้เปลี่ยนไปส่ง path เป็นพารามิเตอร์ของเครื่องมือ หรือกำหนดที่ตัวคอนฟิกเซิร์ฟเวอร์เอง
• Sampling (เซิร์ฟเวอร์ขอให้ไคลเอนต์เรียกโมเดลให้) ให้เซิร์ฟเวอร์เรียก LLM API เองตรง ๆ
• Logging ให้ใช้ stderr หรือ OpenTelemetry แทน
• Dynamic Client Registration ให้ลงทะเบียน OAuth ไว้ล่วงหน้า (หรือใช้ CIMD)
• ทรานสปอร์ตแบบ HTTP+SSE ให้ย้ายไป Streamable HTTP

ฝั่งเครื่องมือพร้อมแล้ววันแรก SDK หลักทั้ง TypeScript, Python, Go และ C# รองรับสเปกใหม่ตั้งแต่วันประกาศ ส่วน Rust อยู่ในสถานะเบต้า ใครเริ่มโปรเจกต์ใหม่วันนี้จึงเริ่มบนของใหม่ได้เลย

เสียงค้าน: ภาระความปลอดภัยย้ายมาอยู่บนบ่าคนเขียนเซิร์ฟเวอร์

คนดูแล infra ส่วนใหญ่รับการเปลี่ยนนี้ในทางบวก (Nate Barbettini ผู้ก่อตั้ง Arcade.dev เรียกมันว่าจุดที่โปรโตคอล “โตขึ้น” จากของที่เคยรันบนเครื่องตัวเองมาเป็นบริการบนเน็ตจริง ๆ) แต่เสียงค้านที่ควรฟังมาจากฝ่ายความปลอดภัย ทีมวิจัยภัยคุกคามของ Akamai สรุปประเด็นไว้ว่า เส้นแบ่งความปลอดภัยที่สำคัญตอนนี้ขึ้นอยู่กับว่าคนเขียนเซิร์ฟเวอร์ implement มันยังไง ไม่ใช่สิ่งที่โปรโตคอลรับประกันให้แล้วเหมือนก่อน ส่วนบริษัทความปลอดภัย Backslash ชี้พื้นที่โจมตีใหม่ 3 จุดที่เกิดจากสเปกนี้โดยตรง

1. รหัสอ้างอิงถูกขโมยไปใช้ซ้ำ เมื่อ session หายไป handle ที่เซิร์ฟเวอร์ออกให้กลายเป็นตัวแทนสถานะ แต่มันคือ สตริงที่วิ่งอยู่ในบทสนทนา ซึ่งโมเดลมองเห็น คัดลอกต่อได้ และไม่ได้ผูกกับผู้ใช้ ไอพี หรือ TLS มาแต่กำเนิด ถ้ามันหลุดไปอยู่ในตั๋วงานหรือประวัติแชท ใครก็หยิบไปยิงซ้ำได้ ทางแก้คือผูก handle กับผู้ใช้ที่สร้างมัน ตั้งอายุหมดอายุ และตรวจคู่ (handle + สิทธิ์ผู้เรียก) ทุกครั้ง ไม่ใช่ตรวจแค่ handle

2. ขอบเขตไฟล์ไม่ใช่ของโปรโตคอลอีกแล้ว เดิม Roots เป็นวิธีมาตรฐานในการจำกัดว่าเซิร์ฟเวอร์แตะโฟลเดอร์ไหนได้ พอมันถูกเลิกใช้ การจำกัดขอบเขตกลายเป็นเรื่องที่คนเขียนเซิร์ฟเวอร์แต่ละคนทำเองตามใจ (ทำหรือไม่ทำก็ได้) และ เครื่องมือที่หน้าบ้านตรวจไม่เห็นว่าใครทำไม่ทำ ผลที่แย่ที่สุดคือ agent ที่ควรอ่านแค่โฟลเดอร์โปรเจกต์กลับเดินไปอ่านไฟล์ .env หรือที่เก็บคีย์ได้ ทางแก้ที่ควรทำคือบังคับขอบเขตไว้ที่เซิร์ฟเวอร์เป็นค่าเริ่มต้น (ไม่ใช่เปิดให้เลือก) แล้วไล่ตรวจว่าแต่ละเซิร์ฟเวอร์เอื้อมถึง path ไหนได้จริง

3. HTML จาก MCP Apps คือโค้ดของคนอื่นที่รันในเครื่องมือของเรา ความน่ากลัวไม่ใช่ตัว iframe แต่คือ บริบทที่มันไปโผล่ ถ้า sandbox บนเว็บถูกเจาะ ผลเสียคือแท็บนั้น แต่ถ้าเป็น iframe ใน IDE ผลเสียคือเครื่องที่มีซอร์สโค้ด เทอร์มินัล และคีย์อยู่ครบ ประเด็นที่ Backslash เตือนเพิ่มคือ การปลอมหน้าจอ เช่นทำฟอร์มให้เหมือนหน้าล็อกอินจริงของเครื่องมือ ทางแก้คือตั้งนโยบายรีวิว HTML ที่เซิร์ฟเวอร์ส่งมาเหมือนที่รีวิวสคริปต์ของบุคคลที่สาม และจดไว้ว่าเซิร์ฟเวอร์ตัวไหนส่ง UI มา

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

อีกความเสี่ยงที่ฝ่ายวิเคราะห์ตลาดพูดถึงคือช่วงเปลี่ยนผ่าน Jim Mercer นักวิเคราะห์ของ IDC เตือนว่าหลายองค์กร มีเซิร์ฟเวอร์ MCP งอกขึ้นเต็มบริษัทโดยไม่มีใครทำบัญชีไว้ พอหมดช่วงผ่อนผัน 12 เดือน ของที่ไม่ได้อัปเดตจะเริ่มคุยกันไม่รู้เรื่องแบบเงียบ ๆ

วิเคราะห์: เรื่องนี้กระทบใครและต้องทำอะไร

กระทบนักพัฒนาทั่วไปยังไง

แบ่งเป็นสองกลุ่มชัดเจน ถ้าคุณเป็น ผู้ใช้ MCP (เสียบเซิร์ฟเวอร์สำเร็จรูปเข้ากับผู้ช่วยเขียนโค้ดหรือ IDE) แทบไม่ต้องทำอะไร แค่ไล่อัปเดตเครื่องมือตามรอบปกติ แต่ถ้าคุณ เขียนเซิร์ฟเวอร์ MCP เอง หรือมีไคลเอนต์/agent ที่ทำเอง นี่คืองานแก้จริงที่ต้องกันเวลาไว้ โดยเฉพาะโค้ดที่แอบพึ่งสถานะระดับการเชื่อมต่อ (เก็บตัวแปรไว้ในหน่วยความจำระหว่างคำสั่ง) เพราะโค้ดแบบนั้นจะพังแบบเงียบ ๆ ทันทีที่คำขอถัดไปตกไปเครื่องอื่น

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

กระทบคนไทยและองค์กรไทยโดยเฉพาะ

เรื่องต้นทุนเป็นข่าวดีสำหรับทีมเล็ก ก่อนหน้านี้ใครอยากเปิดเซิร์ฟเวอร์ MCP ให้ลูกค้าหรือทีมใช้จากระยะไกล ต้องมี load balancer ที่ทำ sticky ได้ บวกที่เก็บสถานะกลางอย่าง Redis ซึ่งเป็นค่ารายเดือนคงที่ที่ทีมสองสามคนไม่อยากจ่าย สเปกใหม่ทำให้ของแบบนี้ไม่จำเป็นแล้ว เอาไปวางบนแพลตฟอร์มที่คิดเงินตามการใช้จริงได้ ต้นทุนเริ่มต้นของการทำ integration ให้ระบบไทย (ระบบ ERP ในองค์กร, ระบบสมาชิก, ระบบชำระเงิน) จึงถูกลงอย่างมีนัยสำคัญ

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

อีกข้อที่องค์กรไทยควรรู้จักคือ extension EMA เพราะสถานการณ์ที่พบบ่อยตอนนี้คือพนักงานสายเทคเริ่มเสียบเซิร์ฟเวอร์ MCP ที่หาเจอบนอินเทอร์เน็ตเข้ากับเครื่องมือทำงานกันเองโดยฝ่ายไอทีไม่รู้ ซึ่งคือ shadow IT รูปแบบใหม่ที่มีสิทธิ์แตะไฟล์และระบบภายใน การมีมาตรฐานให้จัดสิทธิ์จากศูนย์กลางคือเครื่องมือที่ฝ่ายไอทีรอได้ใช้จริง

ควรเตรียมหรือปรับตัวอะไร

• ทำบัญชีก่อนทำอย่างอื่น ไล่ดูว่าในทีมมีเซิร์ฟเวอร์ MCP อยู่กี่ตัว ใครดูแล อิงสเปกเวอร์ชันไหน (ส่วนใหญ่จะเป็น 2025-11-25) ถ้าไม่มีบัญชีนี้ จะไม่รู้เลยว่าอะไรจะพังตอนหมดช่วงผ่อนผัน
• ไล่หาโค้ดที่พึ่งสถานะระดับการเชื่อมต่อ ถ้าเซิร์ฟเวอร์เก็บบริบทไว้ระหว่างการเรียกเครื่องมือหลายครั้ง ให้เปลี่ยนเป็นการออก handle แล้วคืนกลับไปให้ไคลเอนต์ถืออย่างชัดเจน
• ออกแบบ handle ให้ปลอดภัยตั้งแต่บรรทัดแรก สุ่ม ไม่สื่อความหมาย ผูกกับผู้ใช้ มีวันหมดอายุ และตรวจคู่กับสิทธิ์ผู้เรียกทุกครั้ง
• บังคับขอบเขตไฟล์ที่ฝั่งเซิร์ฟเวอร์แทน Roots ทำเป็นค่าเริ่มต้นที่ปิดไว้ก่อน แล้วเปิดเฉพาะ path ที่จำเป็น
• ย้ายของที่ถูกประกาศเลิกใช้ตั้งแต่ตอนนี้ Sampling ให้เซิร์ฟเวอร์เรียกโมเดลเอง, Logging ไปที่ stderr หรือ OpenTelemetry, HTTP+SSE ไป Streamable HTTP ทั้งหมดมีเวลาถึงกลางปี 2027 แต่การรอถึงเดือนสุดท้ายไม่เคยเป็นแผนที่ดี
• โปรเจกต์ใหม่เริ่มบน SDK รุ่นใหม่ TypeScript, Python, Go, C# พร้อมแล้ว อย่าเริ่มงานใหม่บนของที่รู้ว่าจะถูกถอด
• ตั้งนโยบายรีวิว UI ของ MCP Apps ถ้าจะเปิดใช้ ให้ปฏิบัติกับ HTML ที่เซิร์ฟเวอร์ส่งมาเหมือนสคริปต์ของบุคคลที่สาม คือต้องรีวิวก่อนและรู้ว่ามันมาจากใคร

สิ่งที่สเปกนี้บอกในภาพใหญ่คือ MCP กำลังเดินออกจากสถานะ “ของเล่นบนเครื่องตัวเอง” ไปเป็นชิ้นส่วนโครงสร้างพื้นฐานที่ต้องรับโหลดจริง และการเดินก้าวนั้นแลกมาด้วยงานย้ายระบบที่หลีกไม่ได้ ประเด็นที่น่าจับตาต่อคือ ตอนที่โปรโตคอลถอยออกจากการรับประกันความปลอดภัยให้ ภาระที่โผล่มาอยู่กับคนเขียนเซิร์ฟเวอร์นั้นหนักกว่าที่ประกาศไว้ในเอกสาร ใครทำเซิร์ฟเวอร์ MCP ให้คนอื่นใช้ในปีนี้ ต้องคิดเรื่องขอบเขตสิทธิ์และอายุของรหัสอ้างอิงเป็นงานหลัก ไม่ใช่ของแถมท้ายสปรินต์ ถ้าอยากทบทวนก่อนว่าวงจรการทำงานของ agent มีอะไรอยู่ในนั้นบ้างและเครื่องมือเข้ามาตรงไหน อ่านต่อได้ที่บทความ AI agent ทำงานยังไง และถ้าสนใจมุมการออกแบบระบบทั้งก้อน มีบทความ AI Architect ออกแบบระบบ AI กับข่าว Context Engineering ทักษะหลักใหม่ของ AI Engineer ต่อได้เลย