MCP: ระบบปลั๊กอินอเนกประสงค์ (โดยบังเอิญ)

• USB-C มีคุณค่าไม่ใช่แค่สำหรับการชาร์จหรือถ่ายโอนไฟล์เท่านั้น แต่ยังอยู่ที่ความ อเนกประสงค์ ซึ่งสามารถขยายไปใช้ได้หลากหลายรูปแบบ
• MCP(Model Context Protocol) เดิมออกแบบมาสำหรับผู้ช่วย AI แต่ในทางปฏิบัติสามารถกลายเป็น ระบบปลั๊กอินอเนกประสงค์ ที่เชื่อมต่อ ทุกแหล่งข้อมูลและทุกเครื่องมือ ได้
• เช่นเดียวกับกรณีของ NFT Base64 โปรโตคอลสามารถ ขยาย ออกไปไกลกว่าจุดประสงค์ดั้งเดิม จนถึงขั้นเก็บและใช้งานข้อมูลจริงได้โดยตรง
• ยิ่งมี เซิร์ฟเวอร์ MCP มากขึ้น แต่ละแอปก็ยิ่งดึงเอา ความสามารถที่หลากหลาย มาใช้ได้ง่ายขึ้นโดยไม่ต้องทำอินทิเกรชันแยกกัน
• เช่นเดียวกับ USB-C, MCP ก็อาจกลายเป็น "พื้นที่แห่งความเป็นไปได้ที่เชื่อมต่ออะไรก็ได้" และเป็นรากฐานของ นวัตกรรมที่คาดไม่ถึง

---

MCP: An (Accidentally) Universal Plugin System (Or: The Day My Toaster Started Taking Phone Calls)

USB-C และความอเนกประสงค์ที่คาดไม่ถึง

• ทุกคนคิดว่า USB-C มีไว้เพื่อการชาร์จหรือถ่ายโอนไฟล์ แต่ด้วย โครงสร้างของมัน จึงสามารถขยายไปใช้ในรูปแบบต่าง ๆ ได้
• ผู้เขียนยกตัวอย่างเพื่อนชื่อ Rex ที่เอาเครื่องปิ้งขนมปังไปต่อเข้ากับจอภาพ จนเครื่องปิ้งขนมปังมีความสามารถ ส่งออก HDMI ได้ ซึ่งแสดงให้เห็นถึง ความเป็นไปได้ไร้ขีดจำกัด ของ USB-C
• นี่เกิดจากการที่ USB-C เป็นโครงสร้างที่ไม่ไปจำกัดเรื่อง มาตรฐานพลังงานและข้อมูล มากนัก ขอแค่พอร์ตเข้ากันก็เชื่อมต่ออะไรก็ได้

หลักการของช่องจุดบุหรี่ในรถยนต์

• ช่องจุดบุหรี่ ในรถยนต์เดิมมีไว้สำหรับจุดบุหรี่ แต่ปัจจุบันถูกใช้เป็น พอร์ตจ่ายไฟอเนกประสงค์ สำหรับสารพัดอุปกรณ์
• เช่นเดียวกับช่องจุดบุหรี่ โปรโตคอล ที่ดีไม่จำกัดทางเลือกของผู้ใช้ แต่เปิดให้ใช้งานได้หลากหลาย
• MCP ก็มี ความสามารถในการขยายแบบเดียวกัน

การค้นพบ MCP ใหม่: กลายเป็นระบบปลั๊กอินอเนกประสงค์โดยบังเอิญ

• โดยทั่วไป MCP(Model Context Protocol) เป็นที่รู้จักว่าใช้เพื่อให้ผู้ช่วย AI (เช่น Claude) เข้าถึงและใช้ข้อมูลได้
• ในเอกสารทางการก็ระบุไว้ชัดว่าเป็นการ "เชื่อมต่อโมเดล AI กับแหล่งข้อมูลและเครื่องมือต่าง ๆ แบบมาตรฐาน"
• แต่ถ้าตัด องค์ประกอบ AI ออกไป MCP ก็จะกลายเป็นวิธีสำหรับเชื่อมต่อ "อะไรก็ได้" เข้ากับแหล่งข้อมูลและเครื่องมือที่แตกต่างกัน
• เท่ากับว่ามันกลายเป็น โปรโตคอลเชื่อมต่ออเนกประสงค์ โดยไม่เกี่ยวกับจุดประสงค์เดิมอีกต่อไป

