MCP สเปก 2026-07-28 ออกตัวจริงแล้ว — ยุค stateless เริ่มนับหนึ่ง พร้อม C# SDK v2.0 วันเดียวกัน

Model Context Protocol (MCP) มาตรฐานกลางที่ใช้ต่อโมเดล AI เข้ากับเครื่องมือและข้อมูล ปล่อยสเปกรุ่น 2026-07-28 ออกมาเป็น stable release อย่างเป็นทางการแล้วเมื่อวานนี้ (28 กรกฎาคม 2026) ปิดฉากช่วง Release Candidate ที่ยืดยาวมาตั้งแต่ 29 พฤษภาคม หน้า release บน GitHub ระบุตรง ๆ ว่านี่คือ “the stable release of the 2026-07-28 revision” และเอกสารสเปกบน modelcontextprotocol.io ก็สลับมาชี้ที่ schema เวอร์ชันนี้เรียบร้อย

สิ่งที่ทำให้รุ่นนี้สำคัญกว่าการอัปเวอร์ชันทั่วไปคือ มันคือการรื้อโครงสร้างพื้นฐานของโปรโตคอลครั้งใหญ่ที่สุดนับแต่ MCP เปิดตัว — เอกสารของ Microsoft เองเรียกมันว่า “the largest revision of the protocol since it launched” ใครที่เขียน MCP server หรือ client อยู่ตอนนี้ ควรอ่าน changelog ก่อนวางแผน roadmap ไตรมาสหน้า

หัวใจ: ไม่มี session ในระดับโปรโตคอลอีกต่อไป

การเปลี่ยนแปลงหลักคือ MCP กลายเป็น stateless จริง ๆ ในระดับสเปก:

• ตัด initialize / notifications/initialized handshake ทิ้ง ทุกคำขอพกเวอร์ชันโปรโตคอลและ client capabilities ไปกับตัวเองใน _meta (io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities) ถ้าเวอร์ชันไม่ตรงกันจะได้ UnsupportedProtocolVersionError กลับมา
• ตัดหัวข้อ Mcp-Session-Id ออกจาก Streamable HTTP เซิร์ฟเวอร์ที่ต้องการ state ข้ามคำขอ ให้ใช้ handle ที่เซิร์ฟเวอร์เป็นคนออกให้ แล้วส่งไปมาเป็น argument ของ tool ตามปกติแทน
• เพิ่ม server/discover เป็น RPC ที่เซิร์ฟเวอร์ ต้อง implement เพื่อประกาศเวอร์ชันที่รองรับ ความสามารถ และตัวตนของตัวเอง ไคลเอนต์จะเรียกก่อนคำขออื่นเพื่อเลือกเวอร์ชันล่วงหน้าก็ได้ หรือใช้เป็นตัว probe ความเข้ากันได้ย้อนหลังบน STDIO ก็ได้

ผลเชิงปฏิบัติคือ MCP server สเกลหลัง load balancer ธรรมดาได้โดยไม่ต้องมี sticky session และไม่ต้องมี shared session store — ซึ่งเป็นสาเหตุที่ทีมอย่าง GitHub รีบขยับไปรองรับสเปกนี้ตั้งแต่ยังเป็น RC

ราคาที่ต้องจ่ายคือความทนทานของสตรีม: สเปกใหม่ ตัด SSE stream resumability และการส่งข้อความซ้ำทิ้ง (Last-Event-ID และ SSE event ID หายไป) ถ้าสตรีมขาดกลางคัน คำขอนั้นถือว่าหลุด ไคลเอนต์ ต้อง ยิงใหม่เป็นคำขอใหม่พร้อม request ID ใหม่ ใครที่ออกแบบ tool ที่รันยาว ๆ ต้องคิดเรื่องนี้ตั้งแต่ต้น

Multi Round-Trip Requests — วิธีใหม่ที่เซิร์ฟเวอร์จะ “ถามกลับ”

เมื่อไม่มี session แล้ว รูปแบบเดิมที่เซิร์ฟเวอร์เป็นฝ่ายเปิดคำขอกลับไปหาไคลเอนต์ (roots/list, sampling/createMessage, elicitation/create) ก็ใช้ไม่ได้ สเปกใหม่แทนที่ด้วยรูปแบบ Multi Round-Trip Requests (MRTR):

เซิร์ฟเวอร์ตอบกลับด้วย InputRequiredResult (resultType: "input_required") ที่มีฟิลด์ inputRequests บอกว่าต้องการข้อมูลอะไรเพิ่ม ไคลเอนต์ไปเก็บข้อมูลมา แล้ว ยิงคำขอเดิมซ้ำ พร้อมแนบ inputResponses กลับไป วนแบบนี้ได้หลายรอบโดยที่ทุกอย่างอยู่ใน payload ของคำขอทั้งหมด ไม่ต้องพึ่ง session ที่ค้างอยู่ฝั่งเซิร์ฟเวอร์

