MCP: ข้อบกพร่องและศักยภาพที่ต้องพิจารณา

การรับภาระหน้าที่เกินจำเป็นของ MCP

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

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

ท้ายที่สุดแล้ว ข้อกังวลหลายประการที่เกิดขึ้นเป็นปัญหาที่กว้างกว่าที่เกี่ยวข้องกับการมอบหมายงานให้กับ AI Agent นักพัฒนาต้องรับผิดชอบในการจัดการความท้าทายเหล่านี้ภายในแอปพลิเคชันเฉพาะของตนเอง แทนที่จะคาดหวังว่า API จะจัดการทุกอย่าง

ดาบสองคมของ LLM และการแทรกคำสั่ง

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

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

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

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

ความท้าทายในการปรับขนาด

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

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

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

ปัญหาหลักของ MCP คือพฤติกรรมที่แท้จริงของมันเบี่ยงเบนไปจากความคาดหวังของผู้ใช้ สิ่งสำคัญคือต้องตระหนักว่า MCP ไม่ใช่โซลูชันแบบ Plug-and-Play ที่รวมเครื่องมือจำนวนไม่จำกัดได้อย่างราบรื่นโดยไม่มีผลกระทบ

การจัดการข้อจำกัดด้วย UI และการจัดการเครื่องมือ

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

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

เพื่อจัดการกับตัวเลือกเครื่องมือที่ท่วมท้น มีการเสนอแนวทาง ‘แบ่งแยกและเอาชนะ’ ซึ่งเกี่ยวข้องกับการเพิ่มเครื่องมือที่ออกแบบมาโดยเฉพาะสำหรับการเลือกเครื่องมือที่เกี่ยวข้องมากที่สุดสำหรับงานที่กำหนด ‘เครื่องมือเลือกเครื่องมือ’ นี้อาจเป็นการเรียก LLM อีกครั้ง โดยมีหน้าที่ในการส่งคืนชุดย่อยของเครื่องมือที่มีให้ไปยัง Agent ‘หลัก’ แนวทางแบบแบ่งชั้นนี้เพิ่มระดับของการอ้างอิงทางอ้อมเป็นพิเศษเพื่อจัดการกับความซับซ้อน

อย่างไรก็ตาม เพียงแค่มีเครื่องมือในบริบทก็สามารถเปลี่ยนเอาต์พุตของโมเดลได้อย่างมาก ในขณะที่เครื่องมือที่เกี่ยวข้องกับบริบท (ทำได้ผ่านเทคนิคต่างๆ เช่น Retrieval-Augmented Generation หรือ RAG) เป็นประโยชน์ การซ่อนเครื่องมือทั้งหมดไว้เบื้องหลังคำขอ ‘get_tools’ อาจเป็นอันตรายได้

MCP ในฐานะเลเยอร์การขนส่งและการอนุญาต

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

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

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

ความง่ายในการเปิดเผยข้อมูลที่ละเอียดอ่อน

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

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

การเปรียบเทียบและการวางผังเมือง

ผู้เขียนใช้การเปรียบเทียบการวางผังเมืองเพื่อแสดงให้เห็นปัญหา การเปรียบเทียบ MCP กับถนนในเมืองหกเลนที่มีความเร็วจำกัด 25 ไมล์ต่อชั่วโมง เน้นให้เห็นถึงความไม่สอดคล้องกันระหว่างการออกแบบและการใช้งานที่ตั้งใจไว้ การกำหนดค่าปรับหรือการเพิ่ม ‘การแก้ไข’ ผิวเผินอย่างง่ายๆ ไม่ได้แก้ไขปัญหาพื้นฐานของการออกแบบที่ไม่ดี

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

LLM ทำการกระทำที่ไม่พึงประสงค์

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

แม้ว่าเป้าหมายสูงสุดอาจเป็นการให้ LLM จัดการธุรกิจทั้งหมด แต่เทคโนโลยียังไม่พร้อมสำหรับความเป็นอิสระดังกล่าว ปัจจุบันผู้ใช้อาจไม่ต้องการให้ AI ส่งอีเมลโดยไม่ต้องตรวจสอบก่อนด้วยซ้ำ

