MCP ไม่ได้แทน Function Calling: มันย้ายเครื่องมือออกจากตัวแอป

MCP กับ Function Calling ทำงานคนละชั้นและใช้ร่วมกันได้: MCP ให้เซิร์ฟเวอร์ประกาศเครื่องมือเพื่อให้แอปค้นพบและเรียกใช้ ส่วน Function Calling ให้โมเดลเลือกเครื่องมือและส่งอาร์กิวเมนต์กลับมา ตามเอกสารสถาปัตยกรรม MCP โฮสต์สร้างไคลเอนต์เพื่อเชื่อมกับเซิร์ฟเวอร์ และโปรโตคอลกำหนดการแลกเปลี่ยนระหว่างกัน โดยไม่ได้กำหนดว่าแอปต้องจัดการโมเดลภาษาอย่างไร

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

ขอบเขตที่ย้ายออกจากแอปคืออะไร

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

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

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

คำว่า “ค้นพบ” มีความหมายเฉพาะในชั้นโปรโตคอล MCP client ใช้ tools/list เพื่อทราบว่าเซิร์ฟเวอร์เสนอเครื่องมืออะไร พร้อมข้อมูลสำหรับเรียกแต่ละตัว การที่โฮสต์ได้รับรายการนี้ยังไม่ใช่การตัดสินใจของโมเดล และยังไม่ใช่คำสั่งให้เซิร์ฟเวอร์ทำงาน โฮสต์อาจคัดเครื่องมือบางตัวออกก่อนส่งคำขอถึงโมเดล เพราะเครื่องมือนั้นไม่เกี่ยวกับคำถามของผู้ใช้ หรือผู้ใช้ไม่มีสิทธิ์ใช้งาน

Function Calling เริ่มทำหน้าที่เมื่อโมเดลได้รับคำอธิบายเครื่องมือที่โฮสต์เลือกแล้ว โมเดลอาจตอบตามปกติโดยไม่เรียกอะไร หรืออาจสร้างคำขอเรียกหนึ่งเครื่องมือพร้อมอาร์กิวเมนต์ ขั้นนี้คือการเลือกการกระทำภายใต้ตัวเลือกที่ได้รับ หลังจากนั้นโฮสต์ต้องตรวจคำขอและนำไปยังตัวรับงานที่ถูกต้อง ถ้าเครื่องมือมาจาก MCP ปลายทางของขั้นนี้คือ tools/call บนเซิร์ฟเวอร์ที่ประกาศเครื่องมือนั้น

คำขอเดียวกันเดินผ่านสองเส้นทางอย่างไร

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

1. เตรียมรายการ: เส้นทางที่นิยามในแอปอ่านชื่อ lookup_order คำอธิบาย และ schema จากโค้ดหรือการตั้งค่าของแอป เส้นทาง MCP ให้เซิร์ฟเวอร์ประกาศข้อมูลดังกล่าว แล้ว MCP client ขอรายการด้วย tools/list หากมีหลายเซิร์ฟเวอร์ โฮสต์ต้องเก็บให้ได้ว่าเครื่องมือแต่ละชื่อมาจากเซิร์ฟเวอร์ใด
2. เลือกสิ่งที่โมเดลจะเห็น: ทั้งสองเส้นทางต้องผ่านการตัดสินใจของโฮสต์ก่อนส่งคำถาม การดึงรายการจากเซิร์ฟเวอร์ไม่ได้บังคับให้ใส่ทุกเครื่องมือในคำขอถึงโมเดล สำหรับเครื่องมือจาก MCP โฮสต์ยังต้องแปลงคำจำกัดความให้ตรงรูปแบบเครื่องมือที่ API ของโมเดลรับได้ หากใช้ผู้ให้บริการโมเดลต่างกัน รูปแบบที่ส่งออกอาจต่างกันแม้ MCP server เดิมไม่เปลี่ยน
3. รับการเลือกของโมเดล: โมเดลเห็นคำอธิบาย lookup_order และอาจส่งชื่อเครื่องมือพร้อมเลขคำสั่งซื้อกลับมา ขั้นนี้ยังไม่มีการอ่านข้อมูลคำสั่งซื้อจริง ผลลัพธ์จากโมเดลเป็นคำขอที่แอปต้องตีความและตรวจสอบ ไม่ใช่สิทธิ์ให้เข้าถึงข้อมูลของลูกค้าคนนั้นโดยอัตโนมัติ
4. สั่งทำงาน: หากเครื่องมือนิยามในแอป โฮสต์ส่งอาร์กิวเมนต์ไปยังโค้ดที่ผูกกับ lookup_order หากเครื่องมือมาจาก MCP โฮสต์เลือก MCP client ของเซิร์ฟเวอร์ต้นทาง แล้วส่ง tools/call พร้อมชื่อเครื่องมือและอาร์กิวเมนต์ เซิร์ฟเวอร์รับผิดชอบการดำเนินงานที่อยู่หลังเครื่องมือนั้น
5. ส่งผลกลับ: ทั้งสองเส้นทางต้องนำผลการทำงานไปผูกกับคำขอเรียกเครื่องมือที่โมเดลสร้าง แล้วให้โมเดลใช้ผลนั้นตอบผู้ใช้ หากค้นไม่พบหรือบริการปลายทางล้มเหลว โฮสต์ต้องจัดการผลผิดพลาดโดยไม่แต่งสถานะคำสั่งซื้อขึ้นมาเอง

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

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