ตามมาด้วยการที่ ทุก result ต้องมีฟิลด์ resultType — "complete" สำหรับผลลัพธ์ปกติ และ "input_required" สำหรับผลกลางคันแบบ MRTR ไคลเอนต์ ต้อง ถือว่า result จากเซิร์ฟเวอร์รุ่นเก่าที่ไม่มีฟิลด์นี้เท่ากับ "complete"

การเปลี่ยนแปลงอื่นที่กระทบโค้ดจริง:

• ping, logging/setLevel, notifications/roots/list_changed ถูกถอดออก — ระดับ log ตั้งต่อคำขอผ่าน io.modelcontextprotocol/logLevel ใน _meta แทน และเซิร์ฟเวอร์ ต้องไม่ ส่ง notifications/message สำหรับคำขอที่ไม่ได้ระบุฟิลด์นี้
• resources/subscribe/unsubscribe และ HTTP GET endpoint ถูกแทนด้วย subscriptions/listen — สตรีม POST-response ตัวเดียวที่อยู่ยาว สำหรับการแจ้งเตือนที่ไคลเอนต์เลือก opt-in เอง
• Tasks ย้ายออกจาก core ไปเป็น extension (io.modelcontextprotocol/tasks) และออกแบบใหม่ ใช้ polling ผ่าน tasks/get แทน tasks/result แบบ blocking เพิ่ม tasks/update ให้ไคลเอนต์ส่งข้อมูลกลับได้ และเอา tasks/list ออก
• tools/list และเพื่อน ๆ ต้องมี ttlMs และ cacheScope ผ่าน interface CacheableResult ใหม่ เพื่อให้ไคลเอนต์แคชได้และลดการ poll — และสเปกยัง แนะนำ ให้คืน tool ในลำดับที่คงที่ เพื่อให้ prompt cache ของ LLM ทำงานได้ดีขึ้น
• รองรับ OpenTelemetry อย่างเป็นทางการ ผ่าน _meta key traceparent, tracestate, baggage

ของที่ประกาศ deprecate — และนาฬิกา 12 เดือน

รุ่นนี้มาพร้อม นโยบาย feature lifecycle ใหม่ ที่นิยามสถานะ Active / Deprecated / Removed และกำหนดหน้าต่าง deprecation ขั้นต่ำ 12 เดือน พร้อม registry กลางที่ไล่ดูได้ว่าอะไรกำลังจะหายไป

รายการที่ประกาศ deprecate รอบนี้กระทบงานจริงพอสมควร: Roots, Sampling และ Logging ถูก deprecate ทั้งชุด (SEP-2577) — ยังใช้ได้ในช่วงเปลี่ยนผ่าน แต่โปรเจกต์ใหม่ไม่ควรเพิ่มการรองรับ ทางเลือกที่สเปกแนะนำคือ ส่ง path/ไฟล์เป็น tool parameter หรือ resource URI แทน Roots, ต่อ API ของผู้ให้บริการ LLM ตรง ๆ แทน Sampling และ log ลง stderr หรือใช้ OpenTelemetry แทน Logging

นอกจากนี้ OAuth 2.0 Dynamic Client Registration (RFC 7591) ถูก deprecate โดยหันไปใช้ Client ID Metadata Documents แทน ส่วน transport แบบ HTTP+SSE ที่ deprecate มาตั้งแต่ 2025-03-26 ก็ถูกจัดเข้าสถานะ Deprecated อย่างเป็นทางการภายใต้นโยบายใหม่

Microsoft ปล่อย C# SDK v2.0 วันเดียวกัน

สัญญาณว่าสเปกนี้พร้อมใช้จริง คือ MCP C# SDK v2.0 ที่ Jeff Handley ประกาศบน .NET Blog ในวันเดียวกัน (28 กรกฎาคม) โดยระบุตรง ๆ ว่า implement สเปกรุ่น 2026-07-28

จุดที่น่าสนใจสำหรับนักพัฒนา .NET คือ มี breaking change แค่จุดเดียว — extension ของ Tasks ที่ออกแบบใหม่และเข้ากันไม่ได้กับ Tasks แบบ experimental ของสเปก 2025-11-25 ทั้งในระดับ API และระดับโปรโตคอล นอกนั้นโค้ด v1 เดิมยังคอมไพล์และรันได้ตามปกติ มีแค่ diagnostic เตือน (MCP9004, MCP9005, MCP9006) คอยชี้ทางย้าย และตัว SDK จัดการเจรจาเวอร์ชันกับ client/server รุ่นเก่าให้เองอย่างโปร่งใส

