MCP เวอร์ชัน 2 จะเริ่มใช้งานจริงในวันที่ 28 กรกฎาคม 2026 โดยจะยกเลิกการทำ handshake, session-ID header และระบบย่อยแบบ legacy ทั้งสามระบบที่เคยผูก Model Context Protocol (MCP) ไว้กับ sticky-session servers โปรโตคอลนี้จะกลายเป็นแบบ stateless อย่างสมบูรณ์ ดังนั้น instance ใดๆ ที่ผ่านการ autoscale หรือเป็นแบบ serverless จึงสามารถจัดการคำขอใดๆ ก็ได้โดยไม่จำเป็นต้องรักษา client state ไว้

ทำไมการเปลี่ยนแปลงนี้ถึงสำคัญ

ใน MCP v1 ลูกค้า (client) จำเป็นต้องเริ่ม session ด้วยการทำ initialize handshake จากนั้น server จะกำหนด Mcp-Session-Id ขึ้นมา ทุกการเรียกใช้งานหลังจากนั้นจะต้องแนบ header นี้ไปด้วย ซึ่งเป็นการผูกผู้ใช้ไว้กับ backend node เพียงตัวเดียว ทำให้ load balancers ต้องบังคับใช้ session affinity ซึ่งเป็นการเพิ่ม latency และความยุ่งยากในการดำเนินงาน (operational friction)

ความเป็น stateless ช่วยขจัดความยุ่งยากดังกล่าวออกไป โดย context ทั้งหมดจะถูกเก็บไว้ใน meta fields เฉพาะที่ส่งไปพร้อมกับทุก HTTP call คำขอสามารถส่งไปยัง instance ใดก็ได้ เมื่อประมวลผลเสร็จแล้ว instance นั้นก็สามารถถูกทำลายทิ้งได้ทันทีที่ส่ง response กลับไป ทีมที่ใช้งาน serverless platforms, container-orchestrated clusters หรือสภาพแวดล้อมใดๆ ที่มีการสร้างและลบ pods ตามความต้องการ (on demand) จะสามารถปรับโปรโตคอลให้เข้ากับโครงสร้างพื้นฐานของตนเองได้

สิ่งที่จะถูกยกเลิกการใช้งาน

ระบบย่อยสามระบบที่ต้องพึ่งพาการเชื่อมต่อแบบ persistent จะถูกประกาศ deprecate อย่างเป็นทางการ:

  • Sampling – ใน v1 server สามารถขอให้ client สร้างข้อความได้ ซึ่งเป็นรูปแบบที่ต้องมีการเปิด session ค้างไว้ แต่ใน v2 คาดหวังให้ server เรียกใช้งาน large-language-model provider โดยตรง หรือใช้รูปแบบ InputRequiredResult ซึ่ง client จะส่งข้อมูลที่ขาดหายไปผ่านคำขอในลำดับถัดไป
  • Roots – ก่อนหน้านี้ client จะส่ง URIs เพื่อจำกัดขอบเขตการมองเห็นทรัพยากรภายนอกของ server แนวทางใหม่จะส่ง URIs เหล่านั้นในรูปแบบของ tool parameters หรือฝังไว้ใน resource fields ของคำขอ ซึ่งจะช่วยตัดขั้นตอนการเจรจา (negotiation) เรื่อง “roots” แยกต่างหากออกไป
  • Logging – logging headers ในระดับโปรโตคอลจะหายไป ให้เขียนลงใน stderr สำหรับการทำ local debugging หรือเลือกใช้ OpenTelemetry สำหรับการทำ production observability แทน

ระยะเวลาการ deprecate จะมีเวลาหนึ่งปี โดยฟีเจอร์ที่ถูก deprecate จะยังคงใช้งานได้ในช่วงเวลาดังกล่าว เพื่อให้ทีมต่างๆ มีเวลาในการ refactor ก่อนที่โปรโตคอลจะปฏิเสธการใช้งานฟีเจอร์เหล่านั้น

สิ่งใหม่นอกเหนือจากความเป็น stateless

