/ ディレクトリ / プレイグラウンド / MongoDB
← 全サーバー ↗ GitHub
● 公式 mongodb-js 🔑 自分のキーが必要

MongoDB

作者 mongodb-js · mongodb-js/mongodb-mcp-server

ClaudeがMongoDB Atlasまたはセルフホストクラスターへのクエリ、集計、管理を実行します。デフォルトは読み取り専用で、ツールごとに書き込みを許可できます。

MongoDBの公式MCPは、ドライバー（任意のクラスターに対するCRUD＋集計）とAtlasコントロールプレーン（プロジェクト、クラスター、ユーザーの一覧）の両方をカバーしています。デフォルトでは読み取り専用モードで動作し、書き込みが必要な場合はコマンドファミリーごとに明示的に有効化します。

▶ デモを見る 📦 インストール 💡 ユースケース

なぜ使うのか

主な機能

ライブデモ

実際の動作

mongodb.replay ▶ 準備完了
0/0

インストール

クライアントを選択

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "mongodb": {
      "command": "npx",
      "args": [
        "-y",
        "mongodb-mcp-server"
      ]
    }
  }
}

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

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "mongodb": {
      "command": "npx",
      "args": [
        "-y",
        "mongodb-mcp-server"
      ]
    }
  }
}

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

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "mongodb": {
      "command": "npx",
      "args": [
        "-y",
        "mongodb-mcp-server"
      ]
    }
  }
}

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

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "mongodb": {
      "command": "npx",
      "args": [
        "-y",
        "mongodb-mcp-server"
      ]
    }
  }
}

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

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "mongodb",
      "command": "npx",
      "args": [
        "-y",
        "mongodb-mcp-server"
      ]
    }
  ]
}

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

~/.config/zed/settings.json
{
  "context_servers": {
    "mongodb": {
      "command": {
        "path": "npx",
        "args": [
          "-y",
          "mongodb-mcp-server"
        ]
      }
    }
  }
}

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

claude mcp add mongodb -- npx -y mongodb-mcp-server

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

ユースケース

実用的な使い方： MongoDB

Mongoの集計パイプラインでビジネス上の質問に回答する

👤 Mongoベースのプロダクトに関わるPMやアナリスト ⏱ ~15 min beginner

使うタイミング： 件数、ファネル、トップNリストが必要だが、$group/$lookup の構文を覚えたくない場合。

前提条件
  • 読み取り専用の接続文字列 — Atlas：readAnyDatabase 権限を持つDBユーザーを作成。セルフホスト：対象DBに read ロールを持つユーザーを使用。
フロー
  1. コレクションを確認する
    データベースを一覧表示し、app_prod 内のすべてのコレクションとおおよそのドキュメント数を表示してください。✓ コピーしました
    → コレクションカタログ
  2. サンプリングしてスキーマを推論する
    users と orders から20件ずつサンプリングし、見つかったフィールドと型を説明してください。✓ コピーしました
    → コレクションごとのスキーマ説明
  3. 実際の集計を実行する
    過去30日間に国別で何件の注文がありましたか？降順ソートで上位20件を表示してください。✓ コピーしました
    → 使用したパイプライン付きの結果テーブル

結果： 再実行可能な正確なパイプラインとともにビジネス上の回答が得られます。

注意点
  • インデックスのない集計は巨大なコレクションをフルスキャンする可能性がある — 必ず先に .explain() で確認し、サポートするインデックスが存在することを確認してください。存在しない場合は、パイプラインの先頭でインデックス付きフィールドに絞った $match を追加してください
組み合わせ： notion

整理されていないコレクションの実際のスキーマを推論・文書化する

👤 ドキュメントのないMongoに新しく参加するエンジニア ⏱ ~25 min intermediate

使うタイミング： コレクションが3年間「スキーマレス」で運用され、実際にどのフィールドが存在するか誰も把握していない場合。

フロー
  1. 幅広くサンプリングする
    events から500件のドキュメントをサンプリングし、各トップレベルフィールドについて出現率、型、サンプル値を報告してください。✓ コピーしました
    → フィールドごとの出現率/型マトリクス
  2. スキーマのドリフトを検出する
    ドキュメント間で複数の型を持つフィールドはどれですか？(フィールド, 型) でグループ化しカウントしてください。✓ コピーしました
    → 多態フィールドの一覧
  3. TypeScript型またはJSONスキーマを生成する
    「安定した」フィールド（出現率95%以上、単一型）のTypeScriptインターフェースを生成してください。残りはoptionalまたはunknownとしてマークしてください。✓ コピーしました
    → 利用可能な型定義

