如果你有兩個以上的 MCP server，就會開始想：到底放哪裡、怎麼讓 agent 找得到？
先講結論
我用 MCP Registry 在本機起了一個 registry，當成「內網工具目錄」。搭配 publisher CLI 發佈 demo server，最後用一個小腳本做 registry lookup。對我來說它是 Worth Watching / Incremental：很實用，但目前還是早期，適合先在內網跑起來試。
這篇只講四件事：
- MCP Registry 是什麼、為什麼我需要它
- 用 Docker 快速跑起 registry
- 如何發布一個 server 進 registry
- 我在 OpenClaw/ClawdBot 的整合方式
這個工具解決什麼問題
MCP server 目前很像「散落在 GitHub 的 npm 套件」：
- 每個 repo 的 README 都不一樣
- 版本資訊、健康狀態、維護者可靠度難判斷
- agent 想用工具時，得先知道 repo 在哪
GitHub MCP Registry 想做的事情很直白：把 MCP servers 集中成一個可搜尋的目錄，並且提供 VS Code 的一鍵安裝、排序、信任訊號（stars / 活躍度）。
對我來說，最有用的是：我可以在內網先跑一套 registry，讓 agent 只看得到我核准的工具。
安裝與設定
環境需求
- Docker
- （可選）Go 1.24.x，如果要跑完整 dev-compose
方式 A：直接跑官方 image（最快）
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:latest跑起來後，我用 http://localhost:8080 作為 registry endpoint。
方式 B：完整開發環境（有 Postgres）
# 需要 repo
# https://github.com/modelcontextprotocol/registry
make dev-compose這個方式會啟動 Postgres，適合你想測試完整 publish 流程。
發佈一個 demo MCP server
這裡我用官方提供的 publisher CLI。
make publisher
./bin/mcp-publisher --help我做了一個最小的 server metadata（假資料），再發佈到本機 registry。
{
"name": "openclaw-log-summarizer",
"description": "Summarize CI logs for OpenClaw pipelines",
"version": "0.1.0",
"endpoint": "http://localhost:9001",
"maintainer": "me@openclaw.local"
}發佈後，我在 registry 裡能看到這個 server，後續 agent 就能 lookup 它。
這一步我最有感的是：有 publisher 之後，server 變成「可管理的資產」，不是散落的 repo。
在 OpenClaw/ClawdBot 的整合方式
我做了一個很小的 lookup script：
// registry-lookup.ts
import fetch from "node-fetch";
const REGISTRY = "http://localhost:8080";
async function search(name: string) {
const res = await fetch(`${REGISTRY}/v0/servers?query=${name}`);
const data = await res.json();
return data.items?.[0];
}
const server = await search("openclaw-log-summarizer");
console.log(server);實際上我把它包成一個小 function：
- agent 先 query registry
- 找到 server endpoint 後自動註冊到 MCP host
- 失敗就 fallback 到內建工具
這樣的好處是：我的 agent 不需要寫死工具列表，換掉 server 也不需要改 prompt。
跟現有工具比較
我過去其實是用一個 JSON 檔自己管理 MCP server 清單。效果可以，但有兩個痛點：
- 沒有驗證（任何人可以塞一個 URL）
- 沒有版本 / metadata
Registry 解決了這兩件事，而且未來可以接 GitHub 的信任訊號。這對企業或內網環境特別重要。
踩坑紀錄
1) API 還在早期
目前 API v0.1 還在 freeze，代表不會大改，但也不算正式 GA。我在內網用可以，對外服務就要保守一點。
2) 本機 publisher 沒有想像中「傻瓜」
你還是得準備 metadata + 環境（OAuth/DNS/HTTP 驗證）。如果你只是想快速測試，建議先用 dev-compose + 假資料。
3) Agent 端的 fallback 邏輯要寫好
Registry 一旦掛掉，agent 不能整個停擺。我加了 fallback 的 local tool list，確保 pipeline 不會死。
結論
- 推薦程度：Worth Watching
- 影響評估：Incremental
- 與我們的關聯：直接可用（內網 registry / agent tool discovery）
- 我會繼續用嗎：會，但先放在內網，等 GA 再擴大
參考來源
- GitHub MCP Registry 介紹：https://github.blog/ai-and-ml/github-copilot/meet-the-github-mcp-registry-the-fastest-way-to-discover-mcp-servers/
- MCP Community Registry Repo：https://github.com/modelcontextprotocol/registry
基於實際安裝測試撰寫，非業配。