MCP Gateways: วิธีจัดการเซิร์ฟเวอร์ MCP หลายเครื่องในระบบขนาดใหญ่

สำหรับหลายคนในเรา การเริ่มต้นมักเริ่มจากเซิร์ฟเวอร์ MCP หนึ่งเครื่อง นักพัฒนาเชื่อมต่อ GitHub กับ Claude หรือ Cursor และมันก็ทำงานได้ จากนั้นมีผู้เพิ่ม Slack ตามมา แล้ว Jira และสุดท้ายคือฐานข้อมูลภายใน

หกเดือนต่อมา ผู้พัฒนาทุกคนมีไฟล์การตั้งค่า API keys และรายชื่อเซิร์ฟเวอร์ของตัวเอง

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

ส่วนที่น่ากลัวคือ: เมื่อเอเจนต์ทำสิ่งที่ไม่คาดคิด ก็ไม่มีบันทึกใดที่สามารถอธิบายได้ว่าเหตุใดมันจึงเกิดขึ้นตั้งแต่แรก

โทเค็นเป็นค่าใช้จ่ายอันดับสอง ทุกเซิร์ฟเวอร์ที่เชื่อมต่อจะโหลดนิยามเครื่องมือของตัวเองเข้าไปในหน้าต่างบริบท ในระบบที่มีเซิร์ฟเวอร์ 5 เครื่อง Anthropic วัดได้ประมาณ 55,000 โทเค็นของนิยามเครื่องมือก่อนที่เอเจนต์จะอ่านคำขอเพียงหนึ่งครั้ง

ดังนั้น การจัดการเซิร์ฟเวอร์ MCP หลายเครื่องจึงสรุปได้เป็นสองงานหลัก: การควบคุมการเข้าถึงในจุดเดียว และการรักษาให้รายชื่อเครื่องมือของเอเจนต์แต่ละตัวมีขนาดเล็ก MCP gateway จัดการงานแรกโดยค่าเริ่มต้น ส่วนงานที่สองจะจัดการก็ต่อเมื่อมีการกรองหรือค้นหาเครื่องมือเท่านั้น เรากำลังพิจารณา gateway ห้าตัวที่ควรประเมินค่าใช้จ่ายของแต่ละตัว และวิธีการนำ gateway หนึ่งตัวมาใช้งานโดยไม่ทำให้เอเจนต์ของคุณหยุดทำงาน

MCP Gateway คืออะไร?

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

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

การเลือกเครื่องมือและความปลอดภัยของเซิร์ฟเวอร์ยังคงขึ้นอยู่กับวิธีที่คุณกำหนดค่าการกรองและสิทธิ์ ซึ่งเราจะอธิบายในส่วนวิธีการใช้งานด้านล่าง

เกตเวย์ MCP แตกต่างจากรีจิสทรี, เกตเวย์ LLM หรือ API Gateway อย่างไร?

ทั้งสี่ตัวนี้ล้วนอยู่ระหว่างลูกค้ากับสิ่งที่ลูกค้าต้องการ ซึ่งนี่คือเหตุผลที่ทีมต่าง ๆ มักใช้พวกมันร่วมกัน

ความแตกต่างอยู่ที่ปริมาณการรับส่งข้อมูลที่แต่ละระบบจัดการ MCP gateway ตัดสินใจว่าเอเจนต์สามารถเรียกใช้เครื่องมือได้หรือไม่ ในขณะที่รีจิสทรีเพียงแจ้งให้ไคลเอนต์ทราบว่ามีเซิร์ฟเวอร์ใดบ้าง และไม่เคยส่งคำขอใดๆ ไปเลย LLM และ API gateways จัดการการรับส่งข้อมูลที่แตกต่างกัน: ระบบแรกเลือกว่าโมเดลใดจะตอบคำถาม และระบบหลังปกป้องการเรียก HTTP ปกติไปยังบริการของคุณ

ในความเป็นจริง เส้นแบ่งระหว่างทั้งสองนั้นไม่ชัดเจน ตัวอย่างเช่น เครื่องมืออย่าง Kong AI Gateway ส่งการรับส่งข้อมูล LLM และ MCP ผ่านชั้นควบคุมเดียว ส่วน ContextForge ทำงานร่วมกับรีจิสทรีควบคู่กับเกตเวย์ของมัน เมื่อเปรียบเทียบผลิตภัณฑ์ต่างๆ ให้ตรวจสอบว่าแต่ละผลิตภัณฑ์ครอบคลุมชั้นใดบ้าง

MCP Registry อย่างเป็นทางการเปิดตัวในเดือนกันยายน 2025 โดยได้รับการสนับสนุนจาก Anthropic, GitHub, PulseMCP และ Microsoft หนึ่งปีต่อมา มันยังคงอยู่ในช่วงทดลองใช้ ใช้มันเพื่อค้นหาเซิร์ฟเวอร์ แต่ควรเก็บรายชื่อเซิร์ฟเวอร์ที่ได้รับการอนุมัติไว้เอง

เกตเวย์ MCP ช่วยลดการใช้โทเค็นได้หรือไม่?

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

คุณจะประหยัดโทเคนได้ก็ต่อเมื่อเกตเวย์ซ่อนเครื่องมือที่งานนั้นไม่ต้องการ

ค่าใช้จ่ายเป็นเพียงครึ่งหนึ่งของปัญหา จุดล้มเหลวที่พบบ่อยคือเมื่อโมเดลเลือกเครื่องมือผิดหรือส่งพารามิเตอร์ผิด สิ่งนี้เกิดขึ้นโดยเฉพาะเมื่อชื่อเครื่องมือคล้ายกัน เช่น notification-send-user และ notification-send-channelเอกสารของ Anthropicระบุว่าประสิทธิภาพการเลือกเครื่องมือจะเริ่มลดลงเมื่อมีเครื่องมือที่ใช้งานได้มากกว่า 30 ถึง 50 ตัว และเซิร์ฟเวอร์เพียงไม่กี่เครื่องก็สามารถทำให้จำนวนเครื่องมือเกินขีดจำกัดนั้นได้ด้วยตัวเอง

วิธีแก้ไขที่ Anthropic แนะนำคือโหลดเครื่องมือค้นหาไว้ล่วงหน้า และดึงมาใช้เพียง 3 ถึง 5 เครื่องมือที่งานนั้นต้องการเท่านั้น ในการทดสอบกับเครื่องมือ MCP มากกว่า 50 ตัว ปริมาณบริบทรวมลดลงจากประมาณ 77,000 โทเคน เป็นประมาณ 8,700 โทเคน ซึ่ง Anthropic รายงานว่าเป็นการลดลง 85% ความแม่นยำในการประเมิน MCP ภายในบริษัทก็เพิ่มขึ้นเช่นกัน: Opus 4 เพิ่มขึ้นจาก 49% เป็น 74% เมื่อเปิดใช้งานการค้นหาเครื่องมือ และ Opus 4.5 เพิ่มขึ้นจาก 79.5% เป็น 88.1%

