ACTIVE DEVELOPMENT - WORK IN PROGRESS

---

MCP Gateway & Registry は、MCP サーバーや AI エージェントから、スキル、チームが構築するあらゆるカスタムアセットまで、組織内のすべての AI アセットを一元管理する、単一のガバナンス対応コントロールプレーンです。Apache 2.0 ライセンスのオープンソースで、Kubernetes（Amazon EKS）、フルマネージドのサーバーレス（Amazon ECS）、または Docker Compose（Amazon EC2）で実行できます。

このプロジェクトは、Model Context Protocol (MCP) 向けのゲートウェイおよびレジストリとして始まりました。複数の MCP サーバーへの安全な単一の入口を提供し、検出とガバナンスを一元化します。チームがサーバーと並行してエージェント、スキル、その他のアセットを登録するようになると、当初から使用していた同じゲートウェイ、アクセス制御、監査モデルを基盤に、汎用的なAI アセットレジストリへと発展しました。

開発の背景

コントロールプレーンがなければ、各チームがそれぞれ手作業で MCP サーバーやエージェントを接続することになります。dotfile ごとに認証情報が分かれ、共有のインベントリも監査証跡もなく、何が存在するのかを検出したり、ガバナンスを適用したりする方法もありません。エージェントはほかのエージェントを見つけられず、サーバーとエージェントはポリシーを共有できない別々のレジストリに存在します。

このプラットフォームは、これをすべての AI アセットに対応する、ガバナンスを適用した単一の入口に置き換えます。サーバー、エージェント、スキル、またはカスタムエンティティを一度登録すれば、自然言語検索で検出し、アクセスを制御してすべての呼び出しを記録する、単一の認証済みゲートウェイを通じて利用できます。あらゆるアセットタイプにわたって、単一のコントロールプレーン、単一のアクセスモデル、単一の監査証跡を提供します。

┌─────────────────────────────────────┐     ┌──────────────────────────────────────────────────────┐
│          BEFORE: Chaos              │     │    AFTER: MCP Gateway & Registry                     │
├─────────────────────────────────────┤     ├──────────────────────────────────────────────────────┤
│                                     │     │                                                      │
│  Developer 1 ──┬──► MCP Server A    │     │  Developer 1 ──┐                  ┌─ MCP Server A    │
│                ├──► MCP Server B    │     │                │                  ├─ MCP Server B    │
│                └──► MCP Server C    │     │  Developer 2 ──┼──► MCP Gateway   │                  │
│                                     │     │                │    & Registry ───┼─ MCP Server C    │
│  Developer 2 ──┬──► MCP Server A    │ ──► │  AI Agent 1 ───┘         │        │                  │
│                ├──► MCP Server D    │     │                          │        ├─ AI Agent 1      │
│                └──► MCP Server E    │     │  AI Agent 2 ──────────────┤        ├─ AI Agent 2     │
│                                     │     │                          │        │                  │
│  AI Agent 1 ───┬──► MCP Server B    │     │  AI Agent 3 ──────────────┘        └─ AI Agent 3     │
│                ├──► MCP Server C    │     │                                                      │
│                └──► MCP Server F    │     │              Single Connection Point                 │
│                                     │     │                                                      │
│  ❌ Multiple connections per user  │     │         ✅ One gateway for all                      │
│  ❌ No centralized control         │     │         ✅ Unified server & agent access            │
│  ❌ Credential sprawl              │     │         ✅ Unified governance & audit trails        │
└─────────────────────────────────────┘     └──────────────────────────────────────────────────────┘