แพ็กเกจแบ่งเป็น ModelContextProtocol.Core (client + low-level server, dependency น้อย), ModelContextProtocol (stdio server, hosting/DI, attribute-based discovery), ModelContextProtocol.AspNetCore (Streamable HTTP server) และ extension แยกอีกสองตัวคือ ModelContextProtocol.Extensions.Tasks กับ ModelContextProtocol.Extensions.Apps (ยัง experimental) ทั้งหมด target net8.0, net9.0, net10.0 และ netstandard2.0

อีกจุดที่ SDK เน้นคือ HTTP header มาตรฐาน (Mcp-Method, Mcp-Name, Mcp-Param-*) ที่ทำให้โครงสร้างพื้นฐาน HTTP ทั่วไปเราต์ทราฟฟิก MCP ได้โดยไม่ต้องแกะ payload — เปิดทางให้ deploy แบบกระจายหลายภูมิภาคได้จริง

มุมมอง AI Curator

การที่สเปกนี้ใช้เวลาสองเดือนเต็มจาก RC (29 พฤษภาคม) กว่าจะเป็น stable บอกอะไรบางอย่าง: MCP ไม่ใช่โปรเจกต์ทดลองของแล็บเดียวอีกแล้ว แต่เป็นมาตรฐานที่มีคนใช้งานจริงมากพอจนต้องรอบคอบ และการที่รุ่นนี้มาพร้อม นโยบาย deprecation 12 เดือน เป็นครั้งแรก คือสัญญาณของการโตเป็นผู้ใหญ่ที่ชัดกว่าฟีเจอร์ใด ๆ ในรายการ — มันบอกว่าคนที่ลงทุนเขียน MCP server วันนี้จะมีเวลาหายใจเมื่อของถูกถอด

แต่สำหรับทีมไทยที่กำลังสร้าง agent อยู่ตอนนี้ ผมอยากเตือนสองเรื่องที่เป็นงานจริงมากกว่าข่าว

เรื่องแรก การ deprecate Sampling กระทบสถาปัตยกรรมมากกว่าที่หลายคนคิด ทีมจำนวนไม่น้อยใช้ Sampling เป็นวิธีให้ MCP server ยืม LLM ของ host มาใช้ โดยไม่ต้องถือ API key เอง พอทางเลือกที่สเปกแนะนำคือ “ต่อ API ของผู้ให้บริการ LLM ตรง ๆ” นั่นแปลว่า server ต้องมี key ของตัวเอง มีบิลของตัวเอง และมีความรับผิดชอบเรื่องข้อมูลของตัวเอง — สำหรับองค์กรไทยที่ต้องคิดเรื่อง PDPA และการที่ข้อมูลจะวิ่งออกไปที่ไหน นี่คือคำถามเชิงสถาปัตยกรรมที่ต้องตอบใหม่ ไม่ใช่แค่การแก้โค้ดสองสามบรรทัด มี 12 เดือนให้วางแผน ควรใช้มัน

เรื่องที่สอง stateless เป็นข่าวดีสำหรับคนที่ deploy ในภูมิภาคนี้เป็นพิเศษ ทีมไทยส่วนมาก deploy MCP server บนโครงสร้างพื้นฐานที่เรียบง่าย — container หลังตัว load balancer ธรรมดา หรือบน serverless — ซึ่งเป็นสภาพแวดล้อมที่ sticky session และ shared session store เป็นภาระเกินตัวมาตลอด การตัด session ออกทำให้ค่า deploy ของ MCP server ลดลงจริง และการที่ header มาตรฐานใหม่ให้ load balancer เราต์ได้โดยไม่ต้องแกะ payload ยิ่งทำให้ deploy หลายรีเจียน (เช่น เอดจ์ในสิงคโปร์คู่กับต้นทางในไทย) ทำได้ตรงไปตรงมาขึ้น

ข้อควรระวังสุดท้ายคือ การหายไปของ stream resumability ในบริบทเน็ตเวิร์กแบบมือถือหรือการเชื่อมข้ามประเทศที่สายหลุดง่ายกว่า การที่คำขอที่รันอยู่หลุดแล้วต้องยิงใหม่ทั้งหมด แปลว่า tool ที่ทำงานหนักและนานควรออกแบบให้ idempotent และควรย้ายไปใช้ Tasks extension ตั้งแต่แรก แทนที่จะปล่อยให้คำขอเดียวค้างยาว — เป็นข้อจำกัดที่ควรออกแบบรับตั้งแต่วันนี้ ไม่ใช่ไปเจอตอนขึ้นโปรดักชัน

แหล่งข่าว

• MCP Specification 2026-07-28 — Key Changes (changelog)
• modelcontextprotocol/modelcontextprotocol — release 2026-07-28 (GitHub)
• Announcing v2.0 of the official MCP C# SDK — .NET Blog
• MCP Specification — Overview