MongoDB(データベース)のクエリ(データ検索命令)の最適化(処理を高速化)とインデックス(検索を速くするための目印)に関するお手伝いを提供します。 次のような場合に使用: - 「このクエリをどうやって最適化できますか?」 - 「このデータにインデックスを作成するには?」 - 「なぜこのクエリは遅いのですか?」 - 「遅いクエリを修正してもらえますか?」 - 「私のクラスター(複数のサーバーで構成されたシステム)に遅いクエリがありますか?」 など、性能や速度に関する質問をされた場合のみです。 通常の MongoDB クエリ作成のご質問では使用しません。ユーザーが明確に性能やインデックスのサポートを求めない限り、このスキルは呼び出されません。最適化戦略としてはインデックスの活用を優先します。利用可能な場合は MongoDB MCP を使用します。
Help with MongoDB query optimization and indexing. Use only when the user asks for optimization or performance: "How do I optimize this query?", "How do I index this?", "Why is this query slow?", "Can you fix my slow queries?", "What are the slow queries on my cluster?", etc. Do not invoke for general MongoDB query writing unless user asks for performance or index help. Prefer indexing as optimization strategy. Use MongoDB MCP when available.
次のような場合に使用してください:
通常のクエリ作成の支援は行いません。ただし、ユーザーが最適化・遅いクエリ・インデックスについての助言を求めた場合は対応します。
ユーザーが遅いクエリを調べたい、または特定のクエリに限らず一般的なパフォーマンス改善のアドバイスを求めている場合:
Atlas MCP サーバーが設定されていないか、正しいクラスタに対して atlas-get-performance-advisor を実行するための情報が不足している場合は、一般的なパフォーマンス分析には Atlas MCP サーバーを API 認証情報付きで設定する必要があることをユーザーに伝え、設定を促すか、代わりに特定のクエリについて尋ねることを提案してください。
ユーザーが特定のクエリについて質問している場合:
収集した情報と MongoDB のベストプラクティス、参考ファイルの例に基づいて最適化の提案を行います。可能な限り、クエリ全体をカバーするインデックスの作成を優先してください。MongoDB MCP サーバーが使えない場合でも、提案を試みてください。
呼び出し方法: MongoDB MCP サーバーを ツール名そのもので toolName として、単一の引数オブジェクトを arguments として呼び出してください。ツール名をオプション・クエリパラメータ・ネストされたキーとして渡さないでください。MCP ツール名として渡し、パラメータを引数オブジェクトとして指定してください。完全な MCP サーバーツールリファレンス: MongoDB MCP Server Tools
データベースツール(MCP クラスタ接続が機能している場合):
| ツール名(正確に) | 引数オブジェクト |
|---|---|
collection-indexes |
{ "database": "<db>", "collection": "<coll>" } — 両方必須の文字列 |
explain |
{ "database": "<db>", "collection": "<coll>", "method": [ { "name": "find", "arguments": { "filter": {...}, "sort": {...}, "limit": N } } ], "verbosity": "executionStats" } — method は 1 つのオブジェクトの配列。name は "find"、"aggregate"、"count" のいずれか。arguments にそのメソッドのパラメータ(例:find は filter、sort、limit;aggregate は pipeline;count は query)を含める。オプションの verbosity: "queryPlanner"(デフォルト)、"executionStats"、"queryPlannerExtended"、"allPlansExecution" |
find |
{ "database": "<db>", "collection": "<coll>", "filter": {...}, "projection": {...}, "sort": {...}, "limit": N } — database、collection、filter は必須。オプション: projection、sort、limit |
Atlas ツール(Atlas API 認証情報が設定されている場合):
| ツール名(正確に) | 引数オブジェクト |
|---|---|
atlas-list-projects |
{} または { "orgId": "<24 文字の 16 進数>" } — プロジェクトと ID を返す。Performance Advisor の projectId を取得するために使用 |
atlas-get-performance-advisor |
必須: "projectId"(24 文字の 16 進数文字列)、"clusterName"(1~64 文字の英数字・アンダースコア・ハイフン)。オプション: "operations" — "suggestedIndexes"、"dropIndexSuggestions"、"slowQueryLogs"、"schemaSuggestions" から選ぶ文字列の配列(必要なものだけリクエスト);slowQueryLogs のみの場合: "since"(ISO 8601 形式の日時)、namespaces("db.coll" 文字列の配列) |
ユーザーの質問に対しては、最適化対象のクエリに関連して、接続文字列と Atlas API の両方から情報を取得するように心がけてください。
典型的なフロー: collection-indexes → explain → find(サンプルドキュメント)
collection-indexes — 結果の classicIndexes(各要素は name、key を持つ)を使い、既存インデックスがそのクエリで使えるかどうかを確認explain — まず "queryPlanner" モードで実行し、COLLSCAN(全件スキャン)がないかチェック。クエリがインデックスを使用しているか、コレクションが非常に小さい場合は、"executionStats"(タイムアウト 10 秒)で再実行し、スキャンされたドキュメント数と返されたドキュメント数を確認プロジェクト ID が必要な場合は、まず atlas-list-projects を呼び出してください。次に、必要な operations だけを指定して atlas-get-performance-advisor を呼び出します:
| 操作の値 | 使用する場面 |
|---|---|
slowQueryLogs |
遅いクエリを取得する場合 — 最も遅く、最も頻繁に実行されるものを優先。オプション: namespaces で特定のコレクションに限定;since で期間を指定 |
suggestedIndexes |
クラスタのインデックス推奨事項を取得する場合 |
dropIndexSuggestions |
ユーザーが不要なインデックスや削除すべきインデックスについて尋ねる場合 |
schemaSuggestions |
ユーザーがスキーマ・クエリ構造についてインデックスと一緒にアドバイスを求める場合 |
MCP ツール名を operations の値として渡さないでください — operations は取得すべきデータを列挙する別個の引数です。
ユーザー: 「このクエリが遅いのはなぜですか?db.orders.find({status: 'shipped', region: 'US'}).sort({date: -1})」
MCP DB 接続が設定されており、データベース名とコレクション名がわかっている場合は、ステップ 1~3 を実行してください。そうでない場合はステップ 4 にスキップしてください。
既存コレクションのインデックスを確認:
collection-indexes を database=store、collection=orders で呼び出し{_id: 1}、{status: 1}、{date: -1} が存在explain を実行:
explain を method=find、filter={status: 'shipped', region: 'US'}、sort={date: -1}、verbosity=queryPlanner と executionStats で呼び出し{status: 1} インデックスを使用、その後メモリ内で並べ替え、totalKeysExamined: 50000、nReturned: 100find を実行:
find を limit=1 で呼び出し、スキーマを推測するためのサンプルドキュメントを取得MCP Atlas 接続が設定されている場合は、ステップ 4 を実行してください。そうでない場合はステップ 5 にスキップしてください。
atlas-get-performance-advisor を実行:
store、collection=orders からの遅いクエリログを取得診断: explain 出力とスローログに基づき、このクエリは 100 ドキュメント(レコード)を対象としていますが、50,000 のインデックスエントリをスキャンしています(選別性が低い: 0.002)。メモリ内の並べ替えがオーバーヘッドを追加しています。インデックスはフィルタ条件両方または並べ替え条件をサポートしていません。
推奨: ESR ルール(等値条件 2 つ、次に並べ替え)に従い、複合インデックス {status: 1, region: 1, date: -1} を作成してください。これでメモリ内の並べ替えが不要になり、status と region の両方でフィルタリングすることで選別性が向上します。
MongoDB MCP サーバーが設定されていない場合でも、MongoDB のベストプラクティスに従って提案を行ってください。
ユーザー: 「クラスタの遅いクエリ最適化を手伝ってもらえますか?」
atlas-get-performance-advisor を実行:
診断と推奨: スローログとパフォーマンスアドバイザーの提案に基づき、db.orders コレクションに複合インデックス {status: 1, region: 1, date: -1} を作成し、find({status: 'shipped', region: 'US'}).sort({date: -1}) のようなクエリを最適化できます
パフォーマンスアドバイザーの出力とスローログをすべて調査してください。何が改善され、なぜそうなるのかについて情報を提供し、最大のインパクトが期待できる提案に焦点を当ててください(例:多くのクエリに影響するインデックス、最も悪いパフォーマンスのクエリなど)。
診断と推奨を開始する前に、参考ファイルを読み込んでください。
常に読み込む:
references/core-indexing-principles.mdreferences/antipattern-examples.md条件に基づいて読み込む:
references/aggregation-optimization.mdreferences/update-query-examples.md(オペレーションログ効率的な更新と一般的な更新のアンチパターン)Invoke only when the user wants:
Do not invoke for routine query authoring unless the user has requested help with optimization, slow queries, or indexing.
If the user wants to examine slow queries, or is looking for general performance suggestions (not regarding any particular query):
If Atlas MCP Server for Atlas is not configured or you don’t have enough information to run atlas-get-performance-advisor against the correct cluster, tell the user that general performance analysis requires Atlas MCP Server configuration with API credentials, and suggest they configure it or ask about a specific query instead.
If the user is asking about a particular query:
Then make an optimization suggestion based on collected information and MongoDB best practices and examples from reference files. Prefer creating an index that fully covers the query if possible. If you cannot use MongoDB MCP Server then still try to make a suggestion.
How to invoke. Call the MongoDB MCP server with the exact tool name as toolName and a single arguments object as arguments. Do not pass the tool name as an option, query param, or nested key; pass it as the MCP tool name and the parameters as the arguments object. Full MCP Server tool reference: MongoDB MCP Server Tools.
Database tools (when the MCP cluster connection works):
| Tool name (exact) | Arguments object |
|---|---|
collection-indexes |
{ "database": "<db>", "collection": "<coll>" } — both required strings. |
explain |
{ "database": "<db>", "collection": "<coll>", "method": [ { "name": "find", "arguments": { "filter": {...}, "sort": {...}, "limit": N } } ], "verbosity": "executionStats" }. method is an array of one object: name is "find", "aggregate", or "count"; arguments holds that method's params (e.g. find: filter, sort, limit; aggregate: pipeline; count: query). Optional verbosity: "queryPlanner" (default), "executionStats", "queryPlannerExtended", "allPlansExecution". |
find |
{ "database": "<db>", "collection": "<coll>", "filter": {...}, "projection": {...}, "sort": {...}, "limit": N } — database, collection, and filter are required. Optional: projection, sort, limit. |
Atlas tools (when Atlas API credentials are configured):
| Tool name (exact) | Arguments object |
|---|---|
atlas-list-projects |
{} or { "orgId": "<24-char hex>" }. Returns projects with their IDs; use to get projectId for Performance Advisor. |
atlas-get-performance-advisor |
Required: "projectId" (24-character hex string), "clusterName" (string, 1–64 chars, alphanumeric/underscore/dash). Optional: "operations" — array of strings from "suggestedIndexes", "dropIndexSuggestions", "slowQueryLogs", "schemaSuggestions" (request only what you need); for slowQueryLogs only: "since" (ISO 8601 date-time), "namespaces" (array of "db.coll" strings). |
For a user question, try to fetch information from both the connection string and Atlas API related to the query you are optimizing.
Typical flow: call collection-indexes → explain → find (sample doc).
collection-indexes — Use the result's classicIndexes (each has name, key) to see if the query can already use an existing index.explain — Run in "queryPlanner" mode first to check for COLLSCAN. If the query uses an index or the collection is very small, run again with "executionStats" (10-second timeout) to get docs scanned vs. returned.If you need a project ID, call atlas-list-projects first. Then call atlas-get-performance-advisor with only the operations you need:
| Operation value | Use when |
|---|---|
slowQueryLogs |
Fetching slow queries—prioritize by slowest and most frequent. Optional: namespaces to scope to a collection; since for a time window. |
suggestedIndexes |
Fetching cluster index recommendations |
dropIndexSuggestions |
User asks what to remove or reduce index overhead |
schemaSuggestions |
User asks for schema/query-structure advice alongside indexes |
Do not pass the MCP tool name as an operations value—operations is a separate argument listing what data to fetch.
User: "Why is this query slow? db.orders.find({status: 'shipped', region: 'US'}).sort({date: -1})"
If MCP db connection is configured and the database + collection names are known, run steps 1–3. Otherwise skip to step 4.
Check existing collection indexes:
collection-indexes with database=store, collection=orders{_id: 1}, {status: 1}, {date: -1}Run explain:
explain with method=find, filter={status: 'shipped', region: 'US'}, sort={date: -1}, verbosity=queryPlanner and executionStats{status: 1} index, then in-memory SORT, totalKeysExamined: 50000, nReturned: 100Run find:
find with limit=1 to fetch a sample document to impute the schema.If MCP Atlas connection is configured, run step 4. Otherwise skip to step 5.
Run atlas-get-performance-advisor:
store, collection=orders in the past 24 hoursDiagnose: Based on explain output and slow query logs, this query targets 100 docs but scans 50K index entries (poor selectivity: 0.002). In-memory sort adds overhead. Index doesn't support both filter fields or sort.
Recommend: Create compound index {status: 1, region: 1, date: -1} following ESR (two equality fields, then sort). This eliminates in-memory sort and improves selectivity by filtering on both status and region.
If the MongoDB MCP server is not set up, follow best indexing practices.
User: "Can you help with optimizing slow queries on my cluster?”
{status: 1, region: 1, date: -1} on the db.orders collection to optimize queries such as find({status: 'shipped', region: 'US'}).sort({date: -1})Examine all performance advisor output as well as slow query logs. Provide information on what is being improved and why, and focus on suggestions that have the potential for greatest impact (e.g., indexes that affect the most queries, or queries that have the worst performance).
Before beginning diagnosis and recommendation, load reference files.
Always load:
references/core-indexing-principles.mdreferences/antipattern-examples.mdConditionally load these files:
references/aggregation-optimization.mdreferences/update-query-examples.md for oplog-efficient updates and common update anti-patterns原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。