มอง MCP แบบวิพากษ์วิจารณ์

 (raz.sh)
1 คะแนน โดย GN⁺ 2025-05-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • MCP(Model Context Protocol) คือวิธีการเชื่อมต่อมาตรฐานที่ช่วยให้ LLM โต้ตอบกับโลกภายนอกได้
  • ช่วงหลังมานี้มีมาตรฐานลักษณะใกล้เคียงกันอย่าง ACP ของ IBM และ A2A ของ Google ปรากฏขึ้น ทำให้การนำ MCP ไปใช้งานและเครื่องมือที่เกี่ยวข้องเพิ่มขึ้นอย่างรวดเร็ว
  • อย่างไรก็ตาม มีการชี้ให้เห็นปัญหาเรื่อง ความสับสนในการออกแบบ เอกสารไม่เพียงพอ และการขาดสเปกโปรโตคอลที่ชัดเจนในทางปฏิบัติ ซึ่งสะท้อนถึงแนวปฏิบัติด้านวิศวกรรมที่ยังไม่สุกงอม
  • วิธีการขนส่งที่เสนออยู่ในปัจจุบัน เช่น HTTP+SSE และ Streamable HTTP กลับเพิ่มทั้งความซับซ้อนและประเด็นด้านความปลอดภัย โดยมีการแนะนำให้ใช้ WebSocket เป็นทางเลือก
  • โปรโตคอลล่าสุดยังเพิ่มความไม่สอดคล้องและความซับซ้อนเกินจำเป็นในเรื่อง การอนุญาตและการจัดการเซสชัน

ทบทวน MCP และแนวโน้มล่าสุด

  • MCP เป็นโปรโตคอลเปิดที่สร้างขึ้นเพื่อทำให้วิธีที่แอปพลิเคชันมอบบริบทให้กับ โมเดลภาษาขนาดใหญ่ (LLM) เป็นมาตรฐานเดียวกัน
  • ในช่วงหนึ่งเดือนที่ผ่านมา MCP ได้ก้าวขึ้นมาเป็นมาตรฐานสำคัญในการทำให้ LLM กลายเป็น เอเจนต์ และกำลังถูกนำไปใช้รวมถึงพัฒนาอิมพลีเมนเทชันอย่างรวดเร็ว
  • มาตรฐานที่มีจุดประสงค์คล้ายกัน เช่น ACP ของ IBM หรือ A2A ของ Google ก็เกิดขึ้นอย่างรวดเร็วเช่นกัน

ปัญหาด้านแนวปฏิบัติทางวิศวกรรมและสเปกโปรโตคอล

  • หลายจุดเผยให้เห็นว่าระดับของการอิมพลีเมนต์และการจัดทำเอกสารยังต่ำ
  • บริษัทเทคโนโลยีขนาดใหญ่ลงทุนมหาศาลกับการฝึกโมเดล แต่ SDK และเอกสาร กลับมีคุณภาพต่ำจนสร้างความสับสนให้ผู้ใช้
  • MCP ก็มีปัญหาคล้ายกัน โดยบางส่วนของการออกแบบไม่สมเหตุสมผล และยังขาดสเปก ตัวอย่าง และแนวทางปฏิบัติ

การอภิปรายเรื่องโปรโตคอลขนส่ง (Transport)

วิธีขนส่งแบบ stdio

  • Stdio เป็นวิธีดั้งเดิมที่เชื่อม MCP server และ client ในเครื่องเดียวกันโดยตรงผ่าน pipe (stdout, stdin)
  • มีภาระเรื่องการจัดการ socket หรือปัญหาเฉพาะระบบปฏิบัติการน้อยกว่า และตั้งค่าสภาพแวดล้อมได้ เรียบง่าย ทั้งตัวแปรแวดล้อมและสตรีมอินพุต/เอาต์พุต

