你已經做出一個可以回答問題的 MCP server，卻在「上架給別人用」這一步看到 ZIP、OAuth、網域驗證與掃描，甚至遇到「OAuth client ID is required when using pre-defined OAuth client credentials」。這篇 ChatGPT Plugin 上架教學把這些步驟接成一條路，讓你知道每一關要交什麼、錯誤應該往哪裡查。
文章寫給第一次發布工具的開發者，也讓沒有 OAuth 背景的讀者看懂流程。以下依據截至 2026 年 10 月 6 日的 OpenAI Plugin 提交指南與驗證文件。我們沒有你的開發者帳號或 MCP 端點，因此介面專屬欄位與連線結果，請依本文檢查表在自己的草稿中逐項核對。
先說結論：ChatGPT Plugin 上架是「包裹＋連線＋審查」
一句話記住：公開 Plugin＝描述功能的 ZIP 包裹＋可連線的遠端 MCP server＋能讓審查者走完的驗證與測例。 ZIP 像商品外盒，告訴平台名稱、說明與連到哪個服務；MCP server 是真正工作的店面；OAuth 是需要私人資料時的門禁；掃描和人工審查則確認店面能安全提供承諾的服務。官方說明：上傳 ZIP 建立草稿，處理自動檢查，再送交審查；核准後由開發者選擇發布。
ChatGPT Plugin 上架前：先決定匿名唯讀，還是登入後讀取
先用一個例子貫穿全文：做一個「公開活動查詢」工具，輸入活動主題，回傳你自己公開網站上的活動名稱、日期與頁面網址。它只讀公開資料、沒有使用者帳戶，因此可以先走匿名唯讀路線。OpenAI 的驗證指南指出，許多唯讀、匿名的 MCP server 可以這樣運作；只要會讀取顧客專屬資料或執行寫入，就應設計使用者驗證。
- 公開查詢：只有公開資料，不需替每個使用者認身分；先驗證工具描述與回傳資料是否準確。
- 查個人行程：資料屬於登入者，MCP server 要在每次請求驗證權杖與權限；這時才進入 OAuth 路線。
- 新增或刪除行程：屬於會改變外部狀態的工具；不要把它標成唯讀，並為誤操作設計額外保護。
對新手最有用的切法是：先讓公開查詢順利連線，再把私人資料與 OAuth 加入第二版。本文的 ZIP 範例沿用同一個公開查詢服務；OAuth 小節則說明切換成「個人行程」後會增加哪些關卡。若你還在規劃工具邊界，可以先讀 Agent Harness 是什麼，了解模型與外部工具如何分工。
第一步：把遠端 MCP 與 Plugin ZIP 分開準備
ZIP 裡放的是 Plugin 清單與 MCP 連線設定；真正的工具程式仍在你的公開 HTTPS 伺服器上。先讓伺服器的 /mcp 端點可連線，並讓工具名稱、輸入結構、輸出及說明與實際行為一致。OpenAI MCP server 指南建議用 MCP Inspector 檢查初始化、工具清單、正常及錯誤輸入；本機可用 npx @modelcontextprotocol/inspector，公開提交則要換成正式 HTTPS 端點。
為這個公開活動查詢工具建立 plugin.json 與 mcp.json。下面是包裝骨架，其中 example.com、開發者名稱、分類與網站政策網址，都要換成你有權使用的真實資料；工具本身須先在伺服器部署。OpenAI 的包裝文件提供相同的根目錄結構與 streamable-http 連線型別。
event-reader/ ├── plugin.json └── mcp.json
{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "event-reader",
"version": "1.0.0",
"description": "查詢公開活動資訊",
"author": {"name": "Example Team"},
"extensions": {"com.openai": {"interface": {
"displayName": "Event Reader",
"shortDescription": "查詢公開活動",
"longDescription": "依活動主題查詢公開活動名稱、日期與原始頁面。",
"developerName": "Example Team",
"category": "Developer Tools",
"capabilities": ["Search"],
"websiteURL": "https://example.com",
"supportURL": "https://example.com/support",
"privacyPolicyURL": "https://example.com/privacy",
"termsOfServiceURL": "https://example.com/terms"
}}}
}
{
"$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
"mcpServers": {
"events": {
"type": "streamable-http",
"url": "https://example.com/mcp"
}
}
}
把上面的 JSON 存成對應檔案，再把示意品牌、分類與網址換成你的真實資料。進入 event-reader 目錄後執行 zip -r ../event-reader.zip plugin.json mcp.json。用 unzip -l ../event-reader.zip 確認兩個檔案在 ZIP 根目錄，而不是藏在多一層資料夾裡。這個 ZIP 只示範最小結構，送審前還要補齊真實的公開頁面、測例、影片與審查資訊。
第二步：ChatGPT Plugin 上架遇到 OAuth client_id，先辨認三條路
當工具改成讀取「我的行程」，OAuth 的 client_id 就像門禁系統認得的訪客證號；它識別的是 ChatGPT 這個 OAuth 用戶端，不是你的 OpenAI API key，也不是 MCP server URL。依官方驗證文件，ChatGPT 可使用三種用戶端識別方式；選哪一種，要配合你的授權伺服器能力與 Plugin 連線設定。
- ① CIMD：授權伺服器宣告
client_id_metadata_document_supported: true；ChatGPT 使用 HTTPS 用戶端中繼資料文件網址作為client_id。符合官方所述的 issuer 條件時，穩定網址為https://chatgpt.com/oauth/client.json；其他情況使用含 callback ID 的文件網址。管理頁會顯示該連線的確切值。 - ② DCR：授權伺服器提供
registration_endpoint；ChatGPT 動態註冊並取得專屬client_id，之後沿用該連線的註冊資料。 - ③ 預設 OAuth client：先在你的身分服務建立可用的 OAuth 用戶端，再把那個用戶端的 ID 與所選驗證方式對上。若介面顯示
OAuth client ID is required when using pre-defined OAuth client credentials，先核對選擇的路徑與 ID 來源，再檢查授權伺服器的用戶端紀錄。
這句錯誤來自社群提問；目前公開官方文件能支持「三種路徑」與 OAuth 需要正確 client 身分，但不能證明每個帳號介面的同一錯誤都由同一欄位造成。具體做法是：在自己的 MCP 連線管理頁記下選定方式、頁面顯示的 redirect URI 與 client 資訊；在授權伺服器確認相同的用戶端存在、允許該 redirect URI，且它的憑證仍有效。若你其實打算走 CIMD 或 DCR，就先確認服務端中繼資料確實宣告對應能力，再重新連線。
無論選哪條路，授權伺服器中繼資料須有 code_challenge_methods_supported: ["S256"]；MCP 端要提供 protected resource metadata，登入後每次工具呼叫都要核對權杖的 issuer、audience、期限與 scopes。官方也要求把管理頁顯示的確切 production redirect URI 加入身分服務 allowlist，不要自行猜一個共用回呼網址。這一層可以想成「門禁名單、入場證與可進房間」要彼此對得上。
第三步：上傳 ZIP，完成網域驗證與工具掃描
在 OpenAI Platform 的 Plugins 選擇擁有者組織與專案，確認個人或企業 Developer identity 已完成驗證，再用 Upload new or existing plugin 上傳 ZIP。官方說組織擁有者可提交；其他成員需要 Apps Management Write 權限。上傳完成進入草稿後，先看 Metadata & Skills 的自動檢查結果，逐項修正再重新上傳。
接著在草稿的 MCPs 選取服務，按 Connect 核對 MCP URL 與 Authentication。Portal 會給一段網域驗證 token：把原樣純文字放到它指定的 https://<challenge-base-host>/.well-known/openai-apps-challenge，確認網址回應只有那段 token。通過後連線、完成必要的 OAuth，等待自動工具掃描，檢查掃出的工具名稱、描述、輸入輸出結構與 issues；修正伺服器後用 Reconnect 或 Rescan 再看一次。
把「公開活動查詢」跑一遍：輸入活動主題，工具應回傳公開活動與可開啟的原始網址；輸入不存在的活動主題，應清楚回傳空結果；要求它刪除活動時，應維持唯讀邊界。伺服器提供的 readOnlyHint、openWorldHint、destructiveHint 要符合真實行為，官方 Plugin 規範要求三者明確標示。想理解為何系統驗收比工具名稱重要，可接著讀 Agent Harness 實作教學。
第四步：把審查資料做成別人真的能照走的路線
工具掃描通過後，正式送審的服務仍要有真實用途與穩定內容；目前提交指南要求準備五個正向測例、三個反向測例、可觀看的功能影片與版本說明。正向測例寫清楚情境、使用者提問、預期工具與結果；反向測例描述什麼情況工具不應行動、原因與安全回應。先用同一個測試帳號走完全部測例，再填進 Review information。
如果工具需要登入，另外在 Review details 提供專用審查帳號、登入網址、測試資料與操作步驟；憑證留在私密審查欄位，別包進 ZIP。審查帳號要能立即操作，避免審查者卡在人工核准、一次性簡訊或私有網路。影片應實際展示主要工具和測例；沒有自訂 UI 的工具，按官方要求處理截圖，不要用裝飾截圖湊資料。最後選擇草稿，按 Submit for review 並完成政策確認；核准後再按 Publish plugin。
三個常見卡點：用症狀回推是哪一關
- ZIP 上傳失敗：先查 ZIP 根目錄、JSON 語法、清單欄位與公開網址；從
Metadata & Skills → Issues → Copy issues取到精確錯誤再修。 - OAuth 連線失敗：核對 CIMD／DCR／預設 client 路徑、授權伺服器 discovery、
S256、redirect URI、client 紀錄與 token scopes。若是既有連線回invalid_client，官方排查文件建議確認動態註冊的 client 及其 secret 是否仍有效。 - 掃描結果不對：先在 MCP Inspector 看伺服器實際宣告的工具，再回 Portal 比對掃描快照；修正服務端的描述與 annotation 後部署，重新掃描。申請表的解釋不會自動改掉伺服器送出的 metadata。
常見問題：ChatGPT Plugin 上架的八個短答案
1. 有 MCP server 就能直接公開嗎？
還要完成包裝與提交。 公開 Plugin 流程包括 ZIP、草稿檢查、MCP 連線掃描、審查資料及核准後發布；單純能在本機連線只是起點。
2. ZIP 需要放伺服器原始碼嗎？
這個遠端 MCP 範例的 ZIP 放清單與連線設定。 工具服務由你的 HTTPS 端點提供；若 Plugin 另含 skills 或資產，再按清單所引用的檔案一起打包。
3. 唯讀工具一定要 OAuth 嗎？
看資料邊界。 只讀公開資料可先做匿名模式；讀取某位使用者的私人資料，即使不修改，也要辨認並授權該使用者。
4. client_id 是 OpenAI API key 嗎？
不是。 OAuth client_id 識別登入流程中的用戶端；API key 是另一種憑證。先確認你選的是 CIMD、DCR 還是預設用戶端，才能找到該核對的值。
5. CIMD 和 DCR 怎麼選？
從身分服務能力開始。 有 CIMD 支援與政策配置時，官方建議優先考慮 CIMD；若使用 DCR，服務端須提供註冊端點並保留已註冊的 client。
6. 網域 token 放哪裡？
放在 Portal 指定的 HTTPS 網域與 /.well-known/openai-apps-challenge 路徑。 回應內容只放指定 token 純文字，不要包成 JSON。
7. 掃描完成就等於審核通過嗎？
不等於。 掃描是自動檢查與工具快照；送審還要填好測例、影片及必要的審查帳號，提交後等待審查結果。
8. 服務端工具更新後，要再上傳 ZIP 嗎？
依變更內容判斷。 官方目前說已發布 Plugin 的 hosted MCP 工具變更可由掃描處理；Plugin 清單、metadata 或 skills 的變更則需要新 ZIP 版本。
給新手的最後檢查
- 先用一個公開、唯讀的工具把連線與回傳結果驗清楚，再決定是否加入私人資料。
- ZIP 的兩個檔案在根目錄；MCP 端點是可公開連線的正式 HTTPS 網址。
- 選了 OAuth，就要說得出 client_id 從哪條路取得，並核對 redirect URI、PKCE 與 scopes。
- 網域驗證、工具掃描、五正三反測例、影片與審查帳號各有自己的驗收結果。
接著閱讀
左右滑動查看更多推薦
下一步：先交出一個能掃描的公開查詢工具
拿「公開活動查詢」作練習：先讓 /mcp 回應一個真的唯讀工具，用 Inspector 檢查正常與錯誤輸入，再把真實網址寫入 ZIP，進 Portal 建草稿、驗網域、看掃描。成功後再評估是否需要 OAuth；這樣你每碰到一個錯誤，都知道它屬於包裹、連線、門禁還是審查。如果你想系統地學習 Agent 工具設計與驗收，可接著看 AlphaLab 的 AI 課程。