結果： 既知の問題点を含む文書化されたスキーマ — マイグレーションやバリデーター設定の基盤となります。

注意点
  • 500件では稀だが重要なバリエーションを見逃す可能性がある — 時間バケット（月ごとに1つ）でサンプリングし、レガシーな構造も捕捉する
組み合わせ： filesystem

Atlasプロジェクトのセキュリティとコストを監査する

👤 Atlasを利用するDevOps/プラットフォームチーム ⏱ ~20 min intermediate

使うタイミング： 四半期ごとに、オーバースペックなクラスター、広すぎるIPアクセスリスト、誰がアクセス権を持っているかを確認する場合。

前提条件
  • Atlas APIのパブリック＋プライベートキー — cloud.mongodb.com → Organization Access → API keys でプロジェクトスコープのキーを作成
フロー
  1. プロジェクトとクラスターを一覧表示する
    すべてのプロジェクトと、各プロジェクト内のすべてのクラスターについて、ティア、リージョン、バックアップ状態を表示してください。✓ コピーしました
    → 完全なインベントリ
  2. リスクのあるアクセスを検出する
    各プロジェクトのIPアクセスリストを出力してください。0.0.0.0/0 のエントリがあればプロジェクト名とともにフラグを立ててください。✓ コピーしました
    → リスクのあるアクセスのレポート
  3. 適正サイズを提案する
    M30以上のティアで使用量が10GB未満のクラスターはありますか？ダウングレードを推奨してください。✓ コピーしました
    → コスト削減リスト

結果： セキュリティおよび財務担当者向けの簡潔な改善アクションリストが得られます。

注意点
  • APIキーのスコープが狭すぎてすべてのプロジェクトを参照できない — プロジェクトレベルのキーではなく、読み取り専用モードのOrganizationレベルキーを使用する
組み合わせ： notion

一回限りのデータクリーンアップを安全に計画・実行する

👤 データバグを修正するバックエンドエンジニア ⏱ ~30 min advanced

使うタイミング： バグにより不正なデータが書き込まれ、約1万件のドキュメントを修正する必要があるが、誤ったデータを削除してはならない場合。

前提条件
  • 書き込み可能なユーザー（対象DBのみにスコープ） — Atlas：対象DBに readWrite ロールのみを持つユーザーを設定
  • このセッションで --read-only を明示的にOFFにする — MCPを --read-only なしで起動する
フロー
  1. 件数で修正範囲を確認する
    users で status='active' かつ last_login IS NULL かつ created_at < 2024-01-01 に一致するドキュメントの件数をカウントしてください。変更は行わないでください。✓ コピーしました
    → 影響予定件数（例：9,873件）
  2. 更新をドライランする
    実行予定のupdateManyパイプライン（フィルター＋$set）を提示し、変更対象のサンプルドキュメントを5件表示してください。実行はしないでください。✓ コピーしました
    → フィルター＋更新内容のプレビュー
  3. 実行して検証する
    更新を実行してください。その後、元のカウントクエリを再実行し、結果が0であることを確認してください。matchedCountとmodifiedCountを報告してください。✓ コピーしました
    → 件数が期待値と一致し、検証クエリが0を返す

結果： 更新前後の件数が記録された、クリーンで監査可能な修正が完了します。

注意点
  • フィルターが誤ったupdateManyはコレクション全体を破壊する — 必ず先にフィルターを countDocuments で実行し、件数が想定外であれば中断して調査する
  • 影響対象のバックアップがない — 更新前に、対象ドキュメントを <collection>_backup_<date> コレクションにコピーしておく
組み合わせ： filesystem

遅いクエリパターンから不足しているインデックスを提案する

👤 パフォーマンス問題を調査するバックエンドエンジニア ⏱ ~25 min advanced

使うタイミング： Mongoのクエリが遅く、場当たり的ではなく的を絞ったインデックス計画が必要な場合。

フロー
  1. 既存のインデックスを確認する
    orders と users について、すべてのインデックスとそのキーおよびディスク上のサイズを一覧表示してください。✓ コピーしました
    → インデックスカタログ
  2. 特定のクエリをプロファイルする
    このクエリ [貼り付け] に対して .explain('executionStats') を実行してください。totalDocsExamined と nReturned、および winning plan のステージを報告してください。✓ コピーしました
    → Explain出力
  3. 最小限の新規インデックスを提案する
    そのプランを踏まえて、IXSCANに変換できるインデックスを1つだけ提案してください。フィールド順序の根拠も説明してください。✓ コピーしました
    → 根拠付きの具体的な createIndex コマンド