エンタープライズ向けの方法で、サードパーティの OAuth MCP サーバーを導入できます。 ゲートウェイがユーザーごとのエグレス認証を提供するため、Slack、Atlassian、GitHub などの OAuth 保護された SaaS MCP サーバーに接続する際、各ユーザーがサービスへのネットワークアクセスを設定したり、ノート PC に認証情報を保存したりする必要はありません。各ユーザーはアカウントを一度接続するだけです。ゲートウェイが OAuth（3LO）フローを実行し、ユーザーごとのトークンをシークレットマネージャーに保管して、エグレス時に挿入します。これにより、導入に必要な作業を監査可能な単一のチョークポイントに集約できるため、ノート PC ごとの設定や長期有効トークンの分散なしに、チームは新しい SaaS MCP サーバーをエンタープライズ全体で採用できます。

仕組み

ゲートウェイはデータプレーン（TLS、認証検証、バックエンドへのルーティングを担う汎用 nginx リバースプロキシ）で、レジストリはコントロールプレーン（インベントリ、アクセスモデル、監査証跡を管理し、ゲートウェイがルーティングできる対象を決定する FastAPI サービス）です。認証サーバーは OAuth2/OIDC に対応するためにお使いの ID プロバイダー（Keycloak、Entra ID、Okta、Auth0、Cognito、PingFederate）と連携し、MongoDB / DocumentDB は設定、埋め込み、セッション、監査記録を保存します。

flowchart LR
    Users["Human Users"] -->|HTTPS| GW
    Agents["AI Agents"] -->|MCP / auth| GW
    Assistants["Coding Assistants"] -->|MCP / OAuth| GW
    subgraph GWBOX["MCP Gateway & Registry"]
        GW["nginx reverse proxy<br/>(data plane)"] -->|auth_request| Auth["Auth Server"]
        GW --> Reg["Registry API + UI<br/>(control plane)"]
    end
    Auth -.->|validate| IdP["Identity Provider"]
    GW -->|routes to| Servers["MCP Servers, Agents, Skills<br/>(anywhere: EKS / ECS / Lambda / SaaS)"]

デフォルトでは、レジストリが A2A の検出、認証、アクセス制御を担い、その後、エージェント同士がゲートウェイ経由ですべての呼び出しをルーティングするのではなく、直接通信（ピアツーピア）します。設計の全容と不変条件については、システムの理論をご覧ください。レイヤー別の図については、アーキテクチャ図をご覧ください。

実際の動作を見る

MCP サーバー、A2A エージェント、外部レジストリが連携して動的なツール検出を行う様子をご覧ください。

https://github.com/user-attachments/assets/97c640db-f78b-4a6c-9662-894f975f66e2

その他の解説動画はデモ動画をご覧ください。

該当する項目から始めてください...

あなたの役割	まずはこちら
開発者	完全セットアップガイドから始めてください。MacBook で実行するには、macOS セットアップスキルもお試しいただけます。次に、AI コーディングアシスタントの統合ガイドに従って AI コーディングアシスタントを接続してください。プログラムからアクセスする場合は、OpenAPI 仕様、Python 登録クライアント（registry_client.py）、CLI（registry_management.py）をご覧ください。
プラットフォーム／セキュリティ／運用チーム	Amazon EKS（Helm）、Amazon ECS（Terraform）、Docker Composeのデプロイガイド、認証ガイド、設定リファレンス、アクセス制御とスコープをご覧ください。
導入を検討する意思決定者	エグゼクティブブリーフを読み、デモ動画を視聴し、AWS ワークショップをお試しください。

クイックスタート

最も手軽なのは、ビルド済みの Docker イメージを使う方法です。クローンし、いくつかのシークレットを設定して、実行します。

git clone https://github.com/agentic-community/mcp-gateway-registry.git
cd mcp-gateway-registry
cp .env.example .env

# Edit .env and set the required secrets (e.g. KEYCLOAK_ADMIN_PASSWORD, SECRET_KEY).
# See docs/configuration.md for the full list.
nano .env

# Deploy with pre-built images (pulled from Amazon ECR Public by default)
./build_and_run.sh --prebuilt

# Open the Registry UI (served by nginx on port 80)
open http://localhost        # macOS  (Linux: xdg-open http://localhost)

