一個端點，接入所有 MCP 伺服器
別再讓 MCP 工具定義燒光你的情境。
onemcp 將你所有的 Model Context Protocol（MCP）伺服器統一到一個入口端點背後。AI 用戶端只需連接一次——入口負責路由、原生 OAuth 與 Code Mode，讓代理直接撰寫指令碼呼叫工具，而不必淹沒在成堆的工具定義裡。
~90%系統提示更精簡
1個端點，接入 N 個伺服器
3個中繼工具，而非上百個
~/.config/mcp.json
{ "mcpServers": { "github": { "url": "github.mcp", "auth": "ghp_…" }, "slack": { "url": "slack.mcp", "auth": "xoxb-…" }, "postgres": { "url": "pg.internal", "auth": "pg_…" }, // 還有 +17 個伺服器 } } // 20 個伺服器 · 每次請求 480+ 個工具
# 問題所在
每個工具都是獨立的伺服器、獨立的登入，還有一整面工具定義的高牆。
每個 MCP 伺服器都會在 每一次請求 中向提示灌入成百上千條工具定義——模型還沒開始做事，情境與費用就已經被燒掉了。
不用 onemcp~15,000 tokens
每一條工具定義，每一次請求
使用 onemcp~500 tokens
只需 search · describe · execute
每次請求的情境佔用縮小約 97%——模型把情境視窗花在你的問題上，而不是工具 schema 上。
提示負載 · tools[]
{ "name": "github.create_issue", "inputSchema": { "type": "object", "properties": { repo, title, body?, labels? } } }, { "name": "github.search_issues", "inputSchema": { "type": "object", "properties": { query, state?, sort? } } }, { "name": "github.create_pull_request", "inputSchema": { "type": "object", "properties": { repo, head, base, title } } }, { "name": "slack.post_message", "inputSchema": { "type": "object", "properties": { channel, text, thread_ts? } } }, { "name": "slack.list_channels", "inputSchema": { "type": "object", "properties": { types?, limit? } } }, { "name": "postgres.query", "inputSchema": { "type": "object", "properties": { sql, params? } } }, { "name": "postgres.list_tables", "inputSchema": { "type": "object", "properties": { schema? } } }, { "name": "linear.create_issue", "inputSchema": { "type": "object", "properties": { team, title, priority? } } }, { "name": "notion.create_page", "inputSchema": { "type": "object", "properties": { parent, properties, children? } } }, { "name": "jira.create_ticket", "inputSchema": { "type": "object", "properties": { project, summary, type } } }, { "name": "stripe.create_refund", "inputSchema": { "type": "object", "properties": { charge, amount? } } }, { "name": "sentry.list_issues", "inputSchema": { "type": "object", "properties": { project, query? } } } // …還有 468 條定義，每一輪都要重新傳送
# 解決方案
一個入口，三個工具，其餘交給代理自己寫。
onemcp 把你所有的伺服器都收攏到單一入口端點背後。入口不再暴露每一個工具，而是只暴露三個，讓模型直接撰寫指令碼來呼叫它們——這正是 Cloudflare 的 MCP Code Mode。點擊體驗一次真實的往返呼叫：
portal › search
請求
portal.search({ query: "open a GitHub issue" })
回應
[
{ tool: "github.create_issue", score: 0.98 },
{ tool: "github.search_issues", score: 0.71 }
]代理層是如何協同運作的
你的用戶端始終只與入口對話。它先探索所需的工具，再寫出一段指令碼，在一次呼叫中完成整件事——而不必來回十幾次、還把整套工具塞進每一條提示。
AI 用戶端
Claude · Cursor · 代理
❯_onemcp 閘道
searchdescribeexecute
路由 · OAuth · 依入口授權
MCP 伺服器
GitHubSlackPostgres+17
# 你將獲得
為代理真實的工作方式而打造。
統一端點
讓每個 MCP 用戶端都連接到同一個入口 URL。新增或替換上游伺服器，再也不用改動用戶端設定。
原生上游 OAuth
入口透過完整的 OAuth 流程向上游伺服器驗證——憑證留在伺服器端，絕不散落到各個用戶端。
Code Mode 高效之道
三個中繼工具取代上百條定義。模型直接撰寫指令碼呼叫你的工具，而不必淹沒在它們的 schema 裡。
依入口隔離的授權
同一台伺服器可以在不同入口中攜帶不同憑證——授權作用於成員關係，而非整個帳戶。
入口匯入與匯出
在不同環境間搬移入口，或將一套設定作為單一可攜設定檔分享出去。
請求記錄
檢視流經入口的每一次用戶端請求，方便你除錯代理究竟在呼叫什麼。
# 實證
“比起直接呼叫 MCP，大型語言模型更擅長撰寫程式碼來呼叫 MCP。”
~90%
系統提示更精簡
Zero
工具定義膨脹
20+
個伺服器，一個端點
3
個中繼工具，而非上百個