すべての MCP サーバーに 1 つのエンドポイント
MCP のツール定義でコンテキストを浪費するのは、もう終わり。
onemcp は、あなたのすべての Model Context Protocol（MCP）サーバーを 1 つのポータルエンドポイントの背後に集約します。AI クライアントは一度つなぐだけ——ルーティング、ネイティブ OAuth、Code Mode はポータルが引き受け、エージェントは大量のツール定義に溺れることなく、ツールを呼び出すスクリプトを書けます。
{ "mcpServers": { "github": { "url": "github.mcp", "auth": "ghp_…" }, "slack": { "url": "slack.mcp", "auth": "xoxb-…" }, "postgres": { "url": "pg.internal", "auth": "pg_…" }, // さらに +17 台のサーバー } } // 20 台のサーバー · リクエストごとに 480+ ツール
# 課題
どのツールも、それぞれ独立したサーバー・ログイン・ツール定義の壁を抱えている。
MCP サーバーはどれも、リクエストのたびに 何百ものツール定義をプロンプトに流し込みます——モデルが何かを始める前から、コンテキストとコストを食いつぶしてしまうのです。
すべてのツール定義を、毎リクエスト
search · describe · execute だけ
リクエストごとのコンテキスト占有を約 97% 削減——モデルはツールのスキーマではなく、あなたの課題にウィンドウを使えます。
{ "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 個の定義、毎ターン再送信
# 解決策
1 つのポータル、3 つのツール、あとはエージェントが書く。
onemcp は、あなたのすべてのサーバーを単一のポータルエンドポイントの背後にまとめます。ポータルはすべてのツールを露出させる代わりにたった 3 つだけを公開し、モデルにそれらを呼び出すスクリプトを書かせます——Cloudflare の MCP Code Mode です。実際の往復をクリックで体験してみてください：
portal.search({ query: "open a GitHub issue" })
[
{ tool: "github.create_issue", score: 0.98 },
{ tool: "github.search_issues", score: 0.71 }
]プロキシ層はどう組み合わさっているか
クライアントが話すのは常にポータルだけ。必要なものを見つけ出し、1 回の呼び出しで仕事を丸ごと片づける 1 本のスクリプトを書きます——ツール一式を毎回プロンプトに詰め込んで何十往復もする代わりに。
# 得られるもの
エージェントの実際の働き方に合わせて設計。
統一エンドポイント
すべての MCP クライアントを 1 つのポータル URL に接続。上流サーバーの追加や差し替えに、クライアント設定を触る必要はもうありません。
ネイティブな上流 OAuth
ポータルは完全な OAuth フローで上流サーバーへ認証します——認証情報はホスト側に留まり、各クライアントに散らばりません。
Code Mode の効率
3 つのメタツールが数百の定義を置き換えます。モデルはスキーマに溺れることなく、あなたのツールを呼び出すスクリプトを書きます。
ポータル単位の認証スコープ
同じサーバーでも、ポータルごとに異なる認証情報を持てます——認証はアカウントではなくメンバーシップにひも付きます。
ポータルのインポート／エクスポート
ポータルを環境間で移動したり、構成一式を 1 つの持ち運べる設定ファイルとして共有したり。
リクエストログ
ポータルを通過するすべてのクライアントリクエストを確認でき、エージェントが実際に何を呼んでいるかをデバッグできます。
# 根拠
“LLM は MCP を直接呼び出すよりも、MCP を呼び出すコードを書く方が得意だ。”