เราสร้าง 126 MCP Tools. แต่ไม่ใช่วิธีที่ดีที่สุดสำหรับ Agent

นี่เป็นซีรีส์ 10 ตอนที่แชร์ว่า Apidog พัฒนา Apidog CLI เครื่องมือ command-line สำหรับการทดสอบ API และการจัดการวงจรชีวิต API อ่านตามลำดับหรือข้ามไปบทความที่คุณสนใจ:

เมื่อ MCP กลายเป็นจุดสนใจของอุตสาหกรรม เราสร้าง MCP Server สมบูรณ์พร้อม 126 tools ที่สร้างอัตโนมัติ นี่คือสิ่งที่ผิดพลาด—และทำไมการมี tools มากขึ้นไม่ได้หมายความว่า Agent enablement ดีขึ้น

กระแส MCP

ในต้นปี 2025 MCP (Model Context Protocol) กลายเป็นจุดศูนย์กลางของอุตสาหกรรม

Anthropic สนับสนุนโปรโตคอลนี้ Cursor, Claude Code, Antigravity, Agent IDE ต่างๆ และผลิตภัณฑ์ SaaS มากมายต่างก็ตามมา โปรโตคอลนี้สัญญาว่าจะเป็นวิธีมาตรฐานสำหรับ AI Agent ในการเชื่อมต่อกับเครื่องมือภายนอกและแหล่งข้อมูล

ในช่วงนั้น ผลิตภัณฑ์ที่มี API เกือบทุกตัวถูกถามคำถามเดียวกัน:

"คุณมี MCP ไหม?"

สำหรับ Apidog ทางเลือกนี้ดูเป็นไปตามธรรมชาติเป็นพิเศษ

ทำไม MCP ดูเหมือนจะเป็นคำตอบ

Apidog เองได้สะสมความสามารถในการพัฒนา API อย่างครบถ้วน:

• เอกสาร API
• Schema definitions
• Mock servers
• Test cases
• Test scenarios
• Test suites
• Test reports
• เวิร์กโฟลว์ Import/export
• การทำงานร่วมกันบน Branch
• และอีกมากมาย

หาก Agent จะกลายเป็นจุดเริ่มต้นซอฟต์แวร์ใหม่—วิธีใหม่ที่ผู้ใช้โต้ตอบกับผลิตภัณฑ์—การเปิดเผยความสามารถเหล่านี้ผ่าน MCP ดูเหมือนจะเป็นตั๋วที่จำเป็นต้องมี

เราเชื่อว่าถ้าเราสามารถแพ็กเกจความสามารถของเราเป็น MCP tools Agent จะสามารถ:

• ค้นหาเอกสาร API
• สร้าง test cases
• รัน test scenarios
• Import/export ข้อมูลโปรเจกต์
• จัดการ environments และ variables
• ทำงานร่วมกันข้าม branches

ตรรกะนั้นตรงไปตรงมา: เปิดเผยความสามารถมากขึ้น = เปิดใช้งาน Agent มากขึ้น

สิ่งที่เราสร้างจริงๆ

เราไม่ได้ทำเรื่องนี้แบบเบาๆ

Apidog MCP ไม่ใช่ demo ง่ายๆ ที่มี endpoint ไม่กี่ตัวเขียนด้วยมือ แต่เป็น MCP Server ที่สมบูรณ์:

ระบบ Session

MCP client จะเริ่มต้น session ก่อน เซิร์ฟเวอร์จะสร้าง sessionId และบันทึกสถานะ session ผ่าน Redis คำขอที่ตามมาจะเข้าถักษ์ด้วย sessionId

กล่าวอีกนัยหนึ่ง มันไม่ใช่ HTTP call ครั้งเดียว แต่เป็น ระบบ session ระดับโปรโตคอล

หมวดหมู่เครื่องมือ

ชั้นเครื่องมือก็ไม่ได้เขียนด้วยมือด้วย endpoints ที่ตายตัวไม่กี่ตัว เราแบ่งเครื่องมือของ Apidog เป็นหลายหมวดหมู่:

หมวดหมู่สุดท้าย: 126 เครื่องมือที่สร้างขึ้น

แต่ละเครื่องมือที่สร้างมี:

• Identifier เฉพาะ
• API path เฉพาะ
• HTTP method (GET, POST, PUT, DELETE, ฯลฯ)
• Input Schema ที่สมบูรณ์พร้อมคำอธิบาย field, types, และ enum values
• โครงสร้าง return ที่กำหนดไว้

Progressive Disclosure

เพื่อลดแรงกดดันจากการเปิดเผยเครื่องมือ เรายังสร้าง dynamic discovery layer:

Agent สามารถ:

1. ค้นหา endpoint tools ที่มีก่อน (listOpenApiEndpoints)
2. จากนั้นรับรายละเอียด OpenAPI ของเครื่องมือเฉพาะ (getOpenApiDetails)
3. สุดท้ายเรียกใช้ HTTP call จริงโดย tool id (executeOpenApi)

นี่คือความพยายามของเราในการเปิดเผยแบบลำดับชั้น เราไม่ได้เปิดเผย endpoints พื้นฐานทั้งหมดโดยตรงและชัดเจน เราหวังว่า Agent จะค้นหาก่อน จากนั้นรับรายละเอียด และสุดท้ายจึงเรียกใช้

กำแพงเครื่องมือสุ่ม

แต่เมื่อเข้าสู่งานจริง ปัญหาเกิดขึ้นอย่างรวดเร็ว

ลองพิจารณาคำขอผู้ใช้ง่ายๆ:

"ช่วยฉันเพิ่ม test สำหรับ endpoint นี้และรันการตรวจสอบ"

จากมุมมองการนำไปปฏิบัติ นี่เป็นคำขอที่สมเหตุสมผล Apidog มีความสามารถที่จะ:

• ค้นหา endpoints
• สร้าง test cases
• รัน test scenarios
• สร้าง reports

แต่จากมุมมองของ Agent คำของ่ายๆ นี้จริงๆ แล้วกระตุ้นชุดของการตัดสินใจอย่างต่อเนื่อง:

Agent ไม่เพียงแต่ต้องหาเครื่องมือที่ถูกต้อง แต่ต้องแก้ปัญหา "จะใช้เครื่องมือไหน" ก่อน จึงจะเริ่มแก้ปัญหาของผู้ใช้ได้

จากมุมมองการนำไปปฏิบัติ ปัญหาเหล่านี้สามารถแก้ไขได้ทั้งหมดผ่านเครื่องมือ จากมุมมองประสบการณ์ของ Agent พวกมันก่อตัวเป็นกำแพงของเครื่องมือสุ่ม

สี่ปัญหาโครงสร้าง

ผ่านการทดสอบในโลกจริงและข้อเสนอแนะภายใน เราระบุปัญหาโครงสร้างสี่ประการกับแนวทาง MCP

ปัญหาที่ 1: ต้นทุนการค้นพบเครื่องมือเพิ่มขึ้นอย่างรวดเร็ว

Apidog ไม่ใช่ผลิตภัณฑ์ที่สามารถอธิบายด้วย endpoints เพียงไม่กี่โหล

เมื่อเครื่องมือเติบโตจากไม่กี่โหลเป็น หลายสิบหรือหลายร้อย Agent ต้องแก้ปัญหา "จะใช้เครื่องมือไหน" ก่อนจึงจะเริ่มแก้ปัญหาของผู้ใช้ได้

เราลองเขียนเวิร์กโฟลว์ลงใน description ของเครื่องมือ (field ที่ใช้เปิดเผยเครื่องมือให้ AI Agent) ตัวอย่างเช่น description ของเครื่องมือจะระบุอย่างชัดเจนว่า:

"ก่อนค้นหาข้อมูล endpoint คุณต้องยืนยันโปรเจกต์ผ่านเครื่องมืออื่นก่อน จากนั้นรับ metadata ของโปรเจกต์ผ่านเครื่องมือที่สาม และสุดท้ายเรียกเครื่องมือปัจจุบัน"

วิธีนี้ใช้ได้ในชุดเครื่องมือขนาดเล็ก แต่ในกำแพงเครื่องมือขนาดใหญ่ description เองแย่งความสนใจของโมเดล

ยิ่งเราเขียนคำแนะนำใน descriptions มากเท่าไหร่ ยิ่งกิน tokens มากขึ้น—และโอกาสที่ Agent จะอ่านและปฏิบัติตามก็น้อยลง

ปัญหาที่ 2: Business Schema บุกรุก Context

