MCP server ที่คนใช้จริง: วัด 11 ตัว แล้วพบว่าโทเคนเป็นข้อจำกัดการออกแบบ

โดย Nokka (นก-กา) | 17 กันยายน 2026

บทความนี้เขียนโดย AI (โมเดล deepseek-v4.1-flash ของผู้ให้บริการ ollama-cloud) ผ่าน Hermes Agent จาก Nous Research ตรวจสอบและเรียบเรียงโดย Nokka

มีตัวเลขหนึ่งที่ผมอ่านแล้วเข้าใจว่าทำไมทีมถึงเริ่มจริงจังกับ MCP

การนับโทเคนของ tool definitions จาก server ที่คนใช้มากที่สุด 11 ตัว พบว่า Notion ใช้ราว 19,050 โทเคน ในขณะที่ Git เพียง 1,119 และ Puppeteer 610 ⇒ ต่างกันกว่า 30 เท่า จากการติดตั้ง server เดียวเหมือนกัน [1]

⇒ และตัวเลขนี้ไม่ใช่ค่าคงที่ ⇒ มันขึ้นกับ tokenizer ของโมเดล เวอร์ชันของ server และวิธีนับของคนวัด [1][2][3]

บทความนี้คือภาคต่อของ หลักออกแบบ MCP tool จากบทความก่อน ผมพูดถึงหลักการออกแบบ ครั้งนี้ผมจะเปิดดู server ที่คนใช้จริง แล้วให้เห็นว่าหลักการเหล่านั้นไปอยู่ตรงไหน

หนึ่ง: เปิดดูว่าการวัดทำกันอย่างไร

ก่อนเชื่อตัวเลขใด ผมต้องรู้ก่อนว่ามันวัดมาอย่างไร ⇒ และนี่คือสองงานวัดที่ผมเลือกใช้เป็นแกน เพราะทั้งคู่ ระบุวิธีและวันที่ชัดเจน ซึ่งหาได้ยาก [1][2]

งานวัดที่ 1: นับด้วย tokenizer จริง

นับจาก tools/list ของ server แต่ละตัวที่รันในเครื่อง แล้วนับด้วย o200k_base ผ่าน tiktoken → งานวัดนี้ระบุว่า ตัวเลขของ tokenizer ต่างกันได้ราว 10 ถึง 20 เปอร์เซ็นต์ ขึ้นกับโมเดล [2]

server tools โทเคน (o200k_base)
Notion 22 15,462
Sentry 22 13,823
Supabase 29 3,422
Playwright 23 3,130
Filesystem 14 1,641
AWS API 2 1,554
Git 12 1,119

⇒ งานวัดนี้ระบุชัดว่าไม่รวม server ระยะไกลที่ต้อง OAuth เช่น Linear, Atlassian และ GitHub แบบ hosted เพราะ "การวัดมันอย่างซื่อสัตย์ต้องมีการเชื่อมต่อที่ยืนยันตัวตนจริง ไม่ใช่การเดา" [2]

⇒ ผมชอบประโยคนี้มาก เพราะมันคือสิ่งที่งานวัดที่ดีควรพูด [2]

งานวัดที่ 2: นับจาก client จริงที่เชื่อมต่อ

งานวัดนี้ทำต่างออกไป คือ เชื่อม client แล้วเรียก tools/list แล้ววัดขนาด schema ที่ได้กลับมา โดยประมาณที่ราว 4 ตัวอักษรต่อโทเคน และระบุว่าเป็น การประมาณ ไม่ใช่การนับด้วย tokenizer [1]

server tools โทเคน (ประมาณ 4 ตัวอักษร/โทเคน)
Notion 24 ~19,050
Firecrawl 27 ~9,870
Supabase 29 ~4,990
Playwright 24 ~4,630
GitHub 26 ~3,960
Filesystem 14 ~3,240
Memory 9 ~2,690
Everything (demo) 13 ~1,910
Context7 2 ~1,215
Sequential Thinking 1 ~1,150
Puppeteer 7 ~610

⇒ งานวัดนี้ยังเลือก server มาอย่างโปร่งใส คือ "เราเปิดสี่แคตาล็อกที่ใหญ่ที่สุด คือ repo ทางการของ Model Context Protocol บวกกับลิสต์ awesome ของชุมชนอีกสามอัน แล้วเก็บ server ที่ทุกอันเห็นตรงกัน" [1]

และมีการเปิดเผยที่ผมคิดว่าซื่อสัตย์มาก ⇒ งานวัดนี้ระบุว่าลิสต์หนึ่ง "บรรยายตัวเองใน README ว่ามันเป็นคู่หูของไดเรกทอรี Glama" และอีกลิสต์ "เป็น repo ที่ถูก archive ไปแล้ว" ⇒ แล้วจึงเขียนว่า "เราระบุทั้งสองเรื่องแทนที่จะนำเสนอทั้งสี่ว่าใช้งานได้เท่ากัน" [1]

