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

 (ejholmes.github.io)
36 คะแนน โดย GN⁺ 2026-03-02 | 8 ความคิดเห็น | แชร์ทาง WhatsApp
  • MCP กำลังสูญเสียความสนใจจากอุตสาหกรรมอย่างรวดเร็ว และตอนนี้ แนวทางแบบ CLI ใช้งานได้จริงมากกว่า
  • LLM นั้น เชี่ยวชาญการใช้เครื่องมือบรรทัดคำสั่งอยู่แล้ว และสามารถทำงานได้เพียงแค่มีเอกสารและ CLI โดยไม่ต้องมีโปรโตคอลแยก
  • CLI ทำให้ทั้งมนุษย์และ LLM รันและดีบักได้ในสภาพแวดล้อมเดียวกัน จึงทำให้การหาสาเหตุของปัญหาง่ายขึ้น
  • ในด้าน ความสามารถในการประกอบต่อ (composability), ระบบยืนยันตัวตน และความเสถียร CLI มีประสิทธิภาพกว่า MCP และดูแลรักษาได้ง่ายกว่า
  • MCP ก่อให้เกิดแรงเสียดทานในการทำงานจริงอย่างต่อเนื่อง เช่น การเริ่มต้นระบบที่ไม่เสถียร การยืนยันตัวตนซ้ำ ๆ และ การขาดการควบคุมสิทธิ์
  • ในกรณีส่วนใหญ่ CLI เป็นตัวเลือกที่เรียบง่ายและเชื่อถือได้มากกว่า และองค์กรควรให้ความสำคัญกับ การมี API และ CLI ก่อนการสร้าง MCP server

ข้อจำกัดของ MCP และความเหนือกว่าของ CLI

  • หลังจาก Anthropic เปิดตัว Model Context Protocol (MCP) อุตสาหกรรมก็แห่กันสร้าง MCP server แต่เครื่องมือหลักอย่าง OpenClaw และ Pi ไม่รองรับสิ่งนี้ และแทบไม่มีประโยชน์ในทางปฏิบัติ
    • LLM สามารถทำงานผ่าน CLI และเอกสารได้อยู่แล้ว
    • MCP เพิ่ม endpoint และระบบยืนยันตัวตนใหม่ แต่เป็นการทำซ้ำความสามารถเดิม
  • LLM ถูกปรับให้เหมาะกับการใช้เครื่องมือ CLI และทำได้อย่างชำนาญมาก
    • เรียนรู้จาก man page, คำตอบบน Stack Overflow, และ shell script บน GitHub หลายล้านรายการ
    • ตัวอย่างเช่น หากสั่ง Claude ด้วยคำสั่งอย่าง gh pr view 123 ก็จะทำงานตามนั้นได้เลย
  • แม้ MCP จะสัญญาว่าจะมีอินเทอร์เฟซที่สะอาดกว่า แต่ในความเป็นจริงก็ยังต้อง จัดทำเอกสารคำอธิบาย พารามิเตอร์ และจังหวะการใช้งาน ของแต่ละเครื่องมือเหมือนเดิม

CLI มีประโยชน์กับมนุษย์ด้วย

  • CLI ทำให้มนุษย์และ LLM ใช้คำสั่งเดียวกันร่วมกันได้
  • เมื่อ Jira ทำงานผิดคาด ก็สามารถรันคำสั่ง jira issue view เดียวกันด้วยตัวเองเพื่อทำซ้ำปัญหาได้
  • ใน MCP เครื่องมือจะ มีอยู่เฉพาะในบทสนทนาของ LLM ทำให้เมื่อเกิดปัญหาต้องไปไล่ดู log การส่ง JSON ซึ่งยุ่งยาก
  • การดีบักไม่ควรต้องพึ่ง protocol decoder
  • CLI มีอินพุตและเอาต์พุตที่ชัดเจน จึงติดตามปัญหาได้ง่าย