完全インストールガイドでは、Amazon EC2 へのインストール手順を詳しく説明しています（前提条件、MongoDB と Keycloak の初期化、最初のユーザーとサービスアカウントの作成、サーバーの登録、ゲートウェイのテスト）。

別の環境にデプロイしますか？

• Amazon ECS：Terraform スタックの READMEをご覧ください。より簡単な方法として、Terraform セットアップスキルを使えば、AI コーディングアシスタントにデプロイを実行させることができます。
• Amazon EKS：Helm チャートをご覧ください。
• macOS で試してみたいだけですか？：macOS セットアップスキルを使えば、MacBook で一連のセットアップを実行できます。

含まれるもの

レジストリには、組み込みのアセットタイプが4種類と、管理者が定義するカスタムタイプがあり、すべて単一のコントロールプレーンで管理できます。

• MCP サーバー：単一の認証済みゲートウェイを通じて、MCP サーバーを登録、検出し、アクセスを管理します。
• エージェント（A2A）：エージェントを登録し、機能に基づいて互いを検出できるようにします。デフォルトでは、エージェント間の通信はピアツーピアで行われます。
• スキル：再利用可能な SKILL.md スキルを登録、バージョン管理、検出し、登録時にセキュリティスキャンを実施します。
• カスタムエンティティ：管理者は、スキーマ駆動の独自エンティティタイプ（n8n ワークフロー、ポリシー、プロンプトテンプレート、モデルカードなど）を定義できます。詳しくはカスタムエンティティタイプをご覧ください。

これらすべてで、セマンティック検索と字句検索、UI、REST、MCP ネイティブインターフェース、統一されたガバナンスを利用できます。主な機能は次のとおりです。

• あらゆる HTTP 通信の AI ゲートウェイとして利用：モデル推論（OpenAI、Amazon Bedrock、OpenAI 互換のあらゆるエンドポイント）、MCP サーバー、A2A エージェント、および汎用 REST エンドポイントの前段に、認証済みの単一エントリーポイントを設けます。呼び出し元が保持するのはゲートウェイトークンのみです。バックエンドの URL と認証情報はレジストリに保存され、保存時に暗号化されて、送信時に注入されます。エンティティごとのストリーミングに対応し、他のすべての機能と同じスコープ、監査、レート制限が適用されます。デフォルトでは無効です。設計 · FAQ：OpenAI と Bedrock
• 単一の認証済みゲートウェイ：エントリーポイントは1つです。既存の IdP（Keycloak、Entra ID、Okta、Auth0、Cognito、PingFederate）を使った OAuth と、きめ細かなスコープに対応しています。
• 動的なツール検出：エージェントやコーディングアシスタントは、ハードコードされた設定ではなく、自然言語によるセマンティック検索で実行時にツールを見つけます。
• 仮想 MCP サーバー：多数のバックエンドのツールを、ツールごとのアクセス制御を備えた単一のエンドポイントの背後に集約します。
• ユーザーごとの送信時認証（3LO / OBO / PAT）：ゲートウェイがサードパーティ SaaS の認証情報を仲介するため、トークンをユーザーのノートパソコンに保存する必要はありません。
• セキュリティスキャンとフェイルクローズ方式の登録ゲート：登録されたすべてのサーバー、エージェント、スキルをスキャンし、安全でないものは審査のため保留します。
• 外部レジストリとのフェデレーション：Anthropic の MCP Registry、AWS Agent Registry、およびピアレジストリを取り込み、統一されたインターフェースを提供します。
• 監査ログ：コンプライアンス対応やインシデントレビューに役立つ、認証情報のマスキング機能を備えた、アクセスと管理イベントの完全で追跡可能な監査証跡を提供します。
• オブザーバビリティ：OpenTelemetry メトリクスとヘルスモニタリングを内蔵しています。

新機能

