สถาปัตยกรรม MCP: เจาะลึกเชิงเทคนิคฉบับสมบูรณ์พร้อมแผนภาพ

สถาปัตยกรรม MCP คือชุดส่วนประกอบพื้นฐานและกฎการสื่อสารที่ทำให้ MCP (Model Context Protocol) ทำงานได้ MCP เป็นมาตรฐานโอเพนซอร์ส และสถาปัตยกรรม MCP คือโครงสร้างพื้นฐานที่มาตรฐานนี้ทำงานอยู่

สถาปัตยกรรม MCP ทุกรูปแบบประกอบด้วยและสร้างขึ้นโดยมีส่วนประกอบหลักสามอย่างเป็นแกนกลาง ได้แก่ โฮสต์ ไคลเอนต์ และเซิร์ฟเวอร์ เฟรมเวิร์กการสื่อสารของ MCP มักถูกอธิบายว่าประกอบด้วยชั้นข้อมูล (data layer) และชั้นการรับส่ง (transport layer) ชั้นข้อมูลคือชุดกฎที่กำหนดรูปแบบของข้อความ (คำขอ MCP ส่งในรูปแบบ JSON-RPC 2.0) ส่วนชั้นการรับส่งทำหน้าที่ส่งข้อความเหล่านั้น โดยใช้ Streaming HTTP สำหรับการเชื่อมต่อภายนอก

สถาปัตยกรรม MCP คือเฟรมเวิร์กเซิร์ฟเวอร์ที่นำ Model Context Protocol มาใช้งาน ซึ่งเป็นมาตรฐานเปิดสำหรับการเชื่อมต่อโมเดล AI เข้ากับเครื่องมือ ทรัพยากรอย่างฐานข้อมูล และพรอมต์ที่ช่วยขยายบริบทของอินพุต สิ่งเหล่านี้เรียกรวมกันว่า “พริมิทีฟ” (primitives) ท้ายที่สุดแล้ว สถาปัตยกรรม MCP ช่วยให้ LLM ค้นพบได้ว่ามีเครื่องมือใดให้ใช้งานบ้างและดำเนินการเวิร์กโฟลว์ได้ โดยไม่จำเป็นต้องอัปเดตฝั่งไคลเอนต์อยู่เป็นประจำ

แผนภาพสถาปัตยกรรม MCP: แอปพลิเคชัน AI แลกเปลี่ยนคำขอกับเซิร์ฟเวอร์ MCP ซึ่งให้บริการเครื่องมือ ทรัพยากร และพรอมต์

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

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

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

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

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

แอปพลิเคชันโฮสต์เป็นแพลตฟอร์มประสานงานส่วนกลางและเชื่อมต่อกับ LLM เครื่องมือที่เป็นที่รู้จักอย่าง Perplexity และ Claude Desktop สามารถทำหน้าที่เป็นโฮสต์ในระบบ MCP ได้

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

ไคลเอนต์คือส่วนประกอบซอฟต์แวร์ในแอปพลิเคชัน AI โดย MCP มีอินเทอร์เฟซมาตรฐานให้ไคลเอนต์สื่อสารกับเซิร์ฟเวอร์ MCP ทั้งภายในและภายนอกตามคำสั่งของโฮสต์หรือ LLM หน้าที่ของไคลเอนต์คือสร้างการเชื่อมต่อ จัดรูปแบบข้อความ JSON-RPC ส่งคำขอ และรับการตอบกลับ

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

แผนภาพโฮสต์ MCP เช่น Perplexity ที่ประสานงานไคลเอนต์ MCP สามตัว โดยแต่ละตัวเชื่อมต่อกับเซิร์ฟเวอร์ MCP ของตนเอง เช่น ฐานข้อมูล ไฟล์ หรือ API ภายนอก

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

เซิร์ฟเวอร์ MCP สามารถให้สิทธิ์เข้าถึงพริมิทีฟได้สามประเภท ดังนี้