結果： 遅いクエリごとに、根拠のある1つのインデックス推奨が得られます — 大量の推奨ではありません。

注意点
  • インデックスの追加しすぎは書き込みスループットを低下させ、ストレージを肥大化させる — 1つ以上の高トラフィッククエリに対応するインデックスのみ追加する。複合インデックスはESR（Equality, Sort, Range）順を反映させる

組み合わせ

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

mongodb + notion

集計結果を共有可能なレポートとしてNotionに投稿する

過去6ヶ月間のプランティアごとのMAUを算出し、Notionの「Growth / Monthly」にテーブル形式で結果ページを作成してください。✓ コピーしました
mongodb + filesystem

クリーンアップ前にコレクションの一部をJSONLとしてバックアップする

users から <filter> に一致するすべてのドキュメントを検索し、/backups/users-cleanup-<date>.jsonl に保存してから削除してください。✓ コピーしました
mongodb + postgres

Mongoからの移行時にクロスDB整合性チェックを行う

Mongoの users にあるすべてのuser_idについて、Postgresの users に対応する行が存在するか確認してください。不一致を報告してください。✓ コピーしました

ツール

このMCPが提供する機能

ツール入力呼び出すタイミングコスト
list_databases 探索セッションの開始時に使用 free
list_collections database: str データベースのインベントリ取得 free
find database, collection, filter?, projection?, sort?, limit? ドキュメント読み取り — 主要な読み取りツール free
aggregate database, collection, pipeline: stage[] グルーピング、結合、分析 free
count database, collection, filter? 破壊的な書き込みの前に必ず実行 — 範囲を確認 free
insert_one / insert_many database, collection, document(s) --read-only がオフの場合に使用可能 writes
update_one / update_many database, collection, filter, update 必ず先にcountでフィルターをプレビューする writes
delete_one / delete_many database, collection, filter 危険 — ユーザーの明示的な確認を必ず求める writes
list_indexes database, collection 新しいインデックスを提案する前のパフォーマンス分析 free
atlas_list_projects / atlas_list_clusters Atlasコントロールプレーンの監査 free

コストと制限

運用コスト

APIクォータ
ドライバー：クラスターの接続数上限に依存。Atlas API：キーごとに100リクエスト/分。
呼び出しあたりのトークン
find/aggregate：結果サイズに応じてスケール。プロジェクションとlimitを使用してください。
金額
既存のクラスターに対しては無料。Atlasにはテスト用の無料M0ティアがあります。
ヒント
必要なフィールドのみをプロジェクションしてください。制限なしのfindは大きなドキュメントを返し、コンテキストとエグレスを消費します。

セキュリティ

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

最小スコープ： readAnyDatabase (read-only) or read on specific DBs
認証情報の保管： ドライバー用：MDB_MCP_CONNECTION_STRING、Atlas用：MDB_MCP_API_CLIENT_ID + MDB_MCP_API_CLIENT_SECRET
データ送信先： ドライバーはお使いのクラスターに接続します。Atlas APIは cloud.mongodb.com のみに接続します
絶対に付与しない： dbAdminAnyDatabase userAdminAnyDatabase root

トラブルシューティング

よくあるエラーと対処法

MongoServerError: Authentication failed

接続文字列のユーザー名/パスワードが間違っているか、ユーザーに認証DBの権限がありません。Atlasの場合は ?authSource=admin を追加してください。

確認： mongosh '$MDB_MCP_CONNECTION_STRING' --eval 'db.runCommand({ping:1})'
MongoNetworkError: ETIMEDOUT

IPがAtlasのアクセスリストに含まれていません。Atlas → Network Access で現在のIPを追加してください。

確認： curl ifconfig.me then compare
not authorized on admin to execute command listDatabases

ロールの権限が不足しています。clusterMonitor を付与するか、listCollections で特定のDBにスコープを絞ってください。

Write rejected / running in read-only mode

MCPを --read-only なしで再起動してください。特定の修正セッションの場合のみ行ってください。

代替案

MongoDB 他との比較

代替案代わりに使う場面トレードオフ
Postgres MCPPostgresを使用している、またはMongoからの移行を検討している場合リレーショナル — ドキュメント型の柔軟性は失われる
DBHubMongoと複数のSQL DBを1つのMCPで扱いたい場合公式サーバーと比べてMongoの機能カバレッジが浅い

その他

リソース

📖 GitHub の公式 README を読む

🐙 オープンな issue を見る

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