แผนที่ทาง MCP ฉบับ ส.ค. 2026 อะไรตัดสินใจแล้วและอะไรยังเป็นความตั้งใจ

เมื่อวันที่ 22 ส.ค. 2026 ทีมดูแล Model Context Protocol อัปเดตหน้าแผนที่ทาง วางกรอบงานหกถึงสิบสองเดือนข้างหน้าไว้ห้าด้าน กระทู้บนกระดานนักพัฒนาได้ 200 คะแนน (นับ ณ วันที่ 23 ส.ค.) และเกิดความเข้าใจผิดสองข้อในกระทู้นั้นที่หน้านี้จะแยกให้ชัด

ข้อมูลทั้งหมดในหน้านี้เป็นข้อมูล ณ วันที่ 23 ส.ค. 2026 หน้าแผนที่ทางเป็นเอกสารที่แก้ทับที่เดิมโดยไม่มีฉบับเก็บถาวร เนื้อหาจึงเปลี่ยนได้โดยลิงก์ไม่เปลี่ยน

เรื่องที่ต้องอ่านก่อนทุกข้อ

หน้านี้เขียนกำกับตัวเองไว้ว่า "This roadmap reflects current thinking rather than firm commitments. Priorities may shift, some items may be delivered differently than described or deferred, and work not listed here may still be included in the release." (roadmap)

และไม่มีรายการไหนในหน้านี้ที่ระบุวันเป้าหมายหรือหมายเลขรุ่นของสเปกรอบหน้าเลย รุ่นเดียวที่มีเลขจริงคือรุ่น 2026-07-28 ที่ประกาศไปแล้ว

ห้าด้านที่จะได้รับการพิจารณาก่อน

เอกสารระบุตรงตัวว่า "Specification Enhancement Proposals (SEPs) that fall within the priority areas below get expedited review and have the best chance of acceptance. SEPs outside them aren't rejected automatically, but expect a longer queue and a higher bar for justification."

ห้าด้านคือ Agentic Messaging Primitives, HTTP-Native Transport Unification and Hardening, Agent Identity and Enterprise-Ready Security, Improved Primitives และ Improved SDK Developer Experience

แยกให้ออกว่าอะไรอยู่ระดับไหน

ของในหน้านี้ไม่ได้อยู่ระดับความแน่นอนเดียวกัน แบ่งได้สามชั้น

ชั้นที่หนึ่ง ของที่ประกาศแล้วและมีผลบังคับ คือทุกอย่างในรุ่น 2026-07-28 ซึ่งไม่ได้อยู่ในแผนที่ทางเลย เพราะจบไปแล้ว

ชั้นที่สอง รายการที่มีคณะทำงานรับผิดชอบอยู่จริง เช่นการทำให้ช่องทางเชื่อมต่อรวมเป็นแบบเดียว การขยายระบบแคชไปรองรับ ETag และการปิดงาน DPoP

ชั้นที่สาม รายการที่คณะทำงานยังไม่ได้ตั้ง เอกสารเขียนว่า "Core Primitives WG (forming during this roadmap period)" สำหรับทั้งรูปผลลัพธ์ของการเรียกเครื่องมือและการค้นพบแบบทยอย และ "Agent Identity WG (forming during this roadmap period)" สำหรับ DPoP นี่เป็นชั้นที่ห่างจากความเป็นจริงมากที่สุด และเป็นชั้นที่ข่าวมักเล่าเหมือนว่าตัดสินใจแล้ว

รูปผลลัพธ์ของการเรียกเครื่องมือ

ปัญหาที่เอกสารระบุคือ tools/call ยอมให้คืนทั้ง content และ structuredContent พร้อมกัน ซึ่ง "has confused server and client authors alike and produced diverging implementations"

สิ่งที่เขียนไว้เป็นความตั้งใจ คือ "We want to spend this roadmap period improving the shape of the tools/call interface for more consistent semantics" และรายการส่งมอบเขียนว่า "Redesign the tools/call interface to resolve fidelity disparities among return types and streamline the handling of structured and unstructured output"

ข้อควรระวังคือไม่มีหมายเลข SEP ไม่มีรุ่นเป้าหมาย และไม่มีกำหนดวัน จึงพูดได้แค่ว่ากำลังจะออกแบบใหม่ พูดไม่ได้ว่าของเดิมจะเลิกใช้เมื่อไร

การค้นพบแบบทยอย

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

แต่ถ้อยคำจริงระวังตัวสองชั้น คือเอกสารเขียนว่าเพิ่งเริ่มความพยายามเพื่อ "define what an experimental server-side discovery mechanism would look like" คือนิยามว่ากลไกแบบทดลองควรมีหน้าตาอย่างไร ยังไม่ใช่การลงมือทำกลไกนั้น

ตัวตนของ agent

โจทย์ที่เอกสารตั้งไว้ตรงมาก คือ "MCP authorization assumes a person with a browser at consent time. Increasingly the caller is an agent: a cloud workload with its own identity, acting for a user who isn't present, or spawning sub-agents that should get narrower authority than their parent." และระบุว่าเซิร์ฟเวอร์ที่มีอยู่ "lean on pasted API keys and long-lived refresh tokens"

งาน DPoP ที่จะปิดให้จบคือการทำร่างที่เปิดค้างอยู่แล้วให้เสร็จ ไม่ใช่การเริ่มใหม่ ร่างนั้นคือ SEP-1932 ซึ่งเปิดตั้งแต่เดือน ธ.ค. 2025 และยังเปิดอยู่ ระวังอย่าสับสนกับ SEP-1933 ซึ่งเป็นเรื่อง Workload Identity Federation คนละเรื่องกัน

