MCP ตายแล้วหรือยัง?

 (quandri.io)
1 คะแนน โดย GN⁺ 5 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • MCP เชื่อม LLM เข้ากับเครื่องมือภายนอก แต่ในเวิร์กโฟลว์การพัฒนา ภาระจากต้นทุนคอนเท็กซ์ ความเสถียรในการปฏิบัติการ และความซ้ำซ้อนกับ CLI/API กลายเป็นปัญหาใหญ่
  • จากการวัดของ Quandri พบว่าคำนิยามเครื่องมือ 77 รายการของ Linear, Notion, Slack และ Postgres กินพื้นที่ราว 21,077 โทเค็น หรือ 10.5% ของคอนเท็กซ์ Claude 200K
  • การดึงข้อมูล issue จาก Linear ด้วย MCP ใช้โทเค็นราว 12,957 โทเค็น เพราะต้องบรรทุกคำนิยามเครื่องมือ 42 รายการตลอดเวลา ซึ่งสูงกว่าวิธี CLI ที่ใช้เพียงราว 200 โทเค็นมาก
  • MCP ต้องมีโปรเซสเซิร์ฟเวอร์แยกต่างหาก พร้อมทั้งเรื่องการยืนยันตัวตน การเริ่มต้นระบบ ความขัดแย้ง และความหน่วงจากการไปกลับกับระบบภายนอก ขณะที่ CLI/API ทำซ้ำ ดีบัก และประกอบเข้าด้วยกันในเทอร์มินัลได้ง่ายกว่า
  • Quandri ห่อ CLI เดิมด้วย Skills เพื่อคืนพื้นที่ราว 21K โทเค็น และจะใช้ MCP เฉพาะกรณีที่ไม่มี CLI หรือจำเป็นต้องควบคุมสิทธิ์ในระดับทีมเท่านั้น

ต้นทุนหลักที่ MCP เปิดเผย

  • MCP(Model Context Protocol) เชื่อม LLM กับเครื่องมือภายนอกอย่าง GitHub, Linear, Notion และ Slack แต่ในเวิร์กโฟลว์การพัฒนาจริง ปัญหาหลักกลับเป็นการใช้คอนเท็กซ์ ความเสถียรในการปฏิบัติการ และความซ้ำซ้อนกับ CLI/API เดิม
  • หลังเปิดตัวช่วงปลายปี 2024 มันถูกเรียกว่า “USB-C แห่งระบบนิเวศ AI” แต่สำหรับนักพัฒนาที่ใช้งานทุกวัน ต้นทุนอีกแบบกลับเด่นชัดขึ้นมาก่อน
  • หลังการวัดผล Claude Code ได้เพิ่ม Tool Search with Deferred Loading เข้ามา ทำให้โหลดสคีมาเครื่องมือ MCP เฉพาะเมื่อจำเป็น และลดการใช้คอนเท็กซ์ได้มากกว่า 85%
  • ปัจจุบันใน Claude Code ปัญหาคอนเท็กซ์พองตัวถูกบรรเทาไปมากแล้ว แต่ปัญหาด้านประสิทธิภาพ การดีบัก และสถาปัตยกรรมยังคงอยู่

กินพื้นที่หน้าต่างคอนเท็กซ์อย่างมาก

  • หน้าต่างคอนเท็กซ์ คือพื้นที่ที่ LLM ใช้ทำงาน และเมื่อเชื่อม MCP server พื้นที่ส่วนใหญ่สามารถถูกกินไปด้วยคำนิยามเครื่องมือเพียงอย่างเดียว โดยไม่ใช่เนื้อหางานจริง
  • เมื่อนำคำนิยามเครื่องมือจริงจาก MCP server ที่เชื่อมในสภาพแวดล้อมของ Quandri มาวัด พบว่าถ้าเชื่อมทั้ง 4 เซิร์ฟเวอร์ จะใช้ 10.5% ของหน้าต่างคอนเท็กซ์ไปกับคำนิยามเครื่องมือเพียงอย่างเดียว
  • ขนาดคำนิยามเครื่องมือ:
    • Linear: 42 เครื่องมือ, ราว 51,229 ตัวอักษร, ราว 12,807 โทเค็น
    • Notion: 14 เครื่องมือ, ราว 16,156 ตัวอักษร, ราว 4,039 โทเค็น
    • Slack: 12 เครื่องมือ, ราว 15,168 ตัวอักษร, ราว 3,792 โทเค็น
    • Postgres: 9 เครื่องมือ, ราว 1,755 ตัวอักษร, ราว 438 โทเค็น
    • รวม: 77 เครื่องมือ, ราว 84,308 ตัวอักษร, ราว 21,077 โทเค็น
  • สัดส่วนการใช้คอนเท็กซ์ตามโมเดล:
    • ในคอนเท็กซ์ Claude 200K คำนิยามเครื่องมือกิน 10.5%
    • ในคอนเท็กซ์ GPT-4o 128K คำนิยามเครื่องมือกิน 16.5%
  • แม้ใช้ Linear เพียงตัวเดียว ก็ยังต้องโหลดคำนิยามเครื่องมือทั้ง 42 รายการเสมอ กินมากกว่า 12,800 โทเค็น และแม้ในกรณีที่ใช้จริงแค่ get_issue กับ save_issue คำนิยามทั้งหมดก็ยังถูกแนบมาด้วย
  • ตัวอย่างคำนิยามเครื่องมือที่มีขนาดใหญ่:
    • linear/save_issue: 2,479 ตัวอักษร, ราว 619 โทเค็น
    • slack/search_public: 1,614 ตัวอักษร, ราว 403 โทเค็น
    • linear/list_issues: 1,588 ตัวอักษร, ราว 397 โทเค็น
    • notion/fetch: 1,379 ตัวอักษร, ราว 344 โทเค็น
    • slack/send_message: 1,248 ตัวอักษร, ราว 312 โทเค็น

