MCP รับ Agent Skills เข้าสเปกอย่างเป็นทางการ — SEP-2640 ขึ้นสถานะ Final ให้เสิร์ฟสกิลผ่าน skill:// พร้อมกฎความปลอดภัยที่สั่งห้าม allowed-tools ของสกิลจากเซิร์ฟเวอร์

SEP-2640: Skills Extension ถูก merge เข้า repo ของสเปก Model Context Protocol เมื่อ 13 ก.ย. 2026 เวลา 21:27 UTC และหน้า SEP บน modelcontextprotocol.io แสดงสถานะ Final บน Extensions Track แล้ว ข้อเสนอนี้เปิดมาตั้งแต่ 23 เม.ย. 2026 รวมเวลาเกือบห้าเดือน เขียนโดย Peter Alexander, Ola Hungerford, Sambhav Kothari และ Aditya Kumar ในนาม Skills Over MCP Working Group (ซึ่งวันถัดมา 14 ก.ย. ก็เพิ่งบันทึก Kothari เป็น WG lead)

สาระคือ การเสิร์ฟ Agent Skills ผ่าน MCP ได้มีวิธีมาตรฐานเสียที ก่อนหน้านี้เซิร์ฟเวอร์ MCP กับสกิลที่สอนเอเจนต์ให้ใช้เซิร์ฟเวอร์นั้น ถูกเวอร์ชัน ค้นหา และติดตั้งแยกกันคนละทาง ใครติดตั้งเซิร์ฟเวอร์จาก registry ก็ไม่มีสัญญาณใด ๆ บอกว่ามีสกิลคู่กันอยู่ ส่วนช่องทางเดิมที่พอใช้ได้คือฟิลด์ instructions ก็มีขนาดจำกัดในทางปฏิบัติ — SEP ยกตัวอย่าง สกิล mcpGraph ยาว 875 บรรทัด ที่ยัดลงช่องนั้นไม่ได้ และผลคือหลายโปรเจกต์ต่างคนต่างประดิษฐ์ URI skill:// ของตัวเองโดยความหมายไม่ตรงกัน

เป็น convention บน Resources เดิม ไม่ใช่ primitive ใหม่

จุดออกแบบที่สำคัญที่สุดคือ SEP นี้ ไม่เพิ่ม primitive ใหม่ ให้โปรโตคอล แต่ให้ทุกไฟล์ในไดเรกทอรีของสกิลเป็น MCP resource ธรรมดา ภายใต้ URI รูปแบบ:

skill://<skill-path>/<file-path>