ผู้เขียนปฏิเสธแนวทางแก้ไขในการแจ้งให้ผู้ใช้ยืนยัน โดยอ้างถึงความเสี่ยงที่ผู้ใช้จะตกอยู่ในรูปแบบของการยืนยันอัตโนมัติ (‘โหมด YOLO’) เมื่อเครื่องมือส่วนใหญ่ดูเหมือนจะไม่เป็นอันตราย สิ่งนี้เปรียบได้กับปรากฏการณ์ทางจิตวิทยาที่ผู้คนใช้จ่ายมากขึ้นด้วยบัตรมากกว่าเงินสด ซึ่งเป็นปัญหาที่มีรากฐานมาจากพฤติกรรมของมนุษย์ ไม่ใช่เทคโนโลยี

คำถามพื้นฐาน: ทำไมไม่ใช้แค่ API?

คำถามที่เกิดขึ้นซ้ำๆ ในการอภิปรายเกี่ยวกับ MCP คือทำไมไม่ใช้แค่ API โดยตรง

MCP อนุญาตให้ไคลเอนต์ LLM ที่ผู้ใช้ไม่ได้ควบคุมโดยตรง (เช่น Claude, ChatGPT, Cursor, VSCode) โต้ตอบกับ API หากไม่มี MCP นักพัฒนาจะต้องสร้างไคลเอนต์แบบกำหนดเองโดยใช้ LLM API ซึ่งเป็นสิ่งที่ต้องใช้ค่าใช้จ่ายมากกว่าการใช้ไคลเอนต์ที่มีอยู่กับการสมัครสมาชิกและสอนวิธีใช้เครื่องมือเฉพาะ

นักพัฒนาคนหนึ่งแบ่งปันประสบการณ์ในการสร้างเซิร์ฟเวอร์ MCP เพื่อเชื่อมต่อกับเครื่องสังเคราะห์ FM ฮาร์ดแวร์ของตนผ่าน USB ซึ่งเปิดใช้งานการออกแบบเสียงที่ขับเคลื่อนด้วย AI

การรวมไคลเอนต์ LLM และการสร้างมาตรฐาน

ปัญหาหลักคือไม่ใช่ไคลเอนต์ LLM ทั้งหมดที่รองรับการโต้ตอบ API โดยตรง โดยที่การกระทำ ChatGPT custom GPT เป็นข้อยกเว้นที่โดดเด่น Anthropic, Google และ OpenAI ได้ตกลงที่จะนำ MCP มาใช้เป็นโปรโตคอลที่ใช้ร่วมกันเพื่อปรับปรุงกระบวนการสำหรับไคลเอนต์ที่ขับเคลื่อนด้วย LLM เช่น Claude, ChatGPT และ Cursor

MCP ช่วยลดความซับซ้อนของกระบวนการสำหรับผู้ที่สร้างไคลเอนต์ LLM หากคุณต้องการให้ LLM โต้ตอบกับ API คุณไม่สามารถให้คีย์ API ได้อย่างง่ายๆ และคาดหวังให้มันทำงานได้ คุณต้องสร้าง Agent

MCP สามารถมองได้ว่าเป็นวิธีในการจัดทำเอกสาร API และอธิบายวิธีเรียกใช้ พร้อมด้วยเครื่องมือมาตรฐานเพื่อเปิดเผยเอกสารประกอบนั้นและอำนวยความสะดวกในการโทร มันให้ความนามธรรมเพียงพอที่จะห่อหุ้ม API โดยไม่มีความซับซ้อนที่ไม่จำเป็น แต่ความเรียบง่ายนี้ยังสามารถนำไปสู่การที่ผู้ใช้ ‘ยิงตัวเองที่เท้า’ ได้

ประสิทธิภาพและความสามารถในการนำกลับมาใช้ใหม่ของ MCP

หากไม่มี MCP นักพัฒนาจะต้องอธิบายซ้ำๆ ให้ LLM ทราบวิธีใช้เครื่องมือทุกครั้งที่เรียกใช้ สิ่งนี้มีความเสี่ยงที่ LLM จะไม่สามารถใช้เครื่องมือได้อย่างถูกต้องเนื่องจากข้อมูลที่ลืมเลือนหรือพฤติกรรม API ที่ไม่ได้มาตรฐาน

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

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

MCP และการเข้าถึงทรัพยากรในเครื่อง

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