ภาระด้านความเสถียรและประสิทธิภาพ

  • MCP ต้องเริ่มและรักษาโปรเซสแยกต่างหาก จึงอาจเกิด การเริ่มต้นล้มเหลว และปัญหาการยืนยันตัวตนซ้ำ ๆ
  • ทุกครั้งที่เรียกใช้เครื่องมือต้องมีการไปกลับกับเซิร์ฟเวอร์ภายนอก ทำให้ ความเร็วการตอบของ AI ช้าลง
  • หากโปรเซส MCP server ล่ม เครื่องมืออาจหายไปกลางเซสชัน
  • สิทธิ์ที่เครื่องมือแต่ละตัวมีจริง ๆ ไม่ชัดเจน ทำให้ การมองเห็นสิทธิ์ ต่ำ
  • ในเบนช์มาร์ก Jira MCP ของ MCP is dead. Long live the CLI พบว่า MCP ช้ากว่าการเรียก REST API โดยตรง 3 เท่าต่อการเรียกหนึ่งครั้ง และช้ากว่า 9.4 เท่าสำหรับการเรียกครั้งแรกเมื่อรวมเวลาเริ่มต้นระบบ
  • ช่องว่างด้านประสิทธิภาพนี้ไม่ได้จำกัดอยู่แค่ Jira แต่เกิดจากโครงสร้างที่มี ชั้นโปรเซส ของ MCP server แทรกอยู่ระหว่าง LLM กับ API พื้นฐาน
  • โอเวอร์เฮดแบบเดียวกันนี้ใช้กับเซิร์ฟเวอร์ Linear, Notion และ Slack ในสแตกของ Quandri ด้วย

ซ้ำซ้อนกับ CLI/API ที่มีอยู่เดิม

  • CLI/API เป็นคำสั่งชุดเดียวกันที่ทั้งคนและ LLM ใช้ได้ แต่ MCP มีอยู่เฉพาะภายในบทสนทนาของ LLM
  • CLI/API ประกอบเข้ากับ pipe, jq, grep ได้อย่างอิสระ แต่ MCP ถูกผูกกับรูปแบบข้อมูลที่เซิร์ฟเวอร์ส่งกลับ
  • CLI/API ทำซ้ำและดีบักได้ทันทีในเทอร์มินัล แต่ MCP ทำซ้ำได้เฉพาะภายในบริบทของบทสนทนา
  • LLM ได้เรียนรู้วิธีใช้ CLI/API จาก man page และ StackOverflow อยู่แล้ว แต่ MCP ต้องมีคำนิยามเครื่องมือแยกต่างหาก
  • CLI/API ส่วนใหญ่มักติดตั้งไว้แล้ว ขณะที่ MCP ต้องมีการตั้งค่าเซิร์ฟเวอร์ การยืนยันตัวตน และการจัดการโปรเซสเพิ่มเติม

ต้นทุนโทเค็นของการดึง issue จาก Linear

  • เมื่อดึง Linear issue เดียวกัน วิธี MCP ใช้โทเค็นมากกว่าวิธี CLI ราว 65 เท่า
  • วิธี CLI ใช้ราว 200 โทเค็น:
    • พรอมป์ต์คำสั่ง curl: ราว 50 โทเค็น
    • คำตอบ: ราว 150 โทเค็น
  • วิธี MCP ใช้ราว 12,957 โทเค็น:
    • คำนิยามเครื่องมือ Linear 42 รายการที่ต้องโหลดตลอด: ราว 12,807 โทเค็น
    • การเรียกใช้เครื่องมือและคำตอบ: ราว 150 โทเค็น
  • ตัวอย่าง CLI นี้เรียก Linear GraphQL API โดยตรง:
curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \  
  -H "Content-Type: application/json" \  
  -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' \  
  https://api.linear.app/graphql

ทางเลือก: กลยุทธ์ CLI ก่อน และ Skills

  • แนวทางที่ให้ CLI → API → เอกสาร ตามลำดับเบากว่าและตรงกว่า
  • LLM เรียนรู้การใช้ CLI จาก man page และ StackOverflow อยู่แล้ว จึงไม่จำเป็นต้องแบกคำนิยามเครื่องมือแยกต่างหากไว้ตลอดเวลา
  • หากใช้ CLI เดิมโดยตรง ก็ไม่ต้องเสียคอนเท็กซ์ไปกับคำนิยามเครื่องมือ และเพราะคนกับ AI ใช้อินเทอร์เฟซเดียวกัน การดีบักจึงง่ายกว่า
  • ยังสามารถประกอบกับคำสั่งอื่นได้อย่างอิสระผ่าน pipeline
  • ถ้า MCP คือวิธีแบบ “กางทุกเมนูบนโต๊ะไว้ล่วงหน้า” Skills ก็ใกล้เคียงกับ “ขอเฉพาะหนังสือที่จำเป็นจากบรรณารักษ์”
  • MCP โหลดคำนิยามเครื่องมือทั้งหมดทันทีที่เชื่อม และกินพื้นที่คอนเท็กซ์ตลอดเวลา ขณะที่ Skills จะถูกโหลดเมื่อจำเป็น และกินคอนเท็กซ์เฉพาะตอนใช้งาน
  • ยิ่งมีเซิร์ฟเวอร์มาก แรงกดดันด้านคอนเท็กซ์ของ MCP ก็ยิ่งสูง แต่ Skills ไม่ได้กินคอนเท็กซ์ตลอดเวลาแบบแปรผันตรงตามจำนวนสกิล
  • หัวใจสำคัญคือการใส่คำแนะนำการใช้ CLI ไว้ใน Skills และเมื่อใช้ร่วมกับกลยุทธ์ CLI ก่อนจะมีประสิทธิภาพที่สุด
  • ตัวอย่าง Linear Skill มีเพียง URL ของ API วิธีการยืนยันตัวตน คำสั่ง curl สำหรับดึง issue วิธีค้นหาแบบ GraphQL และคำแนะนำให้ใช้ jq แยกวิเคราะห์ JSON เท่านั้น:
# Linear Issue Lookup Skill  
- Linear API: https://api.linear.app/graphql  
- Auth: Bearer Token ($LINEAR_TOKEN env var)  
- Get issue: curl -s -H "Authorization: Bearer $LINEAR_TOKEN" -H "Content-Type: application/json" -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' https://api.linear.app/graphql  
- Search issues (GraphQL): adjust the query field for JQL-like filtering  
- Results are JSON, parse with jq
  • ในแนวทางนี้ LLM จะโหลดเนื้อหาข้างต้นเข้าคอนเท็กซ์ก็ต่อเมื่อมีการเรียกสกิลนั้นเท่านั้น
  • ไม่จำเป็นต้องพกคำนิยามเครื่องมือ Linear ทั้ง 42 รายการไว้ตลอดเวลา แต่โหลดเฉพาะคำสั่ง CLI ที่จำเป็นก็พอ

กรณีที่ MCP ยังมีประโยชน์

  • เมื่อ บริการไม่มี CLI MCP อาจเป็นวิธีเชื่อมต่อเพียงทางเดียว
  • สำหรับ ผู้ใช้ที่ไม่ใช่นักพัฒนา และไม่ได้ใช้เทอร์มินัล MCP อาจเข้าถึงได้ง่ายกว่า
  • ในงานที่เป็น การสื่อสารสองทางแบบเรียลไทม์ ซึ่งเกินกว่ารูปแบบ request-response ธรรมดา MCP อาจเหมาะสมกว่า

เกณฑ์เลือกวิธีเข้าถึงฐานข้อมูล

  • ฐานข้อมูลสุดท้ายแล้วคือการรันคิวรี และ LLM ก็รู้จัก SQL กับคิวรีของ MongoDB เป็นอย่างดีอยู่แล้ว
  • หากใส่ข้อมูล DB และวิธีใช้ CLI ลงใน Skill พร้อมให้สคีมา LLM ก็สามารถเขียนคิวรีได้โดยไม่ต้องมี MCP
  • ตัวอย่าง Postgres Skill มีเพียงโฮสต์ สคีมาตาราง และวิธีใช้ psql CLI:
