MongoDB MCPサーバー：ツール、セットアップ、そして読み取り専用がデフォルトとして推奨される理由

MongoDB MCP サーバーとはどのようなものですか?

ザの MongoDB MCP サーバー MongoDB デプロイメントを AI エージェントが呼び出せるツールとして公開しています。 モデルコンテキストプロトコル は、エージェントが外部システム上のツールを検出して呼び出すことを可能にするオープンスタンダードです。このサーバは、データベース操作をそれらのツールに変換します。

TrueFoundryのドキュメントでは、関数名ではなく機能ごとに説明しているので、このように説明します。

GitHubやNotion MCPサーバーとの構造的な違いは重要です。これらは SaaS API を独自の権限モデルで包み込み、アフォーダンスを元に戻します。これで終わりです。 データベースドライバー接続: 接続文字列でできることは何でも、ツールならできます。MongoDB も TrueFoundry のマネージドカタログには載っていないので、 モンゴDB mcp セットアップ ワンクリック統合よりも難しい作業です。

エージェントが実際に使用していること

貴重なものはチェーンツールを一緒に使用しています。

• プロダクションデバッグ。 チケットには、ユーザーの注文が表示されなかったと書かれています。エージェントは注文スキーマを調べ、そのユーザーの文書を照会し、レコードは存在するが、UI に必要なステータスフィールドがないことを報告します。
• スキーマ考古学。 開発者がデータディクショナリを持たないサービスを継承します。エージェントはコレクションを調べ、ドキュメントをサンプリングし、保存されているものとコードで要求されているものを比較します。
• インデックスレビュー。 ホットコレクションのインデックスを一覧表示し、アプリケーションのクエリシェイプと比較し、サポートインデックスのないクエリにフラグを付けます。
• データ品質チェック。 不変条件に違反している文書の数を数える。フィールドが欠落している、参照先が参照されていない、タイムスタンプが見つからない。

何かに注目してください: 4 つすべてが読み取り専用です。 それが全体の議論です。ほとんどの MCP サーバーでは、読み取りと書き込みの分割は、利便性とリスクのどちらを判断するかの判断基準です。ここでは、読み取り側がほぼすべての値をカバーし、書き込み側がとにかく人間が意図的に行うべき作業を扱います。

そのままの接続でチーム規模で中断する理由

1人のエンジニアがステージング時にローカルMCPクライアントを指さしても問題ありません。本番環境では同じパターンはそうではありません。

書き込みツールには元に戻すことはできません。 エージェントがウェアハウステーブルを削除した場合は、パイプラインを再実行します。MongoDB がライブトラフィックを処理しているコレクションを削除した場合は、バックアップから復元し、前回のスナップショット以降のデータ損失を受け入れ、停止について説明します。インデックスの削除はより微妙で、短期的にはさらに悪いことです。エラーは発生せず、アプリケーションはひそかにパフォーマンスの崖から落ちてしまいます。

エージェントが独自のクエリを作成すると、パフォーマンスが低下します。 エージェントはインデックスを知りません。「前四半期にサインアップしたユーザー数」と尋ねると、モデルはインデックスのないフィールドを喜んでフィルタリングし、MongoDB はコレクションをスキャンして回答します。小さなコレクションでは四捨五入エラーになります。大規模なクラスターでは、本番トラフィック用のサイズのクラスターでは、実際の IOPS やワーキングセットに対する要求と競合します。ウェアハウスクエリが不適切だと、請求書の 1 行分のコストがかかります。この場合、ユーザー側のレイテンシーが発生します。

接続文字列は権限モデルです。 同意画面も、ユーザーごとのスコープも、取り消す権限もありません。すべての通話で1つの認証情報を使用します。書き込み権限があれば、すべてのエージェントリクエストに書き込み権限が付与されます。

即効注入がいつもより遠くまで届きます。 ドキュメントを読み取り、書き込みツールを保持するエージェントは、それらのドキュメントによって操作できます。デバッグタスクでは、指示を含むユーザー指定のフィールドが読み込まれ、代わりにレコードの説明を求められたエージェントがレコードを変更します。間違いは、読み取り作業を行う接続にツールを書き込むことでした。

これのどれもMongoDBの接続に反対するものではありません。その前にコントロールプレーンがあると主張しています。 MCP ゲートウェイ。

Want to try it on a real cluster?

Register your MongoDB MCP server on TrueFoundry, disable every write tool, and hand your team a genuinely read-only database agent.

Get started free

TrueFoundry 経由で MongoDB MCP サーバーに接続する

ドキュメントでは、リモートMCPとして登録された自己実行サーバーについて説明しています。4つのステップがあります。

ステップ1 — 専用のAtlas接続文字列を作成します。 アトラスで開く データベース → 接続 → ドライバ そしてそれをコピーしてください。を作成します。 専用データベースユーザ 下 データベースアクセス 最低限の役割で。ドキュメントには、エージェントの作業にとって最低限必要なこと、つまり探索ワークフローへの読み取り専用アクセスが明記されています。MongoDB はエージェントスタックではなく MongoDB が強制するので、これはセットアップで最もレバレッジの高いコントロールです。読み取り専用ユーザーは、すべてのゲートウェイコントロールが失敗してもコレクションを削除できません。

ステップ 2 — MCP サーバーを実行します。 接続文字列を MDB_MCP_CONNECTION_STRING として設定して、TrueFoundry または独自のインフラストラクチャにデプロイします。ホストされた Studio バージョンの場合は、同じ変数を設定し、認証情報はインラインではなくシークレットストアに保管してください。