วิธี HTTP+SSE / Streamable HTTP

  • ด้วยความตั้งใจที่จะรองรับโลกเว็บ จึงมีการนำวิธีแบบ HTTP+SSE และ Streamable HTTP มาใช้บนฐาน HTTP
  • แต่แนวทางนี้ซึ่งตั้งใจจะมาแทน WebSocket กลับก่อให้เกิดความกำกวม ความสับสนเชิงออกแบบ และความซับซ้อนมากยิ่งขึ้น
  • เซสชันและการเชื่อมต่อหนึ่งชุดสามารถถูกสร้างและปิดได้หลายรูปแบบ ส่งผลให้เกิด ภาระอย่างมาก ต่อการจัดการสถานะของเซิร์ฟเวอร์และด้านความปลอดภัย

ความยากลำบากจากกรณีตัวอย่างการอิมพลีเมนต์ MCP server/client

  • ปัญหาการรองรับในหลายภาษาเด่นชัด เช่น การไม่มี Go SDK อย่างเป็นทางการ
  • เอกสารและสเปกไม่ชัดเจนจนหลายกรณีต้องอิมพลีเมนต์ผ่านการ reverse engineering
  • แม้เซิร์ฟเวอร์ตัวอย่างส่วนใหญ่จะอิงกับ Python, JavaScript แต่ก็ยากต่อการใช้ในสภาพแวดล้อมการทำงานจริงเพราะปัญหาเรื่อง dependency และ portability
  • เมื่อต้องอิมพลีเมนต์เซิร์ฟเวอร์ SSE/Streamable HTTP พยายามทำตัวเสมือน socket แต่ในความเป็นจริงกลับรักษาเซสชันและสถานะการเชื่อมต่อให้คงเส้นคงวาได้ยาก และยังต้องมีโครงสร้างพื้นฐานแยกอย่าง message queue เพิ่มเติม

โครงสร้างและปัญหาของ HTTP+SSE และ Streamable HTTP

โหมด HTTP+SSE

  • client จะเปิดเซสชัน SSE กับเซิร์ฟเวอร์ จากนั้นเมื่อส่งคำขอเขียนไปยัง endpoint แยก เซิร์ฟเวอร์จะตอบกลับด้วย 202 และส่งผลตอบกลับผ่านการเชื่อมต่อ SSE เดิม
  • แม้จำเป็นต้องรักษาการเชื่อมต่อเซสชันและการซิงก์สถานะ แต่ขั้นตอนนี้กลับมีเอกสารไม่เพียงพอและมีความซับซ้อนในการปฏิบัติการสูงมาก

โหมด Streamable HTTP

  • ทั้ง การสร้างเซสชัน การเปิด SSE และการส่งคำตอบกลับ ถูกปะปนกันหลายวิธี ทำให้ลำดับการทำงานของคำขอหนึ่งชุดจนถึงการตอบกลับไม่มีความสอดคล้อง
  • การปะปนกันของการจัดการสถานะหลายแบบ รวมถึง endpoint และ header ที่หลากหลาย กลายเป็นอุปสรรคอย่างร้ายแรงต่อ การอิมพลีเมนต์จริงและความสามารถในการขยายระบบ

นัยทั่วไป

  • เมื่อความซับซ้อนทางเทคนิคเพิ่มขึ้น ก็ทำให้ ภาระทางความคิดและการบำรุงรักษา ของนักพัฒนาเพิ่มขึ้น และก่อปัญหาเรื่อง ความเข้ากันไม่ได้และพฤติกรรมที่คาดเดาไม่ได้ ระหว่างการอิมพลีเมนต์ server/client ที่หลากหลาย
  • เซิร์ฟเวอร์ต้องติดตามทุกสถานะและทุกสถานการณ์ของการเชื่อมต่อ และในสภาพแวดล้อมแบบกระจาย การขยายระบบอย่างมีประสิทธิภาพและการซิงก์สถานะยิ่งทำได้ยากขึ้น

นัยด้านความปลอดภัย

  • วิธีการเชื่อมต่อและเซสชันที่ย่อยและหลากหลายเพิ่มความเสี่ยงของ ช่องโหว่ด้านการจัดการสถานะ เช่น session hijacking, replay attack และการปฏิเสธการให้บริการ (DoS)
  • จุดเข้าสู่ระบบและวิธีตอบกลับที่หลากหลายยังขยายพื้นผิวการโจมตี และเอื้อให้ ซ่อนกิจกรรมที่เป็นอันตราย ไว้ในลำดับการทำงานที่ไม่ตั้งใจได้