• 仮想サーバーの認証情報ブローカーとルートエンドポイントのルーティング - 仮想 MCP サーバーから、ユーザーごとの認証情報を必要とするバックエンドサーバーをフロントエンドできるようになりました。バックエンドへのホップでは、直接呼び出しと同じ認証情報の払い出し・注入処理が、解決済みのバックエンドパスをキーとして実行されるため、異なる認証情報モードを持つ2つのバックエンドサーバーを1つの仮想サーバーの背後に配置し、それぞれに個別の認証情報を払い出せます。呼び出し元は、仮想サーバーとバックエンドサーバーの両方に対する許可を持っている必要があり、書き換え後の正確なリクエストに基づいて確認されます。また、呼び出し元自身のゲートウェイトークンが、登録者の管理下にあるバックエンドに転送されることはありません。同じ変更により、仮想サーバーからステートレスな Streamable HTTP バックエンドをフロントエンドできるようになりました。別途、append_mcp_path: false で登録されたサーバーは、MCP クライアントがリダイレクトを追従しない末尾スラッシュ付きの形式だけでなく、サーバーが提示するパスそのものでもアクセス可能になりました。1.33.0 リリースノート
• インターネットへの直接アクセスがないネットワーク向けフォワードプロキシの送信通信 - 外部 MCP サーバーへの唯一の送信経路が企業のフォワードプロキシであるレジストリでは、外部 MCP サーバーにアクセスできず、1.31.0 ではブラウザーでのサインインも完了できませんでした。原因はどちらも同じです。httpx が環境プロキシのサポートを独自のデフォルトトランスポートにしか組み込まない一方、SSRF 対策済みクライアントとプールされたログイン用クライアントはそれぞれ独自のトランスポートを指定しているため、HTTP_PROXY と HTTPS_PROXY が黙って無視されていました。EGRESS_FORWARD_PROXY_ENABLED=true にすると、設定済みのプロキシを通じて両方の通信がルーティングされます。判定にはオペレーターのリストではなく DNS 分類を用い、解決されたすべてのアドレスがパブリックの場合にのみ対象をプロキシ経由にするため、クラスター内サーバーの IP ピン留めは設定なしで維持されます。名前解決と分類は、CONNECT の前に引き続き完全に実行されるため、クラウド認証情報、メタデータ、リンクローカル、予約済みアドレス、マルチキャストの拒否も引き続き機能します。また、シークレットを含むリクエストでは https だけが許可されるため、認証情報はトンネル内を通ります。代償も隠さず明記しています。パブリックな宛先をプロキシ経由にする場合、CONNECT トンネルではリクエスト URL から TLS のホスト名が取得されるため、IP リバインドのピン留めは無効になります。TLS をインターセプトするプロキシには EGRESS_FORWARD_PROXY_CA_BUNDLE を使用できます。この設定では、デフォルトのルート証明書を置き換えるのではなく、その上にバンドルを読み込みます。このフラグを有効にすると、HTTP_PROXY が AWS SDK の通信先も変更するため、NO_PROXY でクラウド認証情報エンドポイントを除外していない場合は起動を拒否します。デフォルトでは無効です。1.32.0 リリースノート · FAQ：フォワードプロキシの設定 · オペレーターガイド
• バックエンドの識別、ツール単位のセキュリティ、高速化されたホットパス - initialize に応答する前に OAuth を要求する MCP サーバーをオンボーディングする際、静的ベアラートークンをレコードに保存し、それをヘルスチェック、ツール検出、セキュリティスキャンのすべてに使う必要がなくなりました。これまでは、検出に限定する方法がありませんでした。これらはユーザーの背後にないヘッドレス呼び出しのため、レジストリには提示できるものがほかにありませんでした。1つのリゾルバーが、3つの階層から最大1つの認証情報を選択します。マシン用の client_credentials グラント、所有者が一度同意するとレジストリがボールトから借りるユーザーごとの OAuth 2.1 ID、または obo_exchange サーバー用のゲートウェイのアプリ専用トークンです。個人の認証情報と借用した ID は、プリンシパル、プロバイダー、サーバーを共有するため、purpose がボールトのアドレスの一部となり、コーデックがこれを AEAD に組み込みます。これにより、書き込み権限を持つ攻撃者に対しても両者を分離できます。借用した ID はツールを一覧表示するだけで、ツールを呼び出すことはありません。tools/call がレジストリの Python に到達することはなく、nginx が呼び出し元自身のヘッダーを使ってプロキシします。スキャナーによってフラグが付けられたツールは、個別にブロックされるようになりました。そのため、誤検知が1つあっても、同じサーバー上のほかのツールまで利用できなくなることはありません。ブロックは管理者権限やワイルドカードの許可より優先され、再スキャン時に調整されるため、古いブロックは解除できます。また、すべての読み取り用ビューからツールを隠します。検索では、これまで固定の 1.0 を返していた箇所で関連度を評価するようになり、アプリ内のレイテンシーは641msから86msに短縮されました。送信呼び出しでは、SSRF 検証済みの IP をキーにしたプール済み HTTP クライアントを再利用するため、IP リバインドに対する安全性を維持したままプーリングできます。1.31.0 リリースノート · 認証 · OBO トークン交換
• あらゆるリソースに対応するゲートウェイ — 推論、MCP、A2A、REST を1つの AI ゲートウェイで - ゲートウェイは MCP サーバーだけでなく、あらゆる HTTP バックエンドをフロントエンドするようになりました。1つの認証済みエントリポイントで、モデル推論（OpenAI、Amazon Bedrock、または OpenAI 互換エンドポイント）、MCP サーバー、A2A エージェント、カスタムエンティティとして登録されたあらゆる汎用 REST エンドポイントという4種類のトラフィックを扱えます。呼び出し元は1つのゲートウェイトークンを使い、レジストリ URL 経由ですべてにアクセスします。バックエンド URL とその認証情報はレジストリ内に保存され、保存時に暗号化され、送信時に注入されるため、プロバイダーのキーがノート PC に渡ることはありません。レコードごとに、各呼び出し元は自身のキーを持ち込みます（呼び出し元によるパススルー）。これはデフォルトであり、リクエストの背後に人がいる場合に適した選択肢です。プロバイダーにはユーザーごとに1つのクライアントとして認識されるため、クォータと課金の帰属を明確に保てます。共有のオペレーターキーも任意で使用でき、帰属させるエンドユーザーがいないサービス間通信を想定しています。エンティティごとのレスポンスストリーミングでは、SSE と AWS event-stream のボディを段階的に転送し、同時実行数、バイト数、処理時間に上限を設けます。すべての呼び出しは、レジストリのほかの機能と同じスコープ、監査証跡、レート制限を通ります。従来の methods: ["all"] 許可では HTTP メソッドは認可されないため、意図せずアクセス権が付与されることはありません。デフォルトでは無効（GATEWAY_GENERIC_PROXY_ENABLED=false）で、エンティティごとに有効化でき、スキーマの移行は不要です。設計 · 運用ガイド · FAQ：ゲートウェイ経由で OpenAI または Bedrock を呼び出す · FAQ：アップグレードによる変更点
• 再利用可能な送信通信の強化と IdP 認証による埋め込み - 統合されたフェイルクローズ型の SSRF／送信通信ガードが、すべての外部フェッチを管理するようになりました。復号された認証情報は検証済みの宛先に正確に結び付けられ、エンティティ群全体でトークンを含まないレスポンスビューが一貫して適用されます。また、AWS_EC2_METADATA_DISABLED=true により、認証サーバーとレジストリのタスクで boto3 の IMDS 認証情報フォールバックを無効にします。セマンティック検索用の埋め込みには、IdP によって保護された OpenAI 互換エンドポイント（LiteLLM など）を使用できます。EMBEDDINGS_AUTH_MODE=idp を設定すると、レジストリは呼び出しごとに OAuth2 クライアント認証情報トークンを取得してキャッシュします。また、エンベロープ形式ではないエンドポイント向けの raw_array アダプターと、Microsoft Entra v1 の api:// スコープのパススルーにも対応しています。1.29.0 リリースノートを参照してください。 以前の主な変更点 → 機能とリリースの主な変更点 · バージョンごとの詳細は、リリースノートおよびGitHub Releases ページをご覧ください。