ผลการวิจัยของบริษัทเกี่ยวกับการทำงานของโค้ดด้วย MCPยังไปไกลกว่านั้น เมื่อเอเจนต์เรียกดูโฟลเดอร์ที่เก็บไฟล์เครื่องมือและอ่านเฉพาะคำนิยามที่จำเป็นเท่านั้น กระบวนการทำงานจาก Google Drive ไปยัง Salesforce หนึ่งกระบวนการจึงลดลงจาก 150,000 โทเค็นเหลือเพียง 2,000 โทเค็น แต่วิธีการนี้จำเป็นต้องมีสภาพแวดล้อมแบบแซนด์บ็อกซ์สำหรับโค้ดที่เอเจนต์เขียน ซึ่งถือเป็นค่าใช้จ่ายในการดำเนินงานของตัวเอง

เกตเวย์ให้คุณมีสองวิธีในการจัดการเรื่องนี้

วิธีแรกคือการตัดลดรายชื่อเครื่องมือด้วยมือ โปรไฟล์ของ Docker ช่วยให้คุณกำหนดรายชื่อเครื่องมือที่อนุญาตสำหรับแต่ละเซิร์ฟเวอร์ได้ ContextForge ใช้เซิร์ฟเวอร์เสมือนเพื่อเผยแพร่ชุดเครื่องมือที่คัดสรรมาอย่างพิถีพิถันจากหลายเซิร์ฟเวอร์ต้นทาง ส่วน Tool Router ของ Composio สามารถตรึงเซสชันไว้กับรายชื่อเครื่องมือที่กำหนดไว้ได้

ข้อที่สองคือการค้นหาขณะเรียกใช้ AgentCore Gateway มีเครื่องมือค้นหาเชิงความหมาย (semantic search) ที่ติดตั้งมาพร้อมตัว ซึ่งเอเจนต์สามารถส่งคำค้นหาด้วยภาษาธรรมดาได้ และ Composio ยังสามารถค้นหาเครื่องมือได้ขณะทำงาน

คำแนะนำของ Anthropic คือให้ดำเนินการเมื่อจำนวนคำนิยามเกิน 10,000 โทเค็น หรือเมื่อมีเครื่องมือ 10 ตัวขึ้นไป การตั้งค่าระบบอัตโนมัติของเวิร์กโฟลว์ AIส่วนใหญ่จะเกินขีดจำกัดนี้อย่างรวดเร็ว และเวิร์กโฟลว์แบบหลายเอเจนต์จะเกินขีดจำกัดนี้เร็วกว่า

เกตเวย์ MCP ที่ดีที่สุดคืออะไร?

มีผลิตภัณฑ์มากมายที่เรียกตัวเองว่าเป็น MCP gateway แต่บางตัวกลับคล้ายกับไดเรกทอรีของเซิร์ฟเวอร์มากกว่า รายการนี้เน้นเฉพาะเครื่องมือที่ทำงานอยู่ตรงกลางของระบบของคุณ เอเจนต์ของคุณจะเชื่อมต่อกับจุดปลายทางเดียว (endpoint) เกตเวย์จะเข้าถึงเซิร์ฟเวอร์ที่อยู่เบื้องหลัง และคุณจะมีสิทธิ์ควบคุมอย่างแท้จริงอย่างน้อยหนึ่งอย่างต่อข้อมูลที่ผ่านเข้ามา

การควบคุมดังกล่าวอาจเป็นการลงชื่อเข้าใช้ รายชื่อเครื่องมือที่ได้รับอนุญาต หรือบันทึกการตรวจสอบ

มี 5 ตัวที่ผ่านการคัดเลือกทั้งหมดนี้ แม้จะแก้ปัญหาเดียวกัน แต่ใช้วิธีที่แตกต่างกัน การเลือกตัวที่เหมาะสมที่สุดขึ้นอยู่กับสถานที่ที่เอเจนต์ของคุณกำลังทำงานอยู่: แล็ปท็อปของนักพัฒนา, โครงสร้างพื้นฐานของคุณเอง, การตั้งค่า Kong ที่มีอยู่, AWS หรือแอปพลิเคชัน SaaS

1. Docker MCP Gateway (เหมาะที่สุดสำหรับการพัฒนาในเครื่องบน Docker Desktop)

Docker MCP Gateway เป็นเครื่องยนต์โอเพนซอร์สที่อยู่เบื้องหลัง MCP Toolkit ใน Docker Desktop หากคุณใช้ Desktop อยู่แล้วและเปิดใช้งานชุดเครื่องมือนี้แล้ว เกตเวย์จะทำงานในพื้นหลังโดยไม่ต้องตั้งค่าเพิ่มเติม วิธีที่มันใช้เพื่อแก้ปัญหาการขยายตัวของเซิร์ฟเวอร์คือการใช้คอนเทนเนอร์ แต่ละเซิร์ฟเวอร์ MCP ทำงานในคอนเทนเนอร์ของตัวเองด้วยสิทธิ์การเข้าถึง เครือข่าย และทรัพยากรที่ถูกจำกัด และเกตเวย์จะเริ่มทำงานเซิร์ฟเวอร์นั้นเฉพาะเมื่อเอเจนต์ต้องการใช้เครื่องมือใดเครื่องมือหนึ่งของมันเท่านั้น

โปรไฟล์ช่วยรวมการตั้งค่าไว้ในที่เดียว โปรไฟล์จะจัดกลุ่มเซิร์ฟเวอร์ที่โครงการต้องการ และทุกไคลเอนต์ที่คุณเชื่อมต่อ ไม่ว่าจะเป็น Cursor, VS Code, Claude Desktop หรือ Claude Code จะใช้การตั้งค่าเดียวกันนั้น คุณสามารถส่งโปรไฟล์ไปยัง OCI registry เพื่อให้เพื่อนร่วมทีมดึงมาใช้ได้ ซึ่งช่วยแทนที่ไฟล์การตั้งค่า 15 ไฟล์ที่แก้ไขด้วยมือด้วยนิยามร่วมเพียงหนึ่งเดียว

ภายในโปรไฟล์ คุณสามารถเปิดใช้งานเครื่องมือแต่ละตัวได้ เช่น github.create_issue และปิดเครื่องมืออื่น ๆ บนเซิร์ฟเวอร์นั้นไว้ นั่นคือวิธีที่ Docker ใช้เพื่อรักษาให้รายชื่อเครื่องมือของโมเดลสั้นลง

ข้อมูลรับรองจะไม่ถูกเก็บไว้ในไฟล์การตั้งค่า เกตเวย์จะดึงข้อมูลลับจากที่เก็บข้อมูลลับของ Docker Desktop และเพิ่มข้อมูลเหล่านั้นเมื่อเริ่มต้นเซิร์ฟเวอร์ นอกจากนี้ยังจัดการการลงชื่อเข้าใช้ OAuth สำหรับเซิร์ฟเวอร์ที่ต้องการ ฟีเจอร์การบันทึกและติดตามการเรียกที่สร้างมาในตัวจะแสดงว่าเครื่องมือใดถูกเรียกใช้ เกตเวย์ทำหน้าที่เพียงส่งต่อการเรียกเท่านั้น ส่วนการประมวลผลจะเกิดขึ้นในเอเจนต์ AI ที่คุณใช้เพื่อการทำงานอัตโนมัติ เพื่อเริ่มต้นใช้งาน Docker MCP Catalog มีรายการเครื่องมือและบริการมากกว่า 200 รายการ