ความสับสนของโปรโตคอลการจัดการสิทธิ์ (Authorization)

  • สเปกปัจจุบันใช้กติกาที่ไม่สอดคล้องกัน เช่น บังคับใช้ OAuth2 เฉพาะเมื่อเป็น การขนส่งผ่าน HTTP แต่เมื่อเป็น การขนส่งผ่าน STDIO กลับปล่อยให้ใช้ตัวแปรแวดล้อมตามสะดวก
  • จึงเกิดความสับสนและความไม่สมเหตุสมผล เช่น เหตุใดจึงบังคับให้เฉพาะการขนส่งผ่าน HTTP ต้องรองรับ OAuth2 ที่ซับซ้อน

ข้อเสนอแนะเพื่อการปรับปรุง

  • ควรทำให้เหลือ โปรโตคอล JSON RPC เดียว และทำให้วิธีขนส่งเรียบง่ายโดยเน้นเพียง Stdio และ WebSocket เท่านั้น
  • วิธีที่เหมาะสมคือแมปตัวแปรในสภาพแวดล้อม Stdio ไปเป็น header ในสภาพแวดล้อม HTTP และแมปอินพุต/เอาต์พุตไปเป็นสตรีมสองทิศทางของ WebSocket ตามลำดับ
  • จะช่วยตัดความจำเป็นของการติดตามเซสชัน การจัดการสถานะ และการจัดการกรณียกเว้นจำนวนมากที่ไม่จำเป็น
  • WebSocket ควรเป็นตัวเลือกมาตรฐานสำหรับการขนส่งทั้งหมดบนฐาน HTTP และยังช่วยแก้ปัญหาความซับซ้อนของการซิงก์สถานะได้ด้วย

