ภาพรวมการรับรองเซิร์ฟเวอร์ Microsoft MCP (ตัวอย่าง)

Note

บทความนี้อธิบายคุณสมบัติที่ใช้ในเอเจนต์หรือการไหลของเอเจนต์ที่ขับเคลื่อนโดยฮาร์เนสมาตรฐาน

สำคัญ

บทความนี้มีเอกสารรุ่นพรีวิว Microsoft Copilot Studio และอาจจะมีการเปลี่ยนแปลงในอนาคต

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

หากคุณกำลังสร้างเอเจนต์ที่พร้อมสำหรับการใช้งานจริง โปรดดู ภาพรวมของ Microsoft Copilot Studio

เซิร์ฟเวอร์ Model Context Protocol (MCP) เป็นบริการที่ให้เครื่องมือและการดําเนินการที่เอเจนต์สามารถใช้ได้ทั้งใน Microsoft 365 Copilot และประสบการณ์ที่ขับเคลื่อนด้วย AI อื่น ๆ การรับรองช่วยให้ลูกค้าและผู้ดูแลระบบมั่นใจว่าบริการภายนอกตรงตามความคาดหวังของ Microsoft ในด้านความน่าเชื่อถือ ความปลอดภัย การปฏิบัติตามข้อกําหนด และการดําเนินงานอย่างรับผิดชอบ ก่อนที่จะเปิดให้ใช้งานอย่างกว้างขวาง เซิร์ฟเวอร์ MCP ที่ได้รับการรับรองให้คําแนะนําการตั้งค่าที่ชัดเจน การทํางานเครื่องมือที่เชื่อถือได้ การตรวจสอบสิทธิ์ที่เหมาะสม และเอกสารที่ช่วยให้ผู้ผลิตและผู้ดูแลระบบเข้าใจวิธีใช้งานเซิร์ฟเวอร์อย่างปลอดภัย

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

สำคัญ

ต่อจากนี้ ให้ใช้ประเภทข้อเสนอใน Partner Center Apps and Agents for M365 and Copilot สำหรับการส่งการรับรองเซิร์ฟเวอร์ Microsoft MCP คุณไม่จําเป็นต้องส่งเซิร์ฟเวอร์ MCP ที่ได้รับการรับรองผ่านกระบวนการก่อนหน้าเพียงเพราะการเปลี่ยนแปลงนี้เท่านั้น หากจําเป็นต้องดําเนินการ Microsoft จะติดต่อกลับ Microsoft จะเปลี่ยน MCP ที่ได้รับการรับรองเดิมไปยังเส้นทางกระบวนการใหม่ ถ้าคุณมีปัญหา คุณสามารถใช้เส้นทางเดิมได้จนถึงสิ้นเดือนตุลาคม 2026 เรียนรู้เพิ่มเติมเกี่ยวกับการรับรองเซิร์ฟเวอร์ Microsoft MCP - Microsoft Copilot Studio

เซิร์ฟเวอร์ MCP ที่ผ่านการรับรอง

เซิร์ฟเวอร์ MCP ที่ได้รับการรับรองแต่ละตัวมีเนื้อหาอ้างอิงเพื่อสนับสนุนการตั้งค่าเครื่องมือและการดําเนินการที่รวมกับ Microsoft 365 Copilot และประสบการณ์ AI อื่น ๆ หากต้องการดูรายการที่กรองแล้วของเซิร์ฟเวอร์ MCP ที่ได้รับการรับรองในปัจจุบัน ให้ไปที่ รายการเซิร์ฟเวอร์ MCP ทั้งหมด

ข้อกำหนดเบื้องต้น

