MCP 伺服器該放在哪個網址？我們查了 33 個

公開的 MCP 伺服器都用什麼 URL？

大多是專用的 mcp. 子網域，路徑通常是 /mcp。當時我們正在 mcp.scorestarling.com/mcp 和 ElevenLabs 那種寫法 api.scorestarling.com/v1/mcp 之間猶豫，想知道其他服務實際上怎麼做，就去查了一輪。

2026年10月2日 17:40 至 17:42（UTC），我們對 27 個服務的 33 個網址各送出一個不帶驗證資訊的 POST 請求：請求內容為 {}，帶有 Accept: application/json, text/event-stream 標頭，逾時 8 秒，只記錄狀態碼。401 代表這個網址上有服務回應且需要權杖，受保護的 MCP 伺服器正是這樣開始登入流程的。404 代表這個路徑下沒有任何服務。有些網址是各服務公開的，有些則是我們為了看哪些路徑會回應而嘗試的變體和猜測。這只是一些知名服務的快照，不是普查，其中任何一個之後都可能有所變動。

最實用的教訓來自那幾個 404：MCP 的 URL 無法從網域推斷出來。Stripe 和 Vercel 在不帶路徑的網域上回應，存取 /mcp 反而回傳 404；Higgsfield 正好相反；ElevenLabs 則一定要帶上 /v1。用戶端只會原封不動地使用拿到的 URL，而 RFC 9728 把這個 URL 定為伺服器中繼資料必須相符的識別，所以文件、安裝連結和外掛程式資訊清單裡必須是同一個字串。外掛程式資訊清單的寫法更是五花八門：在我們安裝過的外掛程式中，有直接放在 gitlab.com 主網站路徑上的 gitlab.com/api/v4/mcp，也有 mcp.hubspot.com/anthropic。這兩個我們沒有探測。

MCP 端點該和網站共用同一個網域嗎？

我們認為不該。端點是給軟體用的，連線指南是給人看的，兩者都想佔用那個最直覺的網址。2026年10月2日之前，scorestarling.com/mcp 是我們的 MCP 伺服器，指南只能放在別處；而且每個用戶端都是靠這個 URL 回傳的 401 找到登入入口，它不可能同時又是一個網頁。

我們考慮過在同一個 URL 上同時提供兩者，對瀏覽器回傳網頁、對用戶端回傳 MCP，但沒有把它當成長期做法：對請求的判斷只要錯一次，所有用戶端都會找不到登入入口。傳輸規範還允許用戶端對端點送出 GET 請求來開啟事件串流，預期的回覆是事件串流或 405，而不是 HTML 網頁。

獨立的網域還能讓網站的改動影響不到端點：網站改版動不了它，適合行銷網站的 CDN 快取或瀏覽器人機驗證也永遠不會擋在它前面。AI 助理是從自己的基礎架構、而不是從瀏覽器呼叫伺服器：Anthropic 的連接器文件說，Claude 會從 Anthropic 的雲端發起連線，而身分識別提供者前面的防火牆可能導致登入失敗。我們看過的兩家同業也是這樣拆分（2026年10月2日確認，10月3日再次確認）：Higgsfield 的指南在 higgsfield.ai/mcp，伺服器在 mcp.higgsfield.ai/mcp；ElevenLabs 的指南在 elevenlabs.io/mcp，伺服器在 api.elevenlabs.io/v1/mcp。

