MCPレジストリとAIゲートウェイ：アーキテクチャとエンタープライズユースケース

2020年から2023年の間に、次のようなファンデーションモデルがあります GPT-3 そして GPT-4 大規模な言語モデルは人間のようなテキストを生成し、コードを書き、文書を要約し、複雑な質問に答えることができることが証明されました。しかし、これらのモデルは ステートレス そして サンドボックス化、社内のシステム、データベース、アプリにアクセスできず、実際にアクションを取る方法もありませんでした。

モデルに尋ねることができます：

」MongoDB クエリを記述して、コンプライアンスデータベースのすべてのコレクションを一覧表示します。」

次のような出力が生成されます 見た 有効なMongoDBクエリのようですが、

• かどうかわからなかった データベースが存在しました
• 何が分からなかった コレクションです DBに存在していた
• かどうかわかりませんでした クエリも実行される
• する方法はありませんでした スキーマの検査、 結果を確認、または フォローアップアクションをトリガーする 他のシステムへの要約や通知など

それがすべてだった 当て推測 — と フィードバックループなし。

これを修正するために、開発者はLLMを中心にレイヤーを構築し始めました。

• プロンプトチェーニング
  
• Python のカスタムラッパー
  
• 文字列テンプレートによる REST API コールインジェクション
  
• 手動コンテキストスタッフィング
  (「次のスキーマを使用して、クエリを記述してください」)

これらは巧妙な修正でしたが メンテナンスが難しい。

のようなフレームワーク ラングチェーン、 ラマインデックス、および セマンティックカーネル これらのワークフローを整理するために登場しました。これらのツールは物事を整理するのに役立ちましたが、問題は解決しませんでした。モデルは未だに幻覚的な世界であり、プロンプト・インジェクションに陥り、検証をスキップし、定義された実際の関数を実行する標準的な方法もありませんでした。新しいユースケースはどれも、やはり車輪の再発明のように感じられました。

本当のターニングポイントは、開発者が次のことに気付いたときでした。

」コマンドを推測するのにモデルは必要ありません。フロントエンドアプリがバックエンド API を呼び出すのと同じように、実際の関数を呼び出す必要があります。」

2023年半ば頃、オープンAIが導入されました 関数呼び出し、モデルが構造化された状態に戻ることを可能にする JSON 実際の関数呼び出しに直接マップされた出力。

モデル統合で可能だったことを再定義しました

• LLMは、明確に定義された入力と出力を使用してツールと連携できるようになりました
  
• モデルは次のように動作しました API クライアント、推測ベースのジェネレーターではなく
  
• タスクは次のようになりました 自動化 複数のステップとシステムとのやりとり

関数呼び出しにより、次のことが台頭しました。 道具 そして エージェント — アクションを連鎖させ、ワークフローに従い、実際のシステムと相互作用できるモデル

しかし...
1。すべての実装は ベンダー固有。
2。共有はありませんでした 標準フォーマット ツールがどのように記述されたか、または呼び出されたかについて。

ここは MCP （モデルコンテキストプロトコル）が登場 — として提案 汎用のオープンプロトコル モデルと外部ツール間の構造化された通信用。MCP では、ツール API を各 LLM アプリにハードコーディングする代わりに、 AI ツール接続用ユニバーサル充電器 — 好き OpenAPI、 アントロピック などはLLM呼び出しツール用です。以下に基づいています。 JSON-RPC 2.0は、JSON を使用したリモートプロシージャコール (RPC) をサポートする、広く使用されている仕様です。

MCP が定義する内容

• モデルがツールメソッドを呼び出す方法 (RunAggregation など)
  
• パラメーターを渡して構造化された応答を取得する方法
  
• ツールが利用可能なメソッドをどのように記述するか（スキーマやマニフェストによる記述方法）
  
• ツール統合のための軽量な標準規格 あらゆるバックエンド （DB、CLI、クラウドAPI）