รายละเอียดที่โฮสต์ยังต้องจัดการ

คำจำกัดความจาก MCP server นำไปใช้กับ API ของโมเดลได้เพราะมีข้อมูลหลักที่คล้ายกัน ได้แก่ชื่อเครื่องมือ คำอธิบาย และโครงสร้างอินพุต แต่ “คล้ายกัน” ไม่ได้แปลว่าใช้แทนกันได้ทุกช่อง ฟิลด์ inputSchema ของ MCP อาจต้องย้ายไปยังฟิลด์พารามิเตอร์ของผู้ให้บริการโมเดล หาก API มีเงื่อนไขเพิ่มเติมต่อ JSON Schema โฮสต์ต้องตรวจหรือปรับคำจำกัดความก่อนส่ง ไม่เช่นนั้นคำขออาจถูกปฏิเสธตั้งแต่ยังไม่ถึงขั้นให้โมเดลเลือก

ตัวอย่างหนึ่งคือโหมดที่บังคับรูปแบบอาร์กิวเมนต์อย่างเคร่งครัดของ OpenAI ซึ่งมีข้อกำหนดเกี่ยวกับฟิลด์ required และ additionalProperties ขณะที่ schema ของเครื่องมือ MCP ที่ดึงมาจากเซิร์ฟเวอร์อื่นอาจไม่ได้จัดไว้ตามเงื่อนไขนั้น บทวิเคราะห์ของ Scalar แสดงการแปลงเครื่องมือ MCP เป็นรูปแบบ Function Calling และชี้ว่าการเปิด strict mode กับ schema ที่ไม่เข้าเงื่อนไขเป็นปัญหาจริงของการเชื่อมต่อ ประเด็นนี้จึงอยู่ที่ตัวแปลงและกฎของ API โมเดล ไม่ได้หมายความว่า MCP server ประกาศเครื่องมือผิด

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

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

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

การค้นพบ การเชื่อมต่อ และสิทธิ์มีต้นทุนแยกกัน

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

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

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

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

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

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

บริบทของโมเดลและจังหวะที่ควรเพิ่ม MCP

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

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

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

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

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

ก่อนเพิ่มชั้นเซิร์ฟเวอร์ คำถามต่อไปนี้ช่วยแยกประโยชน์ออกจากต้นทุนของระบบจริง:

• Discovery: ใครเป็นเจ้าของชื่อ คำอธิบาย และ schema ของเครื่องมือ มีแอปกี่ตัวที่ต้องใช้รายการเดียวกัน และโฮสต์จะรีเฟรชรายการที่เปลี่ยนอย่างไร
• Transport: เซิร์ฟเวอร์จะอยู่ในเครื่องผ่าน stdio หรือเข้าถึงระยะไกลผ่าน Streamable HTTP ใครดูแลความพร้อมของปลายทาง และแอปจะตอบอย่างไรเมื่อเรียกไม่สำเร็จ
• Authentication: ผู้ใช้แต่ละคนเข้าถึงข้อมูลหลังเครื่องมือด้วยสิทธิ์ใด ใครส่งข้อมูลรับรอง และการกระทำใดต้องขออนุมัติก่อน
• Context budget: คำขอหนึ่งต้องให้โมเดลเห็นเครื่องมือใดบ้าง จะเลื่อนการโหลดเครื่องมือที่ใช้น้อยอย่างไร และจะย่อผลลัพธ์ก่อนส่งกลับเข้าบริบทเมื่อใด

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