MCP v2 เพิ่ม extension อย่างเป็นทางการสองรายการ:

  • MCP Apps – วิธีการแบบ lightweight ในการอธิบาย user interfaces ที่ถูก render โดย server ซึ่งโปรโตคอลสามารถเรียกใช้งานได้
  • Tasks – รูปแบบสำหรับการจัดการการทำงานที่ใช้เวลานาน (long-running operations) ซึ่งอาจครอบคลุมหลายรอบของ request-response cycles

ทั้งสอง extension นี้ใช้โมเดลคำขอแบบ stateless และหลีกเลี่ยงการเก็บ session state แบบซ่อนเร้น

ความเสี่ยงและข้อควรระวัง

การเปลี่ยนแปลงนี้ไม่ใช่การอัปเกรดแบบ plug-and-play เนื่องจาก v2 SDKs ยังอยู่ในช่วง beta และ public APIs อาจมีการเปลี่ยนแปลงก่อนที่จะมีการปล่อยเวอร์ชัน stable สำหรับงานระดับ production ที่ไม่สามารถยอมรับ breaking changes ได้ ให้ใช้งาน v1 SDK เวอร์ชัน stable ต่อไปจนกว่า v2 SDK จะออกเวอร์ชันเต็ม

นักพัฒนาจำเป็นต้องตรวจสอบ (audit) โค้ดที่มีอยู่เดิมว่ามีการใช้งานระบบย่อยทั้งสามที่กำลังจะถูก deprecate หรือไม่

แผนการย้ายระบบ (migration roadmap) ที่ใช้งานได้จริง

  1. ตรวจสอบตั้งแต่วันนี้ – สแกนบริการของคุณเพื่อหาการใช้งาน handshake, Mcp-Session-Id, การเรียก sampling, roots URIs และ protocol-level logging ระบุโค้ดที่อาจจะพังภายใต้โมเดลแบบ stateless
  2. ทดสอบบน node ที่ไม่สำคัญ – เมื่อ v2 SDK เวอร์ชัน stable ถูกปล่อยออกมา ให้สร้าง sandbox server ขึ้นมา เชื่อมต่อกับ test client และตรวจสอบว่า meta fields ที่จำเป็นทั้งหมดมีอยู่และถูกตีความอย่างถูกต้อง
  3. ย้ายระบบทั้งหมดก่อนกำหนดเส้นตาย – ดำเนินการเปลี่ยนผ่านบน production nodes ทั้งหมดให้เสร็จสิ้นก่อนสิ้นสุดระยะเวลาผ่อนปรนหนึ่งปี เพื่อหลีกเลี่ยงการถูกปฏิเสธการทำงานในขณะรันไทม์ (runtime rejections)

สิ่งที่ต้องติดตามต่อไป

  • การปล่อย stable SDK – SDK เวอร์ชัน beta จะถูกระงับการเปลี่ยนแปลง (frozen) และจะมีการเผยแพร่แพ็กเกจ stable ที่มีการระบุเวอร์ชัน เวอร์ชันนั้นจะเป็นเป้าหมายที่ปลอดภัยสำหรับการ deploy งานที่สำคัญ

การเปลี่ยนผ่านนี้จะต้องมีการแก้ไขโค้ดและช่วงเวลาสั้นๆ ในการทดลองใช้ beta-SDK แต่ผลตอบแทนที่ได้รับคือจุดเชื่อมต่อ (integration point) ที่สะอาดขึ้นและขยายขนาดได้ง่ายขึ้น (more scalable) สำหรับแอปพลิเคชันที่ทำงานบน LLM

สรุปสาระสำคัญ: หาก stack ของคุณยังต้องพึ่งพา MCP handshakes หรือระบบย่อยทั้งสามที่กำลังจะถูก deprecate ให้เริ่มทำการตรวจสอบตั้งแต่วันนี้ แม้ระยะเวลาผ่อนปรนหนึ่งปีจะดูยาวนาน แต่ต้นทุนที่แท้จริงคือความพยายามในการ refactor ไม่ใช่เส้นตาย