AIREITERChatGPT MCP server 的部署，並不是看到 /mcp 有回應就算完成。ChatGPT 還必須能連線、找到正確的工具、驗證使用者身分，並在適當時機選對工具。對大多數團隊來說，託管服務是合理的預設選擇；如果系統必須放在私有基礎架構內，則應考慮 Secure MCP Tunnel。
先決定部署邊界，再開始寫程式
部署邊界會直接影響傳輸方式、驗證工作的複雜度、日常維運負擔，以及 server 能否公開發布。ChatGPT 是遠端 MCP client，不會像部分桌面 client 一樣，直接啟動本機的 stdio 程序（OpenAI Help Center）。
| 部署模式 | ChatGPT 連線方式 | 適用情境 | 主要代價 |
|---|---|---|---|
| 託管公開服務 | 穩定的 HTTPS Streamable HTTP endpoint | 大多數團隊與面向客戶的應用程式 | 平台限制與供應商依賴 |
| 自行管理的公開 endpoint | 部署在 container、VM 或 cluster 上的穩定 HTTPS endpoint | 已有平台團隊，且有合規或網路需求 | TLS、擴展、修補、回滾與監控都由團隊負責 |
| Secure MCP Tunnel | 由 OpenAI 託管的 endpoint 將請求轉送至私有 stdio 或 HTTP server | 內部部署系統、私有網路與開發環境 | 健康運作的 tunnel-client 會成為可用性的一環 |
預設採用託管服務，適用於 MCP server 無狀態、流量間歇性出現，而且團隊尚未維運可靠公開應用平台的情況。Vercel 的 route-handler 模式與 Cloudflare 的無狀態 Worker 模式，都能提供 ChatGPT 所需的穩定 HTTPS endpoint；但在選定平台前，務必確認各平台對請求執行時間、串流與狀態保存的限制（Vercel、Cloudflare）。
自行管理公開 endpoint，適用於 server 必須靠近既有資料庫、使用既有身分識別基礎架構、符合資料落地管控，或執行不適合 serverless 執行時間模型的工作負載。只有在團隊已經具備 secrets 管理、部署回滾、告警機制與值班負責人的前提下，這個選擇才真正合理。
使用 Secure MCP Tunnel，適用於不應採用公開入口作為安全邊界的情境。OpenAI 的 tunnel client 會對 api.openai.com:443 建立對外 HTTPS 連線，再將請求轉送到私有 HTTP 或 stdio server；不需要開放任何入站網際網路 listener。OpenAI 的部署文件也明確指出，Secure MCP Tunnel 不符合公開提交所要求的條件，因為公開提交需要穩定且可從公開網路連線的 HTTPS endpoint（OpenAI tunnel documentation、OpenAI build guidance）。
把本機工具推進成可上線的 ChatGPT MCP server
可靠的 ChatGPT MCP server 部署，應該把工具行為、協定行為、正式環境可達性，以及模型路由分成不同關卡驗證。通過其中一關，不代表下一關也一定沒問題。
1. 定義聚焦的工具與穩定契約
先從每個明確的使用者動作各自建立一個工具開始。OpenAI 的建置指南使用分開的 list_projects、get_project 與 update_project 工具，而不是把彼此無關的模式塞進同一個工具（OpenAI developer documentation）。每個工具都需要具體描述動作的名稱、精確說明、明確的輸入 schema、有用的輸出，以及正確的安全性標註。
只有在工具完全不會改變狀態時，才標記 readOnlyHint: true。對不可逆或難以復原的效果，使用 destructiveHint: true；如果工具會存取開放式的外部實體，則使用 openWorldHint: true。OpenAI 說明，這些標註是提供給模型的中繼資料，用來協助工具行為與安全處理；但每個受保護請求的授權，仍必須由 server 強制執行（OpenAI developer documentation）。
如果後續呼叫可能需要更新同一筆紀錄，請在 structuredContent 回傳穩定的紀錄識別碼。Token、secret 與不必要的個人資料，都不要放進 content、structuredContent 或 _meta；OpenAI 特別指出，_meta 雖然對模型隱藏，卻不是安全的儲存空間。
2. 先在本機提供 Streamable HTTP
ChatGPT 通常透過 Streamable HTTP 建立遠端連線，常見路徑是 /mcp。這個路徑是慣例而非硬性要求，但必須將完整的部署 URL 填入 ChatGPT（OpenAI connection guide）。
先在本機啟動 server，再開啟 MCP Inspector：
npx @modelcontextprotocol/inspector@latest讓 Inspector 連線到類似 http://localhost:3000/mcp 的 URL。確認初始化流程、列出工具，接著針對每個工具測試有效請求、錯誤 schema、缺少識別碼與空結果情境。對受保護工具，也要確認缺少憑證或權限不足時會安全拒絕請求。
3. 對外公開前先做好正式環境存取控管
公開 health check，不代表工具介面也應該公開。如果工具只提供刻意公開的唯讀資料，未驗證的 endpoint 或許可以接受；但只要涉及私有資料、使用者專屬資料或會改變狀態的動作，就必須在每個請求上執行驗證與授權（OpenAI build guidance）。
對採用 OAuth 保護的 MCP 而言，server 扮演 resource server。未驗證的請求應回傳 401，並指向受保護資源中繼資料，通常位於 /.well-known/oauth-protected-resource。授權流程應使用 PKCE、限制 scope 的 token、嚴格驗證 issuer 與 audience；如果持久連線需要，也應支援 refresh token（OpenAI Help Center）。
不要只因為 MCP 與上游服務都接受 bearer token，就把 MCP access token 原封不動傳給上游服務。Token 的目標資源必須是實際接收它的服務；下游呼叫應使用服務憑證，或採用合適的 token exchange 設計（MCP deployment security guide）。
4. 部署不可變更的候選版本
先將通過 Inspector 的同一個 build 部署到 preview 或 staging endpoint，再把該 artifact 推進正式環境。正式 endpoint 必須使用 HTTPS、保留完整的 MCP 路徑、能連到所需相依服務，並將 secrets 放在託管平台的 secret store。
如果要採用精簡的 Vercel 參考流程，請安裝 mcp-handler、@modelcontextprotocol/server 與 zod；將回傳的 Web handler 掛載到 app/api/mcp/route.ts；為 GET 與 POST 匯出 handler，然後執行：
npx vercel deploy --prod接著，ChatGPT 的連線 URL 會是 https://your-project.vercel.app/api/mcp 這類形式。Vercel 文件指出，搭配 Fluid compute 時，函式預設執行時間為 300 秒，符合條件的付費設定可獲得更高上限；因此，超過單一請求生命週期的工作，應改放進可恢復的 job，而不是讓閒置串流一直保持開啟（Vercel deployment guide）。除非選用的 runtime 有刻意設計的共享狀態方案，否則請讓 route 保持無狀態。
在連接 ChatGPT 前，先補上四項營運控制：
- 為成本高昂的工具設定請求逾時與速率限制。
- 記錄初始化失敗與工具失敗，但不要記錄 token 或敏感結果。
- 每次呼叫都記錄 release identifier，讓事件發生時能對應到實際部署的程式碼。
- 為工具 schema 或授權回歸問題維護經過測試的回滾流程。
不要只在 localhost 上測試，也要讓 MCP Inspector 連線正式環境 URL。重新確認工具探索、schema、標註、驗證、有效呼叫與錯誤處理。即使應用程式在本機運作正常，load balancer、proxy、CORS 規則或身分提供者重新導向仍可能造成失敗。
用三層架構設計存取控管
ChatGPT MCP 的存取控管包含三個彼此獨立的強制執行層；啟用 OAuth 只處理身分層，並不等於完成授權。
| 層級 | 強制執行位置 | 必須做出的判斷 |
|---|---|---|
| 工作區存取 | ChatGPT 管理控制項 | 誰可以建立、發布、啟用或使用這個 app？ |
| 使用者身分 | OAuth authorization server 與 MCP resource server | 目前是哪個帳號在呼叫？Token 對這個 server 是否有效？ |
| 資源與動作授權 | MCP tool handler 與 backend | 這位使用者是否能在這個 tenant、紀錄或環境上執行這個動作？ |
在 ChatGPT Business 中，管理員或擁有者負責控制 developer mode 與發布流程。Enterprise 與 Edu 工作區則進一步提供 developer access、app access 與 actions 的 RBAC（OpenAI Help Center）。這些控制項只管理 ChatGPT 是否能使用 app，並不能證明呼叫者有權在 backend 編輯客戶 A 的紀錄。
MCP handler 必須從經過驗證的憑證推導身分，並在每次呼叫時執行 tenant 與物件層級的授權檢查。絕對不要把模型產生的參數中所帶的 user ID、organization ID 或 role，當成身分證明。所有工具參數都必須視為不受信任的輸入。
將讀取 scope 與寫入 scope 分開。一個實用的政策可以是廣泛允許 projects:read，只讓編輯者使用 projects:write，並在破壞性操作前重新由 server 執行即時檢查。ChatGPT 可能會對高影響操作要求確認，但確認是使用者體驗上的安全措施，不是授權控制。
Prompt injection 同樣是存取控管問題。工具輸出與擷取到的文件可能包含惡意指令，因此寫入工具應只提供最小必要的動作，並在 server 端驗證允許寫入的欄位。萬用的 execute_action 工具，會同時增加路由判斷的模糊度與潛在影響範圍。
在 ChatGPT 中連接、測試並發布 app
連接 endpoint 會建立草稿 app 與一份中繼資料快照。發布則是把經過審查的設定提供給工作區使用；這兩者都不是部署 server 程式碼本身。
- 依照適用的 ChatGPT 工作區政策啟用 developer mode。
- 開啟 app 建立流程，輸入完整的 HTTPS MCP URL；如果掛載路由是
/mcp，也要一併包含。 - 選擇驗證機制；如有需要，完成 OAuth 流程。
- 執行 Scan Tools，逐一檢查探索到的名稱、schema、標註與動作，然後建立草稿。
- 先在新的聊天中測試草稿，再將它發布到工作區。
如果是私有 server，請在連線設定中選擇 Tunnel，再選取已關聯的 tunnel，或輸入其 tunnel_id。操作人員需要 OpenAI Platform Tunnels Read + Use 權限；ChatGPT developer mode 則仍是另一項工作區權限（OpenAI tunnel documentation）。
中繼資料變更需要明確的生命週期管理。對 developer-mode connection，部署或重新啟動 server，開啟連線後選擇 Refresh，確認變更過的中繼資料，並開始新的對話。OpenAI 目前針對 Business 的指南指出，已發布的 app 若要變更工具或中繼資料，必須重新建立並發布；Enterprise/Edu 管理員則可以重新整理 actions、檢視差異並啟用新 actions，而新 actions 預設會停用（OpenAI Help Center）。
即使如此，伺服器端仍以向後相容的演進策略最安全。可以新增選用欄位與新工具，但不要悄悄改變既有工具的意義。在所有已核准的快照與 client 完成遷移前，保留舊 schema。
測試 ChatGPT 使用者真正會遇到的行為
協定測試只能證明 server 能回應；ChatGPT 測試則要確認模型會選對工具、提供合適參數、遵守邊界，並在不相關時避免呼叫工具。
Reddit 使用者 u/EmailNo8428 說明了這個雙層問題：
「你其實同時在測試兩件事：工具邏輯，以及特定 client 呼叫工具的方式。」（r/mcp）
建立一組小型、具版本控管的評估案例，至少涵蓋以下情境：
| 案例 | 預期結果 |
|---|---|
| 直接請求 | 使用有效參數選取具名能力 |
| 間接請求 | 從使用者目標推斷正確工具 |
| 後續請求 | 沿用前一次回傳的穩定識別碼 |
| 負面請求 | 不呼叫任何 MCP 工具 |
| 缺少權限 | 回傳有用的授權錯誤，且不洩漏資料 |
| 寫入請求 | 選擇範圍最小的寫入工具，並觸發適用的確認流程 |
| 模糊請求 | 要求補充必要資訊，而不是自行捏造參數 |
| 空結果 | 回傳有效的空狀態，而不是傳輸或 schema 錯誤 |
記錄選用的工具、參數、回傳結果、錯誤與確認行為。每當工具名稱、描述、schema、標註、驗證規則或結果格式發生變化，就重新執行受影響的案例；OpenAI 在連線指南中也要求採用相同的重新整理與重新測試週期。
如果 server 通過 Inspector，卻在 ChatGPT 中經常選錯工具，通常代表工具邊界、描述或 schema 還不夠清楚。如果路由選擇正確，卻出現 401、逾時或狀態遺失，問題則多半位於基礎架構或授權。把這兩類問題分開診斷，可以縮短修復週期。
常見問題
ChatGPT 能直接連線到 localhost 或 stdio MCP server 嗎？
不能。ChatGPT 通常連線到遠端 MCP endpoint。OpenAI Secure MCP Tunnel 可以在不開放公開入口的情況下，將請求轉送到私有 stdio 或 HTTP server；臨時 HTTPS tunnel 則可用於開發，但不能用於公開 plugin 提交。
ChatGPT MCP server 一定需要公開 HTTPS endpoint 嗎？
一般遠端連線與公開 plugin 提交都需要穩定的 HTTPS。私有的 developer-mode server 可以使用 Secure MCP Tunnel，讓 server 留在客戶自行控管的環境中。
search 與 fetch 是必要工具嗎？
不是。OpenAI 表示，已連接的 server 不再強制要求這兩個工具。如果 app 必須參與公司知識或 deep-research 的擷取介面，才需要實作標準的 search 與 fetch 契約（OpenAI Help Center）。
為什麼部署後 ChatGPT 還是顯示舊工具？
ChatGPT 會保存已探索到的中繼資料，不會把每次程式碼部署都視為已核准的工具變更。請重新整理 developer-mode connection，並開始新的對話；已發布的工作區 app 則要依照方案適用的審查與重新發布流程處理。