ステップ 3 — ネットワークアクセスを許可する。 Atlasは未知のソースをブロックするので、デプロイメントの出力IPを下に追加してください セキュリティ → ネットワークアクセス。正常に起動しても、呼び出しのたびにタイムアウトするサーバーは、ほとんどの場合これです。

ステップ 4 — URL を登録します。 で MCP ゲートウェイ、クリック サーバーを追加 そして選択してください 任意のリモート MCP サーバに接続。

に記入 [名前] (小文字、数字、ハイフン — URL に表示される)、オプション [名前を表示]、a [説明]、 URL 実行中のサーバーの コラボレーター、および 認証データ。

認証の実際の仕組み

MongoDBは、ほとんどのMCP投稿が想定しているOAuthパターンに従っていないため、正確に説明する価値があります。TrueFoundry は分離します。 インバウンド auth (クライアントがゲートウェイに対して自分自身を証明する方法) から アウトバウンド auth（ゲートウェイがアップストリームで自身を証明する方法）。

インバウンド — 4 つの方法:

アウトバウンド — ここでMongoDBはマネージドMCPとは異なります。データベース認証情報は MCP サーバー自身の環境に MDB_MCP_CONNECTION_STRING として存在するため、次のようなものがあります。 OAuth 認証コードフローがなく、登録するリダイレクト URI もありません。誰もクリックしない 今すぐ接続、同意画面はありません。また、取り消すユーザー側の許可もありません。

ゲートウェイからサーバーへのホップの認証タイプは API キー、 OAuth、 AWS SigV4、および トークンパススルーAPIキーは、セルフホストサーバーにとって実用的な選択肢です。

2つのモード。 共有認証情報 — 全ユーザーで1つのキーを共有し、ヘッダーとして設定します：

個別認証情報 — 各ユーザーがBearer {{API_KEY}} プレースホルダーと 認証オーバーライド タブを使用して、独自のキーを提供します：

個別認証情報は、属性の特定やユーザーごとのツールスコープ設定に役立つ個別のインバウンドIDを提供しますが、 ユーザーごとのデータベース権限を分離するものでは ありません。すべてのリクエストは引き続き同じ接続文字列とAtlasロールを使用します。完全に分離されたデータアクセスが必要な場合は、個別のAtlasユーザーを使用してサーバーインスタンスを分けて実行してください。

公開前のツールスコープ設定

「 ツール 」タブには、サーバーが公開しているすべての機能が一覧表示されます。MongoDBの場合、これはコンソールで最も重要な画面です。

MCPサーバーのツールタブ。ツールごとの切り替え、試行・編集コントロール、新規ツールのデフォルト有効化、一括操作機能

ツールごとの切り替え。 ツールをオフにすると、tools/listから完全に除外されます。クライアントからは見えなくなり、呼び出すこともできません。これはプロンプト層でのフィルタリングではなく、ツール自体が完全に無効化されます。

他のサーバーに対する推奨事項よりも、ここではより断固としたアドバイスをします。 コレクションおよびインデックスの管理機能は、完全に無効にしてください。 承認ゲートを設けるのではなく、機能自体を無効化するのです。承認ゲートは、ワークフローにおいて正当な理由があり、ダブルチェックが必要な操作には適しています。しかし、本番環境のコレクションを削除することは、私たちが提供するいかなるエージェントワークフローにおいても必要ありません。削除ツールを呼び出せないエージェントであれば、説得されて削除させられることも、悪意のあるドキュメントによって誘導されることも、深夜2時に承認者が誤ってリクエストを承認してしまうこともありません。

書き込みパスが必要な場合は、共有サーバーで有効にしないでください。別の 仮想MCPサーバー を構築し、必要なツールのみを限定的に付与してください。TrueFoundryのMongoDBセキュリティに関する注意書きにも同様のことが記されています。書き込み権限を持つツールは、精査された仮想MCPサーバー経由でのみ公開するようにしてください。

新しいツールをデフォルトで有効にする。 この設定がオンのままだと、アップストリームで追加されたツールが自動的に反映されてしまいます。これを オフにしてください。稼働中のデータベースにおいて、エージェントが既に使用しているサーバーに新しい書き込みツールが予告なく追加されることは、絶対に避けたい事態です。

一括操作。 各行がチェックボックスに切り替わり、複数のツールを一度に操作できます。読み取り専用にする最も早い方法は、すべてを選択し、クエリおよび検査ツールのみ選択を解除して保存することです。

ツールの鉛筆アイコンをクリックすると、表示方法を上書きできます。

「説明」の上書きフィールドと、「読み取り専用」または「破壊的」を選択できるMCPツールアノテーションを備えたツール編集モーダル

この 説明 の上書き（最大20,000文字）は、非常に有効です。どのコレクションが大規模で、どのフィールドにインデックスが貼られているかをモデルに伝えることで、適切なフィルタリングを促せます。これは、インデックスなしのスキャン問題を回避するための最も低コストな対策です。 MCPツールアノテーション は、ツールを 読み取り専用 または 削除、対応するクライアントに対してreadOnlyHintまたはdestructiveHintを設定します。

権限の範囲：コラボレーターの役割

アクセス制御は、ユーザー、チーム、または仮想アカウントに対して、「どのサーバーにアクセスできるか」と「どのツールを実行できるか」という2つの側面で適用されます。

MCPサーバーマネージャーおよびMCPサーバー承認者の役割を持つコラボレーターを表示するMCPサーバードロワーの更新

‍