# Postgres Skill  
- Host: postgres://localhost:5432/myapp  
- Tables: users (id, name, email), orders (id, user_id, status)  
- CLI: psql -h localhost -d myapp -c "SELECT * FROM users WHERE ..."
  • สำหรับฐานข้อมูล MCP ก็ยังมีข้อดีเช่นกัน:
    • ความปลอดภัยของคิวรี: MCP server สามารถบังคับโหมดอ่านอย่างเดียว และบล็อกคิวรีอันตรายในระดับเซิร์ฟเวอร์ได้
    • การปกป้องข้อมูลรับรอง: วิธี CLI อาจทำให้ connection string โผล่ในพรอมป์ต์ แต่ MCP server จัดการข้อมูลรับรองไว้ภายในได้
  • สำหรับการพัฒนาในเครื่องหรือฐานข้อมูลส่วนตัว Skills + CLI จะเบา เร็ว และกู้คืนจากความผิดพลาดได้ง่ายกว่า
  • สำหรับฐานข้อมูลโปรดักชันหรือสภาพแวดล้อมทีมที่ใช้ร่วมกัน MCP เหมาะกว่า เพราะกลไกความปลอดภัยอย่างการตรวจสอบคิวรีและการควบคุมสิทธิ์ในระดับเซิร์ฟเวอร์มีความสำคัญ
  • ในเวิร์กโฟลว์การพัฒนาของนักพัฒนาส่วนใหญ่ MCP มักกลายเป็นการออกแบบที่มากเกินความจำเป็น

วิธีใช้งานของ Quandri

  • Quandri ใช้ Bash + CLI, Skills และ MCP ร่วมกันตามความเหมาะสมของแต่ละบริการ
  • สำหรับเครื่องมือที่ใช้ทุกวันอย่าง gh, psql, aws จะใช้ Bash + CLI:
    • ไม่มีต้นทุนด้านคอนเท็กซ์
    • ยืดหยุ่นสูง
    • ดีบักได้ทันทีในเทอร์มินัล
  • สำหรับเวิร์กโฟลว์หลายขั้นตอนที่ทำซ้ำบ่อย เช่น การเขียน commit และรีวิว PR จะใช้ Skills:
    • โหลดเฉพาะตอนถูกเรียกใช้
  • สำหรับบริการอย่าง Slack, Linear และ Notion ที่ไม่มี CLI แข็งแรงพอ จะใช้ MCP
  • รวมถึงกรณีที่การยืนยันตัวตนระดับทีมและการกำหนดขอบเขตสิทธิ์มีความสำคัญ เช่น การเข้าถึงฐานข้อมูลโปรดักชัน ก็จะใช้ MCP เช่นกัน
  • ถ้ามี CLI อยู่แล้วและยืนยันตัวตนในเครื่องได้ โดยทั่วไปวิธีนั้นมักเบาที่สุด
  • ถ้าบริการไม่มี CLI หรือต้องการการยืนยันตัวตนที่สอดคล้องกันทั้งทีม MCP จึงจะมีคุณค่า

บทสรุปและวิธีการวัดผล

  • สิ่งที่สำคัญกว่าการเชื่อมทุกอย่างเข้าด้วยกัน คือ การสอนให้ดี
  • ที่ Quandri ได้แทนที่ MCP server ด้วย Skills ที่ห่อ CLI เดิมไว้ และคืนพื้นที่คอนเท็กซ์ได้ราว 21K โทเค็น
  • ในเวิร์กโฟลว์ประจำวัน ปัญหาการเริ่มต้นล้มเหลวหายไป และการดีบักยังคงอยู่ในเทอร์มินัล
  • แนวทางที่โหลดเฉพาะเครื่องมือที่ต้องใช้ ในเวลาที่ต้องใช้ พร้อมคำแนะนำ CLI มีประสิทธิภาพกว่า
  • MCP อาจพัฒนาต่อไปเพื่อแก้ปัญหาเหล่านี้ได้ในอนาคต แต่ ณ ตอนนี้ Skills ยังเป็นตัวเลือกที่ดีกว่า
  • วิธีการวัดผล:
    • ดึง JSON schema ของเครื่องมือแต่ละตัวจาก MCP server ที่ถูกโหลดจริงในสภาพแวดล้อม Claude Code
    • วัดขนาดจากชื่อเครื่องมือ คำอธิบาย และพารามิเตอร์
    • ประมาณจำนวนโทเค็นด้วย heuristic 1 โทเค็นต่อประมาณ 4 ตัวอักษร
    • ค่าประมาณของทั้งเซิร์ฟเวอร์ได้จากการ extrapolate จากค่าเฉลี่ยของเครื่องมือตัวอย่าง

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

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

 
aer0700 3 시간 전

ผมคิดว่าแค่เลือกเทคโนโลยีให้เหมาะกับสถานการณ์ของตัวเองก็พอไม่ใช่หรือครับ จะบอกว่ามันตายแล้วก็คงไม่ใช่ เพราะตอนนี้ก็ยังถูกใช้งานกันเยอะมากอยู่แล้วครับ
 