ก่อนส่งเซิร์ฟเวอร์ MCP เพื่อขอการรับรอง ให้แน่ใจว่าองค์กรและแพ็กเกจของคุณตรงตามข้อกําหนดพื้นฐานด้านคุณสมบัติ เทคนิค และการปฏิบัติตามข้อกําหนด:

  • คุณสมบัติของ Publisher: คุณต้องเป็น publisher ที่ได้รับการยืนยันและเป็นเจ้าของหรือควบคุมจุดปลายทางเซิร์ฟเวอร์ MCP ที่คุณส่ง
  • ความพร้อมในการตรวจสอบสิทธิ์: รองรับวิธีการตรวจสอบสิทธิ์ที่ได้รับการอนุมัติและให้รายละเอียดการกําหนดค่าสําหรับการตรวจสอบความถูกต้อง
  • ความสมบูรณ์ของแพ็กเกจ: รวมแพ็กเกจ MCP, เมตาดาต้า, เอกสารสาธารณะ, ไอคอน และลิงก์สนับสนุน, ความเป็นส่วนตัว และข้อกําหนด
  • ความพร้อมในการทดสอบ: ทดสอบเครื่องมือ MCP ก่อนส่งและรวมหลักฐานการประเมินเมื่อมี

คุณสมบัติการมีสิทธิ์ของผู้เผยแพร่

ในการส่งเซิร์ฟเวอร์ MCP เพื่อรับรอง คุณต้องเป็นผู้เผยแพร่ที่ได้รับการยืนยันแล้ว องค์กรของคุณต้อง:

  • มีบัญชี Microsoft Partner Center ด้วยการตรวจสอบยืนยันธุรกิจที่เสร็จสมบูรณ์
  • ลงทะเบียนในโปรแกรม Microsoft 365 และ Copilot
  • เป็นเจ้าของหรือควบคุมจุดสิ้นสุดเซิร์ฟเวอร์ MCP ที่คุณส่ง

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

มีอะไรเปลี่ยนแปลงบ้าง

กระบวนการรับรองที่อัปเดตจะเพิ่มการเปลี่ยนแปลงเส้นทางการส่งข้อมูล ข้อกําหนดของแพ็กเกจ และพื้นผิวการเผยแพร่

พื้นที่ คําแนะนําที่อัปเดต
ประเภทข้อเสนอใน Partner Center ใช้ Apps and Agents สําหรับ M365 และ Copilot สําหรับการส่งใบรับรอง MCP ใหม่
แพ็กเกจ การส่ง MCP ทั้งหมดตอนนี้ต้องใช้ไฟล์ manifest, ไฟล์เครื่องมือ, intro.md ไฟล์ และการกําหนดค่าการตรวจสอบสิทธิ์ Azure Key Vault
MCP ที่ได้รับการรับรองแล้ว MCP ที่ได้รับการรับรองผ่านกระบวนการก่อนหน้าไม่จําเป็นต้องดําเนินการเพียงเพราะการเปลี่ยนแปลงกระบวนการ; Microsoft เปลี่ยนเส้นทางใหม่ให้พวกเขา
ช่องทางการเผยแพร่ คาดว่าเซิร์ฟเวอร์ MCP ที่ได้รับการรับรองจะพร้อมใช้งานใน Azure Foundry นอกเหนือจาก Copilot Studio โดยมีพื้นผิวการค้นหาและกํากับดูแล การจัดการ Microsoft 365 Center ที่กว้างขึ้นตามความเหมาะสม
คําจํากัดความของแพ็กเกจ แนบลิงก์ไปยังแพ็กเกจและคําแนะนําเกี่ยวกับไอคอนของ Microsoft เพื่อให้ผู้เผยแพร่ปฏิบัติตามข้อกําหนดเรื่องขนาด แบรนด์ พื้นที่ปลอดภัย ความคมชัด และภาพที่ถูกต้อง โปรดดู การเตรียมความพร้อมสำหรับการส่งไปยัง Teams Store

กระบวนการออกใบรับรอง

