MCP ประกาศ Roadmap ใหม่ — เลิกให้ client นั่ง polling, ทำ HTTP over stdio, และแก้ปัญหา "เซิร์ฟเวอร์ร้อย tool" ด้วย progressive discovery

22 สิงหาคม 2026 — David Soria Parra และ Den Delimarsky สอง Lead Maintainer ของ Model Context Protocol (MCP) เผยแพร่ roadmap ฉบับใหม่ที่กำหนดทิศทางของโปรโตคอลใน 6–12 เดือนข้างหน้า ครอบคลุมทั้ง spec รอบถัดไปและงานที่ไกลกว่านั้น

นี่ไม่ใช่เอกสารการตลาด แต่เป็นรายการงานที่มีชื่อ Core Maintainer กำกับรายด้าน มี Working Group รับผิดชอบ และมีหมายเลข SEP อ้างอิงจริง สาระที่สำคัญที่สุดสำหรับคนเขียน MCP server คือประโยคเดียวในหน้า roadmap: SEP ที่ตรงกับ 5 ด้านนี้จะได้รีวิวแบบเร่งด่วนและมีโอกาสผ่านสูงสุด ส่วนที่อยู่นอกกรอบไม่ถูกปฏิเสธอัตโนมัติ แต่ต้องรอคิวยาวกว่าและมีเกณฑ์สูงกว่า

1. เลิกให้ client นั่งถามซ้ำ ๆ ว่า “เสร็จหรือยัง”

ทีมยอมรับตรง ๆ ว่า workload แบบ agent ยุคนี้ไม่เข้ากับรูปแบบ request-response อีกแล้ว — งานรันเป็นนาที เซิร์ฟเวอร์ต้อง push ผลลัพธ์ได้ และต้องมีวิธีเข้าไปแทรกกลางทาง MCP ค่อย ๆ เพิ่มของมารองรับหลายชิ้นแล้ว ทั้ง Tasks, subscriptions/listen และ progress notifications แต่ปัญหาคือมันกระจายอยู่คนละ Working Group

ประโยคที่ตรงจุดที่สุดใน roadmap คือ “ความเสี่ยงคือเรามีคำตอบสามแบบสำหรับคำถาม ‘เซิร์ฟเวอร์ยังไม่เสร็จ’ ที่ไม่ได้ใช้ lifecycle, โมเดล cancellation หรือ error surface ร่วมกัน”

รอบนี้จึงโฟกัสสองงาน:

• Server-initiated events (Triggers & Events WG) — channels และ subscriptions สำหรับ push delivery รวมถึง webhooks เพื่อให้เซิร์ฟเวอร์บอก client ได้เองว่างานเสร็จ แทนที่จะให้ client polling ซึ่งเอกสารเรียกตรง ๆ ว่า “expensive”
• Composition review ข้าม Agents, Transports และ Triggers & Events WG เพื่อให้ primitive ใหม่ ๆ ประกอบกันได้จริง

และงานที่เดินต่อคือดัน Tasks extension (SEP-2663) เข้าสู่ core protocol

2. HTTP over stdio — รวมทางเดินให้เหลือเส้นเดียว

สเปก 2026-07-28 ทำให้ remote MCP server กลายเป็น HTTP workload ธรรมดาที่โฮสต์ได้บนโครงสร้างพื้นฐานเดิมของทีม (เราเคยเขียนถึงตอนสเปกนี้ final ไปแล้ว) แต่ผลข้างเคียงคือ ทุกฟีเจอร์ที่เป็น HTTP-native ต้องออกแบบซ้ำอีกรอบสำหรับ stdio ไม่งั้นใช้กับเซิร์ฟเวอร์ local ไม่ได้ SDK ต้องดูแล transport pipeline สองสาย และ metadata ของโปรโตคอลก็ซ้ำกันระหว่าง HTTP header กับ field ในข้อความจนเซิร์ฟเวอร์ต้อง cross-validate เอง

แผนคือทำให้เหลือ transport เดียว: Streamable HTTP พูดผ่าน stdin/stdout โดยทีมเชื่อว่าจะใช้ HTTP/2 over stdio เพื่อให้ได้ multiplexing โดยยังคงการรับประกันด้านความปลอดภัยและ lifecycle ของ subprocess ไว้

อีกงานในด้านนี้คือ caching — สเปกล่าสุดเพิ่ม ttlMs และ cacheScope ให้ผลลัพธ์ list และการอ่าน resource แล้ว (SEP-2549) รอบนี้จะขยายไปถึง ETags เพื่อทำ versioning ให้ผลลัพธ์ของ primitive โดยเฉพาะ tool call

3. Agent identity — เลิกแปะ API key กับ refresh token อายุยาว