ความสามารถในการประกอบต่อ (Composability)

  • CLI สามารถ ประกอบเป็น pipeline ร่วมกับ jq, grep, การ redirect ไฟล์ และอื่น ๆ ได้
  • ตัวอย่างการวิเคราะห์ Terraform plan ขนาดใหญ่:
    • terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
  • หากใช้ MCP ก็ต้อง dump plan ทั้งหมดลงใน context window (มีค่าใช้จ่ายสูงและบ่อยครั้งก็ทำไม่ได้) หรือไม่ก็ต้องไปทำ custom filtering ใน MCP server เอง
  • แนวทางแบบ CLI ใช้เครื่องมือที่มีอยู่แล้วและมีเอกสารครบถ้วน ซึ่งทั้งมนุษย์และเอเจนต์ก็เข้าใจได้

ปัญหาเรื่องการยืนยันตัวตน (Auth)

  • MCP มีความ opinionated เกินความจำเป็นในเรื่องการยืนยันตัวตน
  • เครื่องมือ CLI ใช้ระบบยืนยันตัวตนที่ผ่านการพิสูจน์แล้วอยู่ก่อน: aws ใช้ profile และ SSO, gh ใช้ gh auth login, kubectl ใช้ kubeconfig
  • ไม่ว่ามนุษย์จะใช้งานเองหรือ Claude เป็นผู้รัน ก็ใช้ flow การยืนยันตัวตนแบบเดียวกัน
  • เมื่อมีปัญหาด้านการยืนยันตัวตน ก็แก้ได้ด้วยวิธีเดิมอย่าง aws sso login, gh auth refresh โดยไม่ต้องมีการ troubleshooting เฉพาะ MCP

ปัญหาด้านการปฏิบัติการ: ไม่มีชิ้นส่วนที่เคลื่อนไหว (No Moving Parts)

  • MCP server แบบโลคัลต้องมี process แยกที่ต้องเริ่มและคงการทำงานไว้ และใน Claude Code มันถูกสร้างเป็น child process จึงเกิดปัญหาเป็นครั้งคราว
  • เครื่องมือ CLI เป็นเพียง ไฟล์ไบนารี ที่อยู่บนดิสก์ ไม่ต้องมี background process การจัดการสถานะ หรือขั้นตอนเริ่มต้นระบบ

ความไม่สะดวกในการใช้งานจริง

  • การเริ่มต้นระบบไม่เสถียร: MCP server มักไม่ยอมเริ่ม ทำให้ต้องรีสตาร์ต Claude Code บ่อยครั้ง และต้องลองใหม่หลังรีเซ็ตสถานะ
  • การยืนยันตัวตนซ้ำ ๆ: เมื่อใช้เครื่องมือ MCP หลายตัว ต้องยืนยันตัวตนแต่ละตัวแยกกัน แต่ CLI ที่ใช้ SSO หรือ credential อายุยาว ไม่มีปัญหานี้
  • การควบคุมสิทธิ์ที่หยาบเกินไป: ใน Claude Code สามารถอนุญาตเครื่องมือ MCP ตามชื่อได้ แต่ไม่สามารถจำกัดเป็นอ่านอย่างเดียวหรือระบุขอบเขตพารามิเตอร์ได้
    • CLI สามารถ ควบคุมสิทธิ์ได้ละเอียดกว่า เช่น อนุญาต gh pr view แต่กำหนดให้ gh pr merge ต้องได้รับการอนุมัติ

กรณีที่ MCP ยังใช้ได้

  • หากไม่มีเครื่องมือที่เทียบเท่า CLI เลยจริง ๆ MCP อาจเป็นทางเลือกที่เหมาะสม
  • ยอมรับได้ว่ามันมีคุณค่าในฐานะอินเทอร์เฟซที่เป็นมาตรฐาน และอาจมี use case ที่ MCP เหมาะกว่า CLI
  • แต่สำหรับงานส่วนใหญ่ CLI เรียบง่ายกว่า ดีบักได้เร็วกว่า และเชื่อถือได้มากกว่า

