MCP ตายแล้ว; MCP จงเจริญ

 (chrlschn.dev)
19 คะแนน โดย GN⁺ 2026-03-16 | 6 ความคิดเห็น | แชร์ทาง WhatsApp
  • CLI กำลังกลายเป็นเทรนด์ใหม่ของอินเทอร์เฟซเครื่องมือสำหรับเอเจนต์ แต่ CLI แบบปรับแต่งเองก็เผชิญกับ ปัญหาเรื่องคอนเท็กซ์ เช่นเดียวกับ MCP และต้องแลกมาด้วยการสูญเสียโครงสร้างและข้อดีหลายอย่าง
  • MCP แบบ stdio ในเครื่องและ MCP ระยะไกลที่ใช้ Streamable HTTP เป็นยูสเคสที่ต่างกันโดยสิ้นเชิง และความแตกต่างนี้กำลังถูกมองข้ามในการถกเถียงปัจจุบัน
  • ฟังก์ชัน Prompts และ Resources ของ MCP คือกลไกสำหรับกระจายสกิลและเอกสารที่เป็นมาตรฐานทั่วทั้งองค์กรแบบเรียลไทม์ ซึ่งเป็นกุญแจสำคัญในการเปลี่ยนจาก vibe coding ไปสู่การทำ agentic engineering อย่างเป็นระบบ
  • เซิร์ฟเวอร์ MCP แบบรวมศูนย์ช่วยทำให้ การยืนยันตัวตนด้วย OAuth, เทเลเมทรี, การสังเกตการณ์ระบบ เป็นมาตรฐานเดียวกัน จึงทำให้เกิดความปลอดภัยในระดับองค์กรและวัดประสิทธิผลของเครื่องมือได้
  • สำหรับนักพัฒนารายบุคคล CLI อาจเหมาะกว่า แต่ในระดับ องค์กรและเอนเตอร์ไพรส์ MCP คือเครื่องมือของปัจจุบันและอนาคตที่รับประกันความสม่ำเสมอ ความปลอดภัย และคุณภาพ

วงจรไฮป์ที่ขับเคลื่อนโดยอินฟลูเอนเซอร์

  • เมื่อ 6 เดือนก่อน Model Context Protocol (MCP) ยังเป็นหัวข้อร้อนที่สุดของวงการ และผู้ขายทุกรายต่างพยายามออกผลิตภัณฑ์ที่เกี่ยวข้องกับ MCP
  • แม้ตอนนั้นก็มีมุมมองแบบกังขาว่า “มันก็แค่ API แล้วทำไมต้องมี wrapper” และในความเป็นจริงก็มีทีมที่เลือกข้ามวงจรไฮป์ของ MCP แล้วเขียน tool wrapper แบบง่ายบน REST API endpoint โดยตรง
  • สำหรับยูสเคสส่วนใหญ่ MCP ถูกมองว่าเป็น โอเวอร์เฮดที่ไม่จำเป็น เมื่อเทียบกับการเรียก API โดยตรง
  • ตอนนี้บทสนทนาในวงการได้เปลี่ยนไปเป็นการวิจารณ์ MCP และ การยกย่อง CLI ซึ่งเกี่ยวข้องกับโครงสร้างที่อินฟลูเอนเซอร์สาย AI ต้องสร้างเทรนด์ใหม่อย่างต่อเนื่องเพื่อรักษาความสนใจ
  • แม้แต่บุคคลที่มีชื่อเสียงอย่าง Garry Tan และ Andrew Ng ก็ยังมีแนวโน้มจะเหมารวมจากประสบการณ์ส่วนตัว และวัฒนธรรมอินฟลูเอนเซอร์ที่สร้าง FOMO กับกระแสไฮป์ก็กำลังบิดเบือนบทสนทนาในวงการนี้
  • มีหลายกรณีที่ CLI เหมาะกว่าในฐานะอินเทอร์เฟซเครื่องมือของเอเจนต์จริง แต่ ไม่ได้เป็นเช่นนั้นในทุกกรณี

การประหยัดโทเค็นของ CLI: ความจริงและข้อจำกัด