สอง: 🔴 และนี่คือสิ่งที่ผมพบเมื่อวางสองตารางเทียบกัน

ความไม่ลงรอยกันเองคือบทเรียนที่สำคัญที่สุดของบทความนี้ [1][2]

server งานวัด 1 งานวัด 2 ต่าง
Supabase 3,422 (29 tools) ~4,990 (29) +46%
Playwright 3,130 (23 tools) ~4,630 (24) +48%
Filesystem 1,641 (14 tools) ~3,240 (14) +97%
Notion 15,462 (22 tools) ~19,050 (24) +23%

⇒ สังเกตสองแถวกลาง ⇒ จำนวน tool เท่ากันเป๊ะ แต่ตัวเลขต่างกันเกือบสองเท่า [1][2]

สาเหตุที่เป็นไปได้มีสามข้อ และทั้งสามข้อไม่ใช่ความผิดของใคร [1][2][3]

หนึ่ง ⇒ tokenizer ต่างกัน ⇒ งานวัด 1 นับด้วย o200k_base จริง ส่วนงานวัด 2 ประมาณที่ 4 ตัวอักษรต่อโทเคน ⇒ และงานวัด 1 เองก็ระบุว่าตัวเลขของโมเดลต่างกันได้ 10 ถึง 20 เปอร์เซ็นต์ [2]

สอง ⇒ เวอร์ชัน server ต่างกัน ⇒ schema เปลี่ยนได้ทุกรุ่น และงานวัด 1 บันทึก ชื่อแพ็กเกจพร้อมเวอร์ชันของทุกแถว เพื่อให้รันซ้ำได้ ⇒ "ทุกแถวระบุแพ็กเกจและเวอร์ชันที่แน่นอน เพื่อให้ใครก็รัน server เดียวกันแล้วได้ตัวเลขเดียวกัน" [2]

สาม ⇒ สถานะเริ่มต้นต่างกัน ⇒ งานวัด 1 ระบุว่า "ตัวเลขคือค่าตั้งต้นของแต่ละ server บาง server เปิด tool เพิ่มเมื่อใส่ flag หรือเชื่อมบัญชี" [2]

⇒ บทเรียนที่ผมดึงออกมาคือ: ตัวเลขโทเคนของ MCP ไม่มีความหมายถ้าไม่บอกวิธีนับและเวอร์ชัน [1][2][3]

สาม: และมีตัวเลขที่ถูกอ้างกันบ่อย ซึ่งผมเลือกไม่ใช้เป็นตัวหลัก

คุณอาจเคยเห็นตัวเลขนี้ ⇒ Google Drive 31 tools ใช้ 47,293 โทเคน ⇒ ตัวเลขนี้ถูกอ้างในหลายที่ และมันน่าตกใจจริง [4]

ผมเลือกไม่ใช้มันเป็นตัวเลขหลักในบทความนี้ ด้วยเหตุผลสองข้อที่ผมต้องบอกตรง ๆ [4][5]

หนึ่ง ⇒ ผมพบตัวเลขนี้ในบทความที่ โปรโมตเครื่องมือลดโทเคนของตัวเอง ⇒ การวัดอาจถูกต้อง แต่ผมไม่มีทางตรวจสอบวิธีวัดอย่างอิสระ จึงไม่ควรนำมาเป็นตัวตั้ง [4]

สอง ⇒ และนี่คือเหตุผลที่ชี้ขาด: Google Drive reference server ถูก archive ไปแล้ว ⇒ ตัวเลขของ server ที่ไม่มีใครควรติดตั้งใหม่ ไม่ควรเป็นตัวแทนของปัญหาปัจจุบัน [5]

⇒ และในทำนองเดียวกัน ตัวเลขรวม "111,713 โทเคน" จาก 10 server ก็มาจากงานวัดเดียวกัน ซึ่งใช้ tokenizer cl100k_base ที่ต่างจากสองงานวัดข้างบน ⇒ ผมจึงแสดงตารางจากการวัดที่ระบุวิธีชัด และเล่าตัวเลขนี้เป็นบริบท ไม่ใช่เป็นข้อเท็จจริงตั้งต้น [4]

สี่: แล้วโทเคนไปอยู่ส่วนไหนของ schema

งานวัดชิ้นหนึ่งแยกส่วนประกอบของ schema ออกมาให้เห็น ⇒ นี่คือคำตอบว่าทำไม "ลดคำอธิบาย" อย่างเดียวไม่พอ [4]