ด้านนี้น่าจะเป็นด้านที่เปลี่ยนชีวิตทีม enterprise มากที่สุด เอกสารสรุปปัญหาไว้คมมาก: “MCP authorization ตั้งสมมติฐานว่ามีคนนั่งอยู่หน้าเบราว์เซอร์ตอนกด consent” แต่ความจริงคือผู้เรียกกลายเป็น agent มากขึ้นเรื่อย ๆ — เป็น cloud workload ที่มีตัวตนของตัวเอง ทำงานแทนผู้ใช้ที่ไม่ได้อยู่ตรงนั้น หรือ spawn sub-agent ที่ควรได้สิทธิ์แคบกว่าตัวแม่ ทุกวันนี้ MCP server ส่วนใหญ่จึงพึ่ง API key ที่แปะเอาไว้และ refresh token อายุยาว

งานรอบนี้ (Agent Identity WG ซึ่งกำลังจะตั้ง):

• ปิดสเปก DPoP (Demonstrating Proof of Possession) และผลักดันให้มีคนใช้จริงในวงกว้าง
• นิยามเส้นทางที่ชัดเจนสำหรับ agent identity และ delegation ผ่าน Workload Identity Federation (SEP-1933), ID-JAG (Identity Assertion JWT Authorization Grant) ที่อยู่เบื้องหลัง Enterprise-Managed Authorization และ token exchange ตาม RFC 8693
• ทำงานร่วมกับ IETF OAuth และ WIMSE working group โดยตรง

มีอีกหัวข้อที่อยู่ระหว่างพิจารณาและน่าสนใจมากคือ human-presence attestation — วิธีแยกว่า client ที่เรียกเข้ามาเป็นคนกดจริงหรือเป็น agent แบบ headless

4. tools/call ที่สับสน และเซิร์ฟเวอร์ที่มี tool เป็นร้อย

ปัญหาแรกเป็นเรื่องที่คนเขียน server เจอกันทุกคน: tools/call อนุญาตให้คืนทั้ง content และ structuredContent พร้อมกัน ผลคือ implementation แตกกันไปคนละทาง และคนเขียนเซิร์ฟเวอร์ไม่มีทางรู้ว่า client ตัวไหนจะเอารูปแบบไหนไปวางต่อหน้าโมเดล รอบนี้ Core Primitives WG (กำลังตั้ง) จะ ออกแบบ interface ของ tools/call ใหม่ ให้เหลือสัญญาเดียวที่ชัดเจน

ปัญหาที่สองคือเรื่องสเกล และเป็นข้อที่คนใช้ agent จริงจะพยักหน้าตาม: “การต่อกับเซิร์ฟเวอร์ที่มี tool ร้อยตัว แปลว่าโมเดลต้องจ่ายค่า surface ทั้งก้อนก่อนที่ผู้ใช้จะถามอะไรสักคำ และการเลือก tool ก็มักจะแย่ลงเมื่อรายการยาวขึ้น”

ทางแก้คือ progressive discovery — ให้เซิร์ฟเวอร์เปิดประตูเล็ก ๆ ก่อน แล้วค่อยเผยแคตตาล็อกเพิ่มเมื่อบทสนทนาแคบลง โดยออกแบบให้ทำงานร่วมกับงาน caching ในข้อ 2

นอกจากนี้ยังมีการทบทวน primitive annotations ที่ประกาศ audience และ priority ของเนื้อหา ซึ่งทีมพูดตรง ๆ ว่าถ้ามันไม่มีประโยชน์จริง “เราควรพิจารณาถอดมันทิ้ง” — ความตรงไปตรงมาแบบนี้หาไม่ค่อยได้ในเอกสาร roadmap

5. SDK ที่ generate จากสเปก แทนที่จะเขียนมือ

ด้านสุดท้ายเป็นการทดลองที่น่าจับตา ทุกวันนี้ SDK, reference server และ quickstart ของ MCP ถูกดูแลด้วยมือทั้งหมด ทีมเสนอให้ สเปกบวก conformance test suite ที่มนุษย์รีวิวแล้ว เป็น source of truth แล้ว regenerate ของพวกนี้ทุกรอบ release แทนการไล่ซ่อมทีหลัง

รอบนี้จะทำ generated-artifacts experiment: generate SDK ระดับ Tier 1 หนึ่งตัวพร้อม quickstart จากสเปก ตรวจกับ conformance suite แล้วเผยแพร่ผลว่าชั้นไหนควรเป็น deterministic codegen และชั้นไหนควรให้โมเดลช่วย

เหตุผลที่ทีมยกมาสะท้อนยุคสมัยได้ดี: “เรื่องนี้สำคัญยิ่งขึ้นเมื่อนักพัฒนาจำนวนมากสร้าง MCP client และ server ด้วยการชี้ agent ไปที่ไลบรารีของเรา ซึ่งความชัดเจนของ API และความถูกต้องของเอกสารเป็นตัวตัดสินว่าโค้ดจะใช้ได้เลยหรือไม่” — เอกสารที่เขียนให้ agent อ่าน ไม่ใช่แค่มนุษย์