ロードマップ

ロードマップは、GitHub マイルストーンページで確認するのが最適です。ユーザーごとのエグレス認証（3LO と OBO）および A2A トラフィックルーティングは1.27.0で、あらゆる HTTP リソースに対応するゲートウェイは1.30.0で、バックエンドの OAuth ID とツールごとのブロック機能は1.31.0でリリースされました。大まかに言うと、現在次に取り組んでいる主な機能は次のとおりです。

• OBO 向け Keycloak RFC 8693 トークン交換（1.32.0）：Keycloak デプロイメント向けの標準ベースの代理トークン交換です。Keycloak では、トークンのオーディエンスがリクエストスコープではなくサーバー側マッパーによって指定されるため、現在は OBO エグレス経路やバックエンドの検出を利用できません。
• コーディングアシスタント向けクライアント ID メタデータドキュメント：1.31.0 では、レジストリが独自の CIMD を公開していますが、現在は無効の状態でリリースされています。次は ID プロバイダー側に対応し、クライアント ID を事前登録しなくても、プロバイダーを問わずアシスタントが最小限の手間で接続できるようにします。
• Registry Copilot：レジストリ内でアセットを検索し、エージェントを作成するためのチャットおよびエージェントビルダー機能です。#744で管理されており、リリース時期はまだ決まっていません。