โดย segment สุดท้ายของ <skill-path> ต้องเท่ากับ ค่า name ใน frontmatter ของ SKILL.md (เช่น skill://acme/billing/refunds/SKILL.md แปลว่า prefix คือ acme/billing และชื่อสกิลคือ refunds) ชื่อสกิลจึงอ่านออกจาก URI ได้โดยไม่ต้องเปิดไฟล์ ตัวรูปแบบสกิลเอง — โครงไดเรกทอรี, YAML frontmatter, กฎตั้งชื่อ, โมเดล progressive disclosure — SEP โยนไปให้ สเปก Agent Skills ที่ agentskills.io ทั้งหมด ที่นี่นิยามแค่ “การขนส่ง” เท่านั้น ผลพลอยได้คือ host ที่มองทรัพยากร MCP เป็นระบบไฟล์เสมือนอยู่แล้ว กินสกิลจาก MCP ได้เหมือนสกิลบนดิสก์

เมท็อดที่เพิ่มมามีสามตัว สองตัวแรก บังคับ สำหรับเซิร์ฟเวอร์ที่ประกาศ extension io.modelcontextprotocol/skills:

• skills/list — ไล่รายการสกิลที่เซิร์ฟเวอร์ให้บริการ รองรับ pagination และ (ตั้งแต่โปรโตคอลเวอร์ชัน 2026-07-28) แนบ ttlMs/cacheScope ตาม SEP-2549
• skills/get — ขอ entry ของสกิลเดียวจาก URI ใช้กับสกิลที่ไม่ปรากฏใน listing หรือใช้รีเฟรชหลัง digest ไม่ตรง
• resources/directory/read — ตัวเลือกเสริม ไล่ลูกโดยตรงของ directory resource เปิดใช้เมื่อเซิร์ฟเวอร์ประกาศ directoryRead: true เท่านั้น

สิ่งที่ skills/list คืนมาไม่ใช่สรุปย่อ แต่เป็น manifest เต็มของสกิล: frontmatter ที่คัดลอกมาตรง ๆ ทั้งก้อน บวก resources ที่ไล่ไฟล์ทุกไฟล์พร้อม digest (SHA-256) และ size เป็นไบต์ host จึงสร้าง registry, แสดงให้ผู้ใช้อนุมัติ, ผูกการอนุมัติกับเนื้อหา และตรวจไฟล์ที่อ่านทีหลังได้จากการไล่ listing รอบเดียว ไม่ต้องยิงเพิ่มรายสกิล ส่วนสกิลที่เนื้อหาถูกสร้างสด ๆ จนออก digest คงที่ไม่ได้ ต้องประกาศ "resources": "dynamic" ให้ชัด เพื่อให้ host แยกออกว่านี่คือ “ตรวจสอบไม่ได้โดยตั้งใจ” ไม่ใช่ entry ที่เขียนพัง (entry ที่ไม่มี resources เลยถือว่าไม่ถูกต้องและห้ามโหลด)

สเปกยังตรึงเพดานสองตัวไว้ให้ทุกฝ่ายรู้เท่ากัน คือ 512 ไฟล์ต่อสกิล และ 16 MiB รวมทั้งสกิล ซึ่งนับได้จาก entry ก่อนจะดาวน์โหลดไฟล์แม้แต่ไฟล์เดียว

ครึ่งหนึ่งของเอกสารคือกฎกันสกิลเล่นงาน host

ส่วนที่อ่านแล้วน่าสนใจกว่าตัวโปรโตคอลคือ Security Implications เพราะมันยอมรับตรง ๆ ว่าเนื้อสกิลคือข้อความสั่งงานที่ไหลเข้าโมเดล = พื้นผิว prompt injection และสกิลจาก MCP อันตรายกว่าการเรียกทูลระยะไกล เพราะมัน “วางไบต์ที่เซิร์ฟเวอร์เขียนลงบนระบบไฟล์ของ host แล้วสั่งให้โมเดลรันมันด้วยทูลฝั่ง host ได้” ข้อบังคับที่ออกมาจึงค่อนข้างแข็ง:

• ต้องบอกโมเดลว่าสกิลมาจากไหน — host ต้องติดป้ายต้นทางตอนเนื้อหาเข้า context และห้ามทำให้สกิลจาก MCP ดูแยกไม่ออกจากสกิลในเครื่อง
• ห้าม allowed-tools มีผลโดยอัตโนมัติ — ฟิลด์ที่สกิลบนดิสก์ใช้ประกาศทูลที่ใช้ได้ระหว่างรัน ต้องถูกเมิน เมื่อสกิลมาทาง MCP เว้นแต่ผู้ใช้อนุมัติการให้สิทธิ์นั้นเจาะจงรายสกิล เพราะ “เซิร์ฟเวอร์ระยะไกลที่ใส่ allowed-tools คือการ ขอ สิทธิ์ที่สูงขึ้นบนเครื่องคุณ ไม่ใช่การประกาศคุณสมบัติของสภาพแวดล้อมตัวเอง”
• การอนุมัติผูกกับเนื้อหา — ถ้า entry รอบถัดไปโฆษณาชุด resources ที่ต่างไป (ไฟล์ถูกสลับ เพิ่ม หรือลบ) host ต้องถือว่าการอนุมัติเดิม ถูกเพิกถอน แล้วถามใหม่
• อ่านข้ามเซิร์ฟเวอร์ไม่ได้ — สกิลจากเซิร์ฟเวอร์ A ต้องไม่ทำให้เกิด resources/read ไปยังเซิร์ฟเวอร์ B (confused deputy) และ host ต้องระบุเซิร์ฟเวอร์ด้วย label ที่ host ตั้งเอง ไม่ใช่ serverInfo.name ที่เซิร์ฟเวอร์รายงานตัวเอง
• ชื่อซ้ำคือช่องปลอมตัว — สกิลจาก MCP ห้ามบัง แทนที่ หรือดักการเรียกสกิลชื่อเดียวกันจากต้นทางอื่น รวมถึงสกิลบนดิสก์ของผู้ใช้เอง
• สกิลซ้อนต้องขออนุมัติใหม่ — อนุมัติสกิลแม่ไม่ได้แปลว่าอนุมัติสกิลที่ซ้อนอยู่ข้างใน
• digest ไม่ใช่กำแพงความปลอดภัย — มันไม่ได้เซ็นชื่อ และมาจากเซิร์ฟเวอร์เดียวกับเนื้อหา ตัวกลางที่แก้ทั้ง listing และเนื้อหาพร้อมกันก็ผ่านได้ สเปกเขียนไว้ตรง ๆ ว่า digest ตรงกันพิสูจน์แค่ว่าสองอย่างสอดคล้องกัน ไม่ได้พิสูจน์ว่าน่าเชื่อถือ
• แคชต้องอยู่นอกเส้นทางค้นหาสกิลบนดิสก์ และไฟล์ที่โหลดจากแคชนั้นต้องถือว่า “มาทาง MCP” ตลอดไป แม้ host รีสตาร์ตหรือเซิร์ฟเวอร์ต้นทางหลุดไปแล้ว — “ไบต์ที่แคชไว้ไม่ได้เลื่อนขั้นเป็นสกิลในเครื่องเพียงเพราะมันนอนอยู่บนดิสก์”

อีกจุดที่น่าสังเกตคือ archive distribution ถูกถอดออก ก่อนจบรีวิว ร่างก่อนหน้าเคยให้สกิลโฆษณาไฟล์ tar.gz/zip ของทั้งไดเรกทอรีเพื่อดึงทีเดียวจบ แต่ Core Maintainers ตัดทิ้งด้วยเหตุผลสองข้อ: การแตกไฟล์จากเซิร์ฟเวอร์ระยะไกลเปิดพื้นผิวยาวเป็นหางว่าว (decompression bomb, path traversal, symlink ที่ชี้ออกนอกไดเรกทอรี, การชนกันของ Unicode normalization ที่ทับ SKILL.md เงียบ ๆ, setuid/setgid, device node) ซึ่ง host ทุกตัวต้องทำให้ถูกครบทุกข้อ และการมีสองวิธีเสิร์ฟสกิลเดียวกันคือกับดักความเข้ากันได้ ต้นทุนที่ยอมรับคือสกิลที่มีไฟล์เยอะต้องยิงหนึ่ง round trip ต่อไฟล์ และ executable bit กับ symlink ไม่มีที่อยู่

สเปก Final แล้ว แต่ SDK ยังไม่ merge

จุดที่ควรอ่านก่อนวางแผนใช้งานจริง: สถานะ Final ของ SEP ไม่ได้แปลว่าของพร้อมใช้ เช็กสถานะเมื่อ 16 ก.ย. ตามลิงก์ในหมวด Reference Implementation ของ SEP เอง:

งาน	สถานะ (16 ก.ย. 2026)
Conformance tests (conformance#330)	merge แล้ว 11 ก.ย.
Python SDK (python-sdk#3485)	ยังเปิดอยู่
C# SDK (csharp-sdk#1856)	ยังเปิดอยู่
Go SDK (go-sdk#1238)	ยังเปิดอยู่
GitHub MCP Server (#3046)	ยังเปิดอยู่ ระบุว่าเป็น [Demo]
Claude Code	SEP ระบุว่า “prototyped internally at Anthropic; not yet public”

แปลว่าตอนนี้มีเพียง ชุดทดสอบ conformance ที่เข้าที่แล้ว ส่วนเซิร์ฟเวอร์และไคลเอนต์ที่จะทำให้ skills/list ใช้ได้จริงยังรอ merge ทั้งหมด นอกจากนี้ SEP ยังบอกตรง ๆ ว่า FastMCP SkillsProvider ซึ่งมีคนใช้เยอะอยู่แล้ว ต่างจากสเปกนี้ทั้งโครง URI, วิธี discovery (_manifest รายสกิล เทียบกับ index กลาง) และการ map เมทาดาทา — การพาให้ย้ายมาตรงกันถูกระบุว่าเป็น “near-term Working Group priority” ใครเขียนเซิร์ฟเวอร์เสิร์ฟสกิลอยู่วันนี้จึงควรเผื่อว่าต้องแก้

อีกเรื่องที่บอกทิศทางการออกแบบ: ข้อเสนอคู่แข่ง SEP-2076 “Agent Skills as a First-Class MCP Primitive” ซึ่ง SEP-2640 อ้างถึงในหมวด References ว่าเป็น “alternative approach” ถูกปิดโดยไม่ merge ตั้งแต่ต้นปี ทิศทางที่ชนะจึงเป็น “สกิลคือ resource ที่มี convention” ไม่ใช่ “สกิลคือพลเมืองชั้นหนึ่งของโปรโตคอล”

มุมมอง AI Curator

สิ่งที่ SEP-2640 แก้จริง ๆ ไม่ใช่ปัญหาเทคนิค แต่เป็นปัญหา การกระจาย ทุกวันนี้ทีมที่เขียน MCP server ให้ระบบภายในองค์กร ต้องส่งเอกสารวิธีใช้ให้เอเจนต์ด้วยช่องทางคนละทางกับตัวเซิร์ฟเวอร์ ไม่ว่าจะเป็นไฟล์ในเครื่องผู้ใช้ ลิงก์ในวิกิ หรือ instructions สั้น ๆ พอสกิลกับเซิร์ฟเวอร์มาจากที่เดียวกันและอัปเดตพร้อมกัน ต้นทุนดูแลของทีมแพลตฟอร์มลดลงจริง และนี่คือเหตุผลที่ควรสนใจแม้จะยังใช้ไม่ได้วันนี้

แต่จุดที่ผมคิดว่าคนไทยที่กำลังวางระบบเอเจนต์ในองค์กรควรอ่านซ้ำคือกฎ allowed-tools การเปลี่ยนสกิลจาก “ไฟล์ที่เราเขียนเองแล้ววางไว้ในเครื่อง” เป็น “ไฟล์ที่เซิร์ฟเวอร์ภายนอกส่งมา” ทำให้ฟิลด์เดิมที่เคยหมายถึง “สกิลนี้ต้องใช้ทูลอะไรบ้าง” กลายเป็น “ผู้ให้บริการภายนอกขอสิทธิ์บนเครื่องคุณ” ทันที ซึ่งเป็นการเปลี่ยนความหมายที่มองไม่เห็นจากตัวไฟล์เลย สเปกเลือกทางที่ถูกแล้วคือสั่งให้เมินไว้ก่อน แต่ข้อบังคับพวกนี้ตกอยู่กับ host ทั้งหมด ไม่ใช่กับเซิร์ฟเวอร์ — หมายความว่าความปลอดภัยของการใช้สกิลผ่าน MCP จะดีเท่ากับที่เครื่องมือที่คุณเลือกใช้ทำตามสเปกครบ ทีมที่ประเมินเครื่องมือเอเจนต์ในไทยควรตั้งคำถามตรง ๆ กับผู้ขายว่า ติดป้ายต้นทางให้โมเดลเห็นไหม, ผูกการอนุมัติกับ digest ไหม, แคชไว้ตรงไหน — เพราะตอนนี้ยังไม่มี host ตัวไหนในลิสต์ที่ประกาศว่าทำครบและเปิดสาธารณะแล้ว

สุดท้าย ข้อความที่ซื่อตรงที่สุดในเอกสารทั้งฉบับคือประโยคที่ว่า digest ไม่ใช่กำแพงความปลอดภัย มาตรฐานนี้ทำให้ “สกิลที่คุณอนุมัติ” กับ “ไบต์ที่โมเดลได้รับ” เป็นก้อนเดียวกัน แต่ไม่ได้ทำให้เซิร์ฟเวอร์ที่คุณเชื่อใจน่าเชื่อถือขึ้นแม้แต่นิดเดียว การตัดสินใจว่าจะต่อเข้ากับ MCP server ของใคร ยังเป็นการตัดสินใจที่ต้องใช้คนตัดสินอยู่ดี

แหล่งข่าว

• SEP-2640: Skills Extension — modelcontextprotocol.io
• PR #2640 บน repo สเปก MCP (merge 13 ก.ย. 2026)
• Agent Skills specification — agentskills.io
• conformance#330 — ชุดทดสอบ SEP-2640 (merge 11 ก.ย. 2026)