The NFT Base64 Revelation

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

เครือข่ายเอฟเฟกต์ที่ไม่มีใครคาดคิด

• ยิ่งมีเซิร์ฟเวอร์ MCP สำหรับ AI เพิ่มขึ้น ก็ยิ่งเกิดผลให้ ทุกแอปได้รับฟีเจอร์ใหม่ โดยแทบไม่ต้องพัฒนาเพิ่มเติมแยกต่างหาก
• ตัวอย่างเช่น ถ้ามีคนสร้าง Spotify MCP server แอปออกกำลังกายก็อาจสร้างเพลย์ลิสต์ได้ อัตโนมัติผ่าน MCP
• เกิด network effect ที่ นักพัฒนาและแอปที่ไม่เคยรู้จักกันมาก่อน สามารถเชื่อมต่อกันอย่างเป็นธรรมชาติและทุกฝ่ายได้ประโยชน์
• เซิร์ฟเวอร์ MCP แต่ละตัวจึงสามารถนำกลับมาใช้ซ้ำเป็น ปลั๊กอินอเนกประสงค์ ได้
• ไม่มีใครตั้งใจออกแบบไว้ แต่สุดท้ายกลับเกิด ระบบนิเวศปลั๊กอินอเนกประสงค์โดยบังเอิญ ขึ้นมา

ความหมายของ USB-C และปรัชญาของ MCP

• ผู้คนมักเปรียบ MCP ว่าเป็น USB-C ของ AI และสิ่งที่ทำให้ USB-C พิเศษก็คือ มันไม่ใช่แค่ พอร์ตธรรมดา แต่เป็น พื้นที่แห่งความเป็นไปได้ที่เชื่อมต่ออะไรก็ได้
• เหมือนที่ USB-C รองรับพลังงาน ข้อมูล วิดีโอ และฟังก์ชันอื่น ๆ ที่ยังไม่รู้จัก MCP ก็ไม่ใช่แค่ของ "สำหรับ AI" แต่เป็น 'ช่องที่ออกแบบมาอย่างดีสำหรับความสามารถต่าง ๆ' ซึ่งใครก็เชื่อมฟังก์ชันอะไรก็ได้เข้ามาได้

The Part Where I Tell You I'm Building Something

• ผู้เขียนกำลังพัฒนาแอปจัดการงานชื่อ APM(Actions Per Minute)
• APM ทำงานโดยใช้ เฉพาะเซิร์ฟเวอร์ MCP เท่านั้น เป็นระบบปลั๊กอิน
• ทุกครั้งที่ผู้ใช้ต้องการเพิ่มฟังก์ชัน ก็แค่เชื่อมต่อเซิร์ฟเวอร์ MCP ที่ต้องการ (เช่น ตรวจการสะกด สั่งกาแฟอัตโนมัติ รีแอ็กชันของตัวละครในเกม ฯลฯ)
• โครงสร้างนี้ทำให้ตัวแอปเองสามารถ แปรเปลี่ยนได้อย่างยืดหยุ่นและหลากหลาย

The Toaster Protocol Principle

• โปรโตคอลที่ยิ่งใหญ่ ทุกตัวมักสร้างนวัตกรรมจากการถูกนำไปใช้ใน รูปแบบที่คาดไม่ถึง ต่างจากเจตนาแรกเริ่ม
  • HTTP: สำหรับบทความวิชาการ → โครงสร้างพื้นฐานของอารยธรรม
  • Bluetooth: แฮนด์ฟรี → ปลดล็อกประตูหน้าบ้าน เป็นต้น
  • USB: อุปกรณ์รับข้อมูลเข้า → ชาร์จพัดลมพกพา เป็นต้น