เส้นทางระดับสูงนั้นตรงไปตรงมา: เตรียมแพ็กเกจ ส่งใน Partner Center ผ่านการตรวจสอบและตรวจสอบ จากนั้นเผยแพร่และดูแลเซิร์ฟเวอร์ MCP ที่ได้รับการรับรอง

ขั้นตอน ลำดับขั้น จะเกิดอะไรขึ้น
1 เตรียมพัสดุของคุณ ประกอบแพ็กเกจเซิร์ฟเวอร์ MCP รวมถึง manifest, คําจํากัดความเครื่องมือ, รายละเอียดการตรวจสอบสิทธิ์, ข้อมูลเมตาที่จําเป็น, เอกสารสาธารณะ, ไอคอน และสิ่งประดิษฐ์สนับสนุนอื่น ๆ
2 ส่งผ่าน Partner Center สร้างข้อเสนอใหม่โดยใช้ประเภทข้อเสนอ Apps and Agents สําหรับ M365 และ Copilot อัปโหลดแพ็กเกจและให้ข้อมูลเชิงพาณิชย์ กฎหมาย การสนับสนุน และข้อมูลผู้เผยแพร่ที่จําเป็น
3 การตรวจสอบอัตโนมัติ Microsoft ตรวจสอบโครงสร้างแพ็กเกจ ฟิลด์ที่จําเป็น ความถูกต้องของสคีมา ความสมบูรณ์ของเมตาดาต้า และความพร้อมของนโยบายพื้นฐาน คุณต้องแก้ไขปัญหาการบล็อกก่อนที่จะดําเนินการตรวจสอบต่อไปได้
4 การตรวจสอบฟังก์ชันและความปลอดภัย Microsoft ตรวจสอบเซิร์ฟเวอร์ MCP ในแง่ของฟังก์ชันการทํางาน พฤติกรรมของอุปกรณ์ปลายทาง การตรวจสอบสิทธิ์ ความปลอดภัย การปฏิบัติตามข้อกําหนด ความพร้อมในการส่งข้อมูลทางไกล และข้อพิจารณาด้าน AI ที่รับผิดชอบ หลักฐานการประเมินสามารถช่วยเร่งกระบวนการตรวจสอบได้
5 การอนุมัติและการเผยแพร่ หลังจากได้รับการอนุมัติ เซิร์ฟเวอร์ MCP ที่ได้รับการรับรองจะถูกเผยแพร่ไปยังพื้นผิวการค้นหาและรันไทม์ของ Microsoft ที่รองรับ MCP ที่ได้รับการรับรองคาดว่าจะสามารถค้นหาได้ใน Copilot Studio และ Azure Foundry โดยมีการสนับสนุนการกํากับดูแลผู้ดูแลระบบ Microsoft 365 ตามความเหมาะสม
6 ดูแลรักษาและอัปเดต รักษาการนําไปใช้ให้สอดคล้องกับแพ็กเกจที่ได้รับการรับรอง ส่งอัปเดตใหม่เมื่อมีการแนะนําเครื่องมือใหม่ การเปลี่ยนแปลงเมตาดาต้าที่สําคัญ หรือการเปลี่ยนแปลงแพ็กเกจที่ส่งผลต่อประสบการณ์ที่ได้รับการรับรอง

คํานิยามบรรจุภัณฑ์และการสร้างแบรนด์

สําหรับทรัพย์สินของแพ็กเกจ เช่น ขนาดไอคอน กฎพื้นที่ปลอดภัย การสร้างแบรนด์ และความเปรียบต่าง ให้ใช้คําแนะนําแพ็กเกจของ Microsoft 365 / Teams เป็นข้อมูลอ้างอิงสําหรับความพร้อมในการส่ง โปรดดู การเตรียมความพร้อมสำหรับการส่งไปยัง Teams Store

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

สำคัญ

Microsoft รองรับเฉพาะชื่อและค่าของหัวเรื่อง American Standard Code for Information Interchange (ASCII) ในไฟล์ manifest และ tool definition เท่านั้น อักขระที่ไม่ใช่ ASCII อาจทําให้การตรวจสอบความถูกต้องล้มเหลว