MCPは、モデルとツールの間のAPI契約だと考えてください。標準プロトコルがなければ、あらゆる統合に 個別のエンジニアリング が必要となり、コストがかかり、エラーが発生しやすく、反復的でした。MCPは、 共通の言語を生み出すことで、ツール統合を完全に簡素化しました。しかし、MCPとは一体何なのか、そして実際にどのように機能するのでしょうか？詳しく見ていきましょう。

モデルコンテキストプロトコル

‍MCP（モデルコンテキストプロトコル） は 軽量なプロトコル であり、 AIモデル と 外部ツールの間で構造化された通信を行うために特別に構築されました。

MCPの核となるのはJSON-RPC 2.0です。これは、構造化された入出力でリモートプロシージャを呼び出すための実績あるプロトコルであり、LLMの出力を現実世界のツール呼び出しに変換するのに最適です。

では、 なぜ別のプロトコルを開発するのでしょうか？

既存の選択肢としては、 REST あるいは GraphQL は、AIファーストのワークフローには、汎用性が高すぎたり、冗長すぎたり、あるいは単に脆すぎたりします。MCPは、明確な構造、最小限のオーバーヘッド、そしてAI中心のワークフローへの明確な焦点を当てることで、このギャップを埋めます。これは既存のAPIを置き換えるものではなく、モデルがAPIを安全に、繰り返し、予測可能に利用できるようにするためのものです。

• ホストアプリ：ツールの呼び出しをオーケストレーションし、LLMの出力を処理し、応答を連鎖させます — 例：Mongoをクエリし、結果を要約し、アラートを送信するGRCエージェント。
• MCPサーバー：listCollections、runAggregation、sendMessageToSlackなどのドメイン固有のロジックを実装します。
• MCPクライアント：リクエストのフォーマット、認証、リトライを処理し、ホストを適切なMCPサーバーに接続する最小限のライブラリです。

サーバーは通常、以下を公開します。

• ツール：listCollections、runAggregation、sendSlackMessageなどの実行可能なコマンド。
• リソース：スキーマ定義、コレクションメタデータ、データベース構造などの記述データ。

オプションとして、サーバーは以下も公開できます。

• プロンプト: 標準化されたエージェントプロンプト/テンプレート
• クライアントサイドプリミティブ: キャッシングまたはバッチ処理のヒント
• 通知: リアルタイムイベントストリーム (SSE経由)

トランスポートオプション: STDIO 対 HTTP/SSE

MCPはトランスポート非依存であり、2つのモードをサポートします。

どちらのトランスポートも同じJSON-RPC形式に従うため、ロジックを書き換えることなくトランスポートを切り替えることができます。

これがMCPの大きなアイデアです。脆弱なプロンプトの接着剤なしで、モデルがツールを呼び出すための最小限かつクリーンな方法を提供します。幻覚的なコマンドも、手動でのコンテキスト詰め込みもありません。ただ明確な入力と出力があるだけです。しかし、実際のアプリケーションではどのように機能するのでしょうか？MongoDBを活用したコンプライアンスアシスタントの例を見てみましょう。

Mongo-MCPを使用したGRCワークフローの自動化

GRC（ガバナンス、リスク、コンプライアンス）アシスタントを構築していると想像してみてください。

このアシスタントは以下のことを行う必要があります。

• MongoDBデータベースからコレクションと監査ログを取得する
• コンプライアンス担当者向けに調査結果を要約する
• Slackで関係チームに通知する
• オプションで、GitHubでフォローアップの課題を登録する

従来のセットアップでは、RESTコールやPythonスクリプトを使用してこのロジックをハードコードし、スキーマや認証情報をプロンプトテンプレートに詰め込むことになります。その結果、すべての統合がカスタムで、かつ脆弱なものとなるでしょう。

MCPを使用すると、MongoDB、Slack、GitHubといった各ツールがファーストクラスの関数プロバイダーとなり、以下のような明確に定義されたメソッドを公開します。