• MCP เองก็เช่นกัน แม้เดิมจะมีไว้ส่งต่อบริบทให้ AI แต่โดยแก่นแท้แล้วมันคือ โปรโตคอลที่เชื่อมทุกสิ่งเข้าหากัน
• ผู้เขียนย้ำว่ามันคือรากฐานของ ระบบนิเวศปลั๊กอิน ที่จะก่อให้เกิดนวัตกรรมคาดไม่ถึง
• แม้จะไม่เคยตั้งใจไว้เลย แต่มันกลับเหมาะอย่างยิ่งกับยุคที่ เครื่องปิ้งขนมปังเชื่อมต่อจอภาพผ่าน HDMI

บทส่งท้าย

• PS: ถ้าใครสร้างคอมพิวเตอร์ที่ปล่อยกลิ่นขนมปังสดใหม่ได้ผ่าน MCP server อย่าลืมติดต่อมาด้วย
• PPS: เปิดให้ใช้งาน APM early access แล้ว และสนับสนุน ความพยายามสุดแหวกแนว กับ การทดลองเชิงสร้างสรรค์
• (ที่ไหนสักแห่งยังมีคนใช้โปรโตคอลตามวัตถุประสงค์เดิมอยู่ ซึ่งน่าสงสัยมาก)

[a1eng0]

คำตอบของเซิร์ฟเวอร์ MCP มักเป็นภาษาธรรมชาติโดยไม่มี schema ที่กำหนดไว้แน่นอน

คงจะยากที่จะประมวลผลคำตอบภาษาธรรมชาตินี้ด้วยวิธีเชิงโปรแกรมโดยไม่ใช้ LLM

[winterjung]

อ้างอิงไว้ก่อนว่า สเปก mcp 2025-06-18 ได้เพิ่ม structured tool output เข้ามาใหม่ ทำให้สามารถระบุ response schema ได้แล้ว แม้ว่าเครื่องมือ mcp ที่มีการพัฒนาไว้ก่อนหน้านี้ส่วนใหญ่จะยังเป็นแบบ unstructured อย่างที่คุณบอก แต่สำหรับเครื่องมือ mcp ต่อจากนี้ก็น่าจะพอคาดหวังได้ครับ

[a1eng0]

ได้เจอคุณ Gyeoul อีกแล้วที่นี่นะครับ 555

ผมยังตามสเปกฉบับ 250618 ไม่ทันเลย ขอบคุณครับ!

[GN⁺]

ความเห็นจาก Hacker News

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