เครื่องมือ: โดยพื้นฐานแล้วคือฟังก์ชันการทำงานของซอฟต์แวร์ภายนอก หากพิจารณาแนวทางแบบอิง API แบบดั้งเดิม แอปพลิเคชันวิเคราะห์เว็บอาจดึงข้อมูลโดยใช้คำขอที่จัดรูปแบบแล้วไปยังเซิร์ฟเวอร์ภายนอก ส่วนในสถาปัตยกรรม MCP ฟังก์ชันการทำงานจากบุคคลที่สามทั้งหมดของผู้ให้บริการรายหนึ่งจะพร้อมใช้งานผ่านการเชื่อมต่อเพียงรายการเดียว และคำขอจะสร้างขึ้นตามกฎการจัดรูปแบบมาตรฐาน
ทรัพยากร: ทรัพยากรคือแหล่งข้อมูลที่ให้บริบทแบบอ่านอย่างเดียว ตัวอย่างที่ดีคือสคีมาฐานข้อมูล เซิร์ฟเวอร์ MCP จะเปิดให้โฮสต์เข้าถึงแหล่งข้อมูลต่าง ๆ ที่มีให้ใช้งาน หากโฮสต์คิวรีฐานข้อมูล เช่น ด้วยการค้นหา SQL ที่ LLM สร้างขึ้น จะถือว่าเป็นคำขอใช้เครื่องมือ
พรอมต์: คือเทมเพลตพรอมต์ที่นำกลับมาใช้ซ้ำได้ ซึ่งช่วยให้ LLM ทำงานเฉพาะอย่างได้ ผู้ใช้หรือโฮสต์จะเรียกใช้พรอมต์แทนเครื่องมือเมื่อต้องการคำสั่งสำเร็จรูปเพื่อทำงานให้เสร็จ งานที่ตั้งค่าไว้ล่วงหน้าในแอปพลิเคชันโฮสต์ เช่น ตัวเลือก “รีวิวโค้ด” หรือ “วิเคราะห์ข้อมูล” มักจัดเก็บไว้เป็นพรอมต์ที่ผู้ใช้เลือกได้

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

ชั้นข้อมูลในสถาปัตยกรรม MCP คือชุดกฎที่กำหนดรูปแบบของคำขอ การตอบกลับ และการแจ้งเตือน ภาษามาตรฐานสำหรับข้อความคือ JSON-RPC

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

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

มาดูกันว่าการค้นพบเครื่องมือทำงานอย่างไรผ่านสองตัวอย่างต่อไปนี้ (ซึ่งใช้กับทรัพยากรหรือพรอมต์ได้เช่นกัน):

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

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

ต่อไปนี้คือตัวอย่างคำขอ tools/list ไปยังเซิร์ฟเวอร์ MCP จากแอปพลิเคชันจดบันทึกสมมติ:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

ในตัวอย่างนี้ “id”:101 ระบุคำขอด้วย ID เพื่อให้ไคลเอนต์จับคู่การตอบกลับได้ และฟิลด์ “params” มีข้อมูลเพิ่มเติมเกี่ยวกับไคลเอนต์ เช่น ชื่อไคลเอนต์ (notes-app-client) และความสามารถ

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

ต่อไปนี้คือตัวอย่างของคำขอ:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

ฟิลด์ “method” จะแจ้งเซิร์ฟเวอร์ MCP ว่าเป็นการเรียกใช้เครื่องมือ “name” ระบุว่าจะเรียกใช้เครื่องมือใด และ “arguments” ให้ข้อมูลอินพุตที่จำเป็น

หากชั้นข้อมูลคือ “อะไร” ของการเชื่อมต่อระหว่างไคลเอนต์กับเซิร์ฟเวอร์ MCP ชั้นการรับส่งก็คือ “อย่างไร” ชั้นนี้กำหนดวิธีที่ข้อความเดินทาง ได้แก่ ช่องทางเฉพาะและกฎที่ควบคุมวิธีส่งคำขอและการตอบกลับ

MCP มีเส้นทางการรับส่งสองแบบ ดังนี้