• listCollections
• runAggregation
• メッセージを送信
• 課題を作成

GRCエージェント（当社のホストアプリ）は、MCPのJSON-RPCスキーマを使用してこれらのツールを呼び出すだけです。

シナリオ：ポリシー違反の検出と報告 ユーザー指示：「今日のポリシー違反についてコンプライアンスデータベースを確認し、Slackでチームに通知してください。」

1. ユーザー入力 → ホストアプリ → LLM GRCエージェント（ホストアプリ）はユーザーメッセージをモデルに送信します。モデルはツールを認識し、次のように応答します。

{
  "tool_calls": [
    {
      "name": "listCollections",
      "arguments": {
        "database": "compliance"
      }
    }
  ]
}

2. ホストアプリがMCPクライアント経由でMongo-MCPを呼び出す このツール呼び出しはJSON-RPCリクエストに変換されます。

{
  "jsonrpc": "2.0",
  "method": "listCollections",
  "params": {
    "database": "compliance"
  },
  "id": "req-001"
}

3. Mongo-MCPが関数を実行 Mongo-MCPはこの呼び出しを以下にマッピングします。

def listCollections(database: str) -> List[str]:
    return mongo_client[database].list_collection_names()

関数を実行し、結果を取得して、次のように応答します。

{
  "jsonrpc": "2.0",
  "result": [
    "audit_logs",
    "policy_violations",
    "user_sessions"
  ],
  "id": "req-001"
}

4. エージェントが次の呼び出しを連鎖：runAggregation モデルは、利用可能なコレクションに基づいて後続の呼び出しを生成します。

{
  "tool_calls": [
    {
      "name": "runAggregation",
      "arguments": {
        "database": "compliance",
        "collection": "policy_violations",
        "pipeline": [
          { "$match": { "timestamp": { "$gte": "2025-08-05" } } },
          { "$group": { "_id": "$severity", "count": { "$sum": 1 } } }
        ]
      }
    }
  ]
}

これにより、Mongo-MCPへの別のJSON-RPC呼び出しが行われ、サーバーは次を返します。

{
  "jsonrpc": "2.0",
  "result": [
    { "_id": "high", "count": 5 },
    { "_id": "medium", "count": 12 }
  ],
  "id": "req-002"
}

エージェントはこの結果を、次のようなプロンプトとともにモデルに渡します。

「このポリシー違反データを平易な英語で要約してください。」

モデルは次のように返答します。

「今日、コンプライアンスデータベースで重大度が高いポリシー違反が5件、中程度の重大度のポリシー違反が12件ありました。”

5. モデルがSlack-MCPを呼び出してチームに通知 エージェントは最終的な構造化ツール呼び出しを発行します。

{
  "tool_calls": [
    {
      "name": "sendMessage",
      "arguments": {
        "channel": "#compliance-alerts",
        "message": "5 high and 12 medium policy violations detected today. Please review."
      }
    }
  ]
}

Slack-MCPサーバーがメッセージを送信し、ワークフローが完了します。これらすべては、文字列操作やプロンプトエンジニアリングではなく、構造化されたJSON呼び出しを通じて行われました。

Governing Enterprise AI at Scale: The MCP Gateway Blueprint

$2 Million

The

Wake-Up Call

Your integration architecture determines whether AI becomes a competitive advantage or unmanageable risk.

A Fortune 500 Spent $2M Fixing Ungoverned AI

Don't let this be you, get the complete Al governance blueprint.

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

MCP GatewayにMCPサーバーレジストリが必要なのはなぜですか？

Mongo-MCPのデモはすっきりしています。モデルは構造化されたツール呼び出しを行いました。各機能は期待通りに動作しました。ハルシネーションはありません。壊れやすい文字列テンプレートもありません。しかし、それは理想的なケースに過ぎません。実際のシステムは、単に動作するだけでなく、大規模な環境で安全に、信頼性高く、監視可能に動作することが求められます。

本番環境では、生のMCPにはいくつかの重要な点で不十分な点があります。