• ฉันเห็นด้วยกับแนวคิดในบทความ และคิดว่าน่าสนใจมากที่ผู้เขียนใช้งาน MCP ในแบบที่ค่อนข้างออกนอกทางเล็กน้อย แก่นสำคัญจริง ๆ ของแนวคิดนี้ไม่ใช่การที่มีโปรโตคอลหนึ่งเกิดขึ้นมาเพื่อทำสิ่งใหม่ที่ไม่เคยทำได้มาก่อน อันที่จริงอย่างที่คอมเมนต์อื่นบอก MCP เองไม่ใช่ไอเดียที่ใหม่หรือชวนตื่นเต้นอะไรเป็นพิเศษ ส่วนที่น่าสนใจจริง ๆ คือเพราะกระแส AI agent ทำให้เรื่อง interoperability ได้รับความสนใจ จนปัญหา vendor lock-in ถูกมองว่าเป็นของล้าสมัยไปแล้ว ไม่รู้ว่าปรากฏการณ์นี้จะอยู่นานแค่ไหน แต่ตอนนี้ก็รู้สึกดีกับมันมาก

  • มันทำให้ฉันนึกถึงตอนที่ Winsock ถูกนำมาใช้ สมัยหนึ่งงานด้านเครือข่ายบน Windows ต่างก็ใช้อินเทอร์เฟซปิดของใครของมันกันหมด แล้วมีเรื่องเล่าว่าวันหนึ่งผู้ขายหลายรายมานั่งร่วมโต๊ะกันและตัดสินใจสร้างมาตรฐานร่วมที่ทุกฝ่ายได้ประโยชน์ ดู Winsock บน Wikipedia
  • ประเด็นสำคัญไม่ได้มีแค่ว่า interoperability กลายเป็นกระแสนิยมหรือเชื่อมต่อกันได้ง่ายขึ้น นวัตกรรมที่แท้จริงคือ LLM เองได้เรียนรู้วิธีใช้เครื่องมือแล้ว ถ้าทำแค่แบ็กเอนด์เสร็จ งานฟรอนต์เอนด์ก็ไม่ใช่เรื่องของฉันอีกต่อไป เพราะ AI จัดการเองได้ Claude กับ Gemini ก็สามารถใช้เครื่องมือได้เองถ้าเพียงบอกเป้าหมายให้ชัด แต่ก่อนเราต้องกำหนดขั้นตอนแบบละเอียดทีละสเต็ปเพื่อให้ได้ผลลัพธ์ที่ต้องการ ตอนนี้ LLM ปรับตัวกับสถานการณ์ที่เปลี่ยนไปได้ดีกว่าโปรแกรมแบบตายตัวมาก จึงรู้สึกว่านี่เป็นการเปลี่ยนแปลงครั้งใหญ่จริง ๆ
  • บรรยากาศตอนนี้ดูเต็มไปด้วยความคาดหวังที่สูงเกินไป แต่ฉันคิดว่า AI agent ได้สร้างแรงจูงใจให้เกิด interoperability อย่างชัดเจน ในอดีตต่างคนต่างทำงานช้า ๆ อยู่ในระบบของตัวเองก็เหมือนมีความมั่นคงในอาชีพ แต่ตอนนี้ทุกคนพยายามเชื่อมทุกอย่างเข้าด้วยกัน เอเจนต์ต้องพึ่งพาการเชื่อมต่อได้ เหมือนกับการที่ CEO ลงมาช่วยยกพิซซ่าในแฮกกาธอนเองยังถูกกว่าเสียอีก ในฐานะคนที่เคยอยู่บนคลื่นการปฏิวัติด้าน API integration มาก่อน ตอนนี้รู้สึกเหมือนโลกเพิ่งตามมาทัน และหวังว่าบรรยากาศแบบนี้จะอยู่ต่อไปนาน ๆ
  • ฉันไม่เห็นด้วยทั้งหมดกับความเห็นที่ว่ากระแส AI agent กำลังผลักดัน interoperability และทำให้ vendor lock-in กลายเป็นเรื่องล้าสมัย เครื่องมือที่กำลังมาแรงอย่าง Cursor เองก็ใช้ MCP แค่ทางเดียว และไม่ได้ส่งประวัติการสนทนาหรือคอนเท็กซ์ออกไปข้างนอก ฉันชอบ Cursor นะ แต่ตั้งแต่การเป็น VS Code fork ที่ไม่โอเพนซอร์ซไปจนถึงแนวคิดแบบ "รับอย่างเดียวไม่คืนกลับ" แบบนี้ ฉันคิดว่ามันจะส่งผลเสียต่อความเชื่อมั่นของนักพัฒนา สุดท้ายแล้ว lock-in ก็ยังแข็งแรงเหมือนเดิม
  • น่าเสียดสีตรงที่มาตรการจำกัดการเข้าถึง API ช่วงหลังกลับรุนแรงขึ้นเพราะเรื่องการนำข้อมูลไปฝึก AI จริง ๆ แล้วการปิดกั้น API แบบนี้มีมาก่อนนานแล้ว และถ้ากระแสการเปิดใหม่ครั้งนี้ไปไม่ถึงความคาดหวังที่ร้อนแรงเกินจริง มันก็อาจกลับไปปิดอีกเมื่อไรก็ได้

