AutoGineer
Generated banner for Mongodb Query Optimizer
Generated logo for Mongodb Query Optimizer

Mongodb Query Optimizer

MongoDBOfficialPublished by MongoDB

  • Skill
  • Tool integration
  • Data and AI
  • Apache-2.0
  • No issues found
Download ZIP

From the author

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.
— the description by MongoDB

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The MongoDB Query Optimizer skill provides specialized assistance for identifying and resolving performance bottlenecks in MongoDB databases. It leverages MongoDB MCP tools to analyze query execution plans, existing indexes, and slow query logs. By applying core indexing principles and identifying common anti-patterns, the skill suggests targeted optimizations—primarily through compound indexing—to improve query selectivity and eliminate inefficient operations like in-memory sorts or collection scans.

What it does

  • Analyzes query performance using explain plans and execution statistics.
  • Identifies slow queries and suggests optimizations based on Atlas Performance Advisor data.
  • Evaluates existing collection indexes to determine if they support current query patterns.
  • Recommends compound indexes to improve selectivity and support sorting requirements.
  • Detects common performance anti-patterns such as unanchored regex or inefficient aggregation stages.
  • Provides actionable insights for database schema and index tuning.

When to use it

  • When you need to diagnose why a specific MongoDB query is performing slowly.
  • When you want to optimize your database indexing strategy for better performance.
  • When you need to identify and address slow queries running on your MongoDB cluster.
  • When you are looking for expert guidance on applying MongoDB indexing best practices.

Advantages

  • Reduces query latency by leveraging native MongoDB explain and performance tools.
  • Prevents common performance pitfalls by identifying anti-patterns early.
  • Focuses on high-impact optimizations like index coverage and sort elimination.
  • Provides data-driven recommendations based on actual cluster performance logs.

Usage examples

“Why is this query slow? db.orders.find({status: 'shipped', region: 'US'}).sort({date: -1})”
The agent will analyze the query, check existing indexes, run an explain plan, and suggest a compound index like {status: 1, region: 1, date: -1} to optimize filtering and sorting.
“Can you help me identify slow queries on my cluster?”
The agent will use the Atlas Performance Advisor to fetch slow query logs and provide a prioritized list of queries needing optimization.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/mongodb/mongodb-query-optimizer/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip mongodb-query-optimizer.zip -d .agents/skills

Documentation by MongoDB

MongoDB Query Optimizer

When this skill is invoked

Invoke only when the user wants:

  • Query/index optimization or performance help

  • Why a query is slow or how to speed it up

  • Slow queries on their cluster and/or how to optimize them

Do not invoke for routine query authoring unless the user has requested help with optimization, slow queries, or indexing.

High Level Workflow

General Performance Help

If the user wants to examine slow queries, or is looking for general performance suggestions (not regarding any particular query):

  • Use MongoDB MCP server atlas-get-performance-advisor tool to fetch slow query logs and performance advisor output

  • Make suggestions based on this information

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.

Help with a Specific Query

If the user is asking about a particular query:

  • Use collection-indexes, explain, and find MCP tools to get existing indexes on the collection, explain() output for the query, and a sample document from the collection

  • Use atlas-get-performance-advisor MCP tool to fetch slow query logs and performance advisor output

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.

MCP: available tools

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-advisorRequired: "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.

1. DB connection string works for MongoDB MCP

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.

2. Atlas API access works for MongoDB MCP

If you need a project ID, call atlas-list-projects first. Then call atlas-get-performance-advisor with only the operations you need:

Operation valueUse when
slowQueryLogsFetching slow queries—prioritize by slowest and most frequent. Optional: namespaces to scope to a collection; since for a time window.
suggestedIndexesFetching cluster index recommendations
dropIndexSuggestionsUser asks what to remove or reduce index overhead
schemaSuggestionsUser 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.

Example workflow 1 (help with specific query)

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.

  1. Check existing collection indexes:

    • Call collection-indexes with database=store, collection=orders

    • Result shows: {_id: 1}, {status: 1}, {date: -1}

  2. Run explain:

    • Call explain with method=find, filter={status: 'shipped', region: 'US'}, sort={date: -1}, verbosity=queryPlanner and executionStats

    • Result: Uses {status: 1} index, then in-memory SORT, totalKeysExamined: 50000, nReturned: 100

  3. Run find:

    • Call 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.

  1. Run atlas-get-performance-advisor:

    • Try to get the cluster name from the MCP connection string, or ask the user for projectId/clusterName

    • Use slowQueryLogs to fetch slow query logs from database=store, collection=orders in the past 24 hours

    • Use suggestedIndexes to check for index suggestions for the query

  2. Diagnose: 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.

  3. 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.