1. アクセス制御（RBAC）なし 生のMCPには、誰が何を呼び出せるかを制限する組み込みの方法がありません。.

• 集計の実行は許可したいが、deleteCollectionはブロックしたい場合はどうしますか？
• モデルが特定のデータセット（例：財務部門が人事データにアクセスできないなど）のみを照会すべき場合はどうしますか？

実際の組織では、RBAC（ロールベースアクセス制御）は不可欠です。特にモデルが機密性の高いツールに接続されている場合はなおさらです。

2. 認証またはAPIキーなし 生のMCPは以下を処理しません

• どのエージェントまたはモデルが呼び出しを行っているかを検証すること
• チーム、環境、またはプロジェクトごとに資格情報をスコープすること
• トークンの有効期限切れまたは失効

これは、mcpサーバーにアクセスできる人なら誰でも任意のツールを呼び出せることを意味します。そして、監査証跡も残りません。

3. 監視可能性なし 見えないものは修正できません。

• What’s the latency of each tool call?
• What’s the failure rate or retry count?
• Which tools are being overused or timing out?

With raw MCP, you don’t have dashboards, logs, or traces. You’re flying blind.

4. No Guardrails LLMs are creative — sometimes too creative.

Raw MCP has:

• No token limits (e.g. prevent massive aggregations)
• No result-size bounds (e.g. returning 5MB from Mongo)
• No circuit breakers or pause prompts (e.g. “Are you sure you want to send this Slack alert?”)

Without guardrails, one prompt bug can lead to thousands of Slack messages or accidental data wipes.

5. No Retry, Throttling, or Quotas In production

In production, tools don’t always behave perfectly — they can fail, time out, or respond slowly. Without safeguards, even well-behaved models can:

• Hit rate limits
  
• Hammer services with retries
  
• Expose sensitive tools to misuse
  

The raw MCP protocol assumes everything just works — a “happy path” world. But real-world infrastructure is messy. You need smart retry logic, caching, rate limiting, and access control to stay sane at scale.

• Authentication + token-based access
• RBAC per model, user, org, and tool
• Observability and tracing
• Quotas, limits, and retry strategies
• Approval workflows for sensitive actions

This is exactly what the TrueFoundry Gateway provides.

From Single-Server Demos to Enterprise-Grade Agent Workflows

In the first half of this article we learned what the Model-Context-Protocol is and used a Mongo mcp server to automate a legacy GRC platform. That toy example is great for a hack-day, but it quickly runs into real-world friction:

TrueFoundry’s AI Gateway packages the missing plumbing—an MCP registry, central auth, RBAC, guard-rails, and rich observability—so teams can move from “hello-world agent” to production safely and repeatedly.

What the Gateway Adds on Top of Raw MCP

TrueFoundry positions one of the best MCP gateway as a control-plane that sits between your agents (or Chat UI) and every registered MCP server and LLM provider.

Key capabilities include:

1. Central MCP Registry – add public or self-hosted servers once; discover them everywhere 
2. Unified credentials – generate a single Personal-Access-Token (PAT) or machine-scoped Virtual-Account-Token (VAT) that is automatically exchanged for per-server OAuth / header tokens behind the scenes 
3. Fine-grained RBAC – restrict which users, apps, or environments can see or execute which tools 
4. Agent Playground & built-in MCP client – rapid prototyping without writing a line of code 
5. Observability & guard-rails – latency, cost, traces, approval flows, rate-limits, and caching baked in 

Think of it as the API gateway + service mesh + secret store for the emerging MCP environment. “As noted in the MCP Server Authentication guide, the Gateway handles credential storage and token lifecycle automatically.”

Hands-On: Registering Your First MCP Server

The very first step in the UI is to create a group—e.g. dev-mcps or prod-mcps. Groups let you attach different RBAC rules and approval flows to different environments.

“You can follow the TrueFoundry MCP Server Getting Started guide for detailed steps.”