เครื่องมือ CLI ที่อยู่ในข้อมูลฝึก

  • ยูทิลิตี CLI อย่าง jq, curl, git, grep, psql, aws ที่อยู่ใน ชุดข้อมูลฝึกของ LLM สามารถให้เอเจนต์ใช้งานได้ทันทีโดยไม่ต้องมีคำสั่งเพิ่มเติม สคีมา หรือคอนเท็กซ์
  • MCP ต้องประกาศเครื่องมือล่วงหน้าในผลลัพธ์ tools/list จึงเกิดโอเวอร์เฮดเมื่อเทียบกับเครื่องมือ CLI ที่รู้จักอยู่แล้ว
  • สำหรับเครื่องมือ CLI ที่มีอยู่แล้วในข้อมูลฝึก ควร เลือกใช้ก่อน MCP เสมอ

ข้อจำกัดของ CLI แบบปรับแต่งเอง

  • เครื่องมือ CLI แบบปรับแต่งเอง (bespoke) นั้น LLM ไม่รู้วิธีใช้ จึงต้อง มีคำอธิบายไว้ใน AGENTS.md หรือ README.md
  • แม้จะกำหนดไดเรกทอรี /cli-tools และพึ่งพาชื่อที่สื่อความหมายได้ แต่เอเจนต์ก็มักพลาดอยู่บ่อยครั้งในวิธีนี้ และสุดท้ายก็ต้องมีเอกสารอธิบายเพิ่มอยู่ดี
  • แม้แต่เครื่องมืออย่าง curl เมื่อถึงจุดที่ต้องเข้าใจ OpenAPI schema แบบปรับแต่งเอง ประโยชน์ด้านการประหยัดโทเค็นก็หายไป

การดึงข้อมูลและแปลงข้อมูลแบบ chain

  • การต่อ CLI เป็น chain สามารถค้นหาข้อมูลแล้วแปลงผลลัพธ์เพื่อลดปริมาณข้อมูลที่ต้องใส่ใน context window ได้
  • แต่สำหรับคอนเทนต์ที่มีโครงสร้างอย่าง HTML, JSON, XML ก็สามารถดึงข้อมูลด้วยตัวเลือกอย่าง DOM/CSS, JSONPath, XPath ได้เช่นกัน จึงไม่ใช่ข้อได้เปรียบเฉพาะของ CLI

การใช้คอนเท็กซ์แบบค่อยเป็นค่อยไป

  • ในขณะที่ MCP โหลดทั้งชุดเครื่องมือและสคีมาล่วงหน้า CLI สามารถโหลด คอนเท็กซ์แบบค่อยเป็นค่อยไป ผ่าน --help ได้
  • แต่สำหรับเครื่องมือ CLI แบบปรับแต่งเอง เอเจนต์ต้องไล่สำรวจเนื้อหา help หลายรอบ และสุดท้ายก็เป็นการ โหลดข้อมูลคล้ายสคีมาของ MCP แต่ไม่มีโครงสร้าง
  • ใน flow ที่ซับซ้อนมากพอ เอเจนต์ก็มักต้องสำรวจต้นไม้เกือบทั้งหมดอยู่ดี ทำให้ผลในการประหยัดมีน้อยมาก
  • งานวิจัยของ Vercel ระบุว่าเมื่อวางดัชนีเอกสารทั้งหมดไว้ใน AGENTS.md ความสามารถของเอเจนต์ในการใช้เอกสารดีขึ้น และการให้สคีมาทั้งหมดล่วงหน้าช่วยให้เลือกเครื่องมือได้ถูกต้องกว่า
  • เมื่อ Anthropic มี context window ขนาด 1 ล้านโทเค็น อยู่แล้ว จึงน่าตั้งคำถามว่าการประหยัดโทเค็นยังเป็นเหตุผลชี้ขาดอยู่หรือไม่

ความเป็นสองด้านของ MCP: stdio vs Streamable HTTP

ข้อจำกัดของโหมด stdio

  • ในโหมด stdio เซิร์ฟเวอร์ MCP จะรันอยู่ในเครื่องเดียวกับเอเจนต์ ซึ่งเพิ่ม ความซับซ้อนที่ไม่จำเป็น เมื่อเทียบกับการเขียน CLI ง่าย ๆ
  • สำหรับยูสเคสส่วนใหญ่ MCP โหมด stdio ไม่จำเป็น