ชื่อ tool + คำอธิบาย 35%
คุณสมบัติใน inputSchema 42%
นิยามชนิดข้อมูลซ้อนกัน 15%
อาร์เรย์ required 3%
metadata + headers 5%

⇒ ข้อสรุปของงานวัดนี้ตรงกับหลักออกแบบที่ผมเขียนไว้ในบทความก่อน [4]

"ส่วนที่ใหญ่ที่สุดไม่ใช่คำอธิบาย tool แต่เป็น *คุณสมบัติใน inputSchema** ⇒ ทุกพารามิเตอร์ต้องมีชนิดข้อมูล มีคำอธิบาย บางตัวมี enum บางตัวซ้อน object ⇒ โครงสร้าง JSON นั้นแพง"* [4]

และมีข้อเสนอที่ผมคิดว่าใช้ได้จริงที่สุด ⇒ แต่ต้องระบุให้ตรงว่าใครพูด [4]

ข้อเสนอนี้ไม่ได้อยู่ในเนื้อความของผู้เขียนงานวัด ⇒ มันอยู่ใน คอมเมนต์ใต้บทความ โดยผู้อ่านชื่อ Max Quimby ซึ่งตั้งข้อสังเกตไว้ว่า

"กังวลว่าตัวนับของคุณวัดต้นทุนการส่งซ้ำด้วยไหม ⇒ ความเจ็บส่วนใหญ่ในลูป agent ยาว ๆ ไม่ใช่การโหลดครั้งเดียว แต่คือการจ่ายภาษี schema นั้นซ้ำทุกเทิร์น" และเสนอว่า "Google Drive 31 tools น่าจะเหลือ 4 ได้ด้วย enum ของ operation เดียว" [4]

⇒ ผมยกข้อเสนอนี้เพราะมันตรงกับหลัก "รวม tool เข้าด้วยกัน" ในบทความก่อนอย่างสมบูรณ์ ถ้า Google Drive ให้ files ตัวเดียวที่รับ operation เป็น enum ⇒ แทนที่จะมี 31 schema ที่ต้องส่งทุกครั้ง กลายเป็น schema เดียวที่มี enum [4]

⇒ แต่ผมต้องแยกให้ชัด: นี่คือข้อเสนอของผู้อ่าน ไม่ใช่ผลการวัดของผู้เขียน และผมเปิด [4] อ่านเองจึงเห็นความต่างนี้ ⇒ ผู้อ่านที่สนใจควรเปิดคอมเมนต์ใต้บทความนั้นดูเอง [4]

และมีกลยุทธ์ลดที่ถูกนำเสนอในงานวัดเดียวกัน [4]

• แคช schema ⇒ ใส่ tool definitions ครั้งเดียว ไม่ใช่ทุกบทสนทนา
• ตัด wrapper ของผลลัพธ์ ⇒ คืนข้อความธรรมดา ไม่ใช่ {"content":[{"type":"text","text":"..."}]}
• รูปแบบที่บีบอัดได้ ⇒ รายงานว่าลด 847 tools จาก 111,713 โทเคน เหลือ 3,247 (ลด 97%)

⇒ ผมยังไม่ทดสอบสูตรสุดท้ายด้วยตัวเอง จึงรายงานตามที่เขาระบุและไม่ยืนยันผล [4]

ห้า: โทเคนถูกเลื่อนเวลาออกไปแล้ว แต่ไม่ได้หายไป

นี่คือข้อค้นพบที่ผมคิดว่าสำคัญที่สุด และมันเพิ่งเปลี่ยนไปไม่นาน [1]

งานวัดที่ 2 ทดลองแบบนี้ ⇒ รันเซสชันสั้นหนึ่งเทิร์นใน repo ว่าง แล้ววัดโทเคนรวม จากนั้นทำเหมือนเดิมโดยต่อ filesystem server [1]

"ผลรวมเท่ากันภายในความแปรปรวนระหว่างรอบ ราว 25,300 ทั้งสองแบบ ⇒ *ต่างกันน้อยกว่าความต่างระหว่างการรันพื้นฐานสองรอบ*" [1]

⇒ คำอธิบายคือ Claude Code รุ่นปัจจุบัน (2.1.204) เลื่อนการโหลดนิยาม tool ออกไป ⇒ ตอนเปิดเซสชัน มีเพียงชื่อ tool ที่ตามมา จนกว่าจะมีการเรียกใช้จริง [1]

🔴 และงานวัดนี้เขียนคำเตือนไว้ดีมาก [1]

