ข้อกำหนด MCP – การเปลี่ยนแปลงในเวอร์ชัน 2025-06-18

 (modelcontextprotocol.io)
1 คะแนน โดย GN⁺ 2025-06-20 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • อัปเดตใหม่ของสเปก MCP เน้นไปที่ส่วนของ เมตาดาต้าแบบมีโครงสร้าง และ การจัดการคอนเท็กซ์ โดยมีเป้าหมายเพื่อเพิ่ม ความสามารถในการขยาย และเสริม การทำงานร่วมกันได้ ระหว่างระบบที่หลากหลาย
  • มีการเพิ่ม ฟิลด์ข้อมูลใหม่ และกำหนดรายละเอียดของ ฟิลด์บังคับ เดิมให้ชัดเจนยิ่งขึ้น การจัด โครงสร้างแบบลำดับชั้น ของเมตาดาต้าช่วยให้รองรับวิธีการขยายเฉพาะของแต่ละระบบได้
  • มีการกำหนดกฎที่ชัดเจนสำหรับ การติดตามคอนเท็กซ์ และ การอัปเดตแอตทริบิวต์ โดยเน้นความสามารถในการจัดการ ข้อมูลสถานะอย่างสม่ำเสมอ มากกว่าเดิม
  • มีการระบุขั้นตอน การจัดการสิทธิ์ และ การตรวจสอบข้อมูล ไว้ในข้อกำหนดของโปรโตคอลอย่างชัดเจน ฟิลด์บางส่วนที่เพิ่มเข้ามาใหม่ถูกออกแบบโดยคำนึงถึง ความเข้ากันได้ กับ เวอร์ชันของโปรโตคอลในอนาคต
  • รองรับการผสานข้ามแพลตฟอร์ม: วางรากฐานให้สามารถแลกเปลี่ยน ข้อมูลคอนเท็กซ์ ได้อย่างสม่ำเสมอแม้อยู่บนหลายแพลตฟอร์ม AI และสภาพแวดล้อมบริการคลาวด์
  • MCP(Model Context Protocol) คือ โปรโตคอลสำหรับการแลกเปลี่ยนเมตาดาต้าคอนเท็กซ์ ระหว่างระบบ AI หลากหลายประเภท เช่น โมเดลแมชชีนเลิร์นนิงหรือโมเดลภาษาขนาดใหญ่