GN⁺ 5 시간 전
ความเห็นจาก Hacker News

  • ผมเป็นหัวหน้าทีมที่ OpenAI ซึ่งดูแล ChatGPT App Store, ปลั๊กอิน Codex และ MCP โดยรวม และสิ่งที่บทความแนว “MCP ตายแล้ว” มักมองข้ามคือ แทบไม่สำคัญเลยว่า MCP จะถูกใช้เป็นโปรโตคอลขนส่งหรือไม่
    เหตุผลที่ MCP ยังไม่ตายก็เพราะแทบทุกบริษัทบนโลกกำลังสร้างเซิร์ฟเวอร์ MCP และเรารู้เรื่องนี้เพราะติดต่อกับพวกเขาโดยตรง
    หลายบริษัทเหล่านี้ไม่มี CLI และไม่มีแม้แต่ external API แต่ก็ยังสร้างเซิร์ฟเวอร์ MCP อยู่
    ภายในองค์กร คุณจะเปลี่ยนเซิร์ฟเวอร์ MCP ทั้งหมดให้เป็น CLI หรือใช้ code mode หรือทำระบบค้นหาเครื่องมือก็ได้ แต่นั่นเป็นแค่รายละเอียดการติดตั้งใช้งาน และประเด็นสำคัญคือ ทำให้ AI agent เข้าถึงบริการที่เดิมเข้าไม่ถึงได้
    จะบอกว่า MCP ในฐานะชั้นการสื่อสารที่โมเดลคุยโดยตรงนั้นตายแล้วก็อาจเถียงกันได้ แต่จะบอกว่า MCP ในฐานะโปรโตคอลตายแล้วนั้นไม่จริงเลย
    ข้ออ้างนี้ยิ่งอ่อนลงกว่าเดิมเพราะฟีเจอร์การใช้งานคอมพิวเตอร์/เบราว์เซอร์ในแอป Codex และถ้ายังไม่เคยลอง บอกได้เลยว่าน่าทึ่งมาก

    • ผมคิดว่า MCP มีโอกาสตายสูง
      เหตุผลใหญ่ที่สุดคือ ไม่ว่าการติดตั้งใช้งานจริงจะเป็น API, เว็บ หรือ CLI มันก็เพิ่ม อีกหนึ่งชั้นกับอีกหนึ่งคน ที่อาจทำให้การซิงก์คลาดเคลื่อนได้
      AI ไม่ควรใช้โปรโตคอลหรือชุดคำสั่งที่ต่างจากสิ่งที่มนุษย์ใช้ เข้าถึง และเข้าใจ
      ตอนนี้บริษัทต่าง ๆ อยากเปิด MCP server เพราะมันกำลังเป็นกระแส แต่ความจริงคือใช้ Claude สร้าง MCP server ครอบ API เดิม แล้วค่อยสั่งให้มันอัปเดตตามเอกสารสาธารณะเป็นครั้งคราว
      เอกสาร API ก็เปิดเผยอยู่แล้ว และ Claude Code ก็สร้าง MCP server จากการอ่านแค่เอกสารสาธารณะบนอินเทอร์เน็ต ดังนั้น MCP ตอนนี้จึงให้ความรู้สึกเหมือนเป็น ทางอ้อมชั่วคราว สำหรับข้อจำกัดของโมเดล
    • ท้ายที่สุด MCP ก็คล้ายชื่อแบรนด์ของ “API ที่ large language model ใช้ได้”
      ผลก็คือแม้แต่บริษัทที่ไม่ค่อยเน้นเทคนิคก็เริ่มทำ API เพื่อไม่ให้เครื่องมือของตัวเองดูตกยุคในยุค agent
      ผมเห็นด้วยกับเป้าหมายนี้ แต่จะเลือกสิ่งนี้เป็นโปรโตคอลเพื่อไปถึงจุดนั้นหรือไม่ก็อีกเรื่องหนึ่ง และไม่ว่าอย่างไรตอนนี้มันก็เป็นโปรโตคอลที่คนเคยได้ยินและใช้งานจริงแล้ว
    • คำพูดที่ว่า “แทบทุกบริษัทบนโลกกำลังสร้างเซิร์ฟเวอร์ MCP” นี่แหละที่ฟังดูเหมือน echo chamber
    • MCP กำลังใช้ context window ที่ยังมีค่ามากอยู่ไปกับการแก้ปัญหาที่จริง ๆ ไม่มีอยู่
      การอ้างว่าถ้าไม่มี MCP แล้ว agent จะเข้าไม่ถึงบริการนั้น อย่างดีที่สุดก็ทำให้เข้าใจผิด และตามที่บทความบอก แค่มีเครื่องมือบรรทัดคำสั่งกับอินพุต/เอาต์พุตของมันก็เข้าถึงได้แล้ว
      แม้มองในเชิงเทคนิคอย่างล้วน ๆ MCP ก็มี composability ต่ำกว่าเครื่องมือบรรทัดคำสั่ง และผมคิดว่าฝ่ายที่ไม่ให้ความสำคัญกับ composability สุดท้ายจะต้องจ่ายราคา
      พูดตรง ๆ คือมีอคติจากการลงทุนอยู่ และการที่กำลังขาย MCP ให้หลายบริษัทก็ไม่ได้ช่วยลบล้างอคตินั้น
      แค่ดู Microsoft ก็พอแล้วว่า ความนิยมใช้กับคุณภาพทางเทคนิคไม่จำเป็นต้องสัมพันธ์กันมากนัก และบางคนก็คิดว่าตรงกันข้ามด้วยซ้ำ
      ผมสงสัยว่าเหตุที่ OpenAI กำลังดัน MCP หนักตอนนี้ก็มีปัจจัยเชิงองค์กรอยู่มาก ซึ่งคนภายในอาจมองไม่เห็น
    • การบอกว่ากำลังสร้าง MCP ในที่ที่ไม่มี CLI อยู่แล้ว ฟังดูน่ากังวลทีเดียว
      การทำซ้ำความสามารถ CLI เดิมเพื่อให้รวมกับ agent ได้ดีกว่าเดิม กับการทำให้มันกลายเป็น อินเทอร์เฟซเดียว ที่ผูกทุกคนไว้กับสเปกที่ภายหลังอาจเห็นว่ามีตัวเลือกที่ดีกว่า เป็นคนละเรื่องกัน
      ถ้าเป็นแบบนั้นสุดท้ายก็ต้องกลับมาชำระ หนี้ MCP และอาจลงเอยว่าการไม่ทำตั้งแต่แรกถูกกว่าด้วยซ้ำ

  • อ่านแล้วสงสัยว่านี่ AI เขียนหรือเปล่า
    โดยเนื้อแท้ MCP ก็ใกล้เคียงกับ JSON-RPC ที่ต้องมีฟิลด์เฉพาะเพิ่มเข้ามาไม่กี่อย่าง
    แม้จะมีข้อกังวลเกี่ยวกับ JSON-RPC แต่เราก็ยังต้องการ ชั้นการค้นพบบริการ ที่ large language model ใช้เชื่อมต่อได้
    มันต้องทำงานได้ในหลายจุด ทั้งเว็บไซต์ เดสก์ท็อปแอปพลิเคชัน และบริการแบ็กเอนด์ โดย CLI ก็เป็นเพียงหนึ่งในจุดที่ระบบเหล่านี้เชื่อมต่อกัน
    ไม่ว่าจะเอาอะไรมาแทน MCP ต่อให้กำหนดโปรโตคอลสื่อสารหรือฟิลด์ค้นหาเครื่องมือกันใหม่ ก็น่าจะออกมาในรูปแบบคล้าย ๆ กัน

    • ทุกครั้งที่อ่านบทความเกี่ยวกับ MCP ผมรู้สึกเหมือนทั้งอินเทอร์เน็ตหรือทั้ง HN กำลังอาการกำเริบพร้อมกัน
      มีคนบอกว่า API ดีกว่า MCP แต่จริง ๆ MCP ก็เป็นแค่ API ที่มีคำแนะนำเพิ่มนิดหน่อยเพื่อให้ AI ค้นพบวิธีใช้งานได้
      บางคนก็บอกให้ใช้ CLI แต่ผมไม่ค่อยเข้าใจว่าหมายถึงอะไรกันแน่
      ที่ large language model ใช้เครื่องมือ CLI ทั่วไปอย่าง ffmpeg ได้ดี ก็เพราะความรู้นั้นถูกฝังแน่นอยู่ใน weights แล้ว
      ถ้าคุณสร้างเครื่องมือ CLI ใหม่ คุณก็ยังต้องสอน AI วิธีใช้อยู่ดี และถ้าอยากให้ส่วนที่เป็นการ “สอน” นี้มาจากเซิร์ฟเวอร์ก็ใช้ MCP ถ้าอยากเก็บไว้ในรูปแบบสแตติกบนเครื่องก็ใช้สกิล
      ผมไม่เข้าใจว่าทำไมแนวคิดที่เรียบง่ายขนาดนี้ถึงกลายเป็นประเด็นถกเถียงใหญ่โตได้
    • ปัญหาคือ MCP กินพื้นที่ใน context ค่อนข้างถาวร และไม่ได้มาพร้อมระบบติดตั้ง/ถอนการติดตั้งและการค้นพบที่เรียบร้อย
      สกิลควรจะอยู่บนฐาน MCP ทั้งหมด ควรถูกเรียกใช้เฉพาะเมื่อจำเป็น และทั้งคนกับ AI ควรจัดการและค้นหาได้ง่าย จึงจะทำงานได้ดี
      ถ้ามองจากขอบเขตการใช้งานจริง ขอบเขตเริ่มต้นมันแคบเกินไป และถ้าจะสร้างอะไรทับลงไปข้างบน มันก็อาจยังฟื้นขึ้นมาได้

  • สำหรับข้ออ้างว่า “ปัญหา 1: กลืนกินหน้าต่างบริบท” ผมไม่เห็นว่ามันต่างอะไรกับการรัน linearcli --help, notioncli --help, slackcli --help ทีละตัว
    ที่จริงใน MCP สภาพแวดล้อมรันไทม์สามารถใส่แค่ชื่อของแต่ละเครื่องมือไว้ในบริบท และค่อยเพิ่มเอกสารทั้งหมดตามเซิร์ฟเวอร์ MCP หรือแต่ละเครื่องมือเมื่อจำเป็น
    ถ้าจะให้ CLI ได้ผลแบบเดียวกัน ทุก CLI ก็ต้องมีคำสั่งอย่าง --short-descr
    ส่วน “ปัญหา 2: ความน่าเชื่อถือในการปฏิบัติการต่ำ” ถ้าเครื่องมือใช้ REST API อยู่แล้ว โปรโตคอลก็คล้ายกัน จึงไม่มีเหตุผลที่ MCP จะต้องช้ากว่า
    ถ้าช้ากว่า ก็น่าจะเป็นปัญหาของการติดตั้งใช้งาน เช่น มี MCP ครอบทับอยู่บน API และไปรันบนเซิร์ฟเวอร์ของผู้รับเหมาช่วงในดาต้าเซ็นเตอร์ที่อยู่ไกล
    เซิร์ฟเวอร์ MCP ส่วนใหญ่อาจทำออกมาเละเทะก็จริง แต่ปัญหานั้นไม่ใช่เรื่องของโปรโตคอล เป็นปัญหาของทั้งอุตสาหกรรมมากกว่า
    ส่วน “ปัญหา 3: ซ้ำซ้อนกับ CLI/API เดิม” ก็จริงในกรณีที่มีเครื่องมือ CLI อยู่แล้ว และ SQL MCP server หรือ curl MCP ก็ดูเหมือนสิ้นเปลืองโทเคน
    แต่ในองค์กรส่วนใหญ่ไม่มี CLI และถึงมีก็มักมีแค่ API ที่ออกแบบมาให้โปรแกรมใช้ ไม่ใช่ให้โมเดลภาษาขนาดใหญ่ใช้
    คำพูดที่ว่า “ควรให้บริการเป็นลำดับ CLI → API → เอกสาร” ฟังดูเหมือนการบอกว่าบริษัทควรทำเดสก์ท็อปเนทีฟไคลเอนต์กับโมบายล์เนทีฟไคลเอนต์ก่อน แทนที่จะทำเว็บไซต์ที่ช้าและสิ้นเปลือง

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

  • ในบทความไม่มีวันที่ แต่บอกว่าการโหลดเครื่องมือแบบหน่วงเวลาเป็นอัปเดตล่าสุดที่ออกมาหลังจากเขียนบทความ
    แต่จริง ๆ แล้ว การโหลดเครื่องมือแบบหน่วงเวลา ถูกเพิ่มเข้ามาในเดือนพฤศจิกายน 2025: https://www.anthropic.com/engineering/advanced-tool-use
    ดังนั้นตัวเลขพวกนี้ก็มีอายุอย่างน้อย 7 เดือนแล้ว และผมไม่เข้าใจว่าทำไมเพิ่งถูกโพสต์ตอนนี้

    • มันแปลกที่ยังมาถกเรื่องนี้กันอยู่
      เพราะด้วย การโหลดเครื่องมือแบบหน่วงเวลา, บริบทขนาดใหญ่, และ prompt caching ทำให้ปี 2026 ต่างจากปี 2025 ไปอย่างสิ้นเชิง
      ข้อถกเถียงว่า CLI ประหยัดโทเคนกว่าก็พังทันที ถ้าขั้นแรกยังต้องรัน --help
      ถ้าไม่จำวิธีเรียกพร้อมพารามิเตอร์ได้ สุดท้ายข้อมูลพวกนั้นก็ยังต้องอยู่ในบริบทเหมือนเดิม
    • ยิ่งไปกว่านั้น มันดูเหมือนเป็นบทความที่เก่ากว่านั้นอีก และชวนให้เข้าใจว่า GPT-4o ยังเป็นรุ่นล่าสุด
    • การโหลดเครื่องมือแบบหน่วงเวลาไม่ใช่ส่วนหนึ่งของ MCP
      มันเป็น พารามิเตอร์เฉพาะของ Claude API ที่ API ของโมเดลภาษาขนาดใหญ่ตัวอื่นส่วนใหญ่ยังไม่รองรับ
    • บทความนี้ลงวันที่ 29 พฤษภาคม 2026 และการบอกว่าอัปเดตนั้นเป็นการเปลี่ยนแปลง “ล่าสุด” หลังบทความออก เป็นเรื่องโกหกเพื่อทำให้ตัวเองดูดีขึ้น

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

    • บทความนี้หรือเปล่า? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
    • ถ้าใช่ ผมก็สงสัยว่า ข้อดีของ MCP เมื่อเทียบกับการที่เอเจนต์เข้าถึง API โดยตรงคืออะไร
    • ผมเลยสงสัยว่านี่เป็นการเอามาแทนระบบสิทธิ์ที่ใช้ปกป้อง API หรือเปล่า
      เพราะไม่ว่ายังไง API ก็น่าจะต้องมี กลไกสิทธิ์การเข้าถึง อยู่ดีในรูปแบบใดรูปแบบหนึ่ง
    • เห็นด้วย
      นี่แหละคือเหตุผลที่บริษัทอย่าง Runlayer โตเร็วมาก และถ้าไม่มี central control plane MCP ก็จะกลายเป็นทุ่นระเบิด

  • นอกจากประเด็นที่พูดกันไปแล้ว remote MCP ยังมีข้อดีตรงที่ฝั่งเซิร์ฟเวอร์เป็นผู้ควบคุม ดังนั้นผู้ให้บริการสามารถ เพิ่มฟีเจอร์ใหม่ ได้โดยไม่ต้องอัปเดตสกิลหรือ CLI ของไคลเอนต์ทุกตัว
    อีกทั้ง remote MCP ก็ปลอดภัยกว่า เพราะไม่ต้องขอสิทธิ์รันโค้ดจริงบนระบบโลคัล
    สกิลมักผูกสคริปต์ด้วย npx/uvx ซึ่งในทางปฏิบัติก็อันตรายพอ ๆ กับ curl npm.com | bash

  • ผมเคยทำสกิลที่เชื่อมทีมต่าง ๆ เข้ากับระบบจัดการภายในบริษัท และสุดท้ายก็ต้องลงทะเบียนมันเป็น MCP
    ตัว MCP เองเปิดให้ใช้แค่การ grep เอกสารกับการเรียก API จึงแทบไร้ประโยชน์โดยตัวมันเอง แต่เหตุผลหลักที่เลือกเส้นทางนี้คือ การ deploy
    ทีมที่ไม่ใช่สายเทคนิคต้องการ UI ที่แค่เพิ่ม URL แล้วทุกอย่างใช้งานได้ พร้อมมี OAuth คอยแนะนำ และ MCP ก็ทำให้สิ่งนั้นเกิดขึ้นได้ใน Claude หรือ ChatGPT
    วิธีที่ UI แชตแสดงการเรียก MCP ก็ดีกว่าและชัดเจนกับผู้ใช้มากกว่า

  • แทนที่จะต้องจัดการ MCP server และแจกจ่าย CLI สำหรับทุกแพลตฟอร์ม ผมสงสัยว่าถ้า เปิด API ผ่าน SSH จะเป็นอย่างไร
    SSH เป็นโปรโตคอลที่เหมาะกับโมเดลภาษาขนาดใหญ่มาก
    coding agent ก็ใช้งานได้อยู่แล้ว แค่ ssh api@example.com list-users ก็น่าจะพอ
    ผู้ใช้ 90% ก็น่าจะติดตั้ง ssh ไว้อยู่แล้ว ทั้งอินพุตและเอาต์พุตก็เป็นข้อความ จึงเหมาะกับโมเดลภาษาขนาดใหญ่พอดี
    มันจัดการทั้งการยืนยันตัวตนด้วยกุญแจสาธารณะ, เอาต์พุตแบบสตรีม, อินพุต/เอาต์พุตเชิงโต้ตอบ, และถ้าต้องการก็รวมถึงการโอนไฟล์ผ่าน scp/rsync ได้ด้วย
    ถ้าผู้ใช้เชื่อมบัญชีกับ Github หรือ GitLab อยู่แล้ว ก็อาจดึงคีย์ ssh มาแล้วตั้งค่าการยืนยันตัวตนล่วงหน้าได้ ทำให้แค่เชื่อมต่อก็เข้าใช้งานได้ทันที

    • ลองขยายแนวคิดนี้ไปในระดับทั้งองค์กรดู

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