Example workflow 2 (general database performance help)

User: "Can you help with optimizing slow queries on my cluster?”

  1. Run atlas-get-performance-advisor:

    • Try to get the cluster name from the connection string and deduce the project name you need in atlas-list-projects; if you are not sure, then ask the user for cluster name and project id.

    • Use slowQueryLogs to fetch slow query logs from the past 24 hours

    • Use suggestedIndexes

    • Use dropIndexSuggestions

    • Use schemaSuggestions

  2. Diagnose and Recommend: Based on slow query logs and performance advisor advice, you can create the compound index {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).

Load references

Before beginning diagnosis and recommendation, load reference files.

Always load:

  • references/core-indexing-principles.md

  • references/antipattern-examples.md

Conditionally load these files:

  • If diagnosing aggregation pipelines → references/aggregation-optimization.md

  • If diagnosing queries that change docs such as replaceOne, findOneAndUpdate, etc. → references/update-query-examples.md for oplog-efficient updates and common update anti-patterns

Output

  • Keep answers short and clear: a few sentences on index and optimization suggestions, and reasoning behind them (e.g. general indexing principles, observing slow query logs in the cluster, or seeing advice in Performance Advisor)

  • Focus on highest impact indexes or optimizations - if you've omitted some optimizations let the user know and present them if asked.

  • Do not use strong language, such as saying “You should create these indexes and they will definitely improve application performance” - Explain they are suggestions for certain queries, and give the reasoning behind them.

  • Consider how many indexes already exist on the collection (if known) - there shouldn’t generally be more than 20

  • Suggest removing indexes only if the suggestion comes from Atlas Performance Advisor

  • Do not create indexes directly via MCP unless the user gives approval

Files

references/aggregation-optimization.md

Principles

Aggregation pipelines process documents through sequential stages. Focus on:

  • Reducing documents early in the pipeline

  • Minimizing data moved between stages

  • Leveraging indexes where possible

  • Managing memory usage

Memory limits and disk spilling

Blocking stages (such as in-memory $sort and $group) have a 100MB memory limit per stage. Default behavior when this limit is exceeded is to spill to disk automatically (allowDiskUse defaults to true).

Better solutions:

  • Filter more aggressively early in pipeline

  • Add indexes to enable $sort to use index order

  • Use $limit with $sort to reduce the amount of data the sort must process in memory for unindexed sorts

  • Consider materialized views for repeated aggregations

Optimization Examples

These examples are not exhaustive but representative of some common optimization patterns.

Unindexed $lookup vs. Indexed $lookup

Bad — No index on the foreign collection's join field:

db.orders.aggregate([
  { $lookup: {
      from: "products",
      localField: "productId",
      foreignField: "sku",   // no index on products.sku!
      as: "product"
  }}
])

Good — Index on foreignField in the foreign collection:

db.products.createIndex({ sku: 1 })

db.orders.aggregate([
  { $lookup: {
      from: "products",
      localField: "productId",
      foreignField: "sku",
      as: "product"
  }}
])

Why: Each $lookup executes a find on the from collection. Without an index on foreignField, every join does a full collection scan. This is the single most critical $lookup optimization.

Early $project Defeating Optimization vs. Late $project

Bad — Early $project prevents the optimizer from pruning unused fields, forgets to exclude _id which is unneeded, and includes name which is not used:

db.collection.aggregate([
  { $project: { name: 1, status: 1, amount: 1 } },
  { $match: { status: "active" } },
  { $group: { _id: "$status", total: { $sum: "$amount" } } }
])

Good — Let the optimizer handle field pruning; use $project only at the end for reshaping:

db.collection.aggregate([
  { $match: { status: "active" } },
  { $group: { _id: "$status", total: { $sum: "$amount" } } },
  { $project: { _id: 0, status: "$_id", total: 1 } }  // reshape at the end
])

Why: MongoDB's pipeline optimizer automatically analyzes which fields are used and avoids fetching unused ones. An early $project defeats this optimization, and can inadvertently request the wrong fields.