‘รูปร่าง’ การเรียกเครื่องมือ LLM มาตรฐานคล้ายกับ ‘รูปร่าง’ การเรียกเครื่องมือ MCP อย่างใกล้ชิด ทำให้เป็นมาตรฐานที่ไม่ซับซ้อนสำหรับการเชื่อมต่อเครื่องมือกับ Agent

MCP ทำหน้าที่เป็นสะพานเชื่อมระหว่าง Schema การเรียกฟังก์ชันที่เปิดเผยให้กับโมเดล AI และ API ที่อยู่เบื้องหลัง มันแปลการเรียกฟังก์ชันเป็นเครื่องมือ ทำให้การสื่อสารเป็นไปอย่างราบรื่น

หากคุณเป็นผู้ให้บริการเครื่องมือ MCP นำเสนอโปรโตคอลมาตรฐานสำหรับส่วนหน้าของ AI Agent เพื่อเชื่อมต่อกับเครื่องมือของคุณ นี่คือคำตอบสำหรับคำถามที่ว่าทำไมโปรโตคอลมาตรฐานไม่สามารถเป็น HTTP และ OpenAPI ได้อย่างง่ายๆ

MCP เป็น Meta-API ที่รวม Endpoints และรายละเอียดการดำเนินงานไว้ในข้อกำหนด ทำให้ LLM สามารถโต้ตอบกับ Endpoints ได้อย่างมีประสิทธิภาพมากขึ้น

MCP ในสถานการณ์เฉพาะ

MCP สามารถแก้ปัญหาได้เมื่อผู้ใช้ถามคำถามหรือไม่แน่ใจว่าจะใช้ API ใด นอกจากนี้ยังสามารถประมวลผลคำขอตามข้อความก่อนหน้าได้

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

MCP เปรียบได้กับเฟรมเวิร์กแอปเว็บ FastAPI สำหรับการสร้างซอฟต์แวร์ที่สามารถสื่อสารผ่านเครือข่าย ซึ่งได้รับการออกแบบมาโดยเฉพาะสำหรับประสบการณ์ Agentic สามารถมองได้ว่าเป็น ‘Rails-for-Skynet’ ซึ่งเป็นเฟรมเวิร์กมาตรฐานสำหรับการพัฒนา AI Agent

ข้อกังวลเกี่ยวกับการควบคุมของผู้ให้บริการ

มีความกังวลว่า MCP กำลังถูกผลักดันเพื่อเพิ่มการควบคุมด้านผู้ให้บริการเหนือระบบ ในที่สุดผู้ให้บริการ LLM อาจจำกัดการเข้าถึง API ในทำนองเดียวกับที่ Google ทำให้การใช้ IMAP/SMTP กับ Gmail เป็นเรื่องยาก

การใช้ OpenAPI ช่วยให้ Agent สามารถดึงข้อกำหนด API ได้จาก /openapi.json

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

การจำกัดขอบเขตและความเสี่ยงด้านความปลอดภัย

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

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

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

สิ่งนี้ช่วยให้ทั้งการแทรก Prompt และการแทรกเครื่องมือ ซึ่งอาจนำไปสู่การดำเนินการโค้ดที่ไม่น่าไว้วางใจ

Containerization และการเข้าถึงที่ควบคุม

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

เวิร์กโฟลว์ Agentic นี้ ขับเคลื่อนผ่านอินเทอร์เฟซแบบแชท ได้พิสูจน์แล้วว่ามีประสิทธิภาพมากกว่าวิธีการแบบดั้งเดิม

กุญแจสำคัญคือการให้สิทธิ์ Agent MCP เข้าถึงสิ่งที่พวกเขาต้องการ และไม่มีอะไรเพิ่มเติม Containerization และ UX เครื่องมือที่โปร่งใสมีความสำคัญอย่างยิ่งในการลดความเสี่ยงด้านความปลอดภัย

เครื่องเสมือนและการเข้าถึงอินเทอร์เน็ต

การให้ Agent คอมพิวเตอร์ที่มีการติดตั้ง Linux ขั้นต่ำ (เป็น VM หรือ Container) สามารถให้ผลลัพธ์ที่ดีกว่า ช่วยให้พวกเขาดึงข้อมูลจากอินเทอร์เน็ตได้ อย่างไรก็ตาม สิ่งนี้ทำให้เกิดข้อกังวลด้านความปลอดภัยเกี่ยวกับการให้คำแนะนำที่เป็นอันตรายและการรั่วไหลของข้อมูล

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

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