คุณค่าที่พลิกเกมของ Streamable HTTP

  • MCP ที่ใช้การขนส่งแบบ Streamable HTTP ทำให้สามารถรันลอจิกเดียวกันบน เซิร์ฟเวอร์แบบรวมศูนย์ ได้ ซึ่งเป็นองค์ประกอบสำคัญในการเปลี่ยนจาก vibe coding ไปสู่ agentic engineering สำหรับการนำไปใช้ในองค์กรและเอนเตอร์ไพรส์
  • อินฟลูเอนเซอร์ส่วนใหญ่ยังแยกความต่างของสองโหมดนี้ไม่ออก

ข้อดีของเซิร์ฟเวอร์ MCP แบบรวมศูนย์

ฟังก์ชันฝั่งแบ็กเอนด์ที่หลากหลาย

  • บนเซิร์ฟเวอร์กลางสามารถใช้ความสามารถของแพลตฟอร์มที่หลากหลายกับเครื่องมือได้ เช่น อินสแตนซ์ Postgres หรือการ query กราฟด้วย Cypher บน Apache AGE
  • ฝั่งเอเจนต์เพียงตั้งค่า HTTP endpoint และโทเค็นยืนยันตัวตน ก็ deploy ได้ง่าย
  • แม้จะใช้ฐานข้อมูลในเครื่องอย่าง SQLite ได้ แต่ก็มีข้อจำกัดในการแชร์สถานะทั่วทั้งองค์กร

รันไทม์เอเจนต์แบบชั่วคราว (Ephemeral)

  • ในสภาพแวดล้อมรันไทม์แบบชั่วคราวอย่าง GitHub Actions สามารถใช้เครื่องมือที่ต้องพึ่งแบ็กเอนด์ซับซ้อนผ่านเซิร์ฟเวอร์ MCP ระยะไกลได้โดยไม่ต้องติดตั้งอะไรเพิ่ม
  • ภาระการจัดการ workload ที่มีสถานะ ในสภาพแวดล้อมแบบไร้สถานะ (stateless) ถูกส่งต่อไปยังเซิร์ฟเวอร์กลาง

การยืนยันตัวตนและความปลอดภัย

  • หากต้องเข้าถึง API ที่ปลอดภัยผ่าน CLI นักพัฒนาทุกคนจะต้อง เข้าถึง API key โดยตรง ซึ่งเป็นภาระหนักสำหรับทีมปฏิบัติการ
  • หากรวมศูนย์ไว้หลังเซิร์ฟเวอร์ MCP นักพัฒนาจะ ยืนยันตัวตนกับเซิร์ฟเวอร์ MCP ผ่าน OAuth ขณะที่ API key และ secret ที่อ่อนไหวยังคงถูกควบคุมไว้หลังเซิร์ฟเวอร์
  • เมื่อสมาชิกทีมออกไป เพียง เพิกถอน OAuth token ก็พอ และบุคคลนั้นก็ไม่เคยได้เข้าถึง key หรือ secret อื่น ๆ ตั้งแต่แรก

เทเลเมทรีและการสังเกตการณ์ระบบ

  • บนเซิร์ฟเวอร์ MCP แบบรวมศูนย์สามารถเก็บ trace และ metric ด้วย OpenTelemetry เป็นเครื่องมือมาตรฐานได้
  • ทำให้รู้ได้ว่าเครื่องมือใดมีประสิทธิภาพ ใช้รันไทม์เอเจนต์แบบใด และเครื่องมือมักล้มเหลวตรงไหน
  • แม้ CLI ก็ทำได้ แต่ การ deploy แบบโลคัลต้องให้ผู้ใช้ปลายทางอัปเดต และต้องทำ scaffolding ด้านเทเลเมทรีซ้ำในแต่ละเครื่องมือ CLI

การ deploy ทันทีแบบเป็นมาตรฐานและการอัปเดตอัตโนมัติ

  • เครื่องมือแบบกระจาย (แพ็กเกจ) ทำให้เกิดปัญหา ความเข้ากันได้ของเวอร์ชัน API แต่ MCP ใช้ Subscriptions และ Notifications ให้เซิร์ฟเวอร์แจ้งอัปเดตไปยังไคลเอนต์ได้
  • MCP Prompts เทียบได้กับ SKILL.md ที่ส่งมาจากเซิร์ฟเวอร์ และ MCP Resources เทียบได้กับ /docs ที่ส่งมาจากเซิร์ฟเวอร์

