MCP = Mega Context Problem: เมื่อ Tool เยอะเกินไปจน AI เอ๋อ (และวิธีแก้ที่ถูกต้อง)

จำโพสต์ก่อนหน้านี้ที่ผมเคยบ่นเรื่อง "อย่าใช้ MCP ถ้าไม่จำเป็น" ได้ไหมครับ? ที่ผมบอกว่าลง MCP Server ตัวนึงอย่าง XcodeBuild บางทีมันล่อ context เราไป 45k tokens (เกือบ 25% ของโควตา!) ทั้งๆ ที่เรายังไม่ได้สั่งให้มันทำอะไรเลยด้วยซ้ำ

นั่นแหละครับคือสิ่งที่ Matt Carey จาก Cloudflare เรียกว่า "Mega Context Problem"

วันนี้ผมไปไถ YouTube เจอคลิปนึงชื่อเดียวกับปัญหานี้เลย "MCP = Mega Context Problem" เป็น Talk สั้นๆ แต่โคตรทรงพลังที่มาเฉลยว่า จริงๆ แล้วเรากำลังใช้ MCP กันผิดทางอยู่หรือเปล่า? (ผมถึงกับต้องหยุดดูแล้วจดตามเลยทีเดียว)

ปัญหาคือเรา "Cherry-pick" กันเหนื่อยเกินไป

ปกติเวลาเราจะทำ MCP Server สักตัว เรามักจะทำแบบนี้:

1. ไปดู API ของ service นั้นๆ
2. เลือก (Cherry-pick) มาว่าอยากให้ AI ใช้ endpoint ไหนบ้าง
3. เขียนโค้ดห่อมันเข้าไปเป็น Tool หนึ่งตัว

Matt บอกว่าวิธีนี้มัน Inefficient สุดๆ เพราะนอกจากเราจะ "งานถึก" ต้องมานั่งเขียนโค้ดเองแล้ว ผลลัพธ์ที่ได้คือ MCP Server ที่ "อ้วน" และ "รก context" เพราะเราพยายามยัดคำอธิบาย tool ทุกอย่างเข้าไปให้ AI ตั้งแต่เริ่ม session

มันเหมือนคุณจะไปซ่อมก๊อกน้ำ แต่ดันแบกเครื่องมือช่างทั้งโกดังใส่กระเป๋าเป้ไปขวางทางเดินตัวเองนั่นแหละครับ!

"The best MCP server is the one you didn't have to build"

ประโยคนี้คือหมัดฮุคของคลิปนี้เลยครับ Matt เสนอว่า แทนที่เราจะมานั่งสร้าง service แยกต่างหาก ทำไมเราไม่ใช้ Existing API Specs (OpenAPI) หรือ CLIs ที่มีอยู่แล้วมาทำเป็น MCP แบบ On-demand ล่ะ?

ไอเดียของ Cloudflare คือการสร้างสิ่งที่เรียกว่า "Tool Search":

• แทนที่จะยัด Tool 1,000 ตัวเข้าไปใน context
• เราใส่แค่ "Tool ค้นหา Tool" เข้าไปตัวเดียวพอ
• พอ Agent อยากทำอะไรสักอย่าง (เช่น เคลียร์ cache ใน Cloudflare) มันจะไปเรียก Tool Search เพื่อไปหาใน API Spec ขนาดมหึมาว่า "มี tool ไหนทำเรื่องนี้ได้บ้าง?"
• แล้วค่อยดึงรายละเอียดของ tool นั้นๆ มาใส่ใน context เฉพาะตอนที่จะใช้จริงๆ

Aha Moment! มันคือการทำให้ Server เป็น Stateless และ Tools เป็น Self-discoverable ครับ (นึกภาพกุญแจผีที่มันงอกดอกที่ใช่ขึ้นมาเองตอนเจอแม่กุญแจ โดยที่เราไม่ต้องพกพวงกุญแจหนักๆ น่ะ!!)

แล้ว พรศ ว่าไง?

เอาเข้าจริง ท่าที่ Matt Carey เสนอเนี่ย มันคือเวอร์ชัน "ติดปีก" ของสิ่งที่ผมเคยพยายามทำเองแบบดิบๆ ครับ

จำได้ไหมที่ผมบอกว่า "อย่าใช้ MCP แต่ให้เขียน Bash script หรือบอก command line ใน CLUADE.md แทน" ท่าของผมตอนนั้นคือการตัด "ไขมัน" ออกเพื่อให้ AI ทำงานได้ไวและประหยัด token แต่ข้อเสียคือผมต้องรู้คำสั่งล่วงหน้าและเขียนบอกมันไว้

แต่ท่าของ Cloudflare คือการเอา API Spec ทั้งหมดมาวางไว้ แล้วให้ AI "เดินเลือก" เองได้แบบไม่เปลืองที่

จุดที่ผมอยาก Push-back (และอยากให้ระวัง): ถึงแม้ทฤษฎี "On-demand Tool Discovery" จะดูสวยหรู แต่ในฐานะคนคลุกวงล้าน AI ผมมองว่ามันยังมี Trade-off อยู่:

1. Latency: การต้องไป "หา tool ก่อนใช้ tool" มันเพิ่ม step การทำงาน (Round-trip) ของ AI แน่นอน ถ้าเน็ตช้าหรือ API Spec มันซับ้อนเกินไป AI อาจจะยืนงงหน้าตู้นานขึ้น
2. Hallucination: ยิ่ง API Spec ใหญ่ การที่ AI จะเลือก parameter ถูกเป๊ะๆ โดยไม่มีเราช่วยไกด์ในตอนแรก (เหมือนที่ผมทำใน CLAUDE.md) มันมีโอกาสหลุดได้มากกว่า

แต่ถ้าถามผมว่าชอบไหม? ชอบมากครับ! โดยเฉพาะประโยคที่ว่า "Context limit is an agent problem, not an MCP problem" มันเปลี่ยน mindset ผมไปเลยว่า เราไม่ควรโทษ protocol แต่เราต้องฉลาดขึ้นในการ "ป้อน" ข้อมูลให้ agent

---

🎯 สรุปแบบสั้นๆ

1. ปัญหา: MCP Server แบบเดิมมัน "อ้วน" เกินไป ยัดเยียดรายละเอียด tool ทุกอย่างเข้า context ทำให้ token เต็มไวและ AI เอ๋อง่าย
2. ทางออก: ใช้ระบบ "ค้นหา tool เมื่อต้องการ" (On-demand Discovery) โดยใช้ API Spec ที่มีอยู่แล้ว ไม่ต้องเขียน MCP Server ห่อใหม่ทุกครั้ง
3. ผลลัพธ์: Agent สามารถเข้าถึงความสามารถระดับหมื่น tool ได้ โดยที่ใช้ context tokens แค่นิดเดียว (สายประหยัด token แบบผมกดถูกใจสิ่งนี้)

ใครอยากเห็นภาพชัดๆ แนะนำให้ไปดูคลิปเต็มๆ ของ Matt Carey ครับ เป็น 20 นาทีที่คุ้มค่าสำหรับคนที่สนใจเรื่อง AI Agent และการจัดการ Context Window จริงๆ

ดูคลิปเต็มๆ ได้ที่นี่เลยครับ: https://www.youtube.com/watch?v=YBYUvGOuotE

Happy Scaling Agents ครับผม!