เปรียบเทียบกับโปรโตคอลทางเลือกและแนวโน้มตลาด

  • ACP ของ IBM และ A2A ของ Google มีการออกแบบ Transport ที่กระชับกว่าและมีความสามารถในการค้นหาเอเจนต์ในแง่ของการเชื่อมต่อระหว่างเอเจนต์
  • แต่โดยแก่นแล้ว ส่วนใหญ่ยังเป็นเพียงระดับที่สามารถรวมเข้าเป็นเครื่องมือแยกภายในสภาพแวดล้อมการสร้าง MCP ได้
  • การที่มีโปรโตคอลใหม่เกิดขึ้นอย่างต่อเนื่องมีความเสี่ยงที่จะนำไปสู่ ความกระจัดกระจายของมาตรฐาน ดังนั้นการให้ความสำคัญกับความเรียบง่ายของ Transport จึงสำคัญต่อการเติบโตของอุตสาหกรรม

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

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

 
GN⁺ 2025-05-11
ความเห็นจาก Hacker News
  • มั่นใจว่าสาเหตุที่เอกสารที่ผู้ขาย LLM เขียนออกมาดูสับสน ก็เพราะพวกเขาใช้ LLM เขียนเอกสารนั่นเอง ซึ่งเป็นแนวทางที่แย่มาก โดยเฉพาะการใช้ LLM ทำงานด้านสเปกนั้นแย่ยิ่งกว่าการใช้มันเขียนเอกสารทั่วไปเสียอีก กระบวนการเขียนสเปกเองต่างหากที่เป็นหัวใจสำคัญ เพราะมนุษย์ผู้ออกแบบต้องค่อย ๆ คิดหาข้อบกพร่อง ช่องว่าง และจัดการเคสต่าง ๆ อย่างรอบคอบ แต่ในสเปก MCP กลับแทบไม่เห็นร่องรอยของการตรึกตรองแบบมนุษย์นั้นเลย สไตล์ที่เรียบแบน ความฟุ้งกระจัดกระจาย และโครงสร้างที่เน้นลิสต์เป็นหลัก ล้วนเหมือนผลงานที่ LLM เขียนชัด ๆ
    • ปัญหาของเอกสาร DeepSeek กลับเป็นเรื่องสะกดและไวยากรณ์ที่ผิดเยอะมาก บริษัทแบบนี้ทำงานกับภาษาแทบทั้งวัน และครั้งหนึ่งก็เคยมี English LLM ที่ดีที่สุดในโลกด้วยซ้ำ แต่กลับผลิตเอกสารที่ดูเป็นมืออาชีพในระดับงานจริงไม่ได้ เป็นเรื่องที่แปลกมาก
    • ผมเองก็รู้สึกแรงมากว่าสเปกนี้ก็เป็นงานที่ LLM เขียน หลักฐานทุกอย่างชี้ไปทางนั้น และเดาว่าผลิตภัณฑ์ส่วนใหญ่ตอนนี้ถูกสร้างขึ้นเพื่อเอาไว้โชว์นักลงทุนสำหรับ IPO ว่าใช้วิธีถัวเฉลี่ยผลลัพธ์ที่ดูเข้าท่าที่สุดได้แล้ว
    • ถ้าเป็นเรื่องจริงก็น่าเสียดายมาก ทั้งที่ Anthropic ก็มีคนเก่งอยู่เยอะ แต่กลับเกิดเรื่องแบบนี้กับองค์ประกอบแกนกลางของอีโคซิสเต็มสำคัญ ถือว่าน่าผิดหวัง
    • เพิ่งนึกได้ว่าอาจมีแรงจูงใจที่ผู้ขาย AI coding ทำเอกสารให้อ่านไม่รู้เรื่องโดยตั้งใจ คือสร้างโค้ดที่มนุษย์อ่านไม่เข้าใจและมีแต่ AI ของพวกเขาเองเท่านั้นที่ตีความได้ เพื่อผูกผู้ใช้ให้พึ่งบริการ AI เฉพาะของตนโดยสมบูรณ์ ถ้าพวกเขาไม่สามารถแทนที่โปรแกรมเมอร์จริงได้ทั้งหมดภายใน 2 ปี กลยุทธ์นี้ก็คงทำให้ผู้บริโภคหายไปหมดและพังตลาดของตัวเองด้วย สุดท้ายจะเหลือเพียงกองโค้ดมหึมาที่ทั้งคนและ AI อื่น ๆ แปลงต่อกันไม่ได้
    • เวลาผมอ่านร้อยแก้วที่ LLM เขียนแล้วสมาธิหลุด ก็เริ่มรู้ว่าไม่ใช่ปัญหาของผมคนเดียว เพราะข้อความซ้ำ ๆ ไร้บริบทจากเครื่องนั้นไม่ได้มีความคิดลึกซึ้งอยู่ในนั้น และยิ่งอ่านก็ยิ่งล้าทางอารมณ์ด้วย พอ LLM แบบนี้ถูกเอาไปเขียนสเปกเทคนิค ก็ยิ่งมีแนวโน้มที่เนื้อหาที่แม้แต่ผู้เขียนเองก็ไม่เข้าใจจะปะปนเข้ามาโดยไม่รู้ตัว เรื่องนี้น่ากังวลขึ้นเรื่อย ๆ
    • เอกสารของ DeepSeek โดยรวมดูไม่ได้แย่ ดูเหมือนทำแบบรีบ ๆ แต่ก็ยังอยู่ในระดับที่ไม่เลว นั่นแปลว่าอาจมีข้อยกเว้นต่อแนวคิดที่ว่า ถ้าให้ LLM เขียนเอกสารแล้วทุกอย่างจะแย่เสมอไป
  • ช่วงนี้วงการ LLM กำลังเลียนแบบกระบวนทัศน์ซอฟต์แวร์อย่างรวดเร็วราวกับใช้สูตรโกง ทั้งที่วิธีเปิดให้ใช้ remote function นั้นเคยมีตัวอย่างมากมายในอดีตแล้ว เช่น DLL, gRPC, SOAP, IDL, dCOM แต่ฝั่ง LLM ตอนนี้ดูเหมือนไม่ค่อยรู้ด้วยซ้ำว่าสิ่งเหล่านี้มีอยู่ หวังว่าเวลาผ่านไปจะโตขึ้น แต่สุดท้ายก็ยังต้องทำการบ้านเดิมอยู่ดี
    • อีกไม่กี่เดือนก็คงโตขึ้นแน่ แต่พอมองระบบนิเวศ Python ยุคแรก ก็อดนึกถึงความผิดพลาดที่ฝังลงไปในชั้นล่างของสแตกและทุกคนก็สร้างเครื่องมือใหม่ทับลงไปไม่ได้ ครั้งนี้ยิ่งน่าเสียดาย เพราะทั้งที่เรามีประวัติศาสตร์ของความผิดพลาดแบบเดิมอยู่แล้ว แต่วงการ AI ก็ยังเดินซ้ำรอยอีก
    • ตอนเจอ MCP ครั้งแรก ผมนึกถึง COM/DCOM และนึกถึง DLL Hell สมัยก่อน จะคอยดูว่าต่อไป MCP จะไปจบอย่างไร
    • จนถึงตอนนี้ก็ยังหาไม่เจอว่าจริง ๆ แล้ว MCP คืออะไร และถ้าจะเรียกมันด้วยภาษาพัฒนาในอดีตควรเรียกว่าอะไร
    • อยากชี้ว่าพอเป็นโปรโตคอลที่เข้มงวดและประกาศชัดแบบนี้ พื้นที่ความหมายที่ LLM ถนัดและจุดแข็งเชิงความหมายกลับหายไป อาจจะตรงไปตรงมามากกว่าถ้าแค่ใส่ไฟล์ agents.json ไว้ที่ web root แล้วให้เอเจนต์จัดการกันเองผ่านการสนทนาเชิงความหมาย สุดท้าย HTTP ก็จะกลายเป็นมาตรฐาน input/output ของเอเจนต์
    • คิดว่าตัวอย่างที่ยกมาทั้งหมดเหมาะสมดี
    • สงสัยว่า MPC ใช้ JSON-RPC เป็นฐานหรือเปล่า
  • เห็นด้วยกับเนื้อหาโดยรวมของบทความ โดยเฉพาะประสบการณ์ชวนงงที่หาข้อมูลที่ใช้ได้จริงจากเว็บ MCP ไม่เจอ แม้ RFC จะอ่านยาก แต่ก็ยังดีกว่าการบอกแค่ว่า "ไปใช้ SDK อย่างเดียว"
    • อยากให้คนจำนวนมากตระหนักถึงความสำคัญของบล็อกนี้ ควรหยุดการนำ MCP มาใช้ชั่วคราวแล้วกลับไปดูให้ดีว่ามีฐานเทคนิคที่แข็งแรงจริงไหม กระแสอวยมีเยอะ แต่พอลงลึกถึงขั้นลงมือทำจริงจะผิดหวัง การตัดสินใจหลายอย่างอย่างเช่น WebSocket ในฟังก์ชันแกนกลางก็น่ากังขา และถึงจะไม่ทั้งหมด แต่ให้ความรู้สึกเหมือนของชั่วคราวที่รีบปะขึ้นมา
    • เสียดายที่ในเว็บไซต์ไม่มีสเปกที่ชัดเจน เหมือนครึ่งหนึ่งของสเปกถูกปั่นออกมาด้วย Sonnet และไม่ได้อธิบายหลักการทำงานจริงของโปรโตคอลไว้อย่างชัดเจน เมื่อเทียบกันแล้วสเปก GraphQL เขียนได้ดีกว่ามาก
  • ตอนนี้งานส่วนใหญ่ในวงการ AI ถูกขับเคลื่อนโดยนักคณิตศาสตร์ นักวิทยาศาสตร์(ข้อมูล) นักศึกษา และคนที่หลงใหลแบบสมัครเล่นเป็นหลัก หลายอย่างยังไม่สุกงอมพอ ตามมาตรฐานของวิศวกรซอฟต์แวร์มืออาชีพมันดูเหมือนโปรเจกต์ทำเล่นวันหยุดสุดสัปดาห์
    • ผมคิดว่างานจำนวนมากจริง ๆ ก็ยังถูกทำโดยวิศวกรซอฟต์แวร์มืออาชีพนะ
  • MCP ควรไปทาง stateless HTTP ตั้งแต่แรก เซิร์ฟเวอร์ส่วนใหญ่ไม่จำเป็นต้องเก็บ state ไว้ แค่เก็บสถานะส่วนกลางหรือมี session identifier ก็น่าจะพอ
    • ผมไม่เข้าใจโครงสร้างของการโต้ตอบจริงของ MCP ว่าทำไมถึงไม่เป็นแบบไร้สถานะ และทำไมต้องเปิดการเชื่อมต่อค้างไว้ด้วย
    • ประสบการณ์ส่วนตัวผมอาจยังน้อย แต่ถ้าปิดการเชื่อมต่อหลังแต่ละคำขอ ก็ต้องเชื่อมใหม่ทุกครั้งสำหรับคำขอถัดไป จะเปิด session ค้างไว้หรือปิดก็ขึ้นอยู่กับหลายปัจจัย เช่น รูปแบบการใช้งานและการใช้หน่วยความจำ
  • ผมกำลังสร้างบริการ MCP ชื่อ ninja.ai บน Ruby on Rails ซึ่งเป็น App Store สำหรับติดตั้ง MCP server ได้ในคลิกเดียว โดยใช้ Tauri ติดตั้งเซิร์ฟเวอร์ Model Context Protocol บนอุปกรณ์ไคลเอนต์ และมี cloud MCP server ให้ผ่าน Rails ด้วย ผมค่อนข้างวิจารณ์ HTTP+SSE หรือ Streamable HTTP เพราะถ้าต้องสื่อสารแบบสองทางเรียลไทม์ WebSockets จะดีกว่า และการรองรับ SSE ของ Rails ก็มีข้อจำกัด เลยต้องย้าย endpoint ไปที่ Falcon web server ผมสงสัยว่าทำไมวิศวกร Shopify ถึงเลือก Streamable HTTP บางทีอาจเป็นเพราะข้อจำกัดด้านอินฟราหรือการดีพลอยกได้เหมือนกัน และก็ต้องสังเกตด้วยว่าชั้นขนส่งของ MCP ถูกทำเป็นนามธรรมไว้แล้ว ดังนั้นในอนาคตก็ยังเปิดทางให้ใช้ WebSockets หรือ WebRTC ได้เต็มที่
  • ผมเป็นผู้ดูแลหนึ่งใน MCP registry (glama.ai/mcp/servers) เห็นด้วยกับผู้เขียนบางส่วน แต่โปรโตคอลยังอยู่ในช่วงเริ่มต้นมากและยังเปลี่ยนได้อีกมาก มันได้รับความสนใจเกินคาด จากเดิมมีแค่เซิร์ฟเวอร์ไม่กี่สิบเครื่องก็พุ่งเป็นหลายพันเครื่องในช่วงแรกสุด แต่ที่ใช้งานได้จริงมีแค่บางส่วน ผมเลยใช้เวลาเยอะมากกับการคัดกรอง นี่เป็นผลจากการที่ MCP ถูกจับตามองจากสาธารณะก่อนจะสุกงอมพอ แต่ช่วงหลังอีโคซิสเต็มอย่าง code framework, registry และไคลเอนต์ที่รองรับ MCP ก็เติบโตเร็วอย่างน่าทึ่ง การเปลี่ยนแปลงระดับนี้ภายในแค่ครึ่งปีถือว่าแทบไม่เคยเห็นมาก่อน ถ้ายังไปในทิศทางนี้ต่อ ผมมองว่าอนาคตสดใส และผมก็มีชุดลิงก์เอกสารที่เป็นประโยชน์สำหรับคนเริ่มต้นด้วย
    • ถ้าพลาดในช่วงออกแบบโปรโตคอลตอนแรก ก็ต้องแบกความผิดพลาดนั้นไปตลอด ดังนั้นการทำสเปกต้องถ่อมตัวมากพอ มิฉะนั้นโครงสร้างแบบโกลด์เบิร์กอย่าง SSE อาจแก้ไม่ออกและติดค้างถาวรได้ ในระดับองค์กร การเปลี่ยนแบบหักล้างเดิมของโปรโตคอลไม่ใช่เรื่องง่าย จึงอาจติดอยู่กับการตัดสินใจช่วงแรกไปนานโดยไม่มีการเปลี่ยนแปลง
    • ตัวโปรโตคอล MCP เองก็แน่นอนว่าจะพัฒนาต่อเนื่องไปตามเวลา การคาดหวังให้สมบูรณ์ตั้งแต่ต้นกลับดูแปลกกว่า ที่สำคัญกว่านั้นคือการทำมาตรฐาน agentic API ซึ่งเป็นการเปลี่ยนแปลงที่ทรงพลังมาก ถ้าได้ลองเขียนโค้ดและดีพลอยเอง แล้ว AI รับรู้และใช้งานได้อัตโนมัติทันที จะเข้าใจเลยว่ามันต่างแค่ไหน
    • สิ่งที่ผมห่วงคือด้วยความเร็วแบบนี้ mcp อาจยอมรับการออกแบบชั้นขนส่งที่ควรอยู่ยาวเร็วเกินไป นึกถึงกรณีการแตกมาตรฐานสมัย browser wars ในยุค 90 ที่ใช้เวลานานมากกว่าจะคลี่คลาย หรืออย่าง IE11 ที่อยู่นานเกินไป
  • ประเด็นถกเถียงเรื่องการยืนยันตัวตน (Authentication) กำลังถูกอัปเดตแล้ว โดยทำร่วมกับ Anthropic และชุมชนด้านความปลอดภัย เพื่อแยกบทบาท resource server (RS) กับ authorization server (AS) ใน MCP ตอนนี้มีการเผยแพร่ร่างสเปกชั่วคราวไว้ก่อนจนกว่าโปรโตคอลเวอร์ชันใหม่จะถูกทำให้เป็นทางการ
    • ผมสงสัยว่าสัดส่วนไหนของสเปก MCP ที่เป็นผลลัพธ์จาก LLM กันแน่ หรือจริง ๆ แล้วผมแค่จับสัญญาณเตือนบางอย่างได้โดยสัญชาตญาณ
    • ผมค่อนข้างเป็นกลาง แต่รู้สึกเหมือนแค่ก็อปร่าง OAuth มาแบบลวก ๆ และไม่ชอบที่พอใช้ HTTP แล้วกลับไม่มีทางเลือก นอกจากต้องทำตามโครงสร้างนี้ ทั้งที่จริงน่าจะจัดให้ชัดเจนกว่าว่าฝั่งไคลเอนต์และเซิร์ฟเวอร์จะรองรับ OAuth2 แบบเลือกใช้ได้
  • ผมเคยเปิด issue เรื่องการออก Streamable HTTP ของ MCP ว่าจะทำให้ทุกอย่างเป็นแค่ HTTP request ธรรมดาไปเลยไม่ได้หรือ MCP spec ดูมีอนาคตในฐานะวิธีทั่วไปสำหรับเชื่อม LLM เข้ากับเครื่องมือ แต่ของจริงกลับเจอปัญหาหนักหลายอย่าง ทั้งการยืนยันตัวตน การสตรีมมิง คำสั่งแบบกำหนดเองของแต่ละเครื่องมือ และการตรวจสอบความน่าเชื่อถือของเครื่องมือ ผมเลยมองว่าการเชื่อมผ่าน REST API อย่างเดียวง่ายกว่า แม้ OpenAI หรือ Gemini จะบอกว่าจะรองรับ MCP แต่สุดท้ายสเปกก็น่าจะไปชนกับความไม่ตรงกันในเรื่อง UI ชั้นปฏิสัมพันธ์ และสิ่งที่สเปกไม่ได้อยากกำหนด ทำให้เกิดปัญหาอย่างไม่เข้ากับแบรนด์หรือการยึดการยืนยันตัวตนได้
    • ถึง Anthropic จะเป็นคนสร้าง MCP แต่เมื่อเทียบกับ ChatGPT แล้วขนาดยังเล็กกว่ามาก ผมสงสัยว่าบริษัทใหญ่ ๆ อย่าง OpenAI หรือ Google จะยอมรับสเปกที่ทีมภายนอกทีมหนึ่งเป็นคนกำหนดข้อจำกัดของประสบการณ์ผู้ใช้ไปได้นานแค่ไหน ก่อนหน้านี้ก็เคยมีกรณีอย่าง ChatGPT Plugins ที่ล้มเหลวไม่ใช่เพราะวิศวกรรมไม่ดี แต่เพราะข้อจำกัดด้านประสบการณ์ผู้บริโภค ถึงอย่างนั้นผมก็ยังอยากฝากความหวังไว้กับพลังของชุมชนอยู่บ้าง
    • หลังจากโพสต์บล็อกแล้ว ผมก็เคยไปเขียนประเด็นคล้ายกันไว้เอง เพราะมันเป็นเรื่องสำคัญมาก และถ้าพลาดแล้วจะย้อนกลับได้ยากจริง ๆ
  • ผมงงว่าทำไม MCP ถึงดังขนาดนี้ แต่ยังไงมันก็เป็นเทรนด์อยู่ดี ถ้าเทียบกับสเปก OpenAPI อยากฟังคำอธิบายว่า MCP ดีกว่าในแง่ไหน
    • ผมคิดว่าความนิยมของ MCP ส่วนใหญ่เกิดจากช่วงหลังความสามารถในการใช้เครื่องมือของ LLM ดีขึ้นจริง ๆ OpenAI plugins ในปี 2023 ล้มเหลวเพราะตอนนั้น LLM ยังไม่น่าเชื่อถือพอในการใช้เครื่องมือ แต่ MCP มาได้จังหวะกว่ามาก
    • อีกเหตุผลสำคัญคือการเริ่มต้น MCP server ครั้งแรกทำได้ง่ายมาก และมีอุปสรรคในการเริ่มต้นต่ำ เมื่อเครื่องมือมีมากขึ้น ข้อความที่ต้องส่งให้ LLM ก็เพิ่มขึ้นด้วย แต่ถ้าให้ OpenAPI พร้อมรายละเอียดแต่ละ path และข้อความอธิบาย Claude ก็เชื่อมต่อได้ดีเยี่ยมเหมือนกัน
    • เหตุผลสำคัญอีกข้อของ MCP คือ OpenAPI เป็นเอกสารแบบสถิต ทำให้ LLM ต้องรับภาระทั้งหมดในการสร้างคำขอเอง แต่ MCP server มีชั้นนามธรรมช่วยลดภาระนั้นลง ผลคือสำหรับ LLM แล้วมันง่ายกว่า เร็วกว่า และปลอดภัยกว่า
    • ผมไม่ได้มองว่า MCP สมบูรณ์แบบ แต่มีอยู่หลายจุดที่เหมาะกับ LLM มากกว่า OpenAPI อย่างแรกคือ MCP tools สามารถระบุสเปกได้สั้นและง่ายกว่ามาก ขณะที่สเปก OpenAPI ใหญ่เกินไปและกินพื้นที่คอนเท็กซ์ของ LLM มากเกินจำเป็น LLM เองก็ไม่ได้สร้างการเรียกใช้งานจริง แต่แค่สร้างข้อความผลลัพธ์ ดังนั้นแนวทางแบบ MCP จึงเป็นธรรมชาติกว่า และ MCP ยังยืดหยุ่นกับโครงสร้างแบบไดนามิก เช่น การเพิ่มหรือเปลี่ยนเครื่องมือ ได้มากกว่า จึงแก้ข้อจำกัดความเป็นสถิตของ OpenAPI ได้ แน่นอนว่ายังมีปัญหาอยู่ โดยเฉพาะชั้นขนส่งที่ยังปรับปรุงได้อีกมาก แต่ไลบรารีหลัก ๆ ก็ทำออกมาได้ค่อนข้างดีแล้ว