คุณค่าของ MCP Prompts และ Resources ในระดับองค์กร

  • คอนเทนต์แบบไดนามิก: ไฟล์ *.md ในรีโพซิทอรีเป็นไฟล์สแตติกที่ต้องอัปเดตด้วยมือ แต่พรอมป์ต์และรีซอร์สแบบอิงเซิร์ฟเวอร์สามารถ สร้างแบบไดนามิก ได้แบบเรียลไทม์
    • เอกสารที่มีประโยชน์เฉพาะบางคอนเท็กซ์ ข้อมูลราคา หรือสถานะของระบบปัจจุบัน สามารถ inject แบบไดนามิก ได้โดยไม่ต้องเรียกเครื่องมือ
  • การอัปเดตความสอดคล้องอัตโนมัติ: ไฟล์ *.md ที่แจกจ่ายผ่านรีโพซิทอรีหรือแพ็กเกจต้องมีการซิงก์ แต่เมื่อส่งผ่าน MCP Prompts ก็จะ เป็นเวอร์ชันล่าสุดเสมอ
    • แม้แต่เอกสารทางการของ third-party หากทำ proxy ผ่านเซิร์ฟเวอร์ ก็ไม่จำเป็นต้องคัดลอกและอัปเดตลงรีโพซิทอรีด้วยมือ
  • การแชร์องค์ความรู้ทั่วทั้งองค์กร: คอนเทนต์ที่ใช้ทั้งองค์กร เช่น แนวปฏิบัติด้านความปลอดภัย เทเลเมทรี และข้อควรพิจารณาในการ deploy โครงสร้างพื้นฐาน สามารถแจกจ่ายอย่างสม่ำเสมอไปยัง ทุกรีโพซิทอรี ทุก workflow และทุกเอเจนต์ฟรอนต์เอนด์ (Claude Code, Codex, VS Code Copilot, GitHub Agents, OpenCode เป็นต้น)
    • ในสภาพแวดล้อมแบบไมโครเซอร์วิส ก็สามารถให้ทีมหนึ่งเข้าถึงเอกสารของอีกบริการหนึ่งได้ หรือให้ทีมเจ้าของบริการส่งมอบสกิลแบบไดนามิกทุกครั้งที่มีการ deploy
  • มีกรณียืนยันว่า MCP Prompts และ Resources ใช้งานได้จริงใน OpenCode, Claude Code CLI และอื่น ๆ และเพียงตั้งค่า MCP client ก็ ไม่ต้องมีการจัดการเพิ่มเติมหลัง deploy

สรุป: ในระดับองค์กร MCP คือปัจจุบันและอนาคต

  • เมื่อ 6 เดือนก่อน MCP เคยเป็นหัวข้อที่ร้อนแรงที่สุด แต่ตอนนี้กลับถูกตำหนิว่าเป็นต้นเหตุของ context bloat ทว่า trade-off และกับดักแบบเดียวกันของ CLI แบบปรับแต่งเอง กลับถูกมองข้าม
  • หากทีมกำลังคิดว่าจะเปลี่ยนจาก vibe coding ไปสู่ agentic engineering อย่างไร ก็จะไปถึงแนวคิดและพันธกิจของ MCP อย่างเป็นธรรมชาติ
  • ดังที่เห็นจาก กรณีล่าสุดของฝ่าย Amazon AWS (ที่กำหนดให้การเปลี่ยนแปลงที่มี AI ช่วยต้องได้รับการอนุมัติจากวิศวกรอาวุโส) ในท้ายที่สุดทีมก็ต้อง ปฏิบัติการและบำรุงรักษา ระบบซอฟต์แวร์ที่ AI agent สร้างขึ้น
  • คำแนะนำของ Garry Tan และ Andrew Ng อาจใช้ได้ใน สภาพแวดล้อมส่วนบุคคลที่มีความเป็นเนื้อเดียวกันสูง แต่ในบริบทขององค์กรที่ทีมมีระดับทักษะและประสบการณ์หลากหลาย และต้อง มุ่งสู่คุณภาพที่สม่ำเสมอ ก็ยากจะนำมาใช้ตรง ๆ
  • หากต้องการปล่อยซอฟต์แวร์ที่เชื่อถือได้และดูแลรักษาได้ จำเป็นต้องมี วินัยทางวิศวกรรม ที่รับประกันความสม่ำเสมอ ความปลอดภัย คุณภาพ และความถูกต้อง และด้วยเหตุนี้ MCP จึงเป็นเครื่องมือที่เหมาะสมสำหรับองค์กรและเอนเตอร์ไพรส์ทั้งในปัจจุบันและอนาคต

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

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

 
slowandsnow 2026-03-16

