MCP Server ของคุณไม่จำเป็นต้องมีถึง 40 เครื่องมือ

การสาธิต MCP มักจะแสดงทุกอย่างออกมาพร้อมกัน พวกเขาแสดงทุก endpoint และทุกตารางในฐานข้อมูล พร้อมทั้งอ้างว่า agent สามารถเรียกใช้งานอะไรก็ได้

สิ่งนี้อาจดูทรงพลังในช่วงสิบนาทีแรก แต่หลังจากนั้นโมเดลจะเริ่มทำงานผิดพลาด มันเรียกใช้เครื่องมือผิดตัว ส่ง argument ในรูปแบบที่ผิด ขอให้สร้างแผนภูมิจาก search endpoint หรือพยายามทำซ้ำการกระทำที่ส่งผลเสียต่อข้อมูล (destructive action)

ปัญหาไม่ได้อยู่ที่ MCP แต่ปัญหาคือการปฏิบัติกับ MCP เหมือนเป็นตัวแปลงอัจฉริยะ (magic adapter) สำหรับ backend ของคุณ

MCP server ไม่ใช่แค่การทำให้ API ของคุณเข้าถึงได้โดย agent เท่านั้น แต่มันคือส่วนติดต่อผู้ใช้งาน (product surface) สำหรับผู้ใช้งานที่ตีความตามตัวอักษรอย่างยิ่งและวอกแวกได้ง่ายมาก ซึ่งผู้ใช้งานคนนั้นก็คือโมเดลภาษา (language model)

หากคุณให้เครื่องมือที่คล้ายกันถึง 40 อย่างแก่โมเดล คุณไม่ได้มอบพลังให้มัน แต่คุณกำลังมอบโอกาส 40 ทางที่จะทำให้มัน "เกือบจะถูก"

เลิกทำเลียนแบบ (mirroring) API routes ของคุณเสียที มนุษย์สามารถอ่านเอกสารและเข้าใจบริบทได้ แต่โมเดลจะใช้วิธีจับคู่รูปแบบ (pattern-match) จากชื่อและคำอธิบาย

จงสร้าง MCP layer ของคุณโดยยึดตามความตั้งใจของผู้ใช้ (user intent)

แทนที่จะเลียนแบบทุก route ให้จัดกลุ่มพวกมันเข้าด้วยกันตามขอบเขตที่ชัดเจน:

  • หนึ่งเครื่องมือสำหรับสรุปภาวะตลาด (market summaries)
  • หนึ่งเครื่องมือสำหรับปฏิทินการประกาศข้อมูล (release calendars)
  • หนึ่งเครื่องมือสำหรับข้อมูลย้อนหลังเฉพาะจุด (specific data snapshots)
  • หนึ่งเครื่องมือสำหรับตัวบ่งชี้ทางประวัติศาสตร์ (historical indicators)

API route บอกว่า: หากคุณส่งคำขอนี้ เซิร์ฟเวอร์จะตอบกลับ แต่ MCP tool ควรบอกว่า: ใช้ฉันสำหรับงานนี้โดยเฉพาะ ด้วยข้อมูลนำเข้าเหล่านี้ และคาดหวังผลลัพธ์ที่เฉพาะเจาะจงนี้

คำอธิบายเครื่องมือที่ดีคือตรรกะในการกำหนดเส้นทาง (routing logic) ไม่ใช่คำโฆษณา (marketing copy)

แบบที่ไม่ดี: name: get_data description: ดึงข้อมูลจาก API

แบบที่ดีกว่า: name: lookup_release_calendar description: คืนค่าเหตุการณ์ทางเศรษฐกิจที่มีกำหนดการสำหรับหนึ่งสกุลเงินและช่วงวันที่ที่ระบุ ใช้เครื่องมือนี้ก่อนตอบคำถามเกี่ยวกับเหตุการณ์ทางเศรษฐกิจมหภาคที่กำลังจะเกิดขึ้น

ปฏิบัติตามกฎเหล่านี้เพื่อให้ได้ agent ที่ดีขึ้น:

  1. ใช้ชื่อที่เรียบง่าย (boring names) นักพัฒนาชอบชื่อที่สั้นกระชับอย่าง fetch หรือ query แต่โมเดลต้องการชื่อที่เฉพาะเจาะจงอย่าง search_docs หรือ check_deployment_status ชื่อที่กำกวมนั้นมีราคาแพง

  2. ควบคุมรูปแบบการตอบกลับ (response shape) อย่าส่งคืนออบเจกต์ที่ซ้อนกันขนาดใหญ่ (giant nested objects) ให้ส่งคืนข้อมูลในรูปแบบที่เล็กที่สุดที่เพียงพอต่อการทำงาน หากโมเดลเห็นข้อมูลมากเกินไป มันจะใช้ฟิลด์ผิดหรือสร้างรายละเอียดที่ไม่มีอยู่จริงขึ้นมา (hallucinate)

  3. ออกแบบเผื่อความล้มเหลว (design for failure) คุณภาพระดับโปรดักชัน (production quality) มาจากการจัดการข้อผิดพลาด อย่าเพียงแค่ส่งคืน error 500 หรืออาร์เรย์ว่างเปล่า แต่จงบอกโมเดลว่าทำไมมันถึงล้มเหลว หากไม่พบข้อมูลที่ตรงกัน ให้บอกโมเดลว่าควรแนะนำให้ผู้ใช้ขยายช่วงวันที่ให้กว้างขึ้น

เครื่องมือ agent ที่ดีที่สุดไม่ใช่เครื่องมือที่ทรงพลังที่สุด แต่คือเครื่องมือที่โมเดลไม่มีทางเข้าใจผิด

Source: https://dev.to/roberttidball/your-mcp-server-doesnt-need-40-tools-2ig1

Optional learning community: https://t.me/GyaanSetuAi