"นั่นคือข่าวดีและกับดักในประโยคเดียว *ค่าใช้จ่ายถูกเลื่อน ไม่ได้ถูกลบ** ⇒ วินาทีที่ agent ใช้ server จริง schema จะโหลด ⇒ และเทิร์นที่แตะหลาย server จะจ่ายน้ำหนักรวมจากตาราง ⇒ การอ่านที่ยุติธรรมคืออ่านตารางเป็นค่าใช้จ่ายตอนใช้ และอ่านการเลื่อนออกไปเป็นเหตุผลให้ติดตั้ง server น้อยกว่าที่คุณคิดว่าจะรับไหว เพราะ 'มันฟรีจนกว่าจะใช้' กลายเป็น 'ฉันใช้สี่ตัวในเทิร์นเดียว' อย่างเงียบ ๆ"* [1]

⇒ ประโยค "มันฟรีจนกว่าจะใช้" คือประโยคที่ดีที่สุดที่ผมอ่านในงานวัดนี้ และมันอธิบายพฤติกรรมของผมเองได้เลย [1]

และมีหลักฐานว่าเรื่องนี้เป็นจริง ⇒ งานวัดเดียวกันชี้ว่า server GitHub ที่ถูก archive ไปแล้วยังมีดาวน์โหลดราว 125,000 ครั้งต่อสัปดาห์ ⇒ "ความนิยมในลิสต์เป็นสัญญาณที่ตามหลัง" [1]

⇒ ตัวเลข 125,000 ต่อสัปดาห์นี้เป็นตัวอย่างที่ตรงที่สุด ว่าทำไมคุณไม่ควรเลือก server จากลิสต์ "ยอดนิยม" [1][5]

หก: เปิดดูสิ่งที่ 10 server ทำได้จริง ไม่ได้แค่กินโทเคน

มีงานตรวจสอบที่ทำสิ่งที่ผมไม่เคยเห็นที่อื่น คือ เชื่อมต่อ 10 server ที่ถูกอ้างถึงมากที่สุด แล้วแจกแจงทุก tool ที่มันเปิด ⇒ แล้วดูว่า ค่าเริ่มต้นให้อำนาจอะไรไปบ้าง [6]

124 tools ถูกแจกแจง
28 tool ประกาศตัวเองว่า destructive
84 เส้นทางยกระดับสิทธิ์เชิงโครงสร้าง

⇒ วิธีทำของงานตรวจนี้คือ "แต่ละ server ถูกเริ่มเป็นโปรเซสลูก ทำ handshake ผ่านโปรโตคอล MCP แล้ว query ด้วย tools/list" ⇒ โดยเลือกจาก repo ทางการของ MCP, เอกสาร Anthropic และ top-20 ของ mcp.directory [6]

สอง server ที่ให้อำนาจรันโค้ด

"สอง server มอบการรันโค้ดตามอำเภอใจให้ agent โดยไม่มีประตูอนุมัติ ⇒ *start_process ของ Desktop Commander รันคำสั่ง shell บนเครื่องของคุณ** และ browser_evaluate ของ Playwright รัน JavaScript ในเบราว์เซอร์ พร้อมคุกกี้เซสชันของคุณ"* [6]

⇒ และจุดที่ผมคิดว่าสำคัญที่สุด [6]

"Desktop Commander ประกาศตัวเองว่า 9 จาก 26 tool เป็น DESTRUCTIVE ส่วน Playwright ระบุ 17 จาก 22 ⇒ *ผู้เขียน server รู้ว่านี่อันตราย** แต่ MCP ไม่ได้นิยามกลไกใดที่บังคับให้มีการยืนยันจากมนุษย์ก่อน tool ที่ทำลายข้อมูลจะทำงาน"* [6]

⇒ นี่คือข้อความที่ทำให้ผมเข้าใจคำว่า "annotation เป็นสัญญา ไม่ใช่การบังคับ" ชัดขึ้น ⇒ ตัวเลข 28 จาก 124 คือ คำประกาศที่ไม่มีอะไรบังคับ [6]

ขอบเขตที่ไม่มีขอบเขต

"memory server ไม่มีขอบเขตเลย ⇒ กราฟความรู้ถาวรข้ามเซสชัน **server ใดก็ได้ในเซสชัน MCP เดียวกันอ่านกราฟทั้งหมดได้ หรือลบ entity ออกจากมันได้ ⇒ ไม่มี scoping ไม่มี access control ไม่มี per-server isolation* ⇒ ถ้า agent ถูกชักจูงด้วยเนื้อหาจาก server อื่น มันเข้าถึงหรือทำลายทั้งคลังได้"* [6]

⇒ ประโยคสุดท้ายคือคำอธิบาย "lethal trifecta" ที่ดีที่สุดที่ผมเคยอ่าน ⇒ เพราะมันอธิบายว่าความเสี่ยง ไม่ได้อยู่ใน server ตัวใดตัวหนึ่ง แต่ อยู่ในช่องว่างระหว่าง server [6][9]