ไฟล์แมนิเฟสต์

ไฟล์ manifest เป็นไฟล์ JSON ที่ประกอบด้วยคํานิยามเซิร์ฟเวอร์ MCP, คําจํากัดความเครื่องมือ, การกําหนดค่าการตรวจสอบสิทธิ์, ข้อมูลเมตา, เอกสารสาธารณะ และสิ่งประดิษฐ์สนับสนุนอื่น ๆ ไฟล์ต้องเป็นไปตามโครงสร้างที่กําหนดและรวมข้อมูลที่จําเป็นทั้งหมดเพื่อให้ Microsoft ตรวจสอบความถูกต้องของเซิร์ฟเวอร์ MCP ในระหว่างการรับรอง นี่คือตัวอย่างโครงสร้างของไฟล์ manifest:

{
  "$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/vDevPreview/MicrosoftTeams.schema.json",
  "manifestVersion": "devPreview",
  "version": "1.0.0",
  "id": "<APP_ID>",
  "developer": {
    "name": "<COMPANY_NAME>",
    "websiteUrl": "<COMPANY_WEBSITE_URL>",
    "privacyUrl": "<PRIVACY_POLICY_URL>",
    "termsOfUseUrl": "<TERMS_OF_USE_URL>"
    "contactInfo": {
      "defaultSupport": {
        "userEmailsForChatSupport": [
          "ISV_EmailAddress1",
          "ISV_EmailAddress2"
        ],
        "emailsForEmailSupport": [  
          "<SUPPORT_Email_Address>"
        ]
      }
    }  
  },
  "name": {
    "short": "<MCP_SHORT_NAME>",
    "full": "<MCP_FULL_NAME>"
  },
  "description": {
    "short": "<SHORT_DESCRIPTION>",
    "full": "<LONG_DESCRIPTION>"
  },
  "agentConnectors": [
    {
      "id": "<CONNECTOR_ID>",
      "displayName": "<CONNECTOR_DISPLAY_NAME>",
      "description": "<CONNECTOR_DESCRIPTION>",
      "toolSource": {
        "remoteMcpServer": {
          "mcpServerUrl": "<MCP_SERVER_URL>",
          "mcpToolDescription": {
            "file": "mcptools.json"
          },
          "authorization": {
            "type": "AzureKeyVault",
            "referenceId": "<KEYVAULT_URI>"
          }
        }
      }
    }
  ],
  "icons": {
    "outline": "Outline.png",
    "color": "Color.png"
  },
  "accentColor": "<HEX_COLOR>"
}

ไฟล์แนะนํา

สร้าง intro.md ไฟล์ (หรือ Readme.md) เพื่อบันทึกคุณสมบัติและการทํางานของเซิร์ฟเวอร์ MCP ของคุณ หากต้องการดูตัวอย่างintro.mdไฟล์ ให้ไปที่ Readme.md คุณยังสามารถดูไฟล์อื่น ๆ intro.md ในที่เก็บ Power Platform Connectors GitHub ได้ด้วย

Tip

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

การเผยแพร่และการวางจําหน่าย

หลังจากได้รับการรับรองแล้ว เซิร์ฟเวอร์ MCP จะถูกเผยแพร่ไปยังพื้นผิวการค้นหาและรันไทม์ของ Microsoft ที่รองรับ MCP ที่ได้รับการรับรองมีให้ใช้งานใน Azure Foundry นอกเหนือจาก Copilot Studio หากเหมาะสม MCP ที่ได้รับการรับรองควรสอดคล้องกับการกํากับดูแลผู้ดูแลระบบและประสบการณ์การค้นหาของ Microsoft 365 ที่ใช้ในการเปิดใช้งาน ปรับใช้ หรือจัดการเอเจนต์และเครื่องมือสําหรับองค์กร