บทเรียนสำคัญและข้อเรียกร้องถึงผู้สร้างเครื่องมือ

  • เครื่องมือที่ดีที่สุดคือเครื่องมือที่ ใช้ได้ทั้งกับมนุษย์และเครื่องจักร และ CLI ผ่านการขัดเกลาจากการออกแบบมายาวนานหลายสิบปีจนสามารถประกอบต่อได้ ดีบักง่าย และผสานกับระบบยืนยันตัวตนเดิมได้
  • MCP พยายามสร้าง abstraction ที่ดีกว่า แต่ความจริงคือ มี abstraction ที่ดีพออยู่แล้ว
  • บริษัทที่ลงทุนกับ MCP server ทั้งที่ยังไม่มี CLI อย่างเป็นทางการ ควรทบทวนกลยุทธ์ใหม่ และ
    หากจัดเตรียม API ที่ดี → CLI ที่ดี เอเจนต์ก็จะนำไปใช้ได้เอง
  • สิ่งนี้ช่วยลดความซับซ้อนของโปรโตคอลที่ไม่จำเป็น และ เพิ่มทั้งประสิทธิภาพการทำงานและการดูแลรักษา

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

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

 
sonnet 2026-03-03

ไม่ใช่ว่า MCP ไม่มีข้อดี แต่เราต่างหากที่ตื่นจากภาพฝันที่เอา MCP ไปใช้อย่างพร่ำเพรื่อกับงานที่มันไม่ได้มีข้อดีอะไร พอจะเปิดไมโครเซอร์วิสให้ LLM ใช้ ก็ไม่ได้จะใช้ CLI กันอยู่แล้ว และ MCP ก็เป็นโปรโตคอลแบบ "API" นั่นเอง
 
brainer 2026-03-03

ตอนนั้นก็ใช้ API ได้เหมือนกันครับ จริงๆ แล้วเหตุผลที่ใช้ MCP ก็เพราะข้อจำกัดของ long context แต่ตอนนี้ก็เอาชนะข้อจำกัดนั้นได้เป็นส่วนใหญ่แล้วครับ
 
jamsya 2026-03-03

เห็นด้วยอย่างแรงครับ
ถึงไม่ต้องติดตั้ง AWS MCP แต่ Claude Code ก็จัดการดึงสิ่งที่ต้องใช้ผ่าน AWS CLI มาใช้เองได้เลย 😂
 