$facet for Divergent Processing vs. $unionWith

Bad — $facet sends all documents to every branch, even if branches need very different subsets:

db.collection.aggregate([
  { $facet: {
      "top10": [{ $sort: { score: -1 } }, { $limit: 10 }],
      "totalCount": [{ $count: "n" }]  // gets ALL docs even though it's just counting
  }}
])

Good — Separate pipelines via $unionWith let each branch optimize independently:

db.collection.aggregate([
  { $sort: { score: -1 } }, { $limit: 10 },
  { $unionWith: {
      coll: "collection",
      pipeline: [{ $count: "n" }]
  }}
])

Why: $facet funnels every document into every branch. $unionWith runs independent pipelines that each benefit from their own index usage and optimization.

$sort + $limit as Separate Concerns vs. Top-N Sort

Bad — Large sort, then limit (MongoDB may sort entire dataset):

db.collection.aggregate([
  { $group: { _id: "$category", total: { $sum: "$amount" } } },
  { $sort: { total: -1 } },
  // ... many stages later ...
  { $limit: 10 }
])

Good — Place $limit immediately after $sort:

db.collection.aggregate([
  { $group: { _id: "$category", total: { $sum: "$amount" } } },
  { $sort: { total: -1 } },
  { $limit: 10 }
])

Why: When $sort is immediately followed by $limit, MongoDB performs a top-N sort — it only tracks the top N values instead of sorting the full dataset. Far less memory.

$unwind Best Practices

When $unwind is needed, filter before unwinding so that the $match stage allows index usage:

[
  { $match: { "items.category": "electronics" } },  // Reduce documents first
  { $unwind: "$items" },  // Then unwind
  { $match: { "items.category": "electronics" } }  // Filter unwound elements
]

Never $unwind to re-group by _id: If you are using $unwind followed by $group with _id: you can replace it with an array operator like $filter, $map or $reduce to match or transform array elements without unwinding.

Optimize $lookup operations

$lookup performs collection joins and can be expensive. Strategies to improve performance:

  1. Filter before lookup to reduce left-side documents

  2. Use indexed fields in the lookup localField/foreignField

  3. Add $match in the lookup pipeline to reduce right-side documents early

  4. Add $project last in the lookup pipeline to keep only the fields you need

  5. $unwind immediately after lookup when you need as result flattened

[
  { $match: { active: true } },  // Reduce left side
  { $lookup: {
      from: "inventory",
      localField: "product_id",
      foreignField: "_id",  // _id is always indexed
      pipeline: [
        { $match: { inStock: true } },  // Reduce right side
        { $project: { _id: 0, name: 1, price: 1 } }
      ],
      as: "product"
  }},
  { $unwind: "$product" }
]

Schema consideration: Excessive $lookup usage may indicate over-normalization. Consider embedding frequently-joined data.

$group efficiency

Group operations require accumulating result documents in memory. Keys to efficiency:

  1. Include only needed fields within the $group stage - reference only the fields you need in accumulators

  2. Be mindful of unbounded accumulators - $push and $addToSet grow as group size increases and can cause memory issues

Bad - do not add $project before $group to "reduce fields":

[
  { $match: { date: { $gte: ISODate("2024-01-01") } } },
  { $project: { category: 1, amount: 1 } },
  { $group: {
      _id: "$category",
      total: { $sum: "$amount" },
      count: { $sum: 1 }
  }}
]

Good - reference only needed fields directly in $group:

[
  { $match: { date: { $gte: ISODate("2024-01-01") } } },
  { $group: {
      _id: "$category",
      total: { $sum: "$amount" },
      count: { $sum: 1 }
  }}
]

Why: The $group stage only processes the fields referenced in its expressions. Adding a $project before it does not save memory.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server

The author says: Best with MongoDB MCP server. Uses collection-indexes and explain when the connection string works; uses Atlas Performance Advisor when Atlas API is configured. Without either, suggest indexes from query shape only. User creates indexes in Atlas or migrations unless tooling allows otherwise.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
MongoDB
Publisher
MongoDB (Official)
Source
mongodb/agent-skills · skills/mongodb-query-optimizer · commit 155bb9c
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
mongodb/agent-skills, mongodb/agent-skills

AutoGineer is not affiliated with or endorsed by MongoDB.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download mongodb-query-optimizer.zip