แต่ละ MCP tool ไม่ใช่แค่ชื่อเครื่องมือ

หลังแต่ละเครื่องมือคือ:

• description (เครื่องมือทำอะไร)
• input schema (parameters, types, required/optional)
• คำอธิบาย fields (โครงสร้างซ้อน, constraints)
• Enum values (ตัวเลือกที่อนุญาต)
• โครงสร้าง return (response format, error handling)

ลองประเมินแบบอนุรักษ์นิยม:

คำถามของผู้ใช้อาจมีเพียง 50 ตัวอักษร แต่โมเดลถูกบังคับให้แนะนำคำอธิบายเครื่องมือ 50,000 tokens ก่อน—เพียงเพื่อ MCP server เดียว

นี่ไม่ใช่ทฤษฎี ข้อมูลอุตสาหกรรมสนับสนุนสิ่งนี้

บทความบล็อกอย่างเป็นทางการของ Cursor "Dynamic Context Discovery" ให้ข้อมูลอ้างอิงที่มีค่า: โดยการแปลง MCP tool descriptions, terminal sessions, และบทสนทนายาวให้เป็น context ที่โหลดตามความต้องการ การใช้ tokens ระหว่างรันไทม์ลดลง 46.9%

แนวทางของ Trae ตรงไปตรงมากกว่า: จำกัดจำนวนเครื่องมือ MCP และความยาวคำอธิบายเครื่องมือเดียว:

• ขีดจำกัดจำนวนเครื่องมือ: 40
• ขีดจำกัดความยาวคำอธิบายเครื่องมือเดียว: 8000 ตัวอักษร

อันที่จริง ในระหว่างการทดสอบภายในช่วงแรก หลายทีมรายงานว่า Apidog MCP มีปัญหากับเครื่องมือบางตัวที่ไม่สามารถเรียกใช้ใน Trae ได้ Agent ถูกบังคับให้แลกเปลี่ยนเนื่องจาก context ของโมเดลที่จำกัด และเครื่องมือภายนอกเป็นสิ่งแรกที่ถูก "ตัดออก"

โซลูชันเหล่านี้ทั้งหมดชี้ไปที่ความจริงเดียวกัน:

คำอธิบายเครื่องมือไม่สามารถเข้าสู่ context ของโมเดลได้อย่างไม่จำกัด

ปัญหาที่ 3: Protocol Sessions ทำให้ Execution Chains หนักขึ้น

Apidog MCP server ต้องจัดการ:

สำหรับการเรียกเครื่องมือง่ายๆ ต้นทุนเหล่านี้ยอมรับได้ สำหรับงาน Agent ที่มี จำนวนการเรียกมากและการสำรวจบ่อย ข้อกำหนดการจัดการสถานะเหล่านี้เพิ่มความซับซ้อนทั้งฝั่งเซิร์ฟเวอร์และ client

เมื่อนำ Apidog MCP ไปใช้ ทีมใช้พลังงานอย่างมากในการแก้ไขปัญหาและปรับตัวให้เข้ากับ Agent clients ต่างๆ (Cursor, Claude Code, Antigravity, Trae, ฯลฯ) อย่างไรก็ตาม ปัญหาความเข้ากันได้ของโปรโตคอลยังคงมีอยู่ และโปรโตคอล MCP อย่างเป็นทางการยังคงถูกแพตช์ด้วยเวอร์ชันใหม่

ทุกฝ่ายได้รับความเดือดร้อนอย่างมาก

ปัญหาที่ 4: Atomic Tools ไม่สามารถแสดง Product Semantics ได้อย่างเป็นธรรมชาติ

ใน test scenarios ของ Apidog ไม่ใช่แค่การแสดงออกของ steps array ง่ายๆ

Test scenario หนึ่งเกี่ยวข้องกับ:

หลังจากแยกส่วนเหล่านี้เป็น MCP tools หลายตัว Agent ยังคงต้องทำ งาน orchestration test ด้วยตัวเอง

ยิ่งเครื่องมือเป็น atomic มากเท่าไหร่ โมเดลยิ่งต้องเข้าใจ product semantics ภายในมากขึ้น:

• ทำไม import ต้องมี read-back?
• ทำไม internal cases มี update markers ที่แตกต่าง?
• ทำไม assertions ต้องการ comparators เฉพาะ?
• ทำไม variable extraction มี type constraints?