เรื่องที่คนเข้าใจผิดบ่อย

• แผนที่ทางไม่ได้จะเลิกใช้ stdio สิ่งที่เสนอคือให้พูด Streamable HTTP ผ่าน stdin และ stdout สำหรับเซิร์ฟเวอร์ที่รันบนเครื่องตัวเอง โดยเอกสารเขียนว่า "We believe we can use HTTP/2 over stdio to get multiplexed HTTP transport while retaining the security and lifecycle guarantees of a subprocess" ซึ่งเป็นความเชื่อ ไม่ใช่การตัดสินใจ ตัวที่ถูกประกาศเลิกใช้จริงคือ HTTP+SSE ซึ่งเป็นช่องทางคนละตัวและเกิดขึ้นในรุ่น 2026-07-28 แล้ว
• อ่านว่าแผนที่ทางคือสิ่งที่จะทำให้เซิร์ฟเวอร์เดิมพัง ของที่ทำให้พังจริงอยู่ในรุ่น 2026-07-28 ที่บังคับใช้แล้ว ไม่ใช่ในแผนที่ทางฉบับนี้
• เอาถ้อยคำจากบล็อกประกาศไปปนกับหน้าเอกสาร กระทู้บนกระดานนักพัฒนาลิงก์ไปที่บล็อก ส่วนคำพูดที่ยกในหน้านี้ทั้งหมดมาจากหน้าเอกสาร สองอันใช้ถ้อยคำต่างกัน
• อ่านว่ารายการในแผนที่ทางมีกำหนดส่ง ไม่มีรายการไหนมีวันหรือเลขรุ่นกำกับเลย

ของที่บังคับใช้แล้วในรุ่น 2026-07-28 และกระทบของเดิมจริง

รายการนี้คือสิ่งที่ทีมพัฒนาต้องดูก่อนแผนที่ทาง (changelog)

• ระบบ session ระดับโปรโตคอลและหัวข้อ Mcp-Session-Id ถูกถอดออก
• ขั้นตอนจับมือ initialize กับ notifications/initialized ถูกถอดออก โปรโตคอลกลายเป็นไร้สถานะ รุ่นและความสามารถย้ายไปอยู่ใน _meta
• เพิ่ม server/discover และเซิร์ฟเวอร์ต้องมี
• subscriptions/listen มาแทนช่องทาง HTTP GET และแทน resources/subscribe กับ resources/unsubscribe
• ping, logging/setLevel และ notifications/roots/list_changed ถูกถอดออก
• Tasks ย้ายออกจากแกนไปเป็นส่วนขยาย tasks/result ถูกแทนด้วยการถามซ้ำผ่าน tasks/get และ tasks/list ถูกถอดออก
• ผลลัพธ์ทุกแบบต้องมีฟิลด์ resultType
• การต่อสายที่ขาดแล้วต่อกลับถูกถอดออก ถ้าสายขาดคำขอนั้นหายไป และไคลเอนต์ต้องส่งใหม่ด้วยหมายเลขคำขอใหม่
• ประกาศเลิกใช้ Roots, Sampling, Logging และช่องทาง HTTP+SSE
• รหัสข้อผิดพลาดถูกเปลี่ยนเลข เช่นหาทรัพยากรไม่เจอ จาก -32002 เป็น -32602
• กติกาใหม่คือช่วงเวลาแจ้งเลิกใช้ต้องไม่ต่ำกว่าสิบสองเดือน

จุดที่ถ้อยคำสองหน้าไม่ตรงกันและต้องยึดฉบับบังคับใช้ คือแผนที่ทางเล่าว่า SEP-2549 เป็นการ "adding" ฟิลด์ ttlMs และ cacheScope แต่บันทึกการเปลี่ยนแปลงเขียนว่า "Require ttlMs and cacheScope fields" คือบังคับ ไม่ใช่แค่เพิ่มให้เลือกใช้

เรื่องที่แผนที่ทางพูดถึงแต่ข่าวมักไม่เล่า

• ด้าน Improved Primitives เปิดช่องว่าอาจเลิกใช้ content annotations ด้วย โดยเขียนว่า "If they aren't useful, we should consider deprecating them"
• ด้านช่องทางเชื่อมต่อจะขยายระบบแคชไปรองรับ ETag เพื่อให้กำหนดรุ่นของผลลัพธ์ได้ โดยเฉพาะผลของการเรียกเครื่องมือ
• ด้านแรกครอบคลุมเหตุการณ์ที่เซิร์ฟเวอร์เป็นฝ่ายส่งเอง รวมถึง webhook
• ด้านความปลอดภัยยังมีเรื่องการยืนยันว่ามีคนอยู่จริง เพื่อแยกไคลเอนต์ที่มีคนใช้ออกจาก agent ที่รันเอง
• ด้าน SDK มีการทดลองสร้าง SDK และตัวอย่างจากสเปกโดยอัตโนมัติ แล้วตรวจกับชุดทดสอบความสอดคล้อง

คำถามที่ยังไม่มีคำตอบ

• ยังไม่มีวันหรือเลขรุ่นของสเปกรอบถัดไป
• ยังไม่รู้ว่ารูปผลลัพธ์ของ tools/call จะเปลี่ยนไปทางไหน และของเดิมจะมีช่วงเปลี่ยนผ่านนานแค่ไหน
• ยังไม่รู้ว่าคณะทำงานสองชุดที่ระบุว่ากำลังจะตั้ง จะตั้งเสร็จเมื่อไร