GN⁺ 2026-03-02
ความคิดเห็นจาก Hacker News

  • ฉันพยายามเลี่ยงที่จะพูดแบบนี้มานาน แต่ตอนนี้เริ่มมั่นใจแล้วว่า MCP แทบไม่มีข้อได้เปรียบที่เป็นรูปธรรม
    ฉันรัน AI agent ที่ควบคุมเวิร์กโฟลว์การพัฒนาทั้งหมดผ่าน shell command และถึงจะเจอ CLI flag เป็นครั้งแรก พวกมันก็เข้าใจได้ดีจากแค่ output ของ --help
    ในทางกลับกัน MCP server มักไม่เสถียรและต้องคอยดูแลจัดการเสมอ
    CLI ยังเอามาประกอบกันได้ด้วย jq, grep, file redirection ฯลฯ แต่ MCP ถูกจำกัดอยู่กับรูปแบบที่ server ส่งกลับมา
    สุดท้ายแล้วฉันคิดว่าการรองรับ MCP เป็นแค่ สัญญาณการตลาดแบบ ‘AI-first’ มากกว่าเหตุผลทางเทคนิค

    • MCP โตเร็วมากในปี 2024 แต่พอ terminal agent (Claude Code) โผล่มาช่วงต้นปี 2025 เมตาก็เปลี่ยนอย่างรวดเร็ว
    • ฉันกลับชอบ MCP มากกว่า เพราะ การจัดการ error และการ debug สะอาดกว่า CLI มาก และยังจำกัด flag อันตรายหรือแบ่งผลลัพธ์เป็น pagination ได้
      มองว่า MCP เป็นแค่ wrapper คล้าย REST หรือ gRPC ก็พอ
    • ฉันก็หลีกเลี่ยง MCP เหมือนกัน ลองใช้ JIRA MCP แล้วเละเทะมาก แต่พอให้ LLM เรียก API ตรงและเขียนสคริปต์เองกลับมีประสิทธิภาพกว่ามาก
      ตอนนี้ฉันคิดว่า เครื่องมือ LLM แบบ CLI คือจุดสูงสุด
    • บริษัทเรานำเครื่องมือที่ใช้ได้เฉพาะบนเว็บอย่าง internal wiki มาเปิดผ่าน MCP เพื่อให้ Claude ดึง log กับ metric ได้โดยตรง
      แต่ที่น่ารำคาญคือผลลัพธ์จาก MCP มักถูกยัดเข้า context window ตลอด ถ้าดัมพ์ลง filesystem ได้ก็น่าจะดี
    • MCP server ดูเหมือนผลผลิตช่วงเปลี่ยนผ่านที่ถูกสร้างขึ้นตอน LLM ยังไม่พัฒนาเท่าทุกวันนี้ ฉันคิดว่าการฝึกกับข้อมูลจาก CLI ดีกว่ามาก

  • MCP เหมือน black-box API ที่เรียกใช้ได้ทันทีโดยไม่ต้องติดตั้งหรือ provision resource
    ส่วน CLI เข้าถึง local environment ได้ จึงละเอียดแม่นยำกว่ามาก
    ใช้ jq, duckdb CLI เพื่อสุ่มดูไฟล์ข้อมูลขนาดใหญ่ และ Opus 4.6 จะคอยปรับ query ให้อัตโนมัติระหว่างการสำรวจ
    CLI ตอบสนองแบบเรียลไทม์ได้ดี จึงมีประโยชน์มากโดยเฉพาะกับ exploratory data analysis
    CLI ที่ใช้บ่อยก็มี showboat, br, psql, roborev เป็นต้น

    • ฉันก็เจอประสบการณ์แบบเดียวกัน text I/O ของ CLI เข้ากับวิธีที่ LLM ถูกฝึกมามากที่สุด
      ตอนใช้ duckdb กับ ChatGPT มันสนุกมาก เลยสงสัยว่าคุณตั้ง system prompt ให้รักษา local DB ไว้หรือเปล่า
    • ถ้าไม่ใช้ CLI แล้วไปรันคำสั่งใน Docker container แทน ก็เลี่ยงปัญหาเรื่องการติดตั้งได้ อาจทำเป็น “skill” เพื่อทำสิ่งนี้ให้อัตโนมัติก็ได้
    • ในฐานะคนที่ไม่ได้ใช้ภาษาอังกฤษเป็นภาษาแม่ ฉันรู้สึกว่าการเติมพหูพจน์แบบ MCPs มันน่าขำดี

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

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

  • ตัว MCP เองไม่ได้แย่ แต่ stdio MCP ถูกออกแบบเกินความจำเป็น
    ทุกวันนี้วิธีทำ AI integration ที่มีประสิทธิภาพที่สุดคือ Streamable HTTP + OAuth Discovery
    ตัวอย่างเช่น Sentry MCP ใช้แค่ URL เดียวก็ทำทั้งการยืนยันตัวตนและเข้าถึงข้อมูลได้
    ปัญหาอยู่ที่วิธี implement MCP มากกว่า ถ้าแทนที่จะเรียกผ่าน bash แล้วเอา MCP ไป เปิดเป็น HTTP endpoint จะยืดหยุ่นกว่ามาก

    • ไม่ว่าจะ CLI หรือ MCP ระบบสิทธิ์ควรถูกออกแบบให้สอดคล้องกันในระดับ API ส่วนเรื่อง Streamable HTTP น่าจะต้องอธิบายเพิ่มอีกหน่อย
    • ฉันก็คิดเหมือนกันว่า authentication และ telemetry แบบรวมศูนย์ ง่ายกว่ามาก เพียงแต่ต้องใช้ให้ถูกงาน

  • ลูกค้าของฉันบางรายไม่มี MCP server แต่ฝั่งนักพัฒนากลับเรียกร้องสิ่งนี้
    สุดท้ายก็เลยต้อง export Postman API ออกมาเป็น JSON ให้ แต่ฝั่งนักพัฒนาก็ยังอยากได้ MCP server อยู่ดี
    ความจริงคือ การรองรับ MCP กลายเป็น checklist ทางการตลาด ไปแล้ว

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

    • ใช่เลย ใน chat interface นั้นรัน CLI ไม่ได้ และบริการสำหรับ non-developer ก็ไม่มี CLI อยู่แล้ว
    • ฉันก็เคยสงสัยเหมือนกันว่าในเว็บหรือมือถืออย่าง ChatGPT หรือ LeChat จะรัน CLI ได้จริงหรือเปล่า
    • อินเทอร์เฟซสำหรับ non-developer เองก็กำลังวิวัฒน์ไปเป็นรูปแบบอย่าง OpenClaw, Claude Cowork อยู่แล้ว

  • ประกาศรับสมัครงานทำนอง “ต้องการคนมีประสบการณ์ MCP 5 ปี” เลยกลายเป็น มีมไร้ความหมาย ไปแล้ว

  • เหตุผลหนึ่งที่ CLI ดีกว่า MCP คือมันมี รูปแบบที่ถูกปรับให้เหมาะเชิงทฤษฎีสารสนเทศ
    output ของเครื่องมือ Unix จัดวางข้อมูลที่เกี่ยวข้องไว้ใกล้กัน ทำให้ กลไก attention ของ LLM ทำงานได้มีประสิทธิภาพ
    JSON แม้ parse ง่าย แต่เวลาอ่านและใช้หาเหตุผลกลับไม่สะดวก
    รูปแบบของ CLI จึงเป็นธรรมชาติทั้งสำหรับมนุษย์และ LLM
    ดูเพิ่มเติม: Entropy and Information Layout

  • การเปรียบเทียบ MCP กับ CLI ก็เหมือนการเอา OpenAPI ไปเทียบกับสตริง (JSON)
    MCP ถูกนิยามอย่างเป็นทางการ ส่วน CLI เป็นอินเทอร์เฟซเชิงนามธรรมระดับ (String, List String, Map Int Stream) -> PID
    สุดท้ายทั้งคู่ก็เป็นแค่ API สิ่งสำคัญคือ เลือกเครื่องมือให้เหมาะกับเป้าหมาย

    • แต่ CLI มีเอกสารครบผ่าน --help ดังนั้นถ้า LLM เข้าใจสิ่งนี้ได้ ก็ยากจะบอกว่าการทำมาตรฐานแบบ MCP ดีกว่าอย่างชัดเจน
    • ประสบการณ์การใช้งานจริงสำคัญกว่า ทฤษฎี ถ้าจะบอกว่า MCP กับ CLI เหมือนกัน ก็ควรทำตัวอย่างให้เห็น เช่น Playwright CLI กับ MCP ที่ใช้ โทเค็นเท่ากันและปรับแต่งได้เท่ากัน
      ไม่อย่างนั้นพอใช้งานจริงก็จะสัมผัสได้เองว่าสองแนวทางนี้ต่างกัน
 
develosopher 2026-03-03

ถ้าใครสักคนกำลังพัฒนา SaaS แล้วกำลังลังเลระหว่าง cli กับ mcp เพื่อทำ AI integration ก็คงมีแนวโน้มว่าจะเลือก mcp ก่อน เพราะการรองรับ CLI หมายถึงการเพิ่มจุดที่ต้องดูแล ถึงจะทำทั้งสองอย่างควบคู่กันได้ แต่ก็คงไม่หายไปไหน
 
hanje3765 2026-03-03

ดูเหมือนว่าเมื่อความฉลาดของ llm สูงขึ้น ความจำเป็นของ mcp ก็เริ่มไม่ชัดเจนขึ้น ผมเองก็รู้สึกแบบนั้นจริง ๆ เหมือนกัน
 
m00nlygreat 2026-03-03

ดูเหมือนว่าการทำงานระยะไกลจะถูกจัดอยู่ในหมวด mcp ส่วนการทำงานแบบโลคัลจะถูกจัดอยู่ในหมวด skills
 
hulryung 2026-03-03

ผมเองก็เริ่มสร้างและใช้เครื่องมือด้วย CLI โดยตรง แทน MCP แล้วเหมือนกัน