จุดที่ยังจำกัด: เกตเวย์นี้ถูกออกแบบมาสำหรับนักพัฒนาที่รันเซิร์ฟเวอร์บนเครื่องส่วนตัวของพวกเขาเอง เวอร์ชันการกำกับดูแล ซึ่งขายเป็นส่วนหนึ่งของ Docker AI Governance นั้นมีให้ใช้เฉพาะผู้ที่ได้รับคำเชิญจากทีมขายของ Docker เท่านั้น ดังนั้นคุณจึงไม่สามารถสมัครใช้การควบคุมนโยบายสำหรับทั้งทีมได้ด้วยตัวเอง คุณสามารถรันเกตเวย์นี้ได้โดยไม่ต้องใช้ Docker Desktop ผ่านการติดตั้งแบบแมนนวล แต่การจัดการข้อมูลลับยังคงต้องพึ่งพา Docker Desktop

ผู้ใช้จริงพูดอย่างไรเกี่ยวกับ Docker MCP Gateway

รีวิวจากผู้ใช้ระบุว่า:

เกตเวย์ MCP ของ Docker นั้นดีมากสำหรับการพัฒนาในท้องถิ่น – การแยกคอนเทนเนอร์ตามเซิร์ฟเวอร์ และการจัดการข้อมูลรับรองที่ถูกรวมไว้ใน Docker Desktop – แต่มันไม่ได้ถูกออกแบบมาเพื่อการกำกับดูแลระดับองค์กรที่ข้ามทีมและข้ามภูมิภาค

2. IBM ContextForge (เหมาะที่สุดสำหรับชุดเครื่องมือที่โฮสต์เองและใช้ตามทีม)

IBM ContextForge เป็นเกตเวย์และรีจิสทรีแบบโอเพนซอร์สที่คุณสามารถรันบนโครงสร้างพื้นฐานของคุณเองได้ มันรวมเซิร์ฟเวอร์ MCP บริการ agent-to-agent (A2A) และ API REST หรือ gRPC ทั่วไปไว้ภายใต้จุดสิ้นสุดเดียว คุณสามารถติดตั้งได้จาก PyPI รันเป็นคอนเทนเนอร์ หรือปรับใช้บน Kubernetes ด้วย Helm chart ของโครงการ

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

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

แต่ละเซิร์ฟเวอร์ต้นทางจะเก็บการตั้งค่า OAuth ของตัวเองไว้ และ ContextForge จะเก็บโทเค็นตามผู้ใช้ ดังนั้นเซิร์ฟเวอร์สองเครื่องจึงสามารถใช้ผู้ให้บริการระบุตัวตนที่แตกต่างกันได้ ส่วนหน้าผู้ใช้สำหรับผู้ดูแลระบบ (admin UI) มีเครื่องมือดูบันทึกแบบเรียลไทม์ และข้อมูลการติดตาม (traces) จะถูกส่งผ่าน OpenTelemetry ไปยังระบบแบ็กเอนด์ เช่น Jaeger, Zipkin และ Datadog นอกจากนี้ยังมีปลั๊กอินมากกว่า 40 ตัวที่เพิ่มวิธีการส่งข้อมูลและการผสานรวมเพิ่มเติม

จุดที่ยังต้องปรับปรุง: คุณต้องดำเนินการติดตั้ง ปรับปรุง และขยายระบบด้วยตัวเอง เกตเวย์จะไม่เริ่มทำงานจนกว่าคุณจะสร้างกุญแจลับที่ปลอดภัย โครงการนี้แนะนำให้ใช้ PostgreSQL สำหรับระบบผลิตจริง และการสนับสนุนให้บริการผ่าน GitHub issues และการอภิปราย

ผู้ใช้จริงพูดอย่างไรเกี่ยวกับ IBM ContextForge

รีวิวจากผู้ใช้ระบุว่า:

ได้รับใบอนุญาต Apache และถูกออกแบบมาสำหรับผู้ที่กำลังดำเนินการโครงสร้างพื้นฐาน Kubernetes ระดับมืออาชีพอยู่แล้ว มันได้พัฒนาจนกลายเป็นโซลูชันที่มีความสามารถอย่างแท้จริง — การกำกับดูแลและการเฝ้าติดตามที่แท้จริง รวมถึงความสามารถในการจัดการ MCP พร้อมกับ API อื่นๆ ของบริษัทคุณ อย่างไรก็ตาม การติดตั้งและตั้งค่านั้นซับซ้อนกว่าตัวเลือกที่มีขนาดเล็กกว่า ดังนั้นนี่ไม่ใช่โครงการที่สามารถทำเสร็จได้ภายในวันหยุดสุดสัปดาห์

3. Kong AI Gateway (เหมาะที่สุดสำหรับทีมที่กำลังใช้ Kong อยู่แล้ว)

Kong จัดการกับการรับส่งข้อมูล MCP เหมือนกับการรับส่งข้อมูล API ประเภทอื่น หากทีมของคุณกำลังใช้ Kong Gateway หรือ Kong Konnect อยู่แล้ว การสนับสนุน MCP จะมาในรูปแบบปลั๊กอินบนเกตเวย์ที่คุณกำลังใช้งานอยู่ และจะใช้ระบบการยืนยันตัวตน การจำกัดอัตรา และระบบบันทึกข้อมูลเดียวกันกับที่คุณใช้สำหรับ API ของคุณ

ส่วนสำคัญที่สุดคือปลั๊กอิน AI MCP Proxy ซึ่งสามารถติดตั้งอยู่ด้านหน้าเซิร์ฟเวอร์ MCP ที่คุณกำลังใช้งานอยู่ หรือแปลง API ใดก็ตามที่มีสคีมา OpenAPI ให้กลายเป็นเครื่องมือ MCP ได้โดยไม่ต้องเขียนโค้ดเพิ่มเติม คุณยังสามารถรวมเครื่องมือจาก API หลายตัวเข้าเป็นจุดปลายทาง MCP เดียว เพื่อให้เอเจนต์เชื่อมต่อเพียงครั้งเดียว แทนที่จะต้องเชื่อมต่อแต่ละครั้งสำหรับแต่ละบริการ

การควบคุมการเข้าถึงทำงานตามเครื่องมือแต่ละตัว คุณกำหนดรายชื่อที่อนุญาตและรายชื่อที่ถูกปฏิเสธตามผู้ใช้หรือกลุ่มผู้ใช้ และเมื่อเอเจนต์ขอรายชื่อเครื่องมือ Kong จะส่งคืนเฉพาะเครื่องมือที่ผู้เรียกนั้นสามารถใช้ได้เท่านั้น ทุกความพยายามที่ได้รับการอนุญาตหรือถูกปฏิเสธจะถูกบันทึกไว้ในบันทึกการตรวจสอบของปลั๊กอิน เนื่องจากเอเจนต์ไม่เคยโหลดเครื่องมือที่มันไม่สามารถเรียกได้ รายชื่อที่ถูกกรองจึงช่วยรักษาบริบทให้เล็กลงด้วย

กระบวนการลงชื่อเข้าใช้ดำเนินการผ่านปลั๊กอินการยืนยันตัวตนของ Kong ซึ่งรวมถึง OpenID Connect และปลั๊กอิน AI MCP OAuth2 บันทึกการรับส่งข้อมูล MCP จะบันทึก ID เซสชัน วิธีการ JSON-RPC ข้อมูลที่ส่ง ความล่าช้า และข้อผิดพลาด และคุณสามารถส่งข้อมูลติดตามไปยัง OpenTelemetry ได้ หากคุณยังกำหนดเส้นทางรับส่งข้อมูล LLM ผ่าน AI Gateway ของ Kong การรับส่งข้อมูลของโมเดลและเครื่องมือจะใช้ระนาบควบคุมเดียวกัน

