Microsoft MCP 伺服器認證概觀 (預覽版)

Note

本文描述由 標準線束驅動的代理或代理流程中使用的功能。

Important

本文包含 Microsoft Copilot Studio 預覽版文件,內容可能有所變更。

預覽功能不供生產時使用,而且可能功能受限。 這些功能是在正式發行前先行推出,讓您能夠搶先體驗並提供意見反應。

如果你正在打造一個準備好上線的代理程式,請參考 Microsoft Copilot Studio 概述。

模型情境協定(MCP)伺服器是提供代理在 Microsoft Copilot 及其他 AI 驅動體驗中可用的工具與動作的服務。 認證讓客戶和管理員確信,外部服務在廣泛推出之前,已符合 Microsoft 對可靠性、安全性、合規性及負責任營運的期望。 認證的 MCP 伺服器提供清晰的設定指引、可靠的工具執行、適當的驗證,以及協助製作者和管理員了解如何安全使用伺服器的文件。

此更新流程保留了核心認證基礎:

  • 經過驗證的出版商會提交 MCP 套件。
  • Microsoft 會驗證套件與執行時的行為,並在核准前修復問題。
  • 出版商仍需負責在出版後維持認證體驗。

Important

未來,提交 Microsoft MCP 伺服器認證時,請使用 Partner Center 供應項目類型 Apps and Agents for M365 and Copilot。 如果你已有已認證的 MCP 伺服器:

  • 如果你的 MCP 伺服器已經透過先前流程認證,你 就不必 採取任何行動。
  • 現有認證的MCP正被遷移到新的認證路徑。
  • 如果你需要做什麼,Microsoft 會聯絡你。
  • 如果你已經有現有的 M365 代理和 MCP 伺服器, 就不需要 另外提交。 這些 MCP 伺服器將於今年晚些時候自動以獨立的 MCP 伺服器形式開放。

由於預覽期間提交量大,新路徑的處理時間可能會比平常慢。 若您有即時出版時程或客戶承諾,可持續使用 舊有認證流程 至 2026 年 10 月 31 日。

認證的 MCP 伺服器

每台認證的 MCP 伺服器都提供參考內容,協助設定與 Microsoft Copilot 及其他 AI 體驗整合的工具與動作。 若要查看目前已認證 MCP 伺服器的篩選清單,請前往所有 MCP 伺服器清單。

先決條件

提交 MCP 伺服器進行認證前,請確保您的組織與套件符合基準資格、技術及合規性需求:

  • 發行者資格:您必須是經過驗證的發行者,並擁有或控制您提交的 MCP 伺服器端點。
  • 驗證整備度:支援核准的驗證方法,並提供設定詳細資料以供驗證。
  • 套件完整性:包含 MCP 套件、中繼資料、公開文件、圖示,以及支援、隱私與條款連結。
  • 測試整備度:提交前測試 MCP 工具,並附上評估證據 (若有)。

發布商資格

若要提交 MCP 伺服器認證申請,您必須是已驗證發行者。 您的組織必須:

  • 擁有一個Microsoft Partner Center帳戶,並完成商業驗證。
  • 已註冊加入 Microsoft 365 與 Copilot 計畫。
  • 擁有或控制你要提交的 MCP 伺服器端點。

如果你是獨立出版商,且不擁有底層服務,你就無法直接投稿。 您必須與服務業主合作或完成驗證後,才能申請認證。

改變的是什麼

更新後的認證程序對提交路徑、套件需求和發佈介面進行了變更。

Area 更新的指引
合作夥伴中心的供應項目類型 使用M365 與 Copilot 的應用程式與代理程式來提交新的 MCP 認證申請。
套件 所有 MCP 提交現在都需要資訊清單檔、工具檔案、intro.md檔案以及 Azure Key Vault 驗證設定。
現有已認證 MCP 透過先前程序認證的 MCP 無需僅因程序變更而採取動作;Microsoft 會將這些 MCP 轉換至新路徑。
發佈介面 除了 Copilot Studio 之外,Azure Foundry 預計也將提供經過認證的 MCP 伺服器,並視實際情況提供更廣泛的 Microsoft 365 系統管理中心探索與治理介面。
套件定義 附上 Microsoft 套件與圖示指引的連結,讓發行者遵循正確的大小、商標、安全區域、對比及影像需求。 請參閱準備 Teams 商店提交。

認證過程

整體過程很簡單:準備套件、將其提交至合作夥伴中心、通過驗證和審查,然後發佈並維護已認證的 MCP 伺服器。

Step Stage 會發生什麼事
1 準備您的包裹 組合 MCP 伺服器套件,包括資訊清單、工具定義、驗證詳細資料、必要中繼資料、公開文件、圖示和任何支援成品。
2 透過合作夥伴中心提交 使用適用於 M365 和 Copilot 的應用程式與代理程式供應項目類型建立新的供應項目。 上傳套件並提供必要的商業、法律、支援及發行者資訊。
3 自動驗證 Microsoft 會驗證套件結構、必要欄位、結構描述正確性、中繼資料完整性和基準原則整備度。 您必須先修正阻斷性問題,審查才能繼續進行。
4 功能與安全審查 Microsoft 會審查 MCP 伺服器的功能性、端點行為、驗證、安全性、合規性、遙測整備度及負責任 AI 考量。 評估證明有助於加速審查。
5 審核與出版 核准後,已認證的 MCP 伺服器會發佈至支援的 Microsoft 探索與執行階段介面。 已認證的 MCP 預計可在 Copilot Studio 和 Azure Foundry 中搜尋到,並視實際情況獲得 Microsoft 365 管理員治理支援。
6 維護和更新 讓實作與已認證套件保持一致。 在採用新工具、重大中繼資料變更或影響認證體驗的套件變更時,重新提交更新。

