Skip to content
ข่าวนี้คืออะไร
วันที่ 22 สิงหาคม 2026 ทีมผู้ดูแล core ของ Model Context Protocol หรือ MCP เผยแพร่ roadmap ฉบับใหม่บนบล็อกทางการ เขียนโดย David Soria Parra และ Den Delimarsky สอง lead maintainer เอง เนื้อหาคือทิศทางของ protocol ไปอีก 6 ถึง 12 เดือนข้างหน้า ก่อน spec รอบถัดไปจะออก
5 ทิศทางหลักคือ
- Agentic messaging primitives งาน agent ไม่ได้เป็นแบบถามตอบสั้น ๆ แล้ว MCP จะเพิ่ม webhooks และ channels ให้ server แจ้งกลับเองได้เมื่องานเสร็จ รวมถึงดัน extension ชื่อ Tasks ให้กลายเป็นส่วนของ spec แกนกลาง
- HTTP-native transport unification หลัง spec 2026-07-28 ทำให้ remote MCP server เป็น HTTP workload ปกติแล้ว รอบนี้จะดันให้ server ภายในที่คุยผ่าน stdio ใช้ Streamable HTTP แบบเดียวกัน รวมถึงเพิ่มกลไก caching แบบ ETag
- Agent identity and enterprise-ready security ปัจจุบัน authorization ของ MCP ออกแบบสำหรับคนกดอนุมัติในเบราว์เซอร์ แต่ caller ยุคนี้คือ agent ที่รันเป็น cloud workload มีตัวตนของตัวเอง ทำงานแทนคนที่ไม่ได้อยู่หน้าจอ ทิศทางคือใช้มาตรฐานที่มีอยู่จริงอย่าง DPoP, Workload Identity Federation และ token exchange แทนการแปะ API key กับ long-lived token
- Improved primitives รูปแบบผลลัพธ์ของ tools/call จะถูกออกแบบใหม่ให้ชัดเจน และเริ่มงาน progressive discovery ให้ agent เห็น tool เท่าที่จำเป็น แทนการถ่วง context ด้วย tool list ยักษ์ตั้งแต่ต้น conversation
- Improved SDK developer experience SDK และ quickstart จะค่อย ๆ ถูก generate จาก spec คู่กับ conformance test suite แทนการซ่อมด้วยมือทีละ release
ทำไมทีมเล็กควรสนใจ
ถ้าคุณกำลังต่อ agent เข้ากับระบบภายใน ไม่ว่าจะเป็น CRM, คลังสินค้า, ระบบเอกสาร หรือแม้แต่ LINE OA โอกาสสูงว่าชั้นเชื่อมต่อที่เลือกใช้ตอนนี้คือ MCP เพราะเป็นมาตรฐานเปิดที่ Claude, ChatGPT, Cursor, Codex และเครื่องมือหลัก ๆ รองรับกันแทบทั้งตลาด
roadmap นี้จึงไม่ใช่ข่าว lab แต่คือการบอกล่วงหน้าว่าโครงสร้างที่ทีมคุณจะเขียนในอีกไม่กี่เดือนควรหน้าตาเป็นอย่างไร
จุดที่กระทบกระเป๋าเงินและเวลามากที่สุดคือเรื่อง polling กับ identity
งาน agent หลายแบบไม่จบในคำขอเดียว อาจรันหลายนาที เช่น วิเคราะห์รายงาน สรุปเอกสาร หรือรอผลจากภายนอก วิธีที่ฝั่ง MCP ใช้กันทุกวันนี้คือ client ต้องถามไปเรื่อย ๆ ว่าเสร็จยัง roadmap เลิกแบบนั้น ให้ server แจ้งกลับผ่าน webhook ได้เอง คำว่า “เสร็จแล้ว” จะมี lifecycle กลาง ๆ เดียวกันทั้ง protocol
ด้าน identity ปัญหาที่ทุกทีมเจอคือ agent ต้องมี credential ของตัวเอง วิธีที่นิยมคือสร้าง API key แปะไว้ ซึ่งใช้งานได้แต่ลืม revoke ง่าย มองไม่เห็นว่าใครกำลังเรียกอะไร และขยายสิทธิ์เกินจำเป็นเอาง่าย ทิศทางใหม่คือให้ agent มี identity ตามมาตรฐานที่องค์กรใหญ่ใช้กันอยู่แล้ว จึงตรวจสอบได้ ตั้งสิทธิ์แบบเฉพาะงานได้ และ revoke ได้จริง
วิธีเอาไปใช้จริง
- ออกแบบ endpoint ให้พร้อมมี webhook ตั้งแต่วันนี้ งานที่รันนานเกิน 30 วินาทีควรมี task id ให้ client ถามสถานะได้ และเผื่อทางไว้ว่าอนาคตจะส่ง event กลับไปเองได้ ไม่ต้องรอ spec ออกก่อนค่อยรื้อ
- เลิกสร้าง API key ใหม่ให้ agent ทุกตัว เริ่มแยกให้ชัดว่าอันไหน identity ของคน อันไหนของระบบ อันไหนของ agent ประจำงาน แล้ววางแผนย้าย agent ที่สำคัญไปใช้ short-lived token เมื่อมาตรฐานใหม่มาถึง แทนการแปะ key ถาวรไว้ใน config
- จัด tool list ของ server ให้เล็กและแน่นก่อน อย่ารวมทุกอย่างเป็น server เดียวร้อย tool ให้แยกตามกลุ่มงานและเลือกเสร็จสรรพตาม use case แล้ว progressive discovery จะช่วยต่อให้เมื่อมาถึง
- ทำ result ของ tool ให้เป็นทางการเดียว เลือก format ผลลัพธ์ที่ชัดเจนซึ่ง client ทุกตัวอ่านได้ตรงกัน อย่าส่งทั้ง content และ structuredContent แบบความหมายซ้ำกัน เพราะรูปแบบเดิมกำลังจะถูกออกแบบใหม่
- ติดตามแบบถูกทาง ถ้าทีมมี use case ที่ต้องการ webhook หรือ identity แบบใหม่ ให้เข้าร่วม Working Group หรือเสนอ SEP ในพื้นที่ที่ roadmap ระบุ เพราะ proposal ที่ตรง priority area จะได้รับการพิจารณาเร็วกว่า
Operator Kit
Checklist ออกแบบ MCP server ให้พร้อม roadmap รอบหน้า
โครงสร้างงาน
- งานที่รันนานมี task id และ status endpoint ของตัวเอง
- เผื่อช่องทาง event กลับ เช่น รองรับ callback URL หรือ event queue ไว้แล้ว
- ผลลัพธ์ tool ใช้ format เดียวที่ชัดเจน ไม่ส่งความหมายซ้ำสองรูปแบบ
สิทธิ์และ identity
- แยกรายการ credential ว่าอันไหนของคน อันไหนของระบบ อันไหนของ agent
- Agent ที่จับเงินหรือข้อมูลลูกค้าต้องมี identity เฉพาะ ไม่ใช้ key รวมของทีม
- มีกระบวนการ revoke credential ของ agent ที่เลิกใช้แล้วภายใน 7 วัน
ขนาด tool list
- Server หนึ่งตัวไม่ควรเกินกลุ่มงานเดียว อย่ารวมทุกฝ่ายไว้ด้วยกัน
- ตั้งชื่อ tool ให้เห็นภาพงาน ไม่ใช่ชื่อ table หรือชื่อฟังก์ชันในโค้ด
- ทดสอบว่า agent เลือก tool ถูกเมื่อ list มีมากกว่า 20 ตัว
สัญญาณว่าควรรีเริ่มการออกแบบ
- Agent ต้อง polling สถานะงานทุก ๆ ไม่กี่วินาทีเป็นเวลานาน
- มี API key ที่ไม่มีใครรู้ว่าใครสร้างและใช้ที่ไหน
- Tool list ยาวจน agent เริ่มเลือกผิดหรือช้าลงอย่างเห็นได้ชัด
ข้อจำกัดที่ควรรู้
roadmap ไม่ใช่ spec ที่ใช้ได้ทันที เอกสารทางการเขียนไว้ชัดว่าเป็น current thinking ล้วน ๆ priority เปลี่ยนได้ บางอย่างอาจทำออกมาต่างจากที่เขียนหรือถูกเลื่อนออกไป อย่าเพิ่งเขียนโค้ดตาม webhook หรือ identity แบบใหม่จนกว่าจะมี draft spec จริง
ตัวเลขที่น่าสนใจอย่างจำนวนดาวน์โหลด SDK ที่ก้าวล้านเป็นบริบทความนิยมของ protocol ไม่ใช่ตัวชี้วัดว่าโครงสร้างเดิมของคุณผิด ทีมที่ใช้ MCP แบบถามตอบสั้น ๆ อยู่แล้วก็ยังทำงานได้ดีต่อไป
เริ่มต้นวันนี้
ถ้าทีมคุณกำลังจะต่อ agent เข้ากับระบบภายในและอยากออกแบบให้ถูกทางตั้งแต่ต้น Data-Espresso ช่วยวางแผน MCP server ที่พร้อมรับ roadmap รอบหน้า ตั้งแต่แบ่งกลุ่ม tool จัดการ identity ของ agent ไปจนถึงรันทั้งหมดบน workspace ส่วนตัวผ่าน OPB Stack ที่ควบคุมสิทธิ์ทุกตัวได้จากที่เดียว