จุดที่ยังไม่รองรับ: SSO และบันทึกการตรวจสอบแพลตฟอร์ม (audit logs) บน Konnect มีให้เฉพาะในเวอร์ชัน Enterprise เท่านั้น ปลั๊กอิน AI MCP Proxy ไม่รองรับ WebSocket หรือ gRPC upstreams และ AI guardrails ไม่ถูกนำไปใช้กับคำขอ MCP การแปลง REST จำเป็นต้องมี OpenAPI schema ที่ถูกต้องสำหรับแต่ละ API และ ACL ตามเครื่องมือ (per-tool ACLs) จำเป็นต้องใช้ Kong Gateway 3.13 หรือเวอร์ชันที่ใหม่กว่า การส่ง Ping จากลูกค้า MCP ยังถูกนับรวมในยอดรวมคำขอรายเดือนของคุณด้วย

ผู้ใช้จริงพูดอย่างไรเกี่ยวกับ Kong AI Gateway

รีวิวจากผู้ใช้ระบุว่า:

สิ่งนี้มีความสมเหตุสมผลหากคุณกำลังใช้ Kong อยู่แล้ว นี่ไม่ใช่แค่การเพิ่ม MCP เข้าไปอย่างผิวเผินอีกต่อไป แต่เป็นการสนับสนุนที่ออกแบบมาโดยเฉพาะ ซึ่งรวมถึงการรับส่งข้อมูลระหว่างเอเจนต์กับเอเจนต์ และเมื่อกลางเดือนกรกฎาคมที่ผ่านมา พวกเขาได้ร่วมมือกับบริษัทที่เชี่ยวชาญด้านการกำกับดูแลด้วย AI เพื่อผสานการตรวจสอบนโยบายเข้าไปในเกตเวย์โดยตรง อย่างไรก็ตาม คุณสมบัติบางอย่างที่ลึกซึ้งกว่าอาจจำเป็นต้องใช้แพ็กเกจแบบเสียค่าใช้จ่าย

4. Amazon Bedrock AgentCore Gateway (เหมาะที่สุดสำหรับเอเจนต์ที่ทำงานบน AWS)

Amazon Bedrock AgentCore Gateway เป็นตัวเลือกที่ AWS จัดการอย่างเต็มรูปแบบ ดังนั้นจึงไม่จำเป็นต้องโฮสต์หรือปรับขนาดอะไรทั้งสิ้น มันให้เอเจนต์มีจุดปลายทางเดียวสำหรับเครื่องมือของพวกเขา AgentCore ยังสามารถแปลงสเปก OpenAPI และ Smithy ฟังก์ชัน Lambda และเซิร์ฟเวอร์ MCP ที่มีอยู่ให้เป็นเครื่องมือ MCP ได้โดยไม่ต้องเขียนโค้ดเพิ่มเติม นอกจากนี้ยังรวมถึงการผสานรวมแบบคลิกเดียวสำหรับ Salesforce, Slack, Jira, Asana และ Zendesk

ฟังก์ชันการค้นหาเครื่องมือถูกสร้างไว้ในตัวระบบแล้ว หากเปิดใช้งานการค้นหาเชิงความหมาย (semantic search) เมื่อสร้างเกตเวย์ เอเจนต์จะได้รับเครื่องมือค้นหา (x_amz_bedrock_agentcore_search) ที่สามารถส่งคำสั่งค้นหาด้วยภาษาธรรมชาติได้ ด้วยวิธีนี้ เอเจนต์จะดึงเฉพาะเครื่องมือที่งานนั้นต้องการมาใช้ แทนที่จะโหลดแคตตาล็อกทั้งหมด ซึ่งเป็นรูปแบบตามความต้องการ (on-demand) เดียวกันกับที่ Anthropic อธิบาย แต่ทำงานที่เกตเวย์แทนที่จะทำงานในฝั่งไคลเอนต์

การตรวจสอบความถูกต้องทำงานได้ทั้งสองทาง เมื่อข้อมูลเข้ามา เกตเวย์จะตรวจสอบว่าใครเป็นผู้เรียกผ่าน AWS IAM หรือ JWT จากผู้ให้บริการอัตลักษณ์ของคุณ เมื่อข้อมูลออกไป เกตเวย์จะลงชื่อเข้าใช้กับแต่ละเครื่องมือด้วย OAuth, API key หรือ IAM role และเพิ่มข้อมูลรับรองเหล่านั้นด้วยตัวเอง ดังนั้นเอเจนต์จึงไม่จำเป็นต้องเก็บข้อมูลรับรองเหล่านั้นไว้ AgentCore Identity ไม่คิดค่าใช้จ่ายเพิ่มเติมเมื่อคุณใช้งานผ่านเกตเวย์ และ AgentCore Policy สามารถตรวจสอบการเรียกใช้แต่ละเครื่องมือตามกฎที่เขียนด้วย Cedar

เกตเวย์นี้ทำงานร่วมกับเฟรมเวิร์กโอเพนซอร์สต่าง ๆ รวมถึง CrewAI, LangGraph, LlamaIndex และ Strands Agents รวมถึงโมเดลใด ๆ ก็ตาม การอัปเดตในเดือนมิถุนายน 2026 ได้เพิ่มคำสั่งและทรัพยากร MCP การสตรีมและการจัดการเซสชัน การขอการอนุมัติระหว่างการทำงาน และการแลกเปลี่ยนโทเค็น OAuth แบบ on-behalf-of

จุดอ่อน: มันทำงานได้เฉพาะบน AWS เท่านั้น ดังนั้นคุณจึงไม่สามารถโฮสต์เองได้ การกำหนดราคาขึ้นอยู่กับปริมาณการใช้งานสำหรับบริการ AgentCore หลายอย่าง ซึ่งทำให้ค่าใช้จ่ายรายเดือนยากที่จะคาดการณ์ได้มากกว่าการจ่ายแบบค่าคงที่ ตามตัวอย่างของ AWS เอง เอเจนต์ที่จัดการการโต้ตอบ 50 ล้านครั้งต่อเดือน โดยแต่ละครั้งมีการค้นหา 1 ครั้งและเรียกใช้เครื่องมือ 4 ครั้ง มีค่าใช้จ่ายประมาณ $2,250 ต่อเดือน โดยการค้นหาคิดเป็นมากกว่าครึ่งหนึ่งของค่าใช้จ่ายนั้น การค้นหาเชิงความหมาย (Semantic search) มีให้บริการใน 18 AWS Regions แต่ละเกตเวย์รับเฉพาะเวอร์ชันโปรโตคอล MCP ที่คุณกำหนดไว้เท่านั้น และความสามารถในการสังเกตการณ์ (observability) ดำเนินการผ่าน CloudWatch ด้วยค่าใช้จ่ายแยกต่างหาก

ผู้ใช้จริงพูดอย่างไรเกี่ยวกับ Amazon Bedrock AgentCore Gateway

รีวิวจากผู้ใช้ระบุว่า:

ความซับซ้อนนี้เกิดจากหลายด้าน: 1) ผู้ใช้ต้องตั้งค่าข้อมูลรับรองและสภาพแวดล้อมของ AWS; 2) ผู้พัฒนาต้องเขียนและเพิ่มคำอธิบายให้กับโค้ดเอเจนต์อย่างครบถ้วนเพื่อใช้ AgentCore; และ 3) การจัดการบริบทต้องการโมเดลการเขียนโปรแกรมเฉพาะที่อาจไม่ทำงานได้กับทุกเฟรมเวิร์ก

5. Composio (เหมาะที่สุดสำหรับการเชื่อมต่อเอเจนต์กับแอป SaaS โดยไม่ต้องรันเซิร์ฟเวอร์)

Composio เป็นแพลตฟอร์มที่ได้รับการจัดการ ซึ่งเชื่อมต่อเอเจนต์กับแอปพลิเคชันมากกว่า 1,500 ตัว รวมถึง Gmail, Slack, GitHub, HubSpot และ Salesforce โดยไม่จำเป็นต้องจัดการเซิร์ฟเวอร์ใดๆ เอเจนต์หรือไคลเอนต์ AI ของคุณจะเชื่อมต่อกับ URL MCP เดียว และ Composio จะจัดการการลงชื่อเข้าใช้สำหรับแต่ละแอปพลิเคชัน ตั้งแต่กระบวนการ OAuth และกุญแจ API ไปจนถึงการรีเฟรชโทเค็น

งานส่วนใหญ่ของเกตเวย์เกิดขึ้นใน Tool Router คุณสร้างเซสชันสำหรับผู้ใช้แต่ละคนพร้อมชุดเครื่องมือที่พวกเขาต้องการ และ Composio จะส่งคืนจุดปลายทาง MCP ที่มีขอบเขตกำหนดไว้ ภายในเซสชัน คุณสามารถกำหนดรายการเครื่องมือที่แน่นอน ระงับเครื่องมือเฉพาะ หรือกรองตามคำชี้แนะของ MCP เช่น โหมดอ่านอย่างเดียว หรือโหมดทำลายได้ เครื่องมือยังสามารถค้นหาในแคตตาล็อกขณะทำงานและโหลดเฉพาะเครื่องมือที่งานนั้นต้องการ ซึ่งช่วยรักษาบริบทของเอเจนต์ให้เล็ก

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

มันทำงานร่วมกับ Claude, ChatGPT, Cursor, Claude Code และไคลเอนต์ MCP อื่นๆ รวมถึงเฟรมเวิร์กต่างๆ เช่น LangChain, LlamaIndex, CrewAI และ OpenAI Agents SDK สำหรับงานหลายขั้นตอน Composio ให้บริการรันไทม์ระยะไกลที่แต่ละการดำเนินการทำงานในแซนด์บ็อกซ์ที่แยกกัน บริษัทรายงานว่าผ่านการรับรอง SOC 2 Type II และ ISO 27001:2022

คุณสมบัติที่โดดเด่น

ราคา

คะแนน

จุดที่มันมีข้อจำกัด: เนื่องจากเป็นบริการที่จัดการโดยผู้ให้บริการ ดังนั้นการเรียกเครื่องมือของคุณและข้อมูลรับรองที่ผู้ใช้เก็บไว้จะผ่านระบบคลาวด์ของ Composio เว้นแต่คุณจะตั้งค่าการปรับใช้แบบ bring-your-own-cloud เมื่อคุณเชื่อมต่อผ่าน MCP ฮุคการเรียกเครื่องมือของ SDK และการเปลี่ยนแปลงสคีมาจะไม่ทำงาน และเครื่องมือที่กำหนดเองในโค้ดของคุณจะไม่สามารถใช้งานได้ที่จุดสิ้นสุด MCP ในเดือนพฤษภาคม 2026 Composioได้เปิดเผยเหตุการณ์ด้านความปลอดภัยที่ทำให้ข้อมูลการเชื่อมต่อที่ใช้งานอยู่ประมาณ 0.3% ถูกเปิดเผย ซึ่งส่วนใหญ่เป็น GitHub และจำเป็นต้องให้ลูกค้าเปลี่ยน API keys ของตนเอง ให้รวมรายงานนี้ไว้ในกระบวนการตรวจสอบความปลอดภัยของคุณ

ผู้ใช้จริงพูดอย่างไรเกี่ยวกับ Composio

รีวิวจากผู้ใช้ระบุว่า:

แพลตฟอร์ม MCP ที่ได้รับการจัดการพร้อมไลบรารีขนาดใหญ่ ซึ่งมีแอปกว่า 1,000 ตัว เช่น Gmail และ Slack ข้อได้เปรียบหลักคือคุณไม่จำเป็นต้องสร้างและดูแลการบูรณาการทุกตัวด้วยตัวเอง นอกจากนี้ Composio ยังสนับสนุนการโฮสต์เองใน VPC และ SDK แบบฝังตัว เพื่อตัวเลือกการปรับใช้ที่ยืดหยุ่น

MCP Gateway มีราคาเท่าไร?

ราคาขึ้นอยู่กับว่าคุณจะจ่ายตามการใช้งานแบบจัดการโดยผู้ให้บริการ หรือจัดการโครงสร้างพื้นฐานด้วยตัวเอง

เกตเวย์แบบโอเพนซอร์สไม่มีค่าลิขสิทธิ์ แต่คุณยังต้องจ่ายค่าโฮสติ้ง การบำรุงรักษา และความปลอดภัย ส่วนเกตเวย์แบบจัดการจะมีค่าใช้จ่ายสำหรับการเรียกใช้เครื่องมือ การค้นหา แผนควบคุม หรือการใช้งานอื่นๆ

เกตเวย์ใดมีค่าใช้จ่ายน้อยกว่าขึ้นอยู่กับสิ่งที่คุณกำลังใช้งานอยู่ Composio และ Amazon Bedrock AgentCore Gateway โอนงานด้านโครงสร้างพื้นฐานไปให้ผู้จำหน่ายมากขึ้น และคิดค่าบริการตามการใช้งาน Docker MCP Gateway และ IBM ContextForge ไม่มีค่าลิขสิทธิ์ แต่คุณต้องรับผิดชอบค่าใช้จ่ายในการโฮสต์และดูแลรักษาเอง ส่วน Kong จะมีความคุ้มค่าทางการเงินมากที่สุดเมื่อทีมของคุณกำลังใช้งาน Kong อยู่แล้ว เพราะการนำมันมาใช้เฉพาะสำหรับ MCP จะเพิ่มแพลตฟอร์มใหม่และค่าใช้จ่ายด้านลิขสิทธิ์

วิธีเลือก MCP Gateway

ราคาอาจช่วยจำกัดรายชื่อตัวเลือก แต่แทบไม่เคยเป็นตัวกำหนดการตัดสินใจให้คุณ

จุดเริ่มต้นที่ดีกว่าคือปัญหาที่ทำให้คุณมาค้นหาข้อมูลนี้ ทีมส่วนใหญ่มาพร้อมกับปัญหาหนึ่งในสองอย่างต่อไปนี้: พวกเขาไม่สามารถเห็นหรือควบคุมได้ว่าใครเรียกใช้เครื่องมือใด หรือเอเจนต์ของพวกเขาโหลดนิยามเครื่องมือมากเกินไปจนเริ่มเลือกเครื่องมือที่ผิด บางทีมมีทั้งสองปัญหา

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

เริ่มจากจุดที่เอเจนต์ของคุณกำลังทำงานอยู่แล้ว