• ผู้เขียนดูคาดหวังกับความเป็นสากลของ MCP มาก แต่พูดตรง ๆ ฉันยังสงสัยว่ามันต่างจากแนวคิด API โดยพื้นฐานตรงไหน ถ้าแทนคำว่า MCP ด้วย REST เนื้อหาในบทความจะเปลี่ยนไปมากไหม API ของระบบปฏิบัติการหรือ POSIX รวมถึง Unix pipe ก็มีความคล้ายกันอยู่ แน่นอนว่า MCP เรียบง่ายและครอบจักรวาลกว่าสิ่งเหล่านั้นมาก แต่บางทีทางออกจริง ๆ อาจไม่ใช่การสร้าง abstraction ใหม่ซ้ำแล้วซ้ำเล่า แต่อาจเป็นการกลับไปสร้างซอฟต์แวร์ที่เรียบง่ายและยึดพื้นฐานมากกว่า

  • MCP ไม่เหมือน REST ถ้าจะเปรียบ มันเหมือนโปรโตคอลที่ทำให้ค้นพบ REST endpoint แบบไดนามิกได้ตอนรันไทม์ และให้ผู้ใช้เป็นคนกำหนดเองว่าจะใช้ REST endpoint ไหน เช่น ถ้าอยากให้แอปเล่นเพลงจาก Spotify ก็แน่นอนว่าต้องใช้ Spotify API แล้วถ้าภายหลังอยากรองรับเพลงจาก Sonofm ด้วย วิธีเดิมคือต้องแก้โค้ด เพิ่มเงื่อนไข ออกรุ่นใหม่ และคอยแจ้งให้คนอัปเดต แต่ MCP ทำให้กำหนดสิ่งเหล่านี้ได้ตอนรันไทม์ จึงรู้สึกว่าขยายต่อได้ง่ายกว่ามาก
  • ความต่างสำคัญคือ MCP บังคับให้มี self-description ตั้งแต่แรก REST ก็มี OpenAPI แต่เป็นของที่มาพ่วงทีหลัง และการใช้งานมาตรฐานก็ยังต่ำ ตรงกันข้าม MCP บังคับให้เปิดเผยคำอธิบายก่อนเป็นอันดับแรก จึงเข้าถึงได้ต่างกัน
  • สำหรับฉัน สิ่งเดียวที่ทำให้ MCP ดูใหม่จริง ๆ คือมันบังคับในระดับโปรโตคอลให้ต้องมี schema ให้ด้วย แน่นอนว่าโครงสร้าง request/response ที่สม่ำเสมอทำให้ไลบรารีที่ครอบ dynamic type ด้วย static type จัดการได้สะดวกขึ้น แต่จริง ๆ ทุกคนก็ทำอะไรคล้าย ๆ กันใน API อยู่แล้ว เราแค่ไม่เคยตกลงเรื่องรูปแบบ envelope ร่วมกันเท่านั้นเอง ฉันคิดว่ามันได้รับความสนใจเพราะการมี schema เป็นข้อบังคับตั้งแต่ต้น และ AI model ก็เอาไปใช้ต่อได้ทันที
  • จุดต่างใหญ่ของ MCP กับ REST คือมีคำสั่งในตัวอย่าง list-tools REST API มีวิธีทำรายการ resource ได้หลายแบบ แต่ MCP ให้มาวิธีมาตรฐานเดียว
  • อีกความต่างสำคัญคือ MCP มีขั้นตอน discovery ฝังอยู่ในตัวโปรโตคอลเลย ส่วน REST ไม่มีองค์ประกอบใด ๆ ที่บอกลูกค้าว่ามี resource อะไรได้บ้าง หรือ API นั้นทำอะไรได้บ้าง