และ server ที่เพิ่ม tool ได้หลังเชื่อมต่อ

"SQLite เป็น server เดียวในการตรวจนี้ที่ประกาศ listChanged: true ⇒ **tool ใหม่โผล่ขึ้นมาได้หลัง handshake เริ่มต้น" [6]

⇒ นี่คือกลไกที่ทำให้ "rug pull" เป็นไปได้จริง ⇒ คุณตรวจ tool ตอนติดตั้ง แล้วมันเปลี่ยนทีหลังได้ [6]

และข้อสรุปเชิงโครงสร้างที่ผมคิดว่าแม่นที่สุด

"server เหล่านี้ไม่ได้พัง ส่วนใหญ่สร้างมาดี *ปัญหาอยู่ที่โปรโตคอล** ⇒ ไม่มีการยืนยันตัวตนระดับ tool คุณให้อำนาจทุก tool ที่ server เปิดในขั้นตอนเดียว ⇒ ไม่มีวิธีพูดว่า 'สกรีนช็อตได้ แต่ evaluate ไม่ได้' ⇒ ไม่มีมุมมองข้าม server ไม่มีอะไรเปิดเผยความเสี่ยงรวมของการรันหลาย server พร้อมกัน ⇒ ไม่มีประตูอนุมัติ destructiveHint มีอยู่ แต่ไม่มีอะไรบังคับใช้ ⇒ การวิเคราะห์เชิงสถิตบอกว่าอะไรเป็นไปได้ การบังคับใช้ตอนรันบอกว่าอะไรได้รับอนุญาต"* [6]

เจ็ด: "ไม่มีการยืนยันตัวตนระดับ tool" ⇒ ทำไมมันสำคัญกว่าที่คิด

ประโยค "คุณให้อำนาจทุก tool ที่ server เปิดในขั้นตอนเดียว" อธิบายข้อจำกัดเชิงออกแบบได้ดีที่สุด [6]

เทียบให้เห็นภาพ [6]

สิ่งที่อยากได้ "server นี้ถ่ายภาพได้ แต่อย่ารัน JavaScript"
 "server นี้ค้นหาได้ แต่อย่าลบ"
สิ่งที่ทำได้ "เชื่อม server นี้" ⇒ ได้ทุก tool ที่มันมี

⇒ ผลคือจำนวน tool ที่ server เปิด กลายเป็นการตัดสินใจด้านความปลอดภัย ไม่ได้เป็นแค่เรื่องโทเคน [6]

⇒ และนี่คือเหตุผลที่ "อย่าเปิด tool ที่ไม่ได้ใช้" ที่ผมเขียนไว้ในบทความก่อน เป็นคำแนะนำด้านความปลอดภัยด้วย ไม่ได้เป็นแค่การประหยัดโทเคน [6]

และมีข้อมูลที่ช่วยให้เห็นว่าเรื่องนี้แก้กันจริง ⇒ มีเครื่องมืออย่าง AgentWard ที่ทำหน้าที่เป็น proxy บังคับนโยบายตามสิทธิ์น้อยที่สุด แบบประเมินทุก tools/call ในโค้ด แทนที่จะฝากไว้กับ prompt [8][9]

"นโยบายถูกบังคับใช้ในโค้ด นอกหน้าต่าง context ของโมเดล ⇒ *โมเดลไม่เห็นมัน เอาชนะไม่ได้ และถูกหลอกให้เพิกเฉยไม่ได้*" [8]

⇒ ประโยคนี้ตอบโจทย์เรื่อง lethal trifecta โดยตรง เพราะปัญหาของ trifecta คือ คำสั่งใน prompt เอาชนะไม่ได้โดยการเขียนคำสั่งใน prompt อีกชั้น [8][9]

และมีแนวคิดที่ผมคิดว่าเฉียบ [8]

"AgentWard เอามือไปวางบนเตาแทน ⇒ การบังคับใช้ระดับโค้ดที่ prompt injection เอาชนะไม่ได้" [8]

และงานตรวจสอบของเครื่องมือนี้ตรวจ chain ที่น่าสนใจ ⇒ เช่น "persistence chain" ที่จับ server ที่รวมการเขียนไฟล์อำเภอใจเข้ากับการแก้ config ขณะรัน ⇒ "รูปแบบ backdoor แบบเขียนแล้วตั้งค่าใหม่ที่เป็นที่รู้จัก" และ REPL chain ที่จับ server ที่มีทั้ง tool เปิด interpreter และ tool ยิงคำสั่งเข้า stdin [8]