AI Gateway ➜ MCP Servers ➜ “Add New MCP Server Group

name: prod-mcps
   access control:
       - Manage: SRE-Admins
       - User  : Prod-Runtime-Service-Accounts

Inside the group choose Add/Edit MCP Server and fill three things : 

You can just as easily add:

• No-Auth demo servers (e.g., Calculator)
• Header-Auth servers that accept a static API key (e.g., Hugging Face) 
• Any number of future servers (Atlassian, Datadog, internal micro-services)

Behind the scenes the Gateway stores credentials in its secret store and handles token refresh.

Authentication & RBAC

TrueFoundry supports three auth schemes per MCP server :

“These modes are described in more detail in the MCP Server Authentication documentation.”

Once a server is registered you don’t hand raw tokens to every developer. Instead they authenticate once to the Gateway and receive:

• PAT – user-scoped, human-friendly, good for CLI / experiments
• VAT – service-account scoped, locked to selected servers, perfect for production apps 

The Gateway checks the calling token against:

1. Group-level permissions (can this user reach any server in prod-mcps?)
2. Server-level permissions (is slack-mcp whitelisted?)
3. Tool-level permissions (can they call sendMessageToChannel?)

If any check fails the request is rejected before it hits your Slack workspace.

From Playground to Code: The Agent API

After experimenting in the UI you can click “API Code Snippet” to generate working Python, JS, or cURL examples .Below is a trimmed JSON body that wires three servers together (GitHub, Slack, Calculator):

POST/api/llm/agent/responses

{
  "model": "gpt-4o",
  "stream": true,
  "iteration_limit": 5,
  "messages": [
    {
      "role": "user",
      "content": "Summarize open PRs on repo X and DM me the top blockers."
    }
  ],
  "mcp_servers": [
    {
      "integration_fqn": "truefoundry:prod-mcps:github-mcp",
      "tools": [ {"name": "listPullRequests"}, {"name": "createComment"} ]
    },
    {
      "integration_fqn": "truefoundry:prod-mcps:slack-mcp",
      "tools": [ {"name": "sendMessageToUser"} ]
    },
    {
      "integration_fqn": "truefoundry:common:calculator-mcp",
      "tools": [ {"name": "add"} ]
    }
  ]
}

“You can find a similar example in the Use MCP Server in Code Agent guide, which also includes complete Python and JS snippets.”

The streaming response interleaves:

1. assistant tokens (LLM reasoning)
2. tool-call chunks (function name + incremental arguments)
3. tool-result events (JSON output) 

This lets you build reactive UIs that show each step of the agentic loop in real time.

Observability, Guardrails & Policy

Even a “hello world” agent can cost real money and do real damage. TrueFoundry ships first-class observability:

• Latency / error dashboards – TTFT, task latency, HTTP errors, tool retries 
• Token & cost tracking – attribute spend per model, per team, per feature flag 
• OpenTelemetry traces – hop-by-hop spans across agent, MCP proxy, and LLM 
• Rate-limits & caching – prevent runaway loops and reuse identical web-search results
• Guard-rail hooks – enforce PII-scrubbing, NSFW filters, or “human-in-the-loop approval” on any destructive tool 

All metrics come out of the box; no side-car agents or custom exporters required.

Supporting All MCP Transports (HTTP & STDIO)

Many open-source servers still speak stdio (stdin/stdout) instead of HTTP. TrueFoundry recommends wrapping them with mcp-proxy and deploying as a regular service 

# wrap a Python stdio server
mcp-proxy --port 8000 --host 0.0.0.0 --server stream python my_server.py

Ready-made templates exist for Notion and Perplexity servers, plus K8s manifests for Node or Python images. Once proxied, registration is identical to any other HTTP MCP endpoint.

“TrueFoundry’s MCP Server STDIO guide covers this proxying approach and provides deployment templates.”

Example Walk-Through: Enterprise Compliance Bot

Let’s return to our legacy GRC scenario but crank the ambition up:

“Keep our compliance evidence up-to-date. If a policy file changes in GitHub, store the diff in MongodB, create a Jira ticket, and post a summary in Slack.”

Servers Involved

Flow

1. GitHub webhook hits a cloud function.
2. The function calls the Agent API (VAT token) with the four servers enabled.
3. LLM reasons → calls github.getFileDiff → mongo.insertDocument → jira.createIssue → slack.sendMessage.
4. Each tool call and result is streamed back; observability captures latency of every hop.
5. If the diff is > x (certain number of lines of code, as threshold), a guard-rail inserts “requires manual approval” and pauses execution; a security lead can approve via the Gateway UI.

Governance

• The VAT attached to the function only sees the four listed servers—least privilege.
• Separate dev and prod groups let you test against a sandbox Jira and staging Slack.
• Auditors can replay any incident: traces + full JSON payloads are retained 30 days by default.

Extending the Ecosystem: Building Your Own MCP Server

Because MCP is just JSON-RPC over HTTP or stdio, any internal service can expose tools, here is a small example : 

• Drop this container into your Kubernetes cluster.
• Register it in the dev group with No-Auth while developing.
• Change to Header-Auth または OAuth2 prod-mcpsに移行する前に。

その時点から、 あらゆる 社内のエージェントは、SlackやGitHubとまったく同じ操作性でコンプライアンス管理について推論できます。

ベストプラクティス チートシート

「このシートは、 TrueFoundry MCP概要を基に作成されました。これらのガイドラインは、安全で信頼性の高いデプロイメントを確実にするのに役立ちます。」

まとめ 

MCPにより、大規模言語モデル（LLM）はツールと同じ言語を話すことができますが、エンタープライズレベルでのセキュリティ、検出、ガバナンスといった機能は扱えません。そこでTrueFoundryのAIゲートウェイが登場します。これは、完全な MCPレジストリ、組み込み認証、ロールベースアクセス制御（RBAC）、詳細な可観測性、そしてこれらすべてを連携させる強力なエージェントAPIなど、チームが必要とするあらゆる機能をすぐに利用できる形で提供します。

よくある質問

AIシステムにおけるMCPレジストリとは何ですか？

MCPレジストリは、利用可能なモデルコンテキストプロトコル（MCP）サーバーとその特定の機能を保存・管理する一元化されたカタログです。AIエージェントが検索可能なディレクトリとして機能し、ツールやリソースを動的に検出できるようにします。このレジストリにより、モデルは複雑な多段階タスクを実行するために必要な適切なサービスを特定できます。

MCPレジストリとAIゲートウェイの違いは何ですか？

MCPレジストリがツールの受動的なディレクトリであるのに対し、AIゲートウェイはトラフィックを管理する能動的な強制レイヤーです。レジストリはシステムにどのようなリソースが存在するかを伝えますが、ゲートウェイは、モデルリクエストの実際の実行中に、アクセスを制御し、認証を処理し、PIIマスキングやレート制限などのセキュリティポリシーを適用します。

AIゲートウェイはMCPレジストリなしで機能できますか？

AIゲートウェイは、静的構成を使用すればMCPレジストリなしでも機能しますが、動的なツール検出の柔軟性が失われます。レジストリがない場合、開発者はすべてのサーバー接続を手動でハードコードする必要があり、システムの拡張性や保守が困難になります。レジストリを統合することで、新しいツールがエコシステムに追加されるたびに、ゲートウェイが自動的に適応できるようになります。

AIゲートウェイは、MCPレジストリからのポリシーをどのように適用するのですか？

AIゲートウェイは、MCPレジストリからメタデータとガバナンスルールを取得し、リアルタイムで受信リクエストを検証します。レジストリで定義されたユーザー権限とセキュリティ要件を相互参照し、適切なサーバーにトラフィックをルーティングします。これにより、すべてのやり取りが組織の標準およびデータレジデンシープロトコルに準拠していることが保証されます。