機能のリクエストがありますか？GitHub issue を作成してください。私たちはオープンに開発を進めています。

ドキュメント

ドキュメント一式はドキュメントサイトにあり、各ガイドはすべてdocs/フォルダーにもあります。行き詰まったり、質問があったりする場合は、まずFAQ／トラブルシューティングガイドをご覧ください。セットアップ、認証、デプロイ、登録に関する一般的な問題を取り上げています。

対象別の、よく参照されるページ：

はじめに

• クイックスタート · インストールガイド · 設定リファレンス · FAQ／トラブルシューティング

プラットフォームとセキュリティ

• 認証ガイド · アクセス制御とスコープ · ゲートウェイプロキシガイド · AWS ECS デプロイ · Amazon EKS（Helm） · オブザーバビリティ · フェデレーション · フォワードプロキシのエグレス

アーキテクチャと開発

• アーキテクチャ図 · API リファレンス · AI コーディングアシスタントの統合 · MCP Registry CLI

設計上の決定

• アーキテクチャ決定記録（ADR） · ADR 0001：サーバー側 DCR なし

テレメトリ

レジストリは、利用状況の把握を目的として、匿名かつ機密情報を含まないテレメトリ（バージョン、OS、クラウドプロバイダー、アセット数の集計値）を収集します。オプトアウト方式で、デフォルトで有効です。PII、認証情報、エンドポイント、モデル名が送信されることはありません。MCP_TELEMETRY_DISABLED=1ですべて無効にできます。スキーマとプライバシー保護の詳細については、テレメトリのドキュメントをご覧ください。

コミュニティ

• GitHub Discussions：機能のリクエストや一般的なディスカッション
• GitHub Issues：バグ報告や機能のリクエスト
• ロードマップ（GitHub マイルストーン）：今後のリリースと関連する issue
• コントリビューションガイド · 行動規範 · セキュリティポリシー

スター履歴

スター数の推移を示すインタラクティブなグラフ全体は、star-history.comでご覧いただけます。

ライセンス

Apache-2.0 ライセンスの下でライセンスされています。詳細はLICENSEをご覧ください。