cli เป็นเครื่องมือแบบโลคัล ส่วน mcp เป็นเซิร์ฟเวอร์ เลยมีกรณีการใช้งานที่ต่างกันมาก
 
cnaa97 2026-03-17

ถ้ารัน CLI บนเซิร์ฟเวอร์ก็น่าจะเหมือนกันไม่ใช่หรือ?
 
ng0301 2026-03-16

MCP คืนชีพแล้ว !
 
edunga1 2026-03-16

เอกสารที่เกี่ยวข้อง: MCP ตายแล้ว ขอ CLI จงเจริญ
 
hmmhmmhm 2026-03-16

ผมหวังว่าในแอปมือถือเองก็จะสามารถใช้เครื่องมือ CLI ได้ และถ้ามีการพูดคุยเรื่องความสามารถแบบ CLI sandbox ให้คืบหน้าไปมากกว่านี้ก็คงดี เพราะพอพยายามทำให้รองรับมือถือจริง ๆ สุดท้ายคอขวดก็ดูเหมือนจะอยู่ที่ประเด็น sandboxing นั่นเอง
 
GN⁺ 2026-03-16
ความคิดเห็นจาก Hacker News

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

  • ผมคิดว่าสิ่งที่มีประโยชน์ที่สุดในเครื่องมือ AI คือโครงสร้างที่เอา เอเจนต์เชิงความน่าจะเป็น ไปครอบด้วย เกตเชิงกำหนดแน่นอน
    เพราะงั้นผมเลยใช้ MCP บน HTTP ตัวอย่างเช่น NanoClaw ช่วยกรองข้อความ WhatsApp แบบกำหนดแน่นอนและทำ proxy ให้ API key เพื่อเพิ่มความปลอดภัย โครงสร้างแบบนี้ทำให้ AI น่าเชื่อถือขึ้น

    • ผมก็ใช้แพตเทิร์นคล้ายกัน เอเจนต์อัตโนมัติของผมชื่อ Smith เชื่อม MCP เข้ากับ service mesh เพื่อจัดการนโยบาย (OPA) และ monitoring จากศูนย์กลาง
      โครงสร้างนี้มี ความปลอดภัยและความง่ายในการจัดการ สูง และยังสามารถสร้าง CLI อัตโนมัติจาก tool catalog ได้ด้วย
      ตัวอย่างการใช้งานดูได้ที่ smith-gateway
    • ต่อให้เอเจนต์ถูกเจาะ ขอบเขตก็ต้องยังถูกคงไว้ เราใช้ delegation token แบบเข้ารหัส ที่จำกัดขอบเขตตามหน่วยงาน และตรวจสอบที่ขอบเขตของเครื่องมือ MCP
      แกนโอเพนซอร์สดูได้ที่ tenuo
    • แก่นของ AI tooling ที่ดีทุกวันนี้ไม่ใช่การให้เสรีภาพ แต่คือ การใส่ข้อจำกัด
      MCP แยกการตัดสินใจของ AI ออกจากการทำงานแบบกำหนดแน่นอนของระบบอย่างชัดเจน ผมใช้ Claude Code ร่วมกับเซิร์ฟเวอร์ MCP โดยให้ AI ทำส่วนแก้ปัญหาเชิงสร้างสรรค์ และให้การรันจริงไปตามเส้นทางที่คาดเดาได้ จึงมีประสิทธิภาพมาก

  • MCP คือ ข้อกำหนดโปรโตคอลแบบตายตัว สำหรับการสื่อสารระหว่างแอป AI
    มันไม่ได้ฝืนเอา API ของแต่ละแอปมาผูกกันแบบ “integration” เดิมๆ แต่ให้ abstraction การสื่อสารที่นำกลับมาใช้ซ้ำได้ เหมือน HTTP·FTP·SMTP
    ถ้า AI ต้องโต้ตอบกับบริการหลากหลายแบบ ก็น่าจะต้องมีภาษากลางลักษณะนี้
    ดูสเปกได้ที่ modelcontextprotocol.io/specification/2025-11-25

    • แต่บางคนก็บอกว่า “นี่เป็นคำตอบที่แก้ปัญหาผิดจุด”
      ที่จริงสิ่งที่ต้องการไม่ใช่โปรโตคอลใหม่ แต่เป็น สเปก CLI หรือ API ที่สำรวจได้แบบค่อยเป็นค่อยไป โดยมองว่า MCP เป็นเพียงทางแก้ชั่วคราวในยุคแรกที่เอเจนต์ยังรัน CLI ไม่ได้
    • อีกความเห็นหนึ่งคือ “ถ้า AI เป็น AI จริง ทำไมต้องมีโปรโตคอลแยกต่างหากเพื่อเข้าใจ HTTP หรือ FTP”
      มุมมองนี้เห็นว่า MCP สุดท้ายก็เป็น ทางแก้ชั่วคราวของเทคโนโลยีที่ยังไม่สุกงอม
    • ยังมีการตั้งคำถามในระดับพื้นฐานด้วยว่า “จำเป็นต้องสร้างโปรโตคอลใหม่จริงหรือ”
    • มีคำวิจารณ์ด้วยว่า MCP แทบจะเป็นแค่ นิยาม API แบบคัสตอมที่วางอยู่บน JSON-RPC จึงยากจะบอกว่ามันมาตรฐานกว่าหรือใช้ซ้ำได้ดีกว่าวิธีเดิม
    • บางคนก็เห็นว่าเครื่องมือ CLI เองก็ไม่ได้ต่างจาก MCP ในแง่ที่เป็น “abstraction การสื่อสารที่นำกลับมาใช้ซ้ำได้”

  • ตอน MCP ออกมาใหม่ๆ ผมมองว่ามันเหมือน ขยะที่ออกแบบเกินจำเป็น เลยไม่ได้สนใจ
    จนถึงตอนนี้ก็ยังไม่เสียใจ LangChain ก็เหมือนกัน การไหลตามกระแสเพราะมันดังเป็นเรื่องอันตราย

    • แต่ตอนนี้ผมกลับกำลังติดอินเทอร์เฟซ MCP ให้โค้ดทุกตัวของผม เพราะมันทำให้ LLM debug ได้ง่ายขึ้นมาก และกลายเป็น องค์ประกอบที่สำคัญพอๆ กับ UI
      ลงเวลาเพียงเล็กน้อยก็ได้ประสิทธิภาพเพิ่มขึ้นมาก
    • แน่นอนว่า ‘sniff test’ มีประโยชน์ แต่แค่นั้นยังไม่พอ
      บางครั้ง เครื่องมือที่ดูหยาบๆ กลับอยู่รอดได้เพราะแก้ปัญหา integration ที่ซับซ้อนได้อย่างเรียบง่าย
      ถ้ามองว่ามันไม่สวยแล้วเมินทิ้งตั้งแต่แรก ก็อาจพลาดโอกาสที่มันจะกลายเป็นโครงสร้างพื้นฐานมาตรฐานในภายหลัง
    • LangChain ไม่ใช่แค่ออกแบบเกิน แต่เป็น ความโกลาหลที่แทบไม่มีการออกแบบเลย
    • บางคนกลับบอกว่า MCP ได้รับความนิยมเพราะมัน เรียบง่ายเกินคาด
      ไม่ใช่เรื่องออกแบบเกิน แต่เป็นโครงสร้างที่ชัดเจนและตรงไปตรงมา
    • ก็ยังมีคนที่บอกว่าจนทุกวันนี้ก็ยังไม่รู้แน่ชัดว่า LangChain คืออะไรกันแน่

  • remote MCP ก็ถือว่าโอเคในแง่ที่การยืนยันตัวตนทำให้อัตโนมัติ จึง เข้าถึงบริการได้สะดวก
    แต่เมื่อเทียบกับการใช้ CLIs + Skills แล้ว มันมี ภาระของบริบท (context bloat) สูงกว่า และเสียข้อดีของ Unix CLI อย่างการทำ pipeline หรือรับอินพุตแบบ heredoc
    CLI สามารถสร้าง skill อัตโนมัติจากเอาต์พุต --help ได้อย่างมีประสิทธิภาพ
    MCP ต้องใช้โปรเซสที่รันค้างไว้ แต่ CLI สามารถเรียกใช้เฉพาะตอนจำเป็นได้

    • แน่นอนว่า CLI ต้องติดตั้งก่อน แต่ MCP มีข้อดีตรงที่ทำงานได้ด้วย การตั้งค่าเพียงอย่างเดียว

  • ผมยังคิดว่า MCP เป็น ชั้นที่ไม่จำเป็น อยู่ดี
    แม้จะเห็นด้วยว่า CLI > MCP แต่ข้อดีด้านเอกสารและการรวมศูนย์ก็แก้ได้ด้วยวิธีอื่น
    ตัวอย่างเช่นใช้ Skills เพื่อเก็บคำแนะนำได้ทั้งสำหรับ CLI และ API และโหลดเฉพาะตอนจำเป็น
    ข้อดีของ MCP แบบรวมศูนย์เองก็จริงๆ แล้วทำได้ด้วย proxy เดิมๆ หรือ AWS SSO
    สุดท้ายผมมองว่าควรใช้ Skills สำหรับงานเอกสาร และใช้ CLI หรือ REST API สำหรับการโต้ตอบจริงจะดีกว่า

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

  • ผมรู้สึกว่า MCP เหมาะกับสภาพแวดล้อมผู้บริโภค มากกว่า
    ในสภาพแวดล้อมการพัฒนามันทั้งซับซ้อนและไม่มีประสิทธิภาพ แต่สำหรับผู้ใช้ทั่วไป MCP ช่วยให้เข้าใจได้ง่ายว่าโมเดลทำอะไรได้บ้าง
    ไม่ต้องตั้งค่าสภาพแวดล้อม และใน GUI ก็สามารถ แสดงผลคำตอบแบบภาพเหมือน Siri หรือ Google Assistant ได้

    • ระบบการตอบกลับใน GUI นั้นนิยามไว้ใน MCP progress spec

  • ในฐานะคนที่ต้องให้ผู้ใช้ที่ไม่ใช่นักพัฒนาในองค์กรใช้เครื่องมือ AI แนวทาง เข้าถึง MCP แบบรวมศูนย์ มีประโยชน์มาก
    มันช่วยให้จัดการโทนของแบรนด์ คำศัพท์ภายใน การเข้าถึงข้อมูลร่วมกัน และบริบทเฉพาะโดเมนได้อย่างสม่ำเสมอ
    ผ่าน resource method ของ MCP เราสามารถให้ “skills” ที่เป็นมาตรฐานและควบคุมแพตเทิร์นการเชื่อมต่อข้อมูลได้

  • ผู้เขียนพิจารณาหลายแนวคิดจากหลายมุม แต่ดูเหมือนจะไม่รู้จักแนวคิดที่มีอยู่ก่อนแล้วอย่าง Token Notation (TOON)
    ให้ความรู้สึกเหมือนกำลังหวังให้มีของแบบนั้นอยู่

  • ปัญหาที่แท้จริงของ MCP คือ ภาระในการบำรุงรักษา
    ยกตัวอย่าง ถ้าต้องเชื่อม GitHub ก็ต้องไปพึ่ง npm wrapper แทนที่จะใช้ API ที่มีเอกสารดีอยู่แล้ว
    ผมใช้แค่ gh CLI หรือ curl ถ้า API เปลี่ยน เอเจนต์ก็อ่านเอกสารใหม่แล้วปรับตัวได้
    แต่ MCP ต้องรอให้ wrapper ตรงกลางอัปเดตก่อน
    คำกล่าวอ้างเรื่องความปลอดภัยก็ย้อนแย้ง — ตอนแรกออกมาแบบไม่มีการยืนยันตัวตน แต่ตอนนี้กลับชูเรื่องความปลอดภัยเป็นจุดเด่น
    ในความเป็นจริง วิธีเก่าอย่าง chroot หรือ scoped token ก็แก้ปัญหานี้ไว้ давноแล้ว
    จุดเดียวที่ MCP เหนือกว่าจริงๆ คือ OAuth flow สำหรับผู้ใช้ที่ไม่ใช่นักพัฒนา เท่านั้น สำหรับเครื่องมือของนักพัฒนา ผมคิดว่าการทำ CLI ที่ดีกว่าน่าจะเหมาะกว่า