agent MCP — ユースケース, インストール & ライブデモ

なぜ使うのか

主な機能

OAuth 2.1 + スコープベース認証を標準搭載
ホットリロード：設定を編集するだけで、再起動なしに新しいアップストリームが反映
すべてのツールコールに対する監査ログ
タグベースのフィルタリングにより、クライアントごとに異なるツールセットを表示
npx @1mcp/agent、バイナリ、またはDockerで実行可能

ライブデモ

実際の動作

agent.replay ▶ 準備完了

0/0

インストール

クライアントを選択

~/Library/Application Support/Claude/claude_desktop_config.json · Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "agent": {
      "command": "npx",
      "args": [
        "-y",
        "agent"
      ],
      "_inferred": true
    }
  }
}

Claude Desktop → Settings → Developer → Edit Config を開く。保存後、アプリを再起動。

~/.cursor/mcp.json · .cursor/mcp.json

{
  "mcpServers": {
    "agent": {
      "command": "npx",
      "args": [
        "-y",
        "agent"
      ],
      "_inferred": true
    }
  }
}

Cursor は Claude Desktop と同じ mcpServers スキーマを使用。プロジェクト設定はグローバルより優先。

VS Code → Cline → MCP Servers → Edit

{
  "mcpServers": {
    "agent": {
      "command": "npx",
      "args": [
        "-y",
        "agent"
      ],
      "_inferred": true
    }
  }
}

Cline サイドバーの MCP Servers アイコンをクリックし、"Edit Configuration" を選択。

~/.codeium/windsurf/mcp_config.json

{
  "mcpServers": {
    "agent": {
      "command": "npx",
      "args": [
        "-y",
        "agent"
      ],
      "_inferred": true
    }
  }
}

Claude Desktop と同じ形式。Windsurf を再起動して反映。

~/.continue/config.json

{
  "mcpServers": [
    {
      "name": "agent",
      "command": "npx",
      "args": [
        "-y",
        "agent"
      ]
    }
  ]
}

Continue はマップではなくサーバーオブジェクトの配列を使用。

~/.config/zed/settings.json

{
  "context_servers": {
    "agent": {
      "command": {
        "path": "npx",
        "args": [
          "-y",
          "agent"
        ]
      }
    }
  }
}

context_servers に追加。保存時に Zed がホットリロード。

claude mcp add agent -- npx -y agent

ワンライナー。claude mcp list で確認、claude mcp remove で削除。

ユースケース

実用的な使い方： agent

チームごとに異なるツールを提供するマルチテナントMCPゲートウェイを構築する

👤 異なるツールニーズを持つ複数チームにサービスを提供するプラットフォームチーム ⏱ ~45 min advanced

使うタイミング： デザインチームとエンジニアリングチームで異なるMCPが必要だが、ゲートウェイを2つ運用したくない場合。

前提条件

Node 20+またはDockerが動作するホスト — 小規模なVMで可
OAuth IdP（ローカル用にはビルトインも利用可） — Dex、Auth0、Okta — OIDCに対応していれば何でも可

フロー

エージェント設定でスコープを定義する

Draft an agent config where 'design' scope exposes figma and davinci-resolve MCPs, 'eng' scope exposes github, sentry, postgres.✓ コピーしました

→ スコープ付きアップストリームマッピングの設定ファイル
OAuthを接続する

Connect the agent to our Auth0 tenant, map groups to scopes.✓ コピーしました

→ ユーザーが自分のスコープのツールのみ表示される
利用状況を監査する

Show me the last 24h of tool calls by user, grouped by tool name.✓ コピーしました

→ 利用状況レポート

結果： 1つのゲートウェイで、チームごとのツールビューと完全な監査証跡を実現。

注意点

スコープ設計がすぐに複雑化する — ツールごとのスコープではなく、2〜3個の大まかなスコープ（eng-read、eng-write、designなど）から始める
監査ログがディスク容量を圧迫する — ログを週次でローテーションするか、ログアグリゲーターに転送する

組み合わせ： github · sentry

ホットリロードでカスタムMCPを開発する

👤 自作MCPサーバーをイテレーションしている開発者 ⏱ ~20 min intermediate

使うタイミング： 新しいMCPを開発中で、変更のたびにIDEをリロードしたくない場合。

フロー

開発中のMCPをエージェントに登録する

Add my local dev MCP at node ./my-mcp/dist/index.js under the agent config, tag it 'dev'.✓ コピーしました