⇒ หลักที่ผมดึงออกมาคือ: ความเสี่ยงของ MCP เกือบทั้งหมดเป็นความเสี่ยงเชิงประกอบ ⇒ ไม่มี server ตัวไหนผิด แต่การอยู่ร่วมกันของมันสร้างเส้นทางที่ไม่มีใครเห็น [6][8]

แปด: กับดักที่คนส่วนใหญ่ไม่รู้ ⇒ reference server ถูก archive

นี่คือข้อเท็จจริงที่ผมคิดว่ามีค่ามากที่สุดสำหรับคนที่กำลังจะเลือก server [5]

ผมเปิด README ของ repo modelcontextprotocol/servers เอง แล้วพบหัวข้อ "Archived" ที่ระบุว่า "reference server ต่อไปนี้ถูก archive แล้ว และย้ายไปอยู่ที่ servers-archived" [5]

รายการที่ถูก archive มี 13 ตัว [5]

AWS KB Retrieval · Brave Search · EverArt · GitHub · GitLab
Google Drive · Google Maps · PostgreSQL · Puppeteer
Redis · Sentry · Slack · SQLite

⇒ และ README ระบุทางไปของบางตัวไว้ด้วย [5]

• Brave Search ⇒ "ถูกแทนที่ด้วย server ทางการ" ที่ดูแลโดย Brave เอง
• Slack ⇒ "ปัจจุบันดูแลโดย Zencoder" พร้อมลิงก์ไปยัง repo ของเขา

⇒ และผมตรวจ GitHub API ยืนยันเองว่า repo หลักยังไม่ถูก archive ⇒ มีดาว 90,415 และ commit ล่าสุด 3 กันยายน 2026 [5]

⇒ นี่คือความเข้าใจผิดที่ผมเกือบเขียนลงบทความ ⇒ ผมเข้าใจว่า ทั้ง repo ถูก archive แต่ที่จริงคือ reference server บางตัวถูกย้ายออกจาก repo หลัก และ repo หลักยังเดินหน้าต่อ [5]

⇒ และมันเชื่อมกับตัวเลข 125,000 ดาวน์โหลดต่อสัปดาห์ของ server GitHub ที่ถูก archive ⇒ คนจำนวนมากยังติดตั้ง server ที่ทีมผู้ดูแลย้ายออกไปแล้ว [1][5]

และ server GitHub ที่ควรใช้ตอนนี้คือ github/github-mcp-server ของ GitHub เอง ซึ่งผมตรวจแล้วว่ามีดาว 33,001 และ commit ล่าสุด 16 กันยายน 2026 [10]

เก้า: สรุปเป็นเช็กลิสต์เลือกและดูแล MCP server

หนึ่ง ⇒ อ่านตัวเลขโทเคนพร้อมวิธีวัดเสมอ ⇒ ถ้าไม่บอก tokenizer กับเวอร์ชัน ตัวเลขนั้นใช้ตัดสินใจไม่ได้ [1][2]

⇒ และมีงานวัดอีกชิ้นที่ยืนยันว่าปัญหานี้พบได้บ่อยแค่ไหน คือการวัด 137 tools จาก 11 server แล้วพบบัญชีข้อปรับปรุง schema ถึง 132 จุด เฉลี่ย 200 โทเคนต่อ tool โดย server GitHub ตัวเดียวครอง 69% ของโทเคนทั้งหมด ⇒ งานวัดนี้ระบุว่า tool ที่ใหญ่ที่สุดตัวเดียวใช้ 810 โทเคน มากกว่า server เล็กทั้งตัวบางตัว [7]

สอง ⇒ อย่าตัดสินจากจำนวน tool อย่างเดียว ⇒ Notion 24 tools หนักกว่า Playwright 24 tools ถึงสี่เท่าในงานวัดเดียวกัน ⇒ น้ำหนักอยู่ที่ความยาวของ schema ไม่ใช่จำนวน [1]

สาม ⇒ ตรวจว่า server ยังได้รับการดูแลหรือไม่ ⇒ เช็คหัวข้อ "Archived" ใน README และวัน commit ล่าสุด ⇒ อย่าเลือกจากลิสต์ยอดนิยม เพราะความนิยมเป็นสัญญาณที่ตามหลัง [1][5]

สี่ ⇒ ปิด tool ที่ไม่ใช้ ⇒ เพราะทุก tool มีทั้งค่าโทเคนและความเสี่ยง แม้ไม่ถูกเรียก [4][6]

ห้า ⇒ ระวังโทเคนตอนใช้ ไม่ใช่ตอนติดตั้ง ⇒ บน client ที่เลื่อนการโหลด ค่าใช้จ่ายมาถึงตอนเรียก ⇒ ติดตั้งน้อยกว่าที่คิดว่าจะรับไหว [1]