ความรับผิดชอบหลังการรับรอง

หลังจากได้รับการรับรองแล้ว ผู้จัดพิมพ์มีหน้าที่รับผิดชอบในการรักษาประสบการณ์ที่ได้รับการรับรอง:

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

คำถามที่ถามบ่อย

ฉันจะตั้งค่า Key Vault ได้อย่างไร?

ในการตั้งค่าการตรวจสอบสิทธิ์ด้วย Azure Key Vault ให้ทําตามขั้นตอนเหล่านี้:

  1. สร้าง Azure Key Vault ใน tenant Azure ของคุณโดยใช้พอร์ทัล Azure

  2. เก็บความลับต่อไปนี้ไว้ใน Key Vault:

    ความลับที่จําเป็น:

    • ClientId
    • ClientSecret
    • TokenUrl

    ความลับเสริม (ขึ้นอยู่กับการกําหนดค่าผู้ให้บริการตัวตน):

    • AuthorizationUrl (จําเป็นสําหรับ OAuth2 IdentityProvider)
    • RefreshUrl
    • Scopes
    • AzureActiveDirectoryResourceId (จําเป็นสําหรับ AAD IdentityProvider)

  3. สร้าง service principal สําหรับแอปพลิเคชัน Microsoft:

    8e91e74f-afe9-41cd-8c3f-17a9562a74ea

    มอบสิทธิ์ Key Vault Secrets User (หรือสิทธิ์อ่าน RBAC เทียบเท่า) ให้กับบริการหลักนี้ใน Azure Key Vault เพื่อให้บริการรับรองสามารถดึงความลับระหว่างการตรวจสอบได้

  4. เพิ่ม Key Vault URI ลงใน MCP manifest:

    "authorization": {
  "type": "AzureKeyVault",
  "referenceId": "https://<your-keyvault>.vault.azure.net/"
}

    authorization.referenceIdต้องเป็น Azure Key Vault URI

    ตัวอย่าง:

    "authorization": {
  "type": "AzureKeyVault",
  "referenceId": "https://contoso-mcp-kv.vault.azure.net/"
}

  5. จัดแพ็กเกจและส่งชุดใบรับรอง MCP

ระหว่างการตรวจสอบการรับรอง บริการจะดึงข้อมูลการกําหนดค่า OAuth จาก Azure Key Vault ที่อ้างอิงอย่างปลอดภัย

ข้อกําหนดของผู้ให้บริการข้อมูลประจําตัวคืออะไร?

ตารางต่อไปนี้แสดงรายการความลับที่จําเป็นของ Key Vault สําหรับแต่ละประเภทของผู้ให้บริการตัวตน:

ตัวให้บริการข้อมูลประจำตัว ความลับที่จําเป็นของ AzureKey Vault
OAuth2 ClientId, , ClientSecret, AuthorizationUrlTokenUrl
OAuth2 + โทเค็นรีเฟรช ClientId, ClientSecret, AuthorizationUrl, TokenUrlRefreshUrl
OAuth2 ที่มีขอบเขตการเข้าถึง เพิ่ม Scopes
Azure AD ClientId, , ClientSecret, TokenUrlAzureActiveDirectoryResourceId

ชื่อลับต้องแยกตัวพิมพ์ใหญ่-เล็กหรือไม่?

ใช่ ชื่อลับต้องแยกตัวพิมพ์ใหญ่และควรตรงกันอย่างแม่นยํา:

  • ClientId
  • ClientSecret
  • AuthorizationUrl
  • TokenUrl
  • RefreshUrl
  • Scopes
  • AzureActiveDirectoryResourceId

ควรใช้ค่าใดสําหรับ authorization.referenceId?

ใช้ Key Vault URI (ไม่ใช่ URI ลับ) สําหรับ authorization.referenceId.

เนื้อหาที่เกี่ยวข้อง

  • Last updated on