• มีคนพูดถึง MCP ว่ายิ่งใหญ่มาก แต่ฉันยังไม่ค่อยเห็นตัวอย่างที่สร้างของเจ๋ง ๆ ได้จริงนัก ให้ความรู้สึกคล้ายช่วงกระแสบล็อกเชน สุดท้ายแล้วฉันรู้สึกว่า MCP ก็อาจเป็นเพียงทางแก้ชั่วคราวจนกว่า AI จะฉลาดขึ้น อีกประมาณ 2 ปีต่อจากนี้ เราอาจเลิกใช้ MCP แล้วโยนเอกสารของเครื่องมือหรือ OpenAPI เข้าไปตรง ๆ ให้ AI กลืนคอนเท็กซ์ทั้งหมดเองตามธรรมชาติก็ได้

  • ตัวอย่างเช่น ฉันยังสงสัยว่าการใส่แค่เอกสารของ Ableton Live จะช่วยให้ Claude แต่งเพลงได้ด้วยตัวเองอย่างไร
  • ต่อให้โมเดลดีขึ้นแค่ไหน สุดท้ายถ้าไม่ให้การเข้าถึงเครื่องมือแบบ deterministic และไม่ให้ข้อมูลเกี่ยวกับสถานะของโลกภายนอกโดยตรง ความสามารถในการใช้งานก็ยังถูกจำกัดมาก และถ้าคิดเรื่องความปลอดภัยด้วย เราก็ปล่อยให้โมเดลยิงคำขอเข้าโปรดักชันตามใจโดยไร้การควบคุมไม่ได้ ฉันคิดว่ากระแสความตื่นเต้นต่อ MCP ตอนนี้มากเกินไปหน่อย แต่ปัญหาที่พูดถึงกันอยู่นั้นสำคัญจริง ถ้าโปรโตคอลนี้ช่วยให้นักพัฒนาเปิดความสามารถต่าง ๆ ออกมาเป็น API ที่ชัดเจนขึ้นได้ นั่นก็น่าตื่นเต้นมาก
  • กระแสบล็อกเชนกับ MCP ต่างกันพอสมควร ฉันเองตอนแรกก็สงสัย แต่พอลองทำ MCP server ด้วยตัวเองนิดหน่อยแล้วรู้เลยว่ามันเป็นคนละประสบการณ์กัน การเอา conversational/voice AI และ LLM ปัจจุบันมาผสมกับ MCP พร้อมเครื่องมือและฟังก์ชันต่าง ๆ เข้ากับ API และข้อมูล/บริการภายใน มันให้ความรู้สึกเหมือนกำลังก้าวเข้าสู่ frontier ใหม่ทั้งหมด มันอาจยังไม่สมบูรณ์ 100% แต่สำหรับ use case ใช้งานจริงแทบทั้งหมดก็เพียงพอแล้ว และวิธีสร้างแอปในอนาคตน่าจะเปลี่ยนไปมาก
  • จริง ๆ แล้วฉันสงสัยว่าในสัปดาห์นี้สมาชิกสภานิติบัญญัติในรัฐของฉันทำอะไรไปบ้าง แต่หาแหล่งข้อมูลที่ค้นง่ายไม่ได้ พอได้ยินว่าการใช้ MCP กับ API ของ congress.gov น่าสนใจก็เลยลองทำ MCP server ขึ้นมาเอง โค้ดอยู่ที่นี่ ตอนนี้ใช้งานจริงได้ดีมากสำหรับติดตามความเคลื่อนไหวของสภาคองเกรสสหรัฐแบบเรียลไทม์
  • ตราบใดที่สถาปัตยกรรม AI model ยังพัฒนาต่อไป ฉันคิดว่าชั้น middleware ตรงกลางอย่าง MCP คงหายไปได้ยาก

• ฉันคิดว่านี่เป็นอีกรอบของกลยุทธ์ "Embrace, Expand, Extinguish" ที่ Microsoft ใช้มาตลอด ด้วยเหตุผลด้านเสถียรภาพของระบบและความปลอดภัย การปล่อยให้เอเจนต์ค้นหาเครื่องมือแบบไดนามิกโดยไม่มีการกำกับดูแลย่อมเพิ่มความเสี่ยงต่อความขัดแย้ง แม้จะมีตัวเลือกอื่นอย่าง PydanitcAI แต่สุดท้าย Microsoft ก็ออกมาดัน MCP อย่างเป็นทางการในงาน Build 2025 และกำลังพาอุตสาหกรรมไปตามจังหวะของตัวเอง Anthropic เอามาตรฐานออกมาก่อนทั้งที่เรื่องเครื่องมือยังอ่อนและไม่มี governance จึงเป็นสถานการณ์ที่ Microsoft เข้ายึดได้ง่าย ขั้นต่อไปอาจเป็นการทำให้ registry ของตัวเองกลายเป็นมาตรฐานอุตสาหกรรม และผูกเข้ากับคำสั่งเฉพาะของ Windows สุดท้ายก็อาจกำหนดเกณฑ์ "ความปลอดภัย" ให้เอื้อประโยชน์กับตัวเองและกันคู่แข่งออกไป