Major changes

  1. ยกเลิกการรองรับ JSON-RPC batching (PR #416)
  2. เพิ่มการรองรับ structured tool output (PR #371)
  3. จัดประเภท MCP server เป็น OAuth resource server และเพิ่ม protected resource metadata เพื่อให้ค้นหา Authorization server ที่เชื่อมต่ออยู่ได้ดีขึ้น (PR #338)
  4. กำหนดให้ MCP client ต้องรองรับการทำงานของ Resource Indicator ตาม RFC 8707 (เพื่อป้องกันเซิร์ฟเวอร์ที่เป็นอันตรายจากการได้ access token ไป) (PR #734)
  5. ทำให้ security considerations และ best practices ในข้อกำหนด Authorization ชัดเจนขึ้น พร้อมเพิ่ม หน้าคู่มือด้านความปลอดภัย แยกต่างหาก
  6. เพิ่มฟีเจอร์ Elicitation (คำขอสอบถามข้อมูล) เพื่อให้เซิร์ฟเวอร์สามารถขอข้อมูลเพิ่มเติมจากผู้ใช้ได้ (PR #382)
  7. เพิ่มการรองรับ Resource Links ทำให้สามารถใส่ลิงก์ทรัพยากรในผลลัพธ์ของการเรียกใช้เครื่องมือได้ (PR #603)
  8. ระหว่างการเจรจาเวอร์ชันโปรโตคอล กำหนดให้ต้องมีเฮดเดอร์ MCP-Protocol-Version บน HTTP (PR #548)
  9. เปลี่ยน SHOULD ของ Lifecycle Operation เป็น MUST (อ้างอิง)

Other schema changes

  1. มีการเพิ่มฟิลด์ _meta ไปยัง interface type มากขึ้น (PR #710) พร้อม ระบุวิธีใช้งานที่เหมาะสม
  2. เพิ่มฟิลด์ context ใน CompletionRequest เพื่อให้รวมตัวแปรที่ถูกตีความก่อนหน้าได้ (PR #598)
  3. เพิ่มฟิลด์ title สำหรับการแสดงผลที่เป็นมิตรกับผู้ใช้ แยกจากตัวระบุสำหรับโปรแกรม (name ใช้เป็นตัวระบุในโค้ด ส่วน title ใช้สำหรับการแสดงผล) (PR #663)

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
kernel00 2025-06-20

คอมเมนต์ใน Hacker News น่าผิดหวังนิดหน่อยนะ เหมือนจะดูแค่ stdio แต่ตอนนี้ทั้ง remote MCP server และ registry ที่คอยทำหน้าที่เป็นตัวกลางให้มัน ก็กำลังผุดขึ้นมาเป็นดอกเห็ดเลย....
 
GN⁺ 2025-06-20
ความคิดเห็นจาก Hacker News
  • สิ่งสำคัญที่สุดที่ฉันได้เรียนรู้จากกระแส MCP (Machine Context Protocol) คือ ในการพัฒนาซอฟต์แวร์ฝั่งแบ็กเอนด์นั้นจริง ๆ แล้วไม่จำเป็นต้องใช้ MCP เลย มันมีบางจุดที่ไม่สอดคล้องกันในเชิงสถาปัตยกรรม โดยเฉพาะในสภาพแวดล้อมอย่าง Elixir ยิ่งรู้สึกแบบนั้น ถ้าต้องมีเซิร์ฟเวอร์แยกสำหรับแต่ละ API ก็เท่ากับว่าถ้ามี 500 API ก็ต้องรัน 500 ไมโครเซอร์วิส กว่าฉันจะได้ใช้ MCP server ด้วยตัวเองสัก 20 แบบก็เพิ่งตระหนักว่า สุดท้าย MCP ก็เป็นแค่เปลือกหุ้มของ function call เท่านั้น แต่ละ API แค่ทำเป็นโมดูลแยกต่างหากก็พอ ไม่จำเป็นต้องคอยตามสเปก MCP ล่าสุด และไม่จำเป็นต้องอัปเดตไมโครเซอร์วิสเป็นร้อย ๆ ตัวทุกครั้งที่สเปกเปลี่ยน สรุปคือมันเป็นความซับซ้อนที่ไม่จำเป็น
    • ถ้าไคลเอนต์ไม่ได้เชื่อมต่อกับแต่ละไมโครเซอร์วิสโดยตรงโดยไม่ผ่าน gateway หรือ BFF ก็แค่วาง MCP ไว้หน้าระบบทั้งหมดแล้วเปิดความสามารถออกมาเหมือนวิธีเดิม ๆ เช่น API, GraphQL, RPC ก็พอ ให้ความรู้สึกว่าเป็นอินเทอร์เฟซที่ออกแบบมาสำหรับ LLM โดยเฉพาะด้วยซ้ำ จะใช้ tool call ที่อิงสเปก OpenAPI ก็ยังได้อยู่ดี อย่างไรก็ตาม การจินตนาการให้ทุกไมโครเซอร์วิสสื่อสารกันด้วย MCP อย่างเดียวนั้นเกินไปมาก
    • ฉันมอง MCP แค่เป็นโซลูชันรวมระบบแบบปลั๊กอินที่ทำให้ function call ใช้งานได้โดยไม่มีค่าใช้จ่าย API แบบ Claude ถ้าคุณใช้งาน API อยู่แล้วและไม่ได้รีบร้อนอะไร ก็ไม่ใช่ตัวเลือกที่จำเป็นนัก
    • จริง ๆ แล้วฉันคิดว่า MCP คือโปรโตคอลมาตรฐานที่ใช้เชื่อมไคลเอนต์กับโมเดล ไม่ได้เป็นแค่ภาชนะที่ใช้ห่อการเรียกเครื่องมือเท่านั้น
    • ใช่เลย การมี MCP server แยกหนึ่งตัวต่อหนึ่ง API เป็นโครงสร้างที่ขยายไม่ได้ ถ้าใช้ของอย่าง nango.dev ก็ให้เซิร์ฟเวอร์ตัวเดียวรองรับได้มากกว่า 400 API ทั้งจัดการ authentication เพิ่มการมองเห็น และยังมีอินเทอร์เฟซหลายแบบที่เรียก tool ได้โดยตรงด้วย (อนึ่ง ฉันเป็นผู้ก่อตั้ง)
    • ฉันไปไกลกว่านั้นอีกและคิดว่าวัฒนธรรมการบังคับให้ LLM ส่งออกเป็น JSON นั้นเป็นเรื่องไร้สาระในตัวเอง มันเสียเวลาและแรงไปมากเพื่อให้เข้ากับฟอร์แมตจุกจิกที่ LLM ก็ไม่ได้ถนัดจริง ๆ DSL แบบข้อความที่มีข้อจำกัดมากกว่ากลับเป็นทางเลือกที่ดีกว่ามาก ในสมัย GPT 3.5 แค่ให้ตัวอย่างง่าย ๆ ในพรอมป์ไม่กี่อัน ก็ทำให้มันสร้าง DSL ภาษาอังกฤษได้อย่างน่าเชื่อถือแล้ว แต่ถึงอย่างนั้นก็ยังมีคำเตือนว่าแม้แต่โมเดลรุ่นใหม่ ๆ ก็ยังมักเพิกเฉยต่อบางส่วนของ JSON schema อยู่ดี มันให้ความรู้สึกเหมือนพยายามยัดหมุดกลมลงรูสี่เหลี่ยม อยากให้ทุกคนเลิกฝืนกันเสียที
  • ฉันดีใจมากที่ตอนนี้มีเส้นทางง่าย ๆ ไปยัง MCP server ที่ยืนยันตัวตนแล้ว อยากขอบคุณชุมชน MCP และทีม Anthropic จากใจจริง
    • ฉันยังไม่ค่อยเข้าใจว่าทำไมต้องมี MCP server ถ้าเอเจนต์อยากทำ RPC ก็ใช้ RPC ตรง ๆ ไม่พอหรือ
  • รู้สึกแปลกใจมากที่สเปกแกนหลักถูกเขียนด้วย TypeScript แทนที่จะเป็น OpenAPI หรืออย่างอื่น คงมีเหตุผลที่สมควรอยู่ แต่ก็ยังรู้สึกเหนือความคาดหมาย
    • อยากรู้ว่าทำไมเรื่องนี้ถึงน่าแปลกใจ ฉันเองก็ใช้ TypeScript เยอะ แต่ไม่เคยคิดจากมุมนี้มาก่อน เลยอยากรู้ว่ามีการตัดสินใจอะไรในเชิง language design บ้าง
  • ดีใจมากที่มีการนำ WWW-Authenticate challenge เข้ามาใช้ ตอนนี้ภาพก็ชัดเจนแล้วว่า MCP server สามารถส่งไคลเอนต์ไปยัง OAuth flow ของ resource provider แล้วรับแค่เฮดเดอร์ Authorization: Bearer ... กลับมาก็พอ
  • ฉันคิดว่ามันเป็นความซับซ้อนที่ไม่จำเป็นอยู่<i>เป็นส่วนใหญ่</i> แต่ก็เสียดายความสามารถด้าน batch execution การทำแบบ “ทำงานพวกนี้ทั้งหมดให้เสร็จ แล้วค่อยตอบผลกลับมาทีเดียว” นั้นสนุกดี แน่นอนว่าไคลเอนต์จะรวม batch response เองก็ได้ แต่ก็ยังเสียดายอยู่ดี
    • ใช่ JSON-RPC batch เป็นฟีเจอร์ที่ทำให้รู้สึกว่า “ว้าว อันนี้เจ๋งดีนะ” เลย เสียดายที่ถูกถอดออกจากสเปก แต่ก็เข้าใจได้ เพราะสุดท้ายมันก็เพิ่มแต่ความซับซ้อน
  • ฉันคิดว่า elicitation (การจัดการพรอมป์แบบอิงการอนุมาน) เป็นของที่ได้มาคุ้มที่สุด MCP server ตัวโปรดตัวหนึ่งของฉันคือ SSH server ที่ทำขึ้นเอง มันช่วยทำงานฝั่งเซิร์ฟเวอร์อัตโนมัติได้ 90% เลย ฉันจัดการ authentication ผ่านไฟล์คอนฟิก แต่พอมีกรณีต้องเชื่อมต่อเซิร์ฟเวอร์ใหม่ก็ต้องแก้เองทุกครั้ง เลยแอบยุ่งนิดหน่อย
    • ในกรณีแบบนี้อาจใช้ของอย่าง fabfile.org ก็ได้ ฉันคิดว่าถ้าเป็นบทสนทนาที่ไม่จำเป็นต้องเอา LLM เข้ามาเกี่ยว ก็ควรเก็บไว้ใช้งานส่วนตัวจะดีกว่า
  • ช่วงสองสามวันที่ผ่านมา ฉันลองเล่นกับการทำ dataset wrapper ด้วย MCP
  1. ฉันคิดว่านี่เป็นหนึ่งในความพยายามที่น่าตื่นเต้นที่สุดในวงการ LLM แน่นอนว่าของคล้ายกันก็ทำได้ด้วย API และ tool call แบบเดิม แต่สำหรับเพื่อนที่ไม่คุ้นเทคโนโลยี แค่ส่ง MCP URL สำหรับ Claude ไปให้แล้วเขากดไม่กี่ครั้งก็ลองใช้ได้เลย มันน่าประทับใจมาก
  2. ฉันใช้ csharp SDK อยู่ แต่ฟีเจอร์ authentication ยังมีอยู่แค่ใน branch เลยถือว่ายังอยู่ในช่วงเริ่มต้นมาก ตอนรวม MCP เข้าระบบ เวลาถึง 95% หมดไปกับการทำ authentication (ถ้าไม่ใช่ local build ก็จำเป็นต้องมี) ถ้ามีเอกสารเพิ่มขึ้นก็น่าจะดีขึ้น แต่ตอนนี้ยังเป็นกระบวนการที่ต้องลงแรงมากพอสมควร
  3. อีกจุดคือการเปิดเผย developer log ยังไม่ดีพอ อยากให้ Claude แสดง request/response log ใน developer mode ว่าบนเว็บ (ไม่ใช่เดสก์ท็อป) มันส่งอะไรรับอะไร และพังตรงไหน ฉันหลงทางอยู่พักใหญ่เพราะปัญหา refresh authentication แล้วเพิ่งมารู้ทีหลังว่าฉันกำลังล็อก endpoint ผิดอยู่ ถ้ามี MCP logging ที่ดีกว่านี้ เรื่องที่ควรจบในไม่กี่นาทีก็คงจบไปแล้ว บนเดสก์ท็อปกับ MCP inspector ใช้งานได้ดี
  4. สิ่งที่กังวลที่สุดคือการจัดการงานที่ใช้เวลานาน dataset ที่ฉันเปิดให้ใช้งานเป็นเอกสาร PDF หลายไฟล์ ดูเหมือน Claude เองจะจัดการ PDF ไม่ได้ (ถ้าใครมีวิธีอยากให้บอกที!) ตอนนี้เลยใช้วิธีแปลงเป็นข้อความผ่าน gemini ก่อนแล้วค่อยส่งต่อด้วย MCP เอกสารสั้น ๆ ใช้งานได้ดี แต่เอกสารยาวใช้เวลาประมวลผลนาน ตอนนี้ฉันส่งแค่ข้อความบอกว่า “กำลังประมวลผล โปรดลองใหม่ภายหลัง” แม้จะมี progress API อยู่ แต่ต้องคงการเชื่อมต่อกับเซิร์ฟเวอร์ไว้ตลอด (ซึ่งบน Cloudflare จะถูกตัดหลังผ่านไประยะหนึ่ง) เลยดูมีข้อจำกัดด้านการใช้งานจริง ถ้ามีวิธีให้ LLM กลับมาตรวจอีกครั้งหลังผ่านไป x วินาที และระหว่างนั้นไปทำงานอย่างอื่นได้ พร้อมกับอยู่ในสถานะ “หยุดรอชั่วคราว” จนกว่าไทเมอร์จะครบ ก็คงดีมาก ตอนนี้ถ้าคงการเชื่อมต่อไว้ LLM ก็ทำอะไรไม่ได้และต้องรอเฉย ๆ หรือถ้าคืนค่าเป็น job ID ไป คำตอบที่ได้ก็มักไม่สมบูรณ์และหลุดบริบททั้งหมด ฉันคิดว่านี่อาจเป็นอุปสรรคใหญ่สำหรับงานที่ต้องใช้เวลามากกว่า 10 นาที
  • งานที่รันยาวยังเป็นหัวข้อที่กำลังถกเถียงกันในที่สาธารณะ ฉันเข้าใจว่า MCP เองก็มีเจตนาจะแก้เรื่องนี้ในอนาคต มีข้อเสนอหลายแบบออกมา และเพราะเราไม่อาจรู้ได้เสมอว่างานไหนจะใช้เวลานาน การแยก long-running task API ออกมาต่างหากอย่างเดียวจึงไม่ใช่คำตอบ ฉันเองก็มีข้อเสนอให้แก้เรื่องนี้แบบบูรณาการอยู่ ลิงก์ discussion
  • ดีใจมากที่สเปก MCP พัฒนาอย่างรวดเร็ว ในแต่ละรีลีสใหม่ ฉันเห็นได้เลยว่าจุดที่เคยรู้สึกติดขัดในการรวม MCP เข้าระบบของตัวเองค่อย ๆ ถูกเติมเต็มทีละอย่าง
  • ฉันรู้สึกว่าน่าสนใจดีที่การเปลี่ยนสเปกจะถูกรวมได้ด้วยการอนุมัติเพียงครั้งเดียว
  • ฉันยังไม่ค่อยเข้าใจว่า MCP แก้ปัญหาอะไรได้จริงบ้าง ส่วนตัวนึกออกแค่ว่ามันอาจมีบทบาทเวลาอยากทำ prototype เร็ว ๆ บนโน้ตบุ๊ก ถ้าจะทำโปรแกรมแบบ local ฉันอยากควบคุมชุดเครื่องมือที่ LLM เข้าถึงได้ละเอียดกว่านี้มาก ตัวอย่างเช่นลองนึกถึง MCP server สำหรับ Google Calendar ดู ต่อให้มี MCP มันก็ไม่ได้ช่วยประหยัดเวลาอย่างมีนัยสำคัญ เพราะฉันก็เรียก API เดิมเองได้อยู่แล้ว และยังต้องบอก LLM อย่างชัดเจนอยู่ดีว่าจะเรียก Google Calendar เมื่อไรและอย่างไร เลยไม่อยากมอบหมายให้บุคคลที่สาม อีกอย่าง ไม่ว่าตัว MCP จะเขียนด้วยภาษาอะไร ฉันก็ไม่ค่อยสบายใจกับการไปรันโปรเซสตามอำเภอใจในสภาพแวดล้อมของตัวเอง ถ้าฝั่งฉันเป็น Python แต่ต้องให้ผู้ใช้ติดตั้ง TypeScript runtime เพิ่ม ก็คงลำบาก และถ้า MCP wrapper มีช่องโหว่ก็ยิ่งกังวลเรื่องความปลอดภัย ในสภาพแวดล้อมเซิร์ฟเวอร์ก็ยิ่งหาเหตุผลมารองรับได้ยาก เรามีวิธีที่ดีอยู่แล้วสำหรับการเรียกข้ามเครื่องโดยไม่ต้องรู้รายละเอียดการติดตั้งของอีกฝั่ง นั่นคือ RPC MCP ให้ความรู้สึกเหมือนเพิ่ม middleware ที่มีความเห็นจัดจ้านและเพิ่มปัญหาด้านความปลอดภัยเข้าไปอีกชั้น
    • สิ่งที่ฉันไม่เข้าใจคือ ทำไม MCP ที่เห็นมาจนถึงตอนนี้ถึงเป็นแบบ command-based ทั้งหมด และไม่ใช้อินเทอร์เฟซ HTTP ถ้าเป็นแบบ HTTP ก็รันเซิร์ฟเวอร์เดียวแล้วให้ทั้งองค์กรใช้ร่วมกันได้ โดยแต่ละคนไม่ต้องตั้งค่า toolchain ของตัวเอง
    • จุดเด่นของ MCP คือ ไม่เหมือนแนวทางเดิมที่ให้แบ็กเอนด์บังคับ flow ตายตัว แต่ให้ LLM ทำ orchestration ได้ด้วยตัวเองโดยตรง ตัวอย่างเช่นตอนค้นหาบนเว็บ มันสามารถปรับคำค้นแล้วลองใหม่ซ้ำ ๆ จนกว่าจะเจอข้อมูลที่ต้องการ หรือเวลาแก้ปัญหาเฉพาะทางผ่าน CLI ก็สามารถใช้หลายเครื่องมือในลำดับที่เหมาะสมได้ นี่เป็นการจัดระเบียบที่ flow แบบตายตัวทำไม่ได้
    • สิ่งที่ MCP แก้คือการเชื่อมต่อเครื่องมือและความสามารถต่าง ๆ เข้ากับ agent โดยยึด LLM เป็นศูนย์กลาง ผ่านโปรโตคอลมาตรฐาน
    • ฉันเห็นด้วยมากจริง ๆ พอลองใช้จริงจะรู้สึกว่ามันช้ามาก ฉันถึงขั้นลาออกจากงานเมื่อ 2 ปีก่อนเพื่อไปทำ LLM client แต่จนถึงตอนนี้ก็ยังเชื่อม Google Calendar ไม่ได้ อย่างน้อยจากมุมผู้ใช้ MCP ก็มีประโยชน์ตรงช่วยอุดช่องโหว่ชั่วคราวแบบนี้ได้ ฉันนึกถึงเรื่องที่ว่าเมื่อก่อน 3 แถวบนสุดของหน้าจอโฮม iPhone จะคล้ายกัน แต่แถวล่างสุดของแต่ละคนจะต่างกันหมด ฉันเดาว่าต่อจากนี้ทีม IT และทีมพัฒนาก็คงยังสร้าง MCP server ให้เข้ากับงานของตัวเองกันต่อไป