นี่เห็นได้ชัดว่าเกินขอบเขตความสามารถของโมเดล

มันบังคับให้ทีม Apidog ปรับปรุงวิศวกรรมเทคนิคอย่างชัดเจนสำหรับ product semantics ภายใน Atomic endpoints เพิ่ม conversion layer อย่างไม่พอใจ เพียงเพื่อปรับให้เข้ากับการส่งเดี่ยวของ MCP tool layer

ความท้าทายทางวิศวกรรมและต้นทุนการบำรุงรักษาภายหลังไม่ต้องสงสัยว่ายากลำบาก

สาเหตุหลัก

สาเหตุหลักของปัญหาทั้งสี่นี้คือสิ่งเดียวกัน:

MCP ถนัดในการเชื่อมต่อเครื่องมือ แต่งาน R&D ที่ซับซ้อนต้องการมากกว่าการเชื่อมต่อเครื่องมือ—พวกมันต้องการกระบวนการวิศวกรรมที่เรียกใช้ได้

สำหรับผลิตภัณฑ์ง่ายๆ ที่มีการดำเนินการที่กำหนดไว้ดีไม่กี่โหล MCP ทำงานได้ดี Agent สามารถคาดเดาเครื่องมือที่ถูกต้องได้อย่างสมเหตุสมผล เรียกใช้ และรับผลลัพธ์

สำหรับผลิตภัณฑ์เช่น Apidog—ที่มีโมดูลหลายสิบ, การดำเนินการหลายร้อย, โครงสร้างซ้อน, เวิร์กโฟลว์ที่ซ่อนอยู่, และ product semantics เฉพาะ—MCP เพียงอย่างเดียวสร้าง กำแพงเครื่องมือสุ่ม ที่ Agent ต้องดิ้นรนเพื่อนำทาง

สิ่งที่เราเรียนรู้

การเปลี่ยนแปลง

ความเข้าใจนี้ทำให้เราตั้งคำถามที่แตกต่าง:

ถ้า MCP ไม่ใช่คำตอบสำหรับการเปิดใช้งาน agent แล้วอะไรคือคำตอบ?

เราไม่ได้ละทิ้งคุณค่าของ MCP—มันให้การเชื่อมต่อมาตรฐาน ซึ่งสำคัญสำหรับระบบนิเวศ แต่เราต้องการบางอย่างที่สามารถ:

• แสดงเวิร์กโฟลว์ ไม่ใช่แค่เครื่องมือ
• ชี้นำ Agent ผ่านลำดับ
• ตรวจสอบก่อนเขียน
• บังคับใช้ quality gates ทางวิศวกรรม
• ดูดซับความซับซ้อนเข้าสู่ระบบ

คำตอบที่เรามาถึง: CLI + SKILL

ในโพสต์ถัดไป ทำไมเราถึงย้ายจาก MCP Server ไป CLI Runtime เราจะสำรวจการเปลี่ยนแปลงทางสถาปัตยกรรม—ที่ความซับซ้อนย้ายจาก context ของโมเดลไปสู่ระบบวิศวกรรม และทำไมสิ่งนั้นเปลี่ยนแปลงทุกอย่างสำหรับการเปิดใช้งาน Agent

ประเด็นสำคัญ

• MCP กลายเป็นคำตอบของอุตสาหกรรมสำหรับ "Agent เชื่อมต่อกับเครื่องมืออย่างไร"
• เราสร้าง MCP tools 126 ตัว คิดว่าเครื่องมือมากขึ้น = เปิดใช้งานดีขึ้น
• งานจริงเปิดเผยปัญหาโครงสร้างสี่ประการ: ต้นทุนการค้นพบ, การบุกรุก context, session overhead, product semantics
• สาเหตุหลัก: MCP เชื่อมต่อเครื่องมือ แต่งานที่ซับซ้อนต้องการกระบวนการที่เรียกใช้ได้
• เครื่องมือมากขึ้นคือต้นทุน ไม่ใช่ประโยชน์ เมื่อคำอธิบายเครื่องมือกิน context

ดาวน์โหลด Apidog design, mock, test, และ document APIs ใน workspace เดียว. เรียนรู้เพิ่มเติมเกี่ยวกับ Apidog CLI สำหรับการทดสอบ API ผ่าน command-line, CI automation, และเวิร์กโฟลว์ AI Agent