• ถ้าลองตัดองค์ประกอบ AI ออกไปเลยจะเป็นอย่างไร ถ้าไปพึ่งพา MCP server โดยตรงโดยไม่มี AI middleware ฉันกังวลว่าจะชนกับปัญหา backward compatibility ทันที เพราะ MCP server ต่าง ๆ ตั้งสมมติฐานว่าฝั่งที่เรียกใช้งานคืออัลกอริทึม AI จึงอาจมี breaking change ที่อิงกับเครื่องมือหรือ input/output schema เกิดขึ้นเมื่อไรก็ได้

• ฉันก็เคยคิดคล้ายกัน แต่พอมองไปก็รู้สึกว่า MCP server ส่วนใหญ่คงเป็นแค่ไคลเอนต์รูปแบบใหม่ของ API เดิมเท่านั้นเอง อย่างเช่น Kagi MCP server ก็แค่เรียก Kagi API ถ้าอย่างนั้น ใช้ API โดยตรงเลยไม่ดีกว่าหรือ อีกอย่าง ระบบก็คงมี Python interpreter เพิ่มขึ้นตามจำนวน MCP server ไปเรื่อย ๆ เลยสงสัยว่าจะมีบริการ "โฮสต์" ที่รวบรวมพวกนี้ทั้งหมดแล้ว bridge ให้ใช้งานพร้อมกันในอนาคตหรือไม่

  • จากที่ฉันเข้าใจ MCP ก็เหมือนการเพิ่ม endpoint API ชื่อ /list-tools เข้าไปบน API เดิมอีกตัว ทุกไคลเอนต์จะเข้า /list-tools ก่อนเพื่อรับรายการเครื่องมือที่ใช้งานได้ แล้วค่อยเรียก API แต่ละตัวหลังจากนั้น
  • วิธีคิดของฉันคือ ถ้ามี API ที่มี OpenAPI spec อยู่แล้ว ก็แค่ห่อด้วย FastMCP ไม่ใช่หรือ ฉันลองเชื่อมกับ Goose พร้อมจัดการคำขอด้าน auth แล้ว สรุปคือ Goose แค่ยิงคำสั่ง curl ไปที่ route ของ API เดิมก็จบ ถ้า OpenAPI spec ของเดิมดีพอ MCP อาจไม่จำเป็นเสมอไปก็ได้ แน่นอนว่าถ้ายังไม่มี API เดิมอยู่เลย มันก็ดูมีแนวโน้มว่า MCP server เองจะค่อย ๆ พัฒนาไปเป็นตัวทำงานหลักแทน

• ในคอมเมนต์มีมุมมองแบบตั้งข้อสงสัยเยอะ และฉันก็เห็นด้วย สัปดาห์ก่อนฉันลองทำ MCP server เองแล้ว พูดตรง ๆ ว่าคิดว่าคำชมว่า "ออกแบบมาดี" นั้นเกินจริงไปหน่อย หนึ่งในเป้าหมายของ MCP คือ "ทำให้สร้างได้ง่าย" แต่พอลงมือจริงมันก็ไม่ได้ง่ายขนาดนั้น ถึงอย่างนั้น สิ่งสำคัญคือสายตาของนักพัฒนาจำนวนมากกำลังพุ่งไปในทิศทางเดียวกัน โมเมนตัมแบบนี้ทำให้การแก้ปัญหาเกิดขึ้นได้เร็วมาก และระบบนิเวศจะก่อตัวขึ้นได้ก็ต้องมี critical mass ตอนนี้ฉันรู้สึกว่าจุดเปลี่ยนนั้นมาถึงจริง ๆ ขอให้ทุกคนมีทั้งความอดทนและโชคดี

  • ถ้าใช้แค่ไลบรารี MCP สำหรับ Python มันง่ายมาก แค่ใส่ decorator ให้ฟังก์ชัน เครื่องมือก็เสร็จแล้ว ฉันเองก็ไม่รู้โปรโตคอล MCP เลยแต่ก็ใช้งานวิธีนี้ได้ดี แน่นอนว่าถ้าต้อง implement ตัวโปรโตคอลเอง สถานการณ์อาจต่างออกไป
  • มุมมองที่ว่า MCP server ควรทำแค่ "เปิดเผย API สาธารณะหรือกึ่งสาธารณะที่มีอยู่แล้วอีกครั้ง" นั้นฟังดูมีเหตุผล กล่าวคือควรจะทำได้โดยแก้ endpoint เดิมให้น้อยที่สุดเท่าที่เป็นไปได้
  • ที่ผ่านมาก็เคยมีความพยายามคล้ายกัน แต่พอผ่านไปไม่กี่ปี แอปต่าง ๆ ก็มักล็อก endpoint แล้วบังคับให้เข้าถึงได้เฉพาะเซิร์ฟเวอร์บางรายอย่าง chatgpt หรือ claude เท่านั้น interoperability ในความเป็นจริงก็คือ portability ของผู้ใช้ด้วย และในโลกจริงบริษัทเทคโนโลยีจำนวนมากก็ให้ความสำคัญกับ lock-in และการผูกขาดมากกว่าการย้ายออกได้สะดวก