ขั้นตอนเริ่มต้นของการพัฒนา MCP

MCP เพิ่งได้รับการประกาศในเดือนพฤศจิกายน 2024 และ RFC กำลังมีการพัฒนาอย่างแข็งขัน

บางคนมองว่าแนวคิดผู้ช่วยส่วนตัว AI ทั้งหมด รวมถึง MCP เป็นสิ่งที่ผิดพลาดโดยพื้นฐาน

การผลักดันครั้งแรกสำหรับผู้ช่วย AI ในช่วงปลายทศวรรษ 1990 และต้นทศวรรษ 2000 ล้มเหลวเนื่องจากผู้รวบรวมเนื้อหาที่มีการบูรณาการในแนวตั้งและอำนาจการซื้อจำนวนมากพิสูจน์แล้วว่ามีประสิทธิภาพมากกว่า สิ่งนี้นำไปสู่การเพิ่มขึ้นของแพลตฟอร์มเช่น Expedia และ eBay

ระบบ Multi-Agent ต้องการให้นักเขียนโปรแกรมมีอิทธิพลต่อสถานะของ Agent ซึ่งเป็นงานการเขียนโปรแกรมที่ท้าทาย

ขีดจำกัดของมูลค่าฟรี

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

แม้ว่าไม่ใช่ทุกบริษัทที่จะรวมข้อมูลของตนเข้ากับ AI Agent แต่ศักยภาพในการรวมเครื่องมือต่างๆ เพื่อขับเคลื่อนเวิร์กโฟลว์ยังคงมีนัยสำคัญ

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

หาก booking.com มี API พวกเขามีแนวโน้มที่จะส่งคืนผลลัพธ์เดียวกับเว็บไซต์ของพวกเขา อาจมีการจัดรูปแบบ JSON หรือ XML

การข้ามพ่อค้าคนกลาง

การที่พ่อค้าคนกลางอย่าง booking.com อนุญาตให้ผู้ใช้ข้ามบริการของตนไปโดยสิ้นเชิงนั้นไม่มีเหตุผล

อย่างไรก็ตาม โรงแรมแต่ละแห่งอาจพบว่าเป็นการดีที่จะข้าม booking.com ซึ่งเป็นพ่อค้าคนกลางที่พวกเขาไม่ชอบบ่อยนัก

AI Deep Research สามารถสแกนหาโรงแรมตามเกณฑ์ที่เฉพาะเจาะจงและโต้ตอบกับเซิร์ฟเวอร์ Hotel Discovery MCP ที่ดำเนินการโดยโรงแรมแต่ละแห่ง โดยไม่จำเป็นต้องนำทางอินเทอร์เฟซและโฆษณาของ booking.com

กรณีการใช้งานจริง

MCP สามารถอำนวยความสะดวกในงานต่างๆ เช่น การดึงบันทึกจาก Elasticsearch หรือการสืบค้นฐานข้อมูลในลักษณะที่มีโครงสร้างมากขึ้น

ลักษณะคงที่ของการกำหนดค่าเซิร์ฟเวอร์ MCP ที่เซิร์ฟเวอร์ใหม่ต้องการการแก้ไขไฟล์ .json และการรีสตาร์ทแอป อาจมีข้อจำกัด

โมเดลที่ปรับแต่งอย่างละเอียด

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

การปรับเครื่องมือแบบไดนามิกตามบริบทอาจจำเป็นสำหรับบางสถานการณ์

การสนทนาแบบเปิดและปัญหาทางธุรกิจ

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

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

วิธีที่ดีที่สุดในการมอง MCP คือเป็นการเปลี่ยนแปลงจากนักพัฒนาแต่ละรายที่สร้างตัวหุ้มหุ้มไคลเอนต์รอบ API ไปเป็นผู้ให้บริการ API หรือตัวหุ้มหุ้มที่ได้รับการดูแลโดยชุมชนที่สร้างมัน สิ่งนี้ให้กล่องเครื่องมือขนาดใหญ่ คล้ายกับ NPM หรือ PyPi อย่างไรก็ตาม การจัดระเบียบ ความปลอดภัย และคำจำกัดความการใช้งานยังคงจำเป็น

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