เกตเวย์ทั้งห้าในคู่มือนี้ล้วนมีคุณสมบัติพื้นฐานที่คล้ายกัน ดังนั้นปัจจัยหลักในการตัดสินใจมักขึ้นอยู่กับสแต็กที่คุณมีอยู่แล้ว

หากเอเจนต์ของคุณทำงานส่วนใหญ่ภายในแอป SaaS ในนามของผู้ใช้แต่ละคน Composio จะช่วยลดงานได้มากที่สุด เพราะมันจัดการการเชื่อมต่อ OAuth ของผู้ใช้แต่ละคนให้คุณ ข้อแลกเปลี่ยนคือข้อมูลรับรองเหล่านั้นถูกเก็บไว้ในคลาวด์ของ Composio ซึ่งทีมความปลอดภัยของคุณอาจต้องการตรวจสอบ

สำหรับทีมที่ประสบปัญหากับกระบวนการทำงานที่ขาดความเชื่อมโยงและกระจายอยู่บนแล็ปท็อปของนักพัฒนา Docker MCP Gateway คือขั้นตอนแรกที่เหมาะสมที่สุด มันเหมาะสำหรับทีมที่ใช้ Docker Desktop อยู่แล้ว ทำงานบนเซิร์ฟเวอร์แต่ละเครื่องในคอนเทนเนอร์ของตัวเอง และให้ทั้งทีมสามารถใช้โปรไฟล์เดียวกันได้ หากในภายหลังคุณต้องการระบบการกำกับดูแลระดับทีม คุณจะต้องติดต่อฝ่ายขายของ Docker เพื่อหารือเพิ่มเติม

ทีมแพลตฟอร์มที่ชอบจัดการโครงสร้างพื้นฐานด้วยตนเองจะนิยมใช้ IBM ContextForge เซิร์ฟเวอร์เสมือนของมันให้แต่ละทีมมีชุดเครื่องมือของตัวเอง และสามารถแปลงบริการ REST และ gRPC ภายในองค์กรให้เป็นเครื่องมือ MCP ได้ นอกจากนี้ คุณยังต้องรับผิดชอบงานการอัปเดตแพตช์ การปรับขนาด และงานเวรที่ตามมาจากการโฮสต์ด้วยตนเอง

Kong AI Gateway นำการรับส่งข้อมูล MCP เข้ามาอยู่ภายใต้นโยบายเดียวกันที่ทีมของคุณกำลังใช้กับ API อยู่แล้ว หากคุณต้องการ SSO หรือบันทึกการตรวจสอบแพลตฟอร์ม ให้จัดงบประมาณสำหรับเวอร์ชัน Enterprise เพราะทั้งสองคุณสมบัตินี้มีเฉพาะในเวอร์ชัน Enterprise เท่านั้น

สำหรับทีมที่พัฒนาบน AWS Amazon Bedrock AgentCore Gateway ช่วยจัดการทุกอย่างอย่างเป็นระบบ และเพิ่มฟังก์ชันการค้นหาเครื่องมือแบบเซมานติกที่เกตเวย์ ควรสร้างแบบจำลองการคิดค่าบริการตามการใช้งานตั้งแต่เนิ่นๆ เพราะการเรียกค้นหา การเรียกเครื่องมือ และ CloudWatch จะถูกคิดค่าบริการแยกกัน

หากคุณกำลังดำเนินการเซิร์ฟเวอร์ที่เสถียรจำนวนไม่มากสำหรับทีมขนาดเล็ก คุณอาจยังไม่จำเป็นต้องใช้เกตเวย์ การใช้การตั้งค่าที่แชร์กันในระบบควบคุมเวอร์ชัน ร่วมกับเครื่องมือจัดการข้อมูลลับ (secrets manager) ก็สามารถตอบโจทย์ได้จนกว่าคุณจะต้องการสิทธิ์การเข้าถึงตามทีมหรือบันทึกเหตุการณ์แบบรวมศูนย์

คุณควรตรวจสอบอะไรก่อนที่จะ commit?

เมื่อมีตัวเลือกที่โดดเด่นแล้ว ให้ทดสอบกับระบบของคุณเองก่อนที่จะลงนามในสัญญาใดๆ หน้าคุณสมบัติมักข้ามรายละเอียดที่สำคัญในภายหลัง ดังนั้นควรหารือคำถามเฉพาะบางข้อกับผู้รับผิดชอบด้านความปลอดภัยและแพลตฟอร์มของคุณ:

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

ทำอย่างไรเพื่อย้ายเซิร์ฟเวอร์ MCP ที่มีอยู่ไปยังเกตเวย์?

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

เริ่มต้นด้วยการตรวจสอบระบบ

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

จัดกลุ่มเซิร์ฟเวอร์ตามขอบเขตความเชื่อถือ

จัดวางเซิร์ฟเวอร์ที่อ่านข้อมูลส่วนตัว เซิร์ฟเวอร์ที่จัดการเนื้อหาที่ไม่เชื่อถือได้ และเซิร์ฟเวอร์ที่สามารถส่งข้อมูลออกไปยังภายนอก ในชุดเครื่องมือที่แยกกัน เพื่อให้เอเจนต์เดียวไม่เคยถือทั้งสามอย่างพร้อมกัน การรวมตัวนี้คือสิ่งที่ทำให้การสาธิตการฉีดคำสั่ง (prompt-injection) ของ MCP บน GitHubโดย Invariant Labs เป็นไปได้ นอกจากนี้ ให้ตรวจสอบว่าเซิร์ฟเวอร์แต่ละเครื่องยังคงได้รับการดูแลรักษาอยู่หรือไม่ เซิร์ฟเวอร์อ้างอิง MCP ดั้งเดิมหลายเครื่อง รวมถึง GitHub และ Slack ปัจจุบันอยู่ในคลังเก็บและไม่ได้รับการอัปเดตอีกต่อไป

เมื่อกลุ่มต่าง ๆ ถูกจัดตั้งเรียบร้อยแล้ว ให้ดำเนินการทดลองใช้งานแบบสั้น

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

มีกฎหนึ่งข้อที่บังคับใช้กับเกตเวย์ใดก็ตามที่คุณเลือก ข้อกำหนด MCPห้ามการส่งต่อโทเค็น (token passthrough) เกตเวย์ควรรับเฉพาะโทเค็นที่ออกให้สำหรับเกตเวย์นั้นเท่านั้น และควรเรียกเซิร์ฟเวอร์ปลายทางด้วยข้อมูลรับรองที่ได้รับการอนุญาตแยกต่างหาก แทนที่จะส่งต่อโทเค็นของลูกค้า ตรวจสอบให้แน่ใจว่าการตั้งค่าเกตเวย์ของคุณปฏิบัติตามกฎนี้ก่อนที่จะย้ายการจราจรในสภาพแวดล้อมการผลิต

ClickUp ทำงานร่วมกับ MCP Gateway อย่างไร?

ClickUp เชื่อมต่อกับ MCP จากทั้งสองด้านของเกตเวย์

แอปพลิเคชัน AI นอก ClickUp เช่น Claude, Cursor และ ChatGPT จะเข้าถึงพื้นที่ทำงานของคุณผ่านเซิร์ฟเวอร์ MCP ของ ClickUp ซึ่งตั้งอยู่เบื้องหลังเกตเวย์ของคุณเหมือนเซิร์ฟเวอร์อื่น ๆ ภายใน ClickUpSuper AgentsและBrain²สามารถใช้เครื่องมือจากเซิร์ฟเวอร์ MCP ภายนอกที่คุณเชื่อมต่อได้ และเกตเวย์ของคุณสามารถเป็นหนึ่งในนั้นได้