• อยากย้ำว่าการลดอุปสรรคในการเข้าถึงมีบทบาทสำคัญต่อการยอมรับและการแพร่กระจายของเทคโนโลยีมาโดยตลอด MCP ก็เป็นส่วนหนึ่งของแนวโน้มนี้และไม่ควรถูกมองข้าม ในทีมของเราเอง คนที่ไม่มีพื้นฐานทางเทคนิคเลยก็สามารถใช้งานเอเจนต์เพื่อทำงานอัตโนมัติในการแชร์ไฟล์ได้ด้วยตัวเอง แน่นอนว่าเมื่อก่อนสิ่งนี้ทำได้ผ่านภาษาการเขียนโปรแกรม ไลบรารี หรือ API นับร้อยเท่านั้น แต่ด้วย MCP ตอนนี้เราเข้าสู่ยุคที่คนไม่ใช่ผู้เชี่ยวชาญแก้ปัญหาได้ทันทีโดยแทบไม่ต้องสนใจเบื้องหลัง มันอาจไม่ใช่วิธีที่แรงที่สุดและไม่ใช่ implementation ที่ดีที่สุด แต่คุณค่าของวิธีใหม่แบบนี้ ภายใต้ทรัพยากรและระดับเทคโนโลยีที่เรามีตอนนี้ ถือว่าไม่เคยมีมาก่อน และนั่นแหละคือประเด็นสำคัญจริง ๆ

  • ฉันคิดว่าเรื่องที่บอกว่าสมาชิกทีมที่ไม่ใช่สายเทคนิคจัดระเบียบการแชร์ไฟล์เองได้อย่างดีนั้นฟังดูเกินจริง ถ้าแค่จัดไฟล์หลายพันไฟล์ก็คงอีกเรื่อง แต่จากประสบการณ์ของฉัน ความพยายามจัดระเบียบระบบแชร์ไฟล์แทบทุกครั้งยังยากแม้แต่จะขอความร่วมมือจากฝ่ายที่เกี่ยวข้อง เจ้าของงานเองยังไม่อยากทำเพราะไม่ใช่งานของเขา ต้องถึงขั้นให้ผู้บริหารระดับสูงมาช่วยกดดัน หรือบางทีก็นั่งด้วยกันเป็นชั่วโมงเพื่อรีดโครงสร้างโฟลเดอร์ออกมาให้ได้ 50% ของงานคือการเมืองระหว่างแผนก 20% คือการอัปเดตกระบวนการ 20% คือการฝึกอบรม ปัญหาทางเทคนิคมีแค่ 10% เท่านั้น ฉันเคยเจอทั้งหายนะเล็กใหญ่และความโกลาหลไม่รู้จบ ดังนั้นต่อให้ AI tool ทำให้การสร้างระบบง่ายขึ้น ฉันก็ยังไม่เชื่อว่าความเป็นจริงจะง่ายขนาดนั้น และคาดว่าอีกไม่กี่เดือนก็คงต้องกลับไปกู้ข้อมูลจากแบ็กอัปกันอยู่ดี

• มุกที่ว่า "ฉันอยากให้ AI agent รับคำสั่งแล้วตอบกลับเหมือน peon ใน Warcraft 3" ส่วนฉันขอไปล่องเรือดีกว่า

  • ขอเสริมว่า "I'd rather be sailing" เป็นประโยคจาก Warcraft 2 ส่วนใน Warcraft 3 คำตอบคือ "I'd rather be flying"