套件定義和商標

對於圖示大小、安全區域規則、商標和對比等套件資產,請使用 Microsoft 365/Teams 套件指引做為提交整備度的參考依據。 請參閱準備 Teams 商店提交。

封裝區域 公開指引應包括
資訊清單與工具定義檔案 描述 MCP 伺服器、工具、提示/資源 (如適用)、端點設定和工具結構描述。
驗證與測試設定 包含支援的驗證詳細資料、測試認證或設定指示,以及驗證所需的任何環境設定。
中繼資料和公開文件 提供顯示名稱、簡短與詳細描述、類別、發行者資訊、支援連結、隱私權/條款連結和簡介文件。
商標與應用程式資產 使用必要的 Microsoft 365/Teams 套件圖示與影像指引,以了解色彩圖示、外框/預設圖示、調整大小、安全區域、對比和商標。 請參閱準備 Teams 商店提交。
評估證據 (若有) 包含代表性功能與安全測試證據。 這些證據對於驗證預期行為並加快審查很有幫助,特別是對高風險動作或 AI 驅動行為來說。

Important

Microsoft 僅支援在資訊清單與工具定義檔案中使用美國資訊交換標準碼 (ASCII) 的標頭名稱和值。 非 ASCII 字元可能導致驗證失敗。

資訊清單檔

資訊清單檔是包含 MCP 伺服器定義、工具定義、驗證設定、中繼資料、公開文件和任何支援成品的 JSON 檔案。 檔案必須遵循規定的結構,並包含所有必要資訊,以便 Microsoft 在認證過程中驗證 MCP 伺服器。 以下是資訊清單檔的範例結構:

{
  "$schema": "https://developer.microsoft.com/json-schemas/teams/v1.30/MicrosoftTeams.schema.json",
  "version": "1.30",
  "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。 您也可以在 Power Platform 連接器 GitHub 存放庫中查看其他 intro.md 檔案。

Tip

在 intro.md 檔案 中加入已知問題與限制區段,讓使用者隨時掌握資訊並協助他們避免常見問題。 例如,如果您的 MCP 伺服器有特定工具或動作的問題,請在此區段記錄問題並提供任何因應措施。

發佈和可用性

獲得認證核准後,Microsoft 會將 MCP 伺服器發佈到支援的探索與執行階段介面。 認證的 MCP 可在 Azure Foundry、Cowork、Copilot chat 及 Copilot Studio 中取得。 在適用情況下,已認證的 MCP 也應與用於啟用、部署或管理組織 Agent 和工具的 Microsoft 365 管理員治理及探索體驗相符。

認證後責任

認證後,發行者需負責維護認證體驗:

  • 讓 MCP 實作與認證套件及公開文件保持一致。
  • 確保支援、隱私權、條款及中繼資料連結的正確性。
  • 監視服務健康情況、遙測和執行階段品質,確保認證體驗持續可靠。
  • 新增工具、變更認證中繼資料或進行重大行為變更時,重新提交套件更新。

FAQ

動態客戶端註冊(DCR)支援嗎?

不,DCR 現在不支援。

如何設定 金鑰保存庫?

若要設定與 Azure Key Vault 的驗證,請執行下列步驟:

  1. 使用 Azure 入口網站在 Azure 租用戶中建立 Azure Key Vault。

  2. 將下列祕密儲存在 金鑰保存庫 中:

    所需的祕密:

    • ClientId
    • ClientSecret
    • TokenUrl

    選用祕密 (視識別提供者設定而定):

    • AuthorizationUrl(OAuth2 IdentityProvider 需要)
    • RefreshUrl
    • Scopes
    • AzureActiveDirectoryResourceId(AAD IdentityProvider 必填)
  3. 建立 Microsoft 應用程式的服務主體:

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

    將此服務主體金鑰保存庫祕密使用者 (或同等 RBAC 讀取權限) 授與 Azure Key Vault,讓認證服務可以在進行驗證時取得祕密。

  4. 將 金鑰保存庫 URI 新增至 MCP 資訊清單:

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

    authorization.referenceId 必須是 Azure Key Vault URI。

    Example:

    "authorization": {
      "type": "AzureKeyVault",
      "referenceId": "https://contoso-mcp-kv.vault.azure.net/"
    }
    
  5. 封裝並提交 MCP 認證套件。

在認證驗證期間,服務會安全地從參考的 Azure Key Vault 擷取 OAuth 設定。

識別提供者有哪些需求?

下表列出每種身分識別提供者類型所需的 金鑰保存庫 祕密:

身份驗證服務商 必要的 Azure Key Vault 祕密
OAuth2 ClientId、ClientSecret、AuthorizationUrl、TokenUrl
OAuth2 + 刷新權杖 ClientId、、 ClientSecret、 AuthorizationUrl、 TokenUrl、 RefreshUrl
具權限範圍的 OAuth2 加上 Scopes
Azure AD ClientId、ClientSecret、TokenUrl、AzureActiveDirectoryResourceId

祕密名稱是否區分大小寫?

Yes. 祕密名稱區分大小寫,應完全符合:

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

authorization.referenceId 應使用什麼值?

對 authorization.referenceId 使用 金鑰保存庫 URI (而非祕密 URI)。