มุมมอง AI Curator

roadmap นี้อ่านแล้วรู้สึกได้ว่า MCP กำลังข้ามเส้นจาก “โปรโตคอลที่น่าตื่นเต้น” ไปเป็น โครงสร้างพื้นฐานที่ต้องรับน้ำหนัก production และของสามอย่างที่บอกเรื่องนี้ชัดที่สุดไม่ใช่ฟีเจอร์หวือหวา แต่คือ caching, ETag และ identity federation — คำศัพท์ชุดเดียวกับที่วงการ API มาตรฐานใช้กันมาสิบปี การที่ MCP เดินมาถึงคำเหล่านี้แปลว่ามีคนรันมันจริงจังพอจะเจ็บกับมันแล้ว

สำหรับทีมไทยที่ทำ MCP server อยู่ ผมคิดว่ามี สามข้อที่ควรลงมือตั้งแต่วันนี้ โดยไม่ต้องรอสเปกออก

ข้อแรก — หยุดออกแบบ auth รอบ API key ที่แปะไว้ในไฟล์ config ถ้าเซิร์ฟเวอร์ของคุณจะขายให้ลูกค้าองค์กรในไทยหรือ SEA ในปีหน้า สิ่งที่ฝ่ายความปลอดภัยของธนาคารหรือโรงพยาบาลจะถามคือ “ตัวตนของ agent ตัวนี้คืออะไร ใครมอบสิทธิ์ให้ และสิทธิ์หมดอายุเมื่อไหร่” ซึ่งเป็นคำถามที่ DPoP กับ Workload Identity Federation ถูกออกแบบมาตอบพอดี ทีมที่เริ่มคิดเรื่องนี้ก่อนจะไม่ต้องรื้อทั้งระบบตอนสเปกลง

ข้อสอง — ทบทวนจำนวน tool ที่คุณ export ประเด็น progressive discovery กระทบต้นทุนโดยตรง ทุกวันนี้ทุก tool description ที่คุณเขียนคือโทเคนที่ลูกค้าจ่ายทุกครั้งที่เปิดบทสนทนา ไม่ว่าจะได้ใช้หรือไม่ และงานวิจัยหลายชิ้น (รวมถึงเปเปอร์เรื่อง agent skills ที่เราเขียนถึงในวันเดียวกันนี้) ชี้ตรงกันว่า ความแม่นของการเลือกเครื่องมือลดลงอย่างรุนแรงเมื่อรายการยาวขึ้น เซิร์ฟเวอร์ที่มี 12 tool ที่ออกแบบดี มักชนะเซิร์ฟเวอร์ที่มี 90 tool แบบยัดทุกอย่าง

ข้อสาม — ถ้าคุณอยากมีส่วนกำหนดทิศทาง ตอนนี้คือจังหวะ roadmap เขียนชัดว่า SEP ที่มี Working Group หนุนหลังและโยงเข้า roadmap ได้ จะเดินเร็วที่สุด และหลาย WG (Agent Identity, Core Primitives) เพิ่งกำลังตั้ง — ช่วงที่ห้องยังว่างคือช่วงที่เสียงหนึ่งเสียงมีน้ำหนักที่สุด ระบบนิเวศ MCP ทุกวันนี้ยังถูกกำหนดโดยคนไม่กี่สิบคนในไม่กี่ timezone และมุมมองจากทีมที่รันงานภาษาไทย, งาน compliance แบบ PDPA หรือ workload ที่แบนด์วิดท์แพงกว่าฝั่งอเมริกา ยังแทบไม่มีอยู่ในบทสนทนา

จุดที่ผมจะจับตาที่สุดคือ HTTP/2 over stdio ฟังดูเป็นรายละเอียดวิศวกรรมเล็ก ๆ แต่ถ้าทำสำเร็จ มันลบเส้นแบ่งระหว่าง “เซิร์ฟเวอร์ local” กับ “เซิร์ฟเวอร์ remote” ออกจากใจของนักพัฒนาไปเลย — เขียนครั้งเดียว ทำงานได้ทั้งบนเครื่องและบนคลาวด์ ซึ่งเป็นสิ่งที่โปรโตคอลระดับนี้ควรให้ได้ตั้งแต่แรก

แหล่งข่าว

• The New MCP Roadmap — Model Context Protocol Blog, 22 ส.ค. 2026
• Roadmap — Model Context Protocol Documentation — หน้า roadmap ฉบับเต็มพร้อมชื่อ Core Maintainer และ SEP รายด้าน
• The 2026-07-28 Specification — สเปกก่อนหน้าที่ roadmap นี้ต่อยอด
• Working and Interest Groups — รายชื่อกลุ่มที่เปิดรับผู้ร่วมพัฒนา