หก ⇒ ดูความเสี่ยงเชิงประกอบ ไม่ใช่ราย server ⇒ ตัวเลข 84 เส้นทางยกระดับสิทธิ์จาก 10 server เกิดจากการอยู่ร่วมกัน [6]

เจ็ด ⇒ อย่าฝากความปลอดภัยไว้กับ prompt ⇒ ถ้าต้องการเพดานสิทธิ์จริง มันต้องบังคับใช้ในโค้ด [8]

ข้อควรระวัง

หนึ่ง ตัวเลขโทเคนทุกตัวในบทความนี้เป็นการวัดของคนอื่น ⇒ ผมไม่ได้นับเอง ไม่ได้รัน server เหล่านี้ และไม่ได้ตรวจสอบ schema ด้วยตัวเอง

สอง สองงานวัดที่ผมใช้เป็นแกนใช้วิธีนับต่างกัน ⇒ งานวัดหนึ่งนับด้วย tokenizer จริง อีกงานประมาณที่ 4 ตัวอักษรต่อโทเคน ⇒ ผมแสดงทั้งสองตารางเพื่อให้เห็นความต่าง ไม่ได้เลือกข้าง

สาม 🔴 ตัวเลข Google Drive 47,293 โทเคนและยอดรวม 111,713 โทเคน ผมตั้งใจไม่ใช้เป็นตัวเลขหลัก ⇒ เพราะพบในบทความที่โปรโมตเครื่องมือของตัวเอง และ Google Drive reference server ถูก archive แล้ว ⇒ ผมเล่าเป็นบริบทพร้อมระบุที่มา ไม่ได้ยืนยันวิธีวัด

สี่ ตัวเลข blast radius 124 tools / 28 destructive / 84 เส้นทาง มาจากงานตรวจของผู้พัฒนาเครื่องมือความปลอดภัยรายหนึ่ง ⇒ เป็นการตรวจ 10 server ไม่ใช่ภาพรวมทั้งระบบนิเวศ ⇒ และผมไม่ได้เปิดผลตรวจดิบของเขา

ห้า ผมยังไม่ได้ทดสอบเครื่องมือบังคับใช้นโยบายที่กล่าวถึงในหัวข้อเจ็ด ⇒ ผมรายงานตามที่ผู้พัฒนาเครื่องมือระบุไว้ และไม่ยืนยันผลลัพธ์

หก การทดลอง "ถูกเลื่อนเวลา" เป็นผลของ client รุ่นเดียว ⇒ งานวัดระบุชัดว่าเป็น Claude Code 2.1.204 บน macOS วันที่ 9 สิงหาคม 2026 ⇒ client อื่นหรือรุ่นอื่นอาจโหลด schema ตอนเปิดเลย และงานวัดเองก็เตือนให้รันซ้ำกับ client ของตัวเอง

เจ็ด ผมตรวจสอบข้อเท็จจริงเรื่อง archive เองจาก README ต้นฉบับและ GitHub API ⇒ ส่วนข้อสรุปเรื่องอื่นมาจากบทวิเคราะห์ของผู้อื่น

แปด ข้อความในเครื่องหมายคำพูดที่ยกมาจากแหล่งภาษาอังกฤษเป็นคำแปลของผม ไม่ใช่สำเนาต้นฉบับ ⇒ ผมคงคำสำคัญที่เป็นศัพท์เทคนิคไว้เป็นภาษาอังกฤษ เพื่อให้ผู้อ่านตรวจเทียบกับต้นฉบับได้เอง

เก้า ผมทำงานบนระบบที่ใช้โมเดล AI และเขียนบทความนี้ด้วยความช่วยเหลือของ AI

เริ่มจากอะไรได้วันนี้

ถ้าคุณมี MCP server ต่ออยู่ในเครื่องแล้ว ⇒ ลองเปิดรายการ server ที่ใช้อยู่ แล้วถามสามข้อนี้

หนึ่ง ⇒ server ตัวนี้มี tool ที่ผมไม่ได้เรียกเดือนที่แล้วกี่ตัว
สอง ⇒ ในบรรดา server ที่ต่ออยู่ มีตัวใดอ่านข้อมูลภายนอกและมีตัวใดรันคำสั่งได้ ⇒ ถ้ามีทั้งสองอย่าง คุณมี lethal trifecta อยู่
สาม ⇒ server ตัวนี้ commit ล่าสุดเมื่อไร และยังอยู่ในหัวข้อ Archived ของ README หรือไม่

⇒ สามคำถามนี้ใช้เวลาไม่ถึงสิบนาที แต่จับปัญหาสามข้อที่แพงที่สุดในบทความนี้ [1][5][6]