อินพุต/เอาต์พุตมาตรฐาน: ใช้เมื่อเซิร์ฟเวอร์ MCP ทำงานในสภาพแวดล้อมภายในเครื่องเดียวกับแอปโฮสต์ ไคลเอนต์จะเขียนคำขอ JSON ไปยังอินพุตมาตรฐานของเซิร์ฟเวอร์ เซิร์ฟเวอร์จะอ่านคำขอ ดำเนินการตามที่ร้องขอ แล้วเขียนการตอบกลับไปยังเอาต์พุตมาตรฐาน
Streamable HTTP: เมื่อเซิร์ฟเวอร์ MCP ทำงานภายนอกแอปพลิเคชันโฮสต์ ไคลเอนต์ MCP จะส่งคำขอไปยังเซิร์ฟเวอร์โดยใช้ HTTP POST เซิร์ฟเวอร์จะตอบกลับด้วยข้อความ JSON เพียงข้อความเดียว หรือด้วยสตรีม Server-Sent Events (SSE) ซึ่งเป็นช่องทาง “รับฟัง” แบบต่อเนื่อง ทำให้สามารถส่งข้อความกลับได้หลายข้อความเมื่อเวลาผ่านไป

สถาปัตยกรรม MCP แบบหลายผู้เช่าคือการใช้งานรูปแบบหนึ่งที่สามารถให้บริการผู้ใช้หลายราย (ผู้เช่า) ได้พร้อมกัน

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

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

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

ผังงานของคำขอ MCP แบบครบวงจรในแปดขั้นตอน ได้แก่ การค้นพบเครื่องมือ อินพุตของผู้ใช้ การประมวลผลของโมเดล การเลือกเครื่องมือ คำขอ การดำเนินการของเครื่องมือ ผลลัพธ์ และการสร้างคำตอบ

ต่อไปนี้คือตัวอย่างการเรียกใช้เครื่องมือ MCP ในทางปฏิบัติ โดยใช้ตัวอย่างก่อนหน้าของแอปพลิเคชันจดบันทึกที่เชื่อมต่อกับบริการจัดการงาน:

การค้นพบเครื่องมือ: แอปพลิเคชันจดบันทึก (โฮสต์) ใช้ไคลเอนต์ MCP ของตนเพื่อขอรายการเครื่องมือที่พร้อมใช้งานของเซิร์ฟเวอร์ผ่านคำขอ tools/list เซิร์ฟเวอร์จะส่งคืนชื่อ คำอธิบาย และอินพุตที่คาดหวังของเครื่องมือเหล่านั้น รวมถึงของเครื่องมือ add-task ขั้นตอนนี้อาจเกิดขึ้นก่อนที่คุณจะส่งพรอมต์
อินพุตของผู้ใช้: คุณส่งคำขอไปยังแอปพลิเคชันจดบันทึกที่ใช้ LLM ผ่านแชทบอทในแอป เช่น “สร้างงานในปฏิทินของฉันเพื่อรีวิวฉบับร่างใหม่ โดยมีลำดับความสำคัญปานกลาง”
การประมวลผลของโมเดล: โฮสต์จะส่งคำขอของคุณพร้อมคำจำกัดความของเครื่องมือที่เกี่ยวข้องไปยัง LLM
การเลือกเครื่องมือ: LLM จะสร้างคำขอใช้เครื่องมือแบบมีโครงสร้าง โดยระบุเครื่องมือและอินพุต ได้แก่ add-task พร้อม title: Review the draft และ priority: Medium โฮสต์จะตรวจสอบว่าการดำเนินการนี้ได้รับอนุญาตหรือไม่ แล้วส่งคำขอต่อไปยังไคลเอนต์ MCP ซึ่งจะส่งข้อความ JSON-RPC
คำขอ: ไคลเอนต์ MCP ส่งคำขอ tools/call ไปยังเซิร์ฟเวอร์ MCP ของตน
การดำเนินการของเครื่องมือ: เซิร์ฟเวอร์ MCP เรียกใช้ API ของแอปพลิเคชันจัดการงานเพื่อสร้างงานใหม่ตามชื่อและลำดับความสำคัญที่ระบุ
การส่งคืนผลลัพธ์: เซิร์ฟเวอร์ส่งผลลัพธ์กลับไปยังไคลเอนต์ MCP ซึ่งจะส่งต่อให้โฮสต์ จากนั้นโฮสต์จะเพิ่มผลลัพธ์นี้ลงในข้อมูลที่ส่งให้ LLM
การสร้างคำตอบ: LLM ใช้ผลลัพธ์เพื่อสร้างคำตอบให้ผู้ใช้ เช่น “ฉันได้สร้างงานเพื่อรีวิวฉบับร่างโดยมีลำดับความสำคัญปานกลางแล้ว”

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

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

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

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