วางเซิร์ฟเวอร์ ClickUp MCP ไว้ด้านหลังเกตเวย์ของคุณ

เซิร์ฟเวอร์ ClickUp MCPทำงานที่ https://mcp.clickup.com/mcp และสามารถใช้งานได้ในทุกแพ็กเกจ รวมถึง Free Forever ด้วย มันรับเฉพาะ OAuth เท่านั้น ดังนั้นเกตเวย์ของคุณจึงไม่จำเป็นต้องเก็บกุญแจ API ส่วนตัวหรือเปลี่ยนกุญแจเมื่อมีผู้ใช้ลาออก หากคุณกำลังพัฒนาไคลเอนต์ของตัวเอง มันต้องสนับสนุน OAuth 2.1 พร้อม PKCE ClickUp เก็บรายชื่ออนุญาต (allowlist) ของไคลเอนต์ที่ได้รับการอนุมัติ ดังนั้น ไคลเอนต์ใดที่ไม่อยู่ในรายชื่อนี้ ต้องส่งมาเพื่อตรวจสอบก่อน

เมื่อเชื่อมต่อแล้ว ตัวแทนของคุณสามารถสร้างและกำหนดเส้นทางงาน สร้างการอัปเดตสถานะจากงานและเอกสาร บันทึกเวลา ค้นหางาน เอกสาร และความคิดเห็น รวมถึงสรุปหัวข้อสนทนาใน Chat ได้ ด้วยวิธีนี้ ตัวแทนสามารถค้นหาบริบทของโครงการได้โดยตรง โดยไม่จำเป็นต้องคัดลอกและวางลงในทุกคำสั่ง

การจำกัดจำนวนคำขอควรได้รับการพิจารณาอย่างละเอียดยิ่งขึ้นเมื่อใช้ผ่านเกตเวย์ การจำกัดนี้ครอบคลุมพื้นที่ทำงานทั้งหมดของคุณ และทุกไคลเอนต์ที่เชื่อมต่อจะใช้โควตาที่แบ่งปันร่วมกันเดียวกัน หากไม่มีส่วนเสริม Everything AI ClickUp จะจำกัดจำนวนคำขอ MCP ต่อช่วงเวลา 24 ชั่วโมงแบบหมุนเวียน ตั้งแต่ 100 สำหรับแผน Free Forever ไปจนถึง 5,000 สำหรับแผน Enterprise

เมื่อใช้ add-on นี้ คำขอ MCP จะถูกจำกัดตามขีดจำกัดต่อนาทีของ API สาธารณะ ซึ่งอยู่ในช่วงตั้งแต่ 100 คำขอต่อนาทีสำหรับแผน Free Forever, Unlimited และ Business ไปจนถึง 10,000 คำขอต่อนาทีสำหรับแผน Enterprise ClickUp ยังไม่แสดงข้อมูลการใช้งาน MCP หากมีหลายทีมเข้าถึง ClickUp ผ่านเกตเวย์เดียว ให้ตั้งขีดจำกัดต่อทีมที่เกตเวย์ เพื่อป้องกันไม่ให้เอเจนต์ที่มีงานมากใช้โควตาจนหมดสำหรับทุกคน

เชื่อมต่อ Super Agents กับเซิร์ฟเวอร์ MCP ของคุณ

ในทางกลับกัน คุณสามารถเชื่อมต่อเซิร์ฟเวอร์ MCP ภายนอกจากClickUp App Center ได้ ทั้งสำหรับพื้นที่ทำงานทั้งหมด หรือเฉพาะสำหรับตัวคุณเอง ผู้ดูแลระบบจะกำหนดว่าใครสามารถเพิ่มแต่ละประเภทการเชื่อมต่อได้ หลังจากเชื่อมต่อเซิร์ฟเวอร์แล้ว คุณสามารถเลือกว่า Super Agent แต่ละตัวจะได้รับเครื่องมือใดจากเซิร์ฟเวอร์นั้น: ทั้งหมด หรือเฉพาะบางเครื่องมือเท่านั้น นี่คือแนวคิดเดียวกันกับการตัดลดรายการเครื่องมือที่กล่าวถึงก่อนหน้านี้ในคู่มือนี้ ซึ่งนำมาใช้กับเอเจนต์ภายในพื้นที่ทำงานของคุณ

หากเซิร์ฟเวอร์ที่คุณเชื่อมต่อเป็นเกตเวย์ของคุณ ให้ตรวจสอบรายละเอียดสองข้อก่อน ClickUp เชื่อมต่อจากที่อยู่ IP บนคลาวด์ที่เปลี่ยนแปลงได้ ดังนั้นรายชื่อ IP ที่อนุญาตจะไม่ให้มันผ่านได้ เกตเวย์ของคุณยังต้องมี URL สาธารณะที่ได้รับการรักษาความปลอดภัยด้วย OAuth หรือกุญแจ API บันทึกการตรวจสอบพื้นที่ทำงานของ ClickUp จะบันทึกว่าใครได้เชื่อมต่อ อัปเดต หรือตัดการเชื่อมต่อกับเซิร์ฟเวอร์ สำหรับบันทึกว่าเอเจนต์แต่ละตัวได้เรียกใช้เครื่องมือใดบ้าง คุณจะต้องใช้บันทึกของเกตเวย์ของคุณ

ติดตามการเปิดตัวใน ClickUp

ขั้นตอนการตรวจสอบและทดสอบนำร่องข้างต้นก่อให้เกิดการตัดสินใจเล็กๆ น้อยๆ จำนวนมาก ซึ่งอาจทำให้ติดตามได้ยาก ให้เพิ่มเซิร์ฟเวอร์แต่ละเครื่องเป็นงานใน List พร้อมด้วย Custom Fields สำหรับเจ้าของ การเข้าถึงข้อมูล กลุ่มความเชื่อถือ และค่าใช้จ่ายของโทเค็น จากนั้นเขียนเกณฑ์การย้อนกลับไว้ใน Doc ที่เชื่อมโยงกับงานการย้ายข้อมูลแต่ละงาน หากการทดสอบนำร่องล้มเหลวหรือเซิร์ฟเวอร์ต้นทางถูกเก็บเข้าคลังข้อมูล เจ้าของและประวัติทั้งหมดจะอยู่ในที่เดียว

เลือกเกตเวย์ที่เหมาะกับปัญหาของคุณ

ทุกส่วนในคู่มือนี้จะกลับมาสู่สองหน้าที่หลักเดียวกัน

หน้าที่แรกคือการควบคุม: จุดปลายทางเดียว, ที่เก็บข้อมูลรับรองเดียว, และบันทึกเดียวว่าเอเจนต์ใดเรียกใช้เครื่องมือใด ทั้งห้าเกตเวย์ในคู่มือนี้ล้วนครอบคลุมจุดนี้ในรูปแบบต่าง ๆ และความแตกต่างหลักอยู่ที่ระดับที่คุณต้องจัดการโครงสร้างพื้นฐานด้วยตัวเอง หน้าที่ที่สองคือการรักษาให้รายชื่อเครื่องมือของเอเจนต์แต่ละตัวมีขนาดเล็ก และเกตเวย์จะช่วยได้ก็ต่อเมื่อคุณตั้งค่าการกรองหรือการค้นหาเท่านั้น