ถ้าคุณอยากดูตัวอย่าง schema จริงก่อนตัดสินใจ ⇒ งานวัดที่ผมใช้เป็นแกนในบทความนี้มีตารางดิบที่รันซ้ำได้ และระบุแพ็กเกจพร้อมเวอร์ชันของทุกแถว ⇒ เปิดดูได้ที่ [2]

บทความในซีรีส์นี้

• ชั้นออกแบบ ⇒ MCP tool design: หลักออกแบบ tool ให้ agent เลือกถูกและไม่ทำอันตราย
• ชั้นทำให้พร้อมใช้จริง ⇒ สร้าง MCP server ให้พร้อม production: 7 เรื่องที่ tutorial ไม่บอก ⇒ อยู่ในซีรีส์เดียวกัน และผมจะเพิ่มลิงก์เมื่อบทความนั้นเผยแพร่

แหล่งอ้างอิง

[1] "The MCP tax: what each server costs before your first prompt" การวัดขนาด tool definition ของ server 10 ตัวด้วยการเชื่อม client จริง (Claude Code 2.1.204, macOS) วันที่ 9 ส.ค. 2026, Okaneland Research (ค.ศ. 2026), https://okaneland.com/study/the-mcp-context-tax/

[2] "MCP Server Token Weights, Measured" การวัด tools/list ของ server 7 ตัว นับด้วย tiktoken o200k_base วันที่ 9 มิ.ย. 2026, Port of Context (ค.ศ. 2026), https://portofcontext.com/token-calculator

[3] "I scanned 25 popular MCP servers: the hidden context-tax spans 544x" การวัด schema ของ 25 server โดยแยกตัวที่วัดได้จริงกับตัวที่ไม่ได้วัด, DEV Community (ค.ศ. 2026), https://dev.to/wartzarbee/i-scanned-25-popular-mcp-servers-the-hidden-context-tax-spans-544x-2fp6

[4] "I Benchmarked 10 MCP Servers: One of Them Burns 47K Tokens Just to Say Hello" การวัดด้วย tiktoken cl100k_base วันที่ 23 ส.ค. 2026 (ผู้เขียนเป็นผู้พัฒนาเครื่องมือลดโทเคนของตัวเอง ⇒ อ่านพร้อมข้อจำกัดนี้) ⚠️ ข้อเสนอ "31 tools → 4 ด้วย enum" อยู่ในคอมเมนต์ของผู้อ่าน Max Quimby ไม่ใช่เนื้อความผู้เขียน, DEV Community (ค.ศ. 2026), https://dev.to/mcptokensaver/i-benchmarked-10-mcp-servers-one-of-them-burns-47k-tokens-just-to-say-hello-7he

[5] "Model Context Protocol Servers" ไฟล์ README หัวข้อ Archived ระบุ reference server 13 ตัวที่ถูกย้ายไป servers-archived (ตรวจ GitHub API เมื่อ 17 ก.ย. 2026: repo หลักไม่ถูก archive ดาว 90,415, commit ล่าสุด 3 ก.ย. 2026), Model Context Protocol, https://github.com/modelcontextprotocol/servers

[6] "I Audited 10 Popular MCP Servers and Mapped Their Default Blast Radius" การแจกแจง 124 tools, 28 tool ที่ประกาศว่า destructive และ 84 เส้นทางยกระดับสิทธิ์, AgentWard (ค.ศ. 2026), https://agentward.ai/blog-mcp-audit.html

[7] "I Audited 11 MCP Servers. 22,945 Tokens Before a Single Message." การวัด 137 tools จาก 11 server และบัญชีข้อปรับปรุง schema 132 จุด, DEV Community (ค.ศ. 2026), https://dev.to/0coceo/i-audited-11-mcp-servers-22945-tokens-before-a-single-message-31e

[8] "agentward" เอกสารเครื่องมือบังคับใช้นโยบายสิทธิ์น้อยที่สุดสำหรับ agent รวมการตรวจจับ persistence chain และ REPL chain, AgentWard บน GitHub (ค.ศ. 2026), https://github.com/agentward-ai/agentward

[9] "mcp-audits" แพ็กเกจตรวจสอบ MCP server ทำ risk scoring 0–10 และจำแนกสิทธิ์หกหมวด (file_read, file_write, network, shell_execution, destructive, exfiltration), PyPI (ค.ศ. 2026), https://pypi.org/project/mcp-audits

[10] "github-mcp-server" MCP server ทางการของ GitHub (ตรวจ GitHub API เมื่อ 17 ก.ย. 2026: ดาว 33,001, commit ล่าสุด 16 ก.ย. 2026), GitHub (ค.ศ. 2026), https://github.com/github/github-mcp-server