→ クライアントにツールが表示される
編集・保存・再試行

I changed the tool. Tell me if the new version is live without me restarting.✓ コピーしました

→ ホットリロードが確認される

結果： MCP開発における高速なイテレーションループ。

注意点

クライアントがキャッシュしている場合、ホットリロードで古いツールハンドルがリークする可能性がある — インターフェースの大きな変更時は、クライアントも再起動する

信頼できないアップストリームMCPにサニタイズ処理を適用する

👤 コミュニティMCPを運用するセキュリティ意識の高い管理者 ⏱ ~15 min intermediate

使うタイミング： コミュニティMCPを試したいが、入力ガードによる二重の安全策を講じたい場合。

フロー

サニタイズを有効にする

Configure 1mcp agent to enable input sanitization on upstream 'community-x', block any tool returning an oversized payload.✓ コピーしました

→ 制限が適用される
動作を検証する

Call a tool from that upstream and confirm sanitization log entries.✓ コピーしました

→ ログにサニタイズされたコールが記録される

結果： コミュニティツールを試す際の影響範囲をより安全に限定。

組み合わせ

他のMCPと組み合わせて10倍の力を

agent + proxy-2

多機能な1mcpと最小構成のtbxark/mcp-proxyを比較する

Run both 1mcp/agent and tbxark/mcp-proxy on the same host and compare tool-call latency through each.✓ コピーしました

agent + jetski

1mcpの上にアナリティクスを追加する

Run 1mcp/agent behind Jetski to get both OAuth and prompt-level analytics.✓ コピーしました

ツール

このMCPが提供する機能

ツール	入力	呼び出すタイミング	コスト
list_tools	(none)	ハンドシェイク — クライアントが自動処理	free
call_tool	name, args	任意のツール呼び出し時	1 upstream call
mcp_add	name, command, args	新しいアップストリームを動的に追加する（管理者専用）	free

コストと制限

運用コスト

APIクォータ: 自身のクォータはなし。アップストリームのクォータに依存
呼び出しあたりのトークン: プロキシによる軽微なオーバーヘッド
金額: 無料、MITライセンス
ヒント: 監査ログは書き込み可能なアップストリームのみに有効化すること — 読み取り専用のログはディスクを圧迫するだけで効果がありません。

セキュリティ

権限、シークレット、影響範囲

最小スコープ： OAuth client config + upstream server credentials

認証情報の保管： 環境変数と設定ファイルで管理。本番環境ではシークレットマネージャーを使用してください

データ送信先： エージェントは設定済みのアップストリームにのみデータを転送します

絶対に付与しない： admin scope to end users — reserve for platform team

監査ログをローテーションしてください — 長期稼働のエージェントはGBレベルのツールコール履歴が蓄積します。
OAuthスコープの安全性はIdPのグループマッピングに依存します。どのユーザーがどのグループに属しているか、四半期ごとに監査してください。

トラブルシューティング

よくあるエラーと対処法

Hot reload didn't pick up my config change（ホットリロードで設定変更が反映されない）

ファイルウォッチャーがマウントされたディレクトリへの権限を持っているか確認してください（macOSのDockerバインドマウントではイベントが検知されないことがあります）。SIGHUPにフォールバックしてください。

確認： docker exec agent kill -HUP 1

OAuth token rejected（OAuthトークンが拒否された）

スコープクレームが設定済みのスコープにマッピングされていません。エージェントログでクレームを確認し、設定を合わせてください。

確認： Decode JWT at jwt.io

Upstream MCP fails health check（アップストリームMCPのヘルスチェックが失敗する）

アップストリームのコマンドを手動で実行し、stderrを確認してください。エージェントログには終了コードのみが記録されます。

確認： docker exec agent sh -c '<upstream command>'

Tool list empty for a user（ユーザーのツールリストが空になる）

そのユーザーのスコープが、ツールの必須スコープタグと一致していません。

確認： Check scope mapping in config vs JWT claims

代替案

agent 他との比較

代替案	代わりに使う場面	トレードオフ
tbxark/mcp-proxy	OAuthなしの最小構成のGoバイナリが必要な場合	認証、ホットリロード、スコープ機能なし
Jetski	フルアナリティクスダッシュボードとDCRが必要な場合	K8s + Postgresのインフラが必要

その他

リソース

📖 GitHub の公式 README を読む

🐙 オープンな issue を見る

🔍 400以上のMCPサーバーとSkillsを見る