ก่อนที่จะลงนามในเอกสารใดๆ ให้ตรวจสอบเครื่องมือที่คุณใช้อยู่ และวัดจำนวนโทเค็นที่คำนิยามของเครื่องมือเหล่านั้นใช้

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

คำถามที่มักถูกถามเกี่ยวกับ MCP Gateways

เกตเวย์ MCP ใดที่ดีที่สุด?

เกตเวย์ MCP ที่ดีที่สุดขึ้นอยู่กับสถานที่ที่เอเจนต์ของคุณกำลังทำงานอยู่ Docker MCP Gateway เหมาะสำหรับการพัฒนาในเครื่อง IBM ContextForge เหมาะสำหรับทีมที่ต้องการโฮสต์เอง Kong AI Gateway เหมาะสำหรับทีมที่ใช้ Kong อยู่แล้ว และ Amazon Bedrock AgentCore Gateway เหมาะสำหรับเอเจนต์บน AWS Composio เหมาะสำหรับเอเจนต์ที่ทำงานข้ามแอปพลิเคชัน SaaS หลายตัว สำหรับอุตสาหกรรมที่อยู่ภายใต้การกำกับดูแล ให้มองหาตัวเลือกการโฮสต์เองหรือการปรับใช้แบบส่วนตัว การควบคุมการเข้าถึงตามเครื่องมือแต่ละตัว และบันทึกการเรียกใช้เครื่องมือแต่ละตัว

MCP เป็น API gateway หรือไม่?

ไม่ครับ Model Context Protocol (MCP) เป็นมาตรฐานที่กำหนดวิธีที่แอปพลิเคชัน AI เชื่อมต่อกับเครื่องมือและข้อมูล ส่วน MCP gateway เป็นซอฟต์แวร์ที่พัฒนาขึ้นตามมาตรฐานดังกล่าว มันทำงานอยู่ระหว่างเอเจนต์และเซิร์ฟเวอร์ MCP และจัดการเรื่องการเข้าถึง ข้อมูลรับรอง และการบันทึกข้อมูล มันทำงานคล้ายกับ HTTP และ API gateway: HTTP กำหนดกฎเกณฑ์สำหรับคำขอ ส่วน gateway จะตัดสินใจว่าคำขอใดจะได้รับการอนุญาต

คุณต้องการเกตเวย์ MCP หรือไม่?

คุณจำเป็นต้องใช้ MCP gateway หากต้องการควบคุมว่าใครสามารถเรียกใช้เครื่องมือใดบนเซิร์ฟเวอร์หลายเครื่อง หรือเก็บข้อมูลกลางเกี่ยวกับกิจกรรมของเอเจนต์ หากทีมขนาดเล็กดำเนินการเซิร์ฟเวอร์จำนวนน้อยที่เสถียร การใช้การตั้งค่าที่แชร์ในระบบควบคุมเวอร์ชันร่วมกับเครื่องมือจัดการข้อมูลลับ (secrets manager) ก็สามารถตอบโจทย์ได้เกือบทั้งหมดแล้ว Gateway จะเริ่มให้ประโยชน์เมื่อคุณต้องการการเข้าถึงเครื่องมือตามทีม หรือต้องการจุดเดียวเพื่อจัดการข้อมูลรับรอง

เซิร์ฟเวอร์ MCP ปลอดภัยหรือไม่เมื่ออยู่หลังเกตเวย์?

เกตเวย์ช่วยให้การรักษาความปลอดภัยของเซิร์ฟเวอร์ MCP ง่ายขึ้น แต่ตัวมันเองไม่ได้ทำให้เซิร์ฟเวอร์ปลอดภัย มันเก็บข้อมูลรับรองไว้ในที่เดียว จำกัดเครื่องมือที่ผู้เรียกแต่ละคนสามารถใช้ได้ และบันทึกการเรียกใช้แบบรวมศูนย์ การฉีดคำสั่งแบบ Prompt injection ยังสามารถเข้ามาได้ผ่านเซิร์ฟเวอร์ที่เชื่อถือได้ เช่นที่ Invariant Labs ได้แสดงให้เห็นกับเซิร์ฟเวอร์ MCP ของ GitHub เครื่องมือที่อ่านข้อมูลส่วนตัว จัดการเนื้อหาที่ไม่น่าเชื่อถือ หรือส่งข้อมูลออกไป ควรถูกเก็บไว้ในชุดเครื่องมือที่แยกต่างหาก ต้องมั่นใจว่าเกตเวย์จะไม่ส่งต่อโทเค็นของลูกค้าไปไหนทั้งสิ้น และหยุดใช้เซิร์ฟเวอร์ที่ไม่ได้รับการอัปเดตอีกต่อไป

การค้นหาเครื่องมือสามารถแทนที่การควบคุมการเข้าถึงได้หรือไม่?

ไม่ใช่ การค้นหาเครื่องมือจะกำหนดว่าเอเจนต์จะเห็นเครื่องมือใดสำหรับงานหนึ่ง ส่วนการควบคุมการเข้าถึงจะกำหนดว่าเอเจนต์นั้นได้รับอนุญาตให้เรียกใช้เครื่องมือเหล่านั้นหรือไม่ ตัวอย่างเช่น Amazon Bedrock AgentCore Gateway จัดการการค้นหาเชิงความหมายและการยืนยันตัวตนเป็นคุณสมบัติที่แยกกัน ให้ดำเนินการค้นหาเฉพาะในเครื่องมือที่ผู้เรียกได้รับอนุญาตให้ใช้ และตรวจสอบสิทธิ์อีกครั้งเมื่อเครื่องมือนั้นทำงานจริง หากการซ่อนเครื่องมือจากการค้นหาเป็นวิธีการป้องกันเพียงอย่างเดียว เครื่องมือนั้นก็ไม่ได้รับการป้องกัน

บันทึกการตรวจสอบของ MCP gateway ควรบันทึกข้อมูลอะไร?

บันทึกการตรวจสอบของ MCP gateway ควรบันทึกว่าใครเป็นผู้เรียกใช้แต่ละครั้ง, ตัวแทนและเครื่องมือใดที่เกี่ยวข้อง, เซิร์ฟเวอร์ใดที่จัดการคำเรียกนั้น, คำเรียกนั้นได้รับการอนุญาตหรือถูกปฏิเสธ, เวลาที่เหตุการณ์เกิดขึ้น, และผลลัพธ์ที่ได้รับกลับมา ตัวอย่างเช่น ปลั๊กอิน AI MCP Proxy ของ Kong จะบันทึกทุกความพยายามเข้าถึงเครื่องมือที่ได้รับการอนุญาตและถูกปฏิเสธ ก่อนที่จะซื้อ ให้ตรวจสอบให้แน่ใจว่าบันทึกดังกล่าวครอบคลุมการเรียกใช้เครื่องมือแต่ละรายการ ไม่ใช่เพียงการเปลี่ยนแปลงบัญชีและการตั้งค่าเท่านั้น จากนั้นตรวจสอบระยะเวลาที่บันทึกถูกเก็บรักษาไว้ และว่าคุณสามารถส่งออกบันทึกเหล่านั้นได้หรือไม่