เครื่องมือเฉพาะผู้ใช้

ในบางกรณี เครื่องมืออาจเจาะจงสำหรับข้อมูลผู้ใช้ เช่น เครื่องมือสำหรับแบ่งส่วนและจัดการไฟล์ CSV ที่อัปโหลด

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

มาตรฐานและเทคโนโลยีที่พัฒนา

มาตรฐานใหม่เกิดขึ้นเมื่อเวลาผ่านไป และเป็นเวลานานมากแล้วที่มาตรฐานมีความสำคัญอย่างแท้จริงจนผู้คนลืมไปว่าพวกมันพัฒนาอย่างไร

การดาวน์โหลดโปรแกรมเซิร์ฟเวอร์ขนาดเล็กจากนักพัฒนาแบบสุ่มเพื่อเพิ่ม ‘เครื่องมือ’ ให้กับไคลเอนต์ LLM อาจมีความเสี่ยง

ปัญหาที่เกิดขึ้นเป็นปัญหาที่ถูกต้องตามกฎหมายที่ระบบนิเวศ MCP ต้องแก้ไข โซลูชันบางอย่างจะอยู่ในข้อกำหนด MCP ในขณะที่โซลูชันอื่นๆ จะเป็นภายนอก

Claude Code และการใช้งานจริง

มีความคิดเห็นที่ขัดแย้งกันเกี่ยวกับความสำเร็จของ MCP บางคนเคยได้ยินเรื่องราวของบริษัทที่รวมเข้ากับ MCP ในขณะที่คนอื่นๆ ได้ยินจากผู้ใช้ที่พบว่ามันน่าผิดหวัง

สิ่งนี้เน้นให้เห็นถึงข้อเสียของการโฆษณาเกินจริงและการนำไปใช้ในช่วงต้น

นักพัฒนาบางคนพบว่า HTTP API นั้นเหนือกว่า MCP สำหรับกรณีการใช้งานส่วนใหญ่ พวกเขาแย้งว่าการใช้ ‘เครื่องมือ’ กลั่นกรองไปถึง Endpoints API สำหรับความสามารถและฟังก์ชันการทำงาน

API ไม่ได้อธิบายตนเองโดยค่าเริ่มต้น ซึ่งแสดงถึงโอกาสที่พลาดไปสำหรับผู้สนับสนุน REST และ HATEOAS ในการแสดงแนวทางของพวกเขา

MCP เป็นทางเลือกของ LangChain หรือไม่

MCP ได้รับการอธิบายว่ามี ‘กลิ่น LangChain’ ซึ่งไม่ได้แก้ปัญหาที่กดดัน มีความเป็นนามธรรมมากเกินไป และมีปัญหาในการอธิบายข้อดีของมัน

บางทีมันอาจต้องพูดว่า ‘END OF LINE’ และเนรเทศแฮ็กเกอร์ที่อยากเป็นไปอยู่ในตารางเกม!

คำถามสำคัญคือกระบวนทัศน์ Chatbot ‘ทั่วไป’ จะยังคงอยู่หรือไม่ แอปเฉพาะทางที่มีเครื่องมือของตนเองอาจไม่จำเป็นต้องใช้ MCP

ในทางกลับกัน เมื่อ LLM มีความสามารถมากขึ้น เครื่องมือภายนอกอาจมีความจำเป็นน้อยลง ทำไมคุณถึงต้องการ MCP เพื่อขับเคลื่อน Photoshop ในเมื่อ LLM สามารถแก้ไขภาพได้โดยตรง

ความฝันของผู้ช่วยหุ่นยนต์ Sci-Fi อาจไม่เป็นจริง และเครื่องมือจัดการภาษาสูงอาจมีประโยชน์มากกว่า

ฐานผู้ใช้และความตระหนักด้านความปลอดภัย

ฐานผู้ใช้ของ MCP รวมถึงบุคคลที่มีความรู้ด้านเทคนิคน้อย ทำให้ปัญหาด้านความปลอดภัยมีความเกี่ยวข้องเป็นพิเศษ การสร้างความตระหนักรู้เกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยมีความสำคัญอย่างยิ่ง