สถาปัตยกรรม MCP มีจุดอ่อนที่อาจเกิดขึ้นได้ดังต่อไปนี้

การแทรกพรอมต์ (prompt injection): ผู้ใช้แทรกพรอมต์ที่เป็นอันตรายลงในข้อมูลภายนอก ซึ่งโมเดล AI ตีความผิดว่าเป็นคำสั่ง
การเข้าถึงที่มีสิทธิ์มากเกินไป: เซิร์ฟเวอร์ MCP อาจเปิดให้โมเดล AI ใช้เครื่องมือจำนวนมาก ซึ่งอาจเพิ่มโอกาสเกิดปัญหาด้านความปลอดภัย (ขอบเขตความเสียหายหรือ blast radius)
ข้อมูลรั่วไหลโดยไม่ตั้งใจ: การใช้งานที่กำหนดค่าไว้ไม่ดีอาจทำให้ข้อมูลที่ละเอียดอ่อน เช่น คีย์ API หรือข้อมูลรับรองของฐานข้อมูล ถูกส่งต่อไปยัง LLM
การแทรกแซงระบบภายในเครื่อง: เซิร์ฟเวอร์ MCP ภายในเครื่องมีความเสี่ยงต่อปัญหาของระบบภายในเครื่อง เช่น สคริปต์ที่เป็นอันตราย ไม่ต่างจากแอปพลิเคชันอื่น ๆ และยังมีปัญหาเพิ่มเติมคืออาจส่งผลเสียต่อเนื่องไปยังระบบ AI แบบเอเจนต์

ปัญหาเหล่านี้ไม่มีข้อใดที่แก้ไขไม่ได้ บ่อยครั้งเพียงแค่มาตรการที่ใช้กันอยู่แล้วก็เพียงพอที่จะรับประกันความปลอดภัยของระบบ มาตรการต่าง ๆ เช่น การให้มนุษย์มีส่วนร่วมในกระบวนการ (human in the loop) การบังคับใช้การควบคุมที่เข้มงวดกับข้อมูลที่ละเอียดอ่อน และการป้องกันการโจมตีเซิร์ฟเวอร์ ล้วนเป็นแนวปฏิบัติทั่วไป

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

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

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

สถาปัตยกรรม MCP คืออะไร

ส่วนประกอบของสถาปัตยกรรม MCP: โฮสต์ ไคลเอนต์ และเซิร์ฟเวอร์

โฮสต์

ไคลเอนต์

เซิร์ฟเวอร์

ชั้นข้อมูลในสถาปัตยกรรม MCP คืออะไร

ชั้นการรับส่งในสถาปัตยกรรม MCP คืออะไร

สถาปัตยกรรม MCP แบบหลายผู้เช่า (multi-tenant) คืออะไร

แผนภาพสถาปัตยกรรม MCP: อธิบายทีละขั้นตอน

สถาปัตยกรรม MCP แตกต่างจากสถาปัตยกรรม API แบบดั้งเดิมอย่างไร

สถาปัตยกรรม MCP ปลอดภัยหรือไม่

ก้าวต่อไปของสถาปัตยกรรม MCP