我們的 MCP 網域只提供 /mcp 和 /.well-known/*。其他路徑一律以 308 重新導向到網站上相同的路徑和查詢參數，讓登入、授權同意、網頁、下載連結和 Cookie 都留在同一個網域。網站上的 /mcp 現在是 Claude、ChatGPT 等用戶端的連線指南。

$ curl -si "https://mcp.scorestarling.com/login?x=1"
HTTP/2 308
location: https://scorestarling.com/login?x=1

該選 mcp.example.com/mcp、不帶路徑的網域，還是 api.example.com/v1/mcp？

三種都可以，看這個網域上還放了什麼。MCP 授權規範把 https://mcp.example.com/mcp 和 https://mcp.example.com 都列為有效的標準伺服器 URI，並要求採用不帶結尾斜線的形式，除非斜線有實際意義。傳輸規範只要求一個同時接受 POST 和 GET 的端點路徑，範例是 https://example.com/mcp；Anthropic 的連接器文件則用 https://mcp.example.com/mcp。

還有兩條小規則。Streamable HTTP 端點不要以 /sse 結尾：Anthropic 的文件說，在 Claude 的連接器表單裡，以它結尾的 URL 會選用舊的 SSE 傳輸方式。另外，除非真有需要，不要加結尾斜線；回傳 401 的 23 個網址裡，只有 GitHub 的帶有斜線。

如何把 MCP 伺服器搬到新的 URL？

讓新舊兩個網址並行一段時間，而且每個網址都要能獨立完整運作：有自己的 401、自己的中繼資料，兩種受眾的權杖都能用。我們分四步完成搬遷，在 2026年10月2日晚間（UTC）一小時內全部上線：

1. 趁還沒有任何地方用到，先上線別名支援。用一項設定列出以前的網址，每個都必須是 HTTPS、以 /mcp 結尾。權杖的受眾是目前網址或某個別名時才算有效，其他受眾一律拒絕。主機允許清單（Starlette 的信任主機清單和 MCP SDK 的 DNS 重新繫結防護）包含所有網址以及網站本身。沒有設定別名時，正式環境的行為和以前完全一樣。

2. 新增網域，然後在同一次變更中切換網址並設定別名。新子網域先設好 DNS 記錄，大約 6 分鐘後憑證也簽發了；在我們的伺服器被設定為信任它之前，這個網域一直回傳 400。一次設定變更既設好新的資源 URL，也把舊網址列為別名，所以只要重新部署一次，兩者就同時生效。如果在第 1 步上線前就這麼做，執行中的程式會拒絕網站自己的網域。

3. 把所有會被人複製的地方都改指向新網址：連線指南（包括為 Claude、Cursor 和 VS Code 編碼好的一鍵安裝連結）、外掛程式資訊清單和文件。

4. 切換權杖受眾，再停用舊網址。一次資料庫遷移讓我們的存取權杖 hook 改為簽發新的受眾，CI 在程式碼上線前就套用了這次遷移；別名還在時，兩種受眾的權杖都照常可用。接著我們刪除別名並重新部署。在那次發布和重新部署之間的幾分鐘裡，網站的 /mcp 對瀏覽器回傳指南、對 MCP 用戶端回傳伺服器。現在它只提供指南，而指南原本的網址 /connect 會以 308 重新導向過來。

最容易漏掉的是中繼資料。RFC 9728 要求其中的 resource 與用戶端連線時使用的 URL 完全相同，Anthropic 的文件也要求它與使用者在 Claude 中輸入的 URL 一致。所以在新舊並行期間，每個網域都描述自己，每個 401 也都指向本網域的中繼資料文件：

GET https://scorestarling.com/.well-known/oauth-protected-resource/mcp
→ "resource": "https://scorestarling.com/mcp"

GET https://mcp.scorestarling.com/.well-known/oauth-protected-resource/mcp
→ "resource": "https://mcp.scorestarling.com/mcp"

我們沒有對 /mcp 本身做重新導向。傳輸規範沒有說明端點的重新導向，而端點 URL 作為資源和權杖受眾，是 OAuth 交握的一部分，所以我們選擇在兩個網址上同時提供 MCP。其他路徑則用 308 而不是 301，這樣能保留請求方法，因為 RFC 9110 不允許用戶端在收到 308 後把 POST 改成 GET。受眾是怎麼寫進權杖的，請見我們關於 MCP OAuth 的筆記。

我們能搬得這麼快，是因為 ScoreStarling 當時還是僅限邀請的小規模試營運，還沒有人依賴舊網址。別名刪除後，仍設定著 scorestarling.com/mcp 的用戶端必須重新連線。依我們維運手冊的預期，已改用新網址、手上卻還是舊受眾權杖的用戶端，會收到一次 401 invalid_token，接著更新權杖、取得新受眾；不過我們還沒親眼看過真實的 Claude 或 ChatGPT 用戶端這樣做。如果已經有真實使用者，就保留別名，直到舊網址不再有流量。

搬遷過程中出了哪些問題？

過程中出了三個小問題：

• 有個檢查腳本用 resource.replace('/mcp', '/.well-known/oauth-protected-resource/mcp') 組出中繼資料 URL。在舊網址上沒問題；換成 https://mcp.scorestarling.com/mcp 後，//mcp. 裡的 /mcp 也被比對到了，結果變成 https://.well-known/oauth-protected-resource/mcp.scorestarling.com/.well-known/oauth-protected-resource/mcp。正確做法是先剖析 URL，再依各部分組合：通訊協定和主機名稱，接著是 well-known 區段，最後是路徑。
• 網址變長後，在 320 像素寬的螢幕上撐破了指南頁面的版面，直到我們允許行內程式碼換行才解決。
• 用 Railway 的命令列工具刪除別名變數，只會把變更暫存起來；直到我們手動重新部署，舊網址都還是會被接受。

MCP 伺服器網址選擇清單

• 給端點一個專用網域，不在上面放任何給人看的內容；在我們的樣本中，常見做法是 mcp. 加上你的網域。
• 路徑一次定好。/mcp 最常見，不帶路徑的網域也有效；不要加結尾斜線，也不要讓路徑以 /sse 結尾。
• 給人看的連線指南放在主網站上，用一個猜得到的網址，並在導覽列放上連結。
• 為這個確切的 URL 提供 RFC 9728 中繼資料：放在 /.well-known/oauth-protected-resource 加上你的路徑之處，根路徑下也放一份，其中的 resource 要等於用戶端使用的網址。
• 把這個 URL 設為權杖受眾，並在需要搬遷之前就做好別名支援。
• MCP 網域上的其他所有路徑都以 308 重新導向到你的網站，並保留查詢字串。
• MCP 網域上不要啟用瀏覽器人機驗證和 HTML 快取。
• 所有地方（指南、安裝連結、外掛程式資訊清單、文件）都只公布同一個字串，並測試每一處是否一致。
• 搬遷順序：先做別名支援，再於同一次變更中切換新網址、設定別名，接著修改每一處引用、切換受眾，等舊網址沒有流量後再停用。