การอิง Xops บน OpenRPC ซึ่งกำหนดให้กำหนด Schema ผลลัพธ์ ช่วยวางแผนว่าเอาต์พุตเชื่อมต่อกับอินพุตอย่างไร ปรับปรุงความน่าเชื่อถือสำหรับเวิร์กโฟลว์ที่ซับซ้อน

เทคโนโลยีมีแนวโน้มที่จะพัฒนาและตั้งรกรากเมื่อเวลาผ่านไป

ความซ้ำซ้อนและโครงสร้างพื้นฐานระบบคลาวด์

บางคนตั้งคำถามถึงผลกำไรของการใช้ MCP มากกว่ามาตรฐาน OpenAPI โดยมองว่ามันซ้ำซ้อน

LLM จะใช้อะไรในการโทรไปยังระบบ OpenAPI LLM จะผูกมัดกับเชลล์อย่างไร โฮสต์ของ LLM จะจัดระเบียบสิ่งนั้นอย่างไร

MCP ให้วิธีการที่มีโครงสร้างสำหรับ LLM ในการโทรเครื่องมือ

เซิร์ฟเวอร์ MCP เป็นเซิร์ฟเวอร์ HTTP อยู่แล้ว

ข้อได้เปรียบที่ใหญ่ที่สุดของ MCP คือสำหรับผู้ให้บริการ LLM เช่น OpenAI ไม่ใช่นักพัฒนาแอปพลิเคชัน

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

CLI กับ API

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

MCP เกิดขึ้นเร็วเกินไปและต้องใช้เวลาในการเติบโต ขาดการตรวจสอบโดยหน่วยงานมาตรฐานทั่วไปและขับเคลื่อนโดยการโฆษณาเกินจริง

ขาดแอปพลิเคชันในโลกแห่งความเป็นจริง

แอปพลิเคชันหลักของ MCP

MCP ใช้ใน Claude Desktop และแอปแชท AI เฉพาะกลุ่ม เครื่องมืออัตโนมัติรหัส และเฟรมเวิร์กอัตโนมัติ Agent/LLM

เป็นอีกเทคโนโลยีที่เร่งรีบซึ่งมีแนวโน้มที่จะถูกทิ้งเมื่อตัวย่อที่สามารถโฆษณาเกินจริงตัวต่อไปมาถึง

มีโปรโตคอลการโทรเครื่องมือโมเดลภาษาสองประเภท: โปรโตคอลที่ผู้คนบ่นถึงและโปรโตคอลที่ไม่มีใครใช้

Anthropic พัฒนา ‘มาตรฐาน’ นี้ในสุญญากาศ นำไปสู่ปัญหาด้านความปลอดภัย

JSON-RPC 2.0

MCP สร้างขึ้นบน JSON-RPC 2.0 ซึ่งเป็นโปรโตคอลน้ำหนักเบาที่ช่วยให้ไคลเอนต์และเซิร์ฟเวอร์สื่อสารโดยใช้ JSON

ให้ความรู้สึกเหมือนเป็นข้อกำหนดส่วนกลางที่ออกแบบมาสำหรับระบบนิเวศเฉพาะ โดยอ้างว่ามีความเป็นสากลโดยไม่ได้สร้างมัน

MCP มีประสิทธิภาพเพียงพอที่จะทำสิ่งที่น่าพอใจ ซึ่งทำให้เกิดข้อกังวลด้านความปลอดภัย

ไม่ใช่มาตรฐานที่ครบกำหนดและไม่ได้ออกแบบมาให้ปลอดภัย

แม้ว่าจะมีคำแนะนำอยู่ แต่ก็ไม่ได้บังคับใช้หรือนำไปใช้

Langchain และการโทรเครื่องมือ

Langchain เป็นหนึ่งในเฟรมเวิร์กมากมายที่ใช้รูปแบบ ‘การโทรเครื่องมือ’

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

ช่วยสร้างมาตรฐานรายละเอียดเพื่อให้ชุดค่าผสมผู้ช่วย/การผสานรวมใดๆ เข้ากันได้

แม้ว่า MCP จะมีปัญหาที่ถูกต้องตามกฎหมาย แต่ผู้วิจารณ์ควรปรับปรุงข้อโต้แย้งของตน

การตรวจสอบสิทธิ์มีความสำคัญอย่างยิ่งและไม่ควรถอดออกจากการเปิดตัวครั้งแรก

มีความซับซ้อนมากเกินไป