AutoGineer
Generated banner for Mongodb Search And AI
Generated logo for Mongodb Search And AI

Mongodb Search And AI

MongoDBOfficialPublished by MongoDB

  • Skill
  • Tool integration
  • Data and AI
  • Apache-2.0
  • Low risk
  • Has scripts
Download ZIP

From the author

Covers everything about search in MongoDB: Atlas Search (full-text), Vector Search (semantic), and Hybrid Search. Use this skill for ANY question about MongoDB search, including open-ended and explanatory ones asked before the user has any data or use case — 'how does search work in MongoDB?', 'I'm new to MongoDB search, where do I start?', 'what's the difference between Atlas Search and Vector Search?', 'which search type should I use?', 'what is vector search?', 'how does automated embedding work?', 'can you explain hybrid search?'. Do not answer these from general knowledge; use this skill. Also use to build search features: full-text queries, autocomplete, fuzzy matching, faceted search, semantic similarity, embeddings, RAG, text containment or substring matching ('contains', 'includes'), case-insensitive or multi-field text search, and filtering across many fields. Provides workflows for choosing a search type, creating indexes, writing queries, and optimizing performance via the MongoDB MCP server.
— the description by MongoDB

AutoGineer summary

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

This skill provides a comprehensive framework for integrating search capabilities into MongoDB applications. It covers the full spectrum of search technologies available in MongoDB, including lexical full-text search, semantic vector search, and hybrid approaches. The skill guides users through the entire lifecycle of search implementation: from initial discovery and use-case validation to index configuration, query construction, and performance optimization. It emphasizes best practices, such as choosing the right search type based on specific business needs, and provides structured workflows for both manual and automated embedding scenarios.

What it does

  • Helps users choose between Atlas Search, Vector Search, and Hybrid Search.
  • Provides workflows for creating and managing search indexes.
  • Assists in constructing complex aggregation pipelines for search queries.
  • Offers guidance on using Automated Embedding for semantic search without custom code.
  • Explains how to implement hybrid search using rank-based or score-based fusion.
  • Validates search configurations against cluster requirements and best practices.

When to use it

  • When you need to add full-text, semantic, or hybrid search to a MongoDB collection.
  • When you are unsure which MongoDB search technology best fits your specific data and use case.
  • When you need to optimize existing search queries or troubleshoot index performance.
  • When you want to implement RAG or semantic search but lack existing embedding infrastructure.
  • When you need to combine keyword-based filtering with semantic similarity.

Advantages

  • Prevents common anti-patterns like using inefficient regex or text operators.
  • Ensures search implementations are aligned with specific MongoDB cluster capabilities.
  • Simplifies complex search concepts into actionable, step-by-step workflows.
  • Provides clear guidance on model selection for automated embeddings.
  • Promotes performance-oriented index design and query construction.

Usage examples

“How do I implement semantic search for my product catalog?”
The agent will initiate a discovery phase to inspect your collection schema, determine if you have existing embeddings, and recommend either Automated Embedding or manual Vector Search.
“What is the difference between Atlas Search and Vector Search?”
The agent will explain the technical distinctions between lexical and semantic search and help you decide which is appropriate for your specific data requirements.
“I want to combine keyword filtering with vector similarity.”
The agent will guide you through the Hybrid Search workflow, explaining how to use lexical prefilters or fusion stages like $rankFusion.
“Help me get started with search.”
The agent will offer a choice between a guided tour using sample data or a discovery process to build search features directly for your own data.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/mongodb/mongodb-search-and-ai/download

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

    mkdir -p .agents/skills && unzip mongodb-search-and-ai.zip -d .agents/skills

Documentation by MongoDB

MongoDB Search and AI Recommendations Skill

You are helping MongoDB users implement, optimize, and troubleshoot Atlas Search (lexical), Vector Search (semantic), and Hybrid Search (combined) solutions.

Core Principles

  1. Understand before building - Validate the use case to ensure you recommend the right solution

  2. Always inspect first - Check existing indexes and schema before making recommendations

  3. Explain before executing - Describe what indexes will be created and require explicit approval

  4. Handle read-only scenarios - Without create, update, or delete operation tools you are in read-only mode; hand the user index JSON to create themselves

  5. Explain in accessible language - Describe technical concepts and map business requirements to technical implementations in terms the user can follow

Workflow

0. Check for a Quickstart Request

references/quick-start.md is a guided walkthrough that builds semantic, keyword, and hybrid search against the sample_mflix sample dataset. It is a teaching tour, not a way to build search for the user's own data.

Do not read references/quick-start.md until the user has chosen the tour. A general request like "I'm new to search, help me get started" can just as easily mean "help me add search to my app." Use AskUserQuestion:

"Two ways I can take this — which fits better?"

  • Guided tour on sample data — we load Atlas's sample movie dataset and build semantic, keyword, and hybrid search on it step by step. Best for learning how each type works.

  • Build search for my own data — tell me what you're searching and I'll design the indexes and queries for your collections.

Prompts that should trigger this offer, rather than being answered directly as a question:

  • "I'm new to MongoDB, how does search work?", "help me get started with search"

  • "what's the difference between Atlas Search and Vector Search?", "which search type should I use?"

  • "I want to try vector search", "show me semantic search", "how does automated embedding work?"

  • "I want to try keyword search", "show me full-text search", "I want to try hybrid search"

Skip the offer only when the intent is already unambiguous:

  • Explicit tour request ("give me a guided tour", "walk me through search using sample data") — load references/quick-start.md and start at its Step 0.

  • The user has their own collection, data, or concrete use case — use the Discovery Phase below, even when they name a single search type.

If the user named a specific search type, carry that into the walkthrough: it skips its own path question and routes straight to that path, after its prerequisite steps.

The walkthrough requires an Atlas cloud cluster — the sample dataset loads from the Atlas UI, and Automated Embedding works on every Atlas tier with no key management. Atlas Local and self-managed MongoDB are out of scope; the walkthrough routes them back here when a step gives evidence of one.

Otherwise, continue with the Discovery Phase.

1. Discovery Phase

Check the environment:

  • Use list-databases and list-collections to understand available data

  • If the user mentions a collection, use collection-schema to inspect field structure

  • Use collection-indexes to see existing indexes

  • Use atlas-inspect-cluster to determine the cluster's MongoDB version

Understand the use case: If the user's request is vague:

  • Ask clarifying questions about their needs

  • Infer likely collection and fields from schema

  • Confirm understanding before proceeding

Common questions to ask:

  • What are users searching for? (products, movies, documents, etc.)

  • What fields contain the searchable content?

  • Are they searching by free text, or by similarity to an existing item (e.g. "given movie A, find similar movies")?

  • Do they need exact matching, fuzzy matching, or semantic similarity?

  • Do they need filters (price ranges, categories, dates)?

  • Do they need autocomplete/typeahead functionality?

  • Do they already generate vector embeddings, or do they want MongoDB to handle that automatically?

2. Determine Search Type and Consult the Reference File

Match the use case to a search type below, then consult the linked reference file before recommending indexes or queries. Each reference file also documents the prerequisites you must verify first (cluster tier, MongoDB version, deployment type, auto-scaling).

Atlas Search (Lexical/Full-Text): Use when users need:

  • Keyword matching with relevance scoring

  • Fuzzy matching for typo tolerance

  • Autocomplete/typeahead

  • Faceted search with filters

  • Language-specific text analysis

  • Token-based search

  • Lexical search with views

→ Consult both references/lexical-search-indexing.md (index) and references/lexical-search-querying.md (query).

Automated Embedding (Semantic search, no embedding code): Use when users need:

  • Semantic / vector search without writing embedding code

  • No existing vector pipeline or embedding infrastructure

  • Quick setup: MongoDB auto-generates and manages embeddings using Voyage AI models

  • Text data already stored in Atlas that they want to search by meaning

  • RAG or AI agent memory with minimal setup

→ Consult references/automated-embedding.md.

Vector Search (Semantic, bring your own embeddings): Use when users need:

  • Semantic similarity with their own pre-generated embeddings

  • A specific embedding model not provided by Voyage AI

  • Image, audio, or multimodal embeddings (Automated Embedding is text-only)

  • Self-managed MongoDB without Voyage AI API key configured

  • Vector search with views

→ Consult references/vector-search.md.

Hybrid Search: Use when users need:

  • Combining multiple search approaches (e.g., vector + lexical, multiple text searches)

  • Queries like "find action movies similar to 'epic space battles'" (combining keyword filtering with semantic similarity)

  • Results that factor in multiple relevance criteria

  • Uses $rankFusion (rank-based) or $scoreFusion (score-based) to merge pipelines

→ Consult references/hybrid-search.md, plus the lexical/vector files for the individual pipeline stages.

3. Execution and Validation

Creating indexes:

  1. Explain the index configuration in plain language

  2. Show the JSON structure

  3. Ask what the user wants to name the index

  4. Get explicit approval: "Should I create this index?"

  5. Use MCP's create-index tool after approval

  6. In read-only mode, provide the complete index JSON for creation via the Atlas UI

Running queries:

  1. Show the aggregation pipeline

  2. Execute using MCP's aggregate tool

  3. Present results clearly

Refining existing queries:

  1. Ask the user to share their current query

  2. Compare against the query patterns and best practices in the relevant reference file(s)

  3. Propose specific improvements with before/after examples

  4. Run the revised query with aggregate to validate the results

Anti-Patterns to Avoid

NEVER recommend $regex or $text for search use cases. Both lack the relevance scoring, fuzzy matching, and language-aware tokenization that search workloads need. If a user asks for either, explain why Atlas Search is more appropriate and show the equivalent pattern.

Handling Edge Cases

  • Fields you can't find — inspect available fields with collection-schema, then confirm the intended field with the user

  • A required field doesn't exist — explain what to add and how (e.g., an embedding field for vector search)

  • Query fails or index missing — verify with collection-indexes; if absent, the index must be created first

  • Multiple collections are relevant — ask which one they mean, unless context makes it obvious

Files

references/hybrid-search.md

Hybrid Search

Scope: This guide covers hybrid search patterns in MongoDB Atlas: combining vector and lexical search using $rankFusion and $scoreFusion, and using lexical prefilters with the vectorSearch operator inside $search. For pure vector search indexes and $vectorSearch query construction, see vector-search.md. For lexical index definitions and query patterns, see lexical-search-indexing.md and lexical-search-querying.md. For automated embedding (autoEmbed) index and query syntax used inside a hybrid pipeline, see automated-embedding.md.

Table of Contents

  • Overview

  • Choosing the Right Approach

  • Indexing for Hybrid Search

  • $rankFusion

  • $scoreFusion

  • Lexical Prefilters (vectorSearch Operator)

  • Best Practices and Limitations

Overview

Hybrid search combines multiple search methods on the same collection and merges the results into a single ranked or scored list.

Three patterns covered in this guide:

PatternStage / OperatorUse When
Rank-based fusion$rankFusionDocument position matters; use RRF algorithm
Score-based fusion$scoreFusionScore magnitude matters; need custom math or normalization
Lexical prefilter$search + vectorSearch operatorNeed fuzzy/phrase/wildcard/compound pre-filtering before vector search

$rankFusion vs $scoreFusion:

  • $rankFusion ranks by position in each input pipeline using the Reciprocal Rank Fusion (RRF) algorithm. A document ranked #1 in multiple pipelines scores much higher than one ranked #1 in only one. Weights influence how much each pipeline's rank contributes.

  • $scoreFusion ranks by the actual score values from each pipeline. Supports normalization (sigmoid, minMaxScaler) and custom combination expressions. Use when score magnitude, not just ordering, matters.

Choosing the Right Approach

ScenarioRecommended Approach
Combine lexical + vector, rank by position$rankFusion
Combine lexical + vector, control score math or normalization$scoreFusion
Multiple query vectors or embedding models on same collection$rankFusion with multiple $vectorSearch pipelines
Pre-filter vector search with fuzzy, phrase, wildcard, or compound$search + vectorSearch operator
Pre-filter vector search with simple equality or rangefilter fields in $vectorSearch (see vector-search.md)
Cross-collection hybrid search$unionWith + $vectorSearch (not $rankFusion/$scoreFusion)
Combine lexical + semantic search without writing embedding code$rankFusion or $scoreFusion with an autoEmbed-type $vectorSearch pipeline (see automated-embedding.md)

Version requirements: $rankFusion requires MongoDB 8.0+. $scoreFusion requires MongoDB 8.3+. Only proceed with this guide if the use case is lexical prefilters, or if the cluster meets the version requirement for the fusion stage of interest. Otherwise do not proceed — inform the user the feature is unavailable and suggest upgrading, and offer to help them build the individual lexical or vector search components separately in the meantime.

Indexing for Hybrid Search

For $rankFusion and $scoreFusion

You need two separate indexes on the collection:

1. A vectorSearch-type index for the $vectorSearch input pipeline:

db.collection.createSearchIndex(
  "<vector-index-name>",
  "vectorSearch",
  {
    "fields": [
      {
        "type": "vector",
        "path": "<embedding-field>",
        "numDimensions": <number>,
        "similarity": "dotProduct"
      }
    ]
  }
)

2. A search-type index for the $search input pipeline:

db.collection.createSearchIndex(
  "<search-index-name>",
  {
    "mappings": { "dynamic": true }
  }
)

Using automated embedding instead: If you want MongoDB to generate and manage the embeddings rather than supplying your own, create an autoEmbed-type vectorSearch index instead of the vector-type index shown above. See automated-embedding.md for the index definition and query syntax — the fusion-stage rules below apply the same way regardless of which index type backs the vector pipeline.

For Lexical Prefilters (vectorSearch Operator)

The vectorSearch operator runs inside $search, so you need a single search-type index that includes a vector field type. This is different from a vectorSearch-type index — you cannot use the $vectorSearch stage to query fields indexed this way.

db.collection.createSearchIndex(
  "<search-index-name>",
  {
    "mappings": {
      "dynamic": true,
      "fields": {
        "<embedding-field>": {
          "type": "vector",
          "numDimensions": <number>,
          "similarity": "dotProduct",
          "quantization": "scalar"  // Optional
        }
      }
    }
  }
)

Note: storedSource: true is not supported on indexes that contain a vector field type. Use include or exclude to specify stored fields explicitly.

Common Rules for Fusion Stages

The following rules apply to both $rankFusion and $scoreFusion.

Pipeline naming restrictions: Pipeline names must not be empty, start with $, contain the null character \0, or contain .

Not allowed inside input pipelines: $project or storedSource fields. Apply modifications ($project, $addFields, $set) in stages after the fusion stage.

$rankFusion

$rankFusion executes all input pipelines independently, de-duplicates results, and ranks them using the Reciprocal Rank Fusion (RRF) algorithm. Documents appearing highly ranked in multiple pipelines score highest.

Syntax
{
  $rankFusion: {
    input: {
      pipelines: {
        <pipelineName1>: [ <stages> ],
        <pipelineName2>: [ <stages> ],
        ...
      }
    },
    combination: {
      weights: {
        <pipelineName1>: <number>,
        <pipelineName2>: <number>
      }
    },
    scoreDetails: <boolean>  // Default: false
  }
}
Fields
FieldTypeDescription
input.pipelinesObjectMap of pipeline names to aggregation stages. At least one required.
combination.weightsObjectOptional. Per-pipeline weights (non-negative numbers). Default weight is 1.
scoreDetailsBooleanOptional. If true, populates $meta: "scoreDetails" per document. Default false.
RRF Formula

For each document, the RRF score is:

RRFscore(d) = sum over all pipelines of: weight * (1 / (60 + rank_of_d_in_pipeline))

The constant 60 is a sensitivity parameter set by MongoDB and cannot be changed. Documents not present in a pipeline do not contribute a term for that pipeline.

Input Pipeline Restrictions

See Common Rules for naming and modification restrictions. Allowed stages: $search, $vectorSearch, $match, $geoNear, $sample, $sort, $skip, $limit.

The ordering requirement is satisfied if the pipeline begins with $search, $vectorSearch, or $geoNear, or contains an explicit $sort.

Example 1: Basic Hybrid (Vector + Lexical, Equal Weights)
db.embedded_movies.aggregate([
  {
    $rankFusion: {
      input: {
        pipelines: {
          vectorPipeline: [
            {
              $vectorSearch: {
                index: "<vector-index-name>",
                path: "plot_embedding",
                queryVector: [<query-vector-2048-dimensions>],
                numCandidates: 100,
                limit: 20
              }
            }
          ],
          textPipeline: [
            {
              $search: {
                index: "<search-index-name>",
                text: {
                  query: "<query-term>",
                  path: "title"
                }
              }
            },
            { $limit: 20 }
          ]
        }
      }
    }
  },
  { $limit: 10 }
])

Note: $search does not auto-limit results — always add $limit inside the $search input pipeline.

Example 2: Weighted Hybrid (Boosting One Pipeline)

Assign higher weight to the pipeline whose ranking should contribute more to the final score:

db.embedded_movies.aggregate([
  {
    $rankFusion: {
      input: {
        pipelines: {
          vectorPipeline: [
            {
              $vectorSearch: {
                index: "<vector-index-name>",
                path: "plot_embedding",
                queryVector: [<query-vector-2048-dimensions>],
                numCandidates: 100,
                limit: 20
              }
            }
          ],
          textPipeline: [
            {
              $search: {
                index: "<search-index-name>",
                phrase: {
                  query: "<query-term>",
                  path: "title"
                }
              }
            },
            { $limit: 20 }
          ]
        }
      },
      combination: {
        weights: {
          vectorPipeline: 0.7,
          textPipeline: 0.3
        }
      }
    }
  },
  { $limit: 10 }
])

Recommendation: Set weights per-query based on which method is more appropriate for that query, rather than using static weights for all queries.

Example 3: Multiple $vectorSearch Pipelines

Use multiple vector pipelines to search different fields, different query vectors, or different embedding models:

db.embedded_movies.aggregate([
  {
    $rankFusion: {
      input: {
        pipelines: {
          plotPipeline: [
            {
              $vectorSearch: {
                index: "<vector-index-name>",
                path: "plot_embedding_voyage",
                queryVector: [<query-vector-2048-dimensions>],
                numCandidates: 200,
                limit: 50
              }
            }
          ],
          titlePipeline: [
            {
              $vectorSearch: {
                index: "<vector-index-name>",
                path: "title_embedding_voyage",
                queryVector: [<query-vector-2048-dimensions>],
                numCandidates: 200,
                limit: 50
              }
            }
          ]
        }
      },
      combination: {
        weights: {
          plotPipeline: 0.5,
          titlePipeline: 0.5
        }
      }
    }
  },
  { $limit: 20 }
])
Example 4: Automated Embedding (autoEmbed) + Lexical Search

If the vector pipeline targets an autoEmbed-type index, pass plain text via query instead of a numeric array via queryVector — MongoDB generates the embedding automatically:

db.movies.aggregate([
  {
    $rankFusion: {
      input: {
        pipelines: {
          semanticPipeline: [
            {
              $vectorSearch: {
                index: "<autoembed-index-name>",
                path: "<text-field>",
                query: "<query-text>",    // Plain text — no embedding vector needed
                numCandidates: 100,
                limit: 20
              }
            }
          ],
          textPipeline: [
            {
              $search: {
                index: "<search-index-name>",
                text: {
                  query: "<query-term>",
                  path: "<text-field>"
                }
              }
            },
            { $limit: 20 }
          ]
        }
      },
      combination: {
        weights: {
          semanticPipeline: 0.7,
          textPipeline: 0.3
        }
      }
    }
  },
  { $limit: 10 }
])

The only difference from Example 2 is the vector pipeline's query field: it takes a text string instead of a queryVector array. Weighting, the $limit inside $search, and RRF scoring all work identically. See automated-embedding.md for model selection and index setup.

Surfacing scoreDetails

Set scoreDetails: true on the stage, then project via $meta: "scoreDetails". The output includes a value (final RRF score), description, and a details array — one entry per input pipeline — containing inputPipelineName, rank, weight, and optionally value (raw pipeline score). See the $scoreFusion scoreDetails section below for a concrete structure example; $rankFusion follows the same pattern with rank instead of inputPipelineRawScore.

$scoreFusion

$scoreFusion executes all input pipelines independently, de-duplicates results, and combines them using the actual score values from each pipeline. Supports normalization and custom combination expressions for fine-grained control over how scores are merged.

Syntax
{
  $scoreFusion: {
    input: {
      pipelines: {
        <pipelineName1>: [ <stages> ],
        <pipelineName2>: [ <stages> ],
        ...
      },
      normalization: "none | sigmoid | minMaxScaler"
    },
    combination: {
      weights: {
        <pipelineName1>: <number>,
        <pipelineName2>: <number>
      },
      method: "avg | expression",
      expression: <arithmetic-expression>
    },
    scoreDetails: <boolean>
  }
}
Fields
FieldTypeDescription
input.pipelinesObjectMap of pipeline names to aggregation stages. At least one required.
input.normalizationStringNormalize scores before combining: none (no normalization), sigmoid, or minMaxScaler.
combination.weightsObjectOptional. Per-pipeline weights applied to normalized scores. Default is 1. Mutually exclusive with combination.expression.
combination.methodStringavg (default) or expression.
combination.expressionExpressionCustom arithmetic expression. Use pipeline names as variables representing each pipeline's score. Mutually exclusive with combination.weights.
scoreDetailsBooleanOptional. If true, populates $meta: "scoreDetails" per document. Default false.
Normalization Options
OptionEffect
noneNo normalization — raw scores combined as-is
sigmoidApplies the sigmoid expression, mapping scores to (0, 1)
minMaxScalerApplies the minMaxScaler window operator, scaling scores to [0, 1]
Input Pipeline Restrictions

See Common Rules for naming and modification restrictions. Allowed stages: $search, $vectorSearch, $match, $geoNear, $sort, $skip, $limit. Note: unlike $rankFusion, $sample is not permitted.

The scoring requirement is satisfied if the pipeline begins with $search, $vectorSearch, $match with legacy text search, or $geoNear. Otherwise, include an explicit $score stage.

Example 1: avg Method with Weights
db.embedded_movies.aggregate([
  {
    $scoreFusion: {
      input: {
        pipelines: {
          vectorPipeline: [
            {
              $vectorSearch: {
                index: "<vector-index-name>",
                path: "plot_embedding",
                queryVector: [<query-vector-2048-dimensions>],
                numCandidates: 100,
                limit: 20
              }
            }
          ],
          textPipeline: [
            {
              $search: {
                index: "<search-index-name>",
                text: {
                  query: "<query-term>",
                  path: "title"
                }
              }
            },
            { $limit: 20 }
          ]
        },
        normalization: "sigmoid"
      },
      combination: {
        method: "avg",
        weights: {
          vectorPipeline: 2,
          textPipeline: 1
        }
      }
    }
  },
  { $limit: 10 }
])
Example 2: expression Method with Custom Score Math

Use expression when you need full control over how pipeline scores are combined. Reference pipeline names as variables in the expression:

db.embedded_movies.aggregate([
  {
    $scoreFusion: {
      input: {
        pipelines: {
          searchOne: [
            {
              $vectorSearch: {
                index: "<vector-index-name>",
                path: "plot_embedding",
                queryVector: [<query-vector-2048-dimensions>],
                numCandidates: 100,
                limit: 20
              }
            }
          ],
          searchTwo: [
            {
              $search: {
                index: "<search-index-name>",
                text: {
                  query: "<query-term>",
                  path: "title"
                }
              }
            },
            { $limit: 20 }
          ]
        },
        normalization: "sigmoid"
      },
      combination: {
        method: "expression",
        expression: {
          $sum: [
            { $multiply: ["$searchOne", 10] },
            "$searchTwo"
          ]
        }
      },
      scoreDetails: true
    }
  },
  {
    $project: {
      _id: 1,
      title: 1,
      plot: 1,
      scoreDetails: { $meta: "scoreDetails" }
    }
  },
  { $limit: 10 }
])

Note: combination.expression and combination.weights are mutually exclusive. When using expression, embed weights directly via $multiply as shown above.

Using autoEmbed pipelines: As with $rankFusion, pass query (text) instead of queryVector (array) in the $vectorSearch stage when it targets an autoEmbed-type index — see Example 4 under $rankFusion and automated-embedding.md for the full syntax.

Surfacing scoreDetails

Set scoreDetails: true, then use $meta: "scoreDetails" in $project, $addFields, or $set:

{
  $project: {
    title: 1,
    scoreDetails: { $meta: "scoreDetails" }
  }
}

scoreDetails structure:

{
  value: 7.847,
  description: "the value calculated by combining the scores...",
  normalization: "sigmoid",
  combination: {
    method: "custom expression",
    expression: "{ $sum: [{ $multiply: ['$searchOne', 10] }, '$searchTwo'] }"
  },
  details: [
    {
      inputPipelineName: "searchOne",
      inputPipelineRawScore: 0.798,
      weight: 1,
      value: 0.689,
      details: []
    },
    {
      inputPipelineName: "searchTwo",
      inputPipelineRawScore: 2.962,
      weight: 1,
      value: 0.950,
      details: []
    }
  ]
}

Lexical Prefilters (vectorSearch Operator)

The vectorSearch operator runs inside a $search stage and performs ANN or ENN vector search with the ability to pre-filter using any Atlas Search operator — including text with fuzzy matching, phrase, wildcard, queryString, and compound. This is more expressive than the MQL-only filter option in the $vectorSearch stage.

Requires: A search-type index (not vectorSearch-type) with the embedding field configured as vector type. See Indexing for Hybrid Search.

Cannot be used: Inside embeddedDocument, compound, or facet operators.

Syntax
{
  $search: {
    index: "<search-index-name>",
    vectorSearch: {
      path: "<vector-field>",
      queryVector: [<array-of-numbers>],
      limit: <number>,
      numCandidates: <number>,       // Required for ANN (exact: false)
      exact: true | false,           // Optional, default false
      filter: { <search-operator> }, // Optional
      score: { <score-options> }     // Optional
    },
    concurrent: true  // Optional, dedicated search nodes only
  }
}
Key Fields
FieldRequiredDescription
pathYesThe field indexed as vector type in the search index
queryVectorYesArray of numbers matching numDimensions in the index
limitYesNumber of results to return
numCandidatesConditionalRequired if exact is false or omitted. Max 10000. Recommend 20x limit.
exactNotrue for ENN, false/omit for ANN
filterNoAny Atlas Search operator to pre-filter documents
concurrentNoParallelizes search across segments on dedicated search nodes. Ignored if no dedicated search nodes.
Example 1: compound Prefilter (queryString + range)

Filter by text match OR date range before running vector search:

db.embedded_movies.aggregate([
  {
    $search: {
      index: "<search-index-name>",
      vectorSearch: {
        path: "plot_embedding",
        queryVector: [<query-vector-2048-dimensions>],
        limit: 10,
        exact: true,
        filter: {
          compound: {
            should: [
              {
                queryString: {
                  defaultPath: "fullplot",
                  query: "plot:courtroom OR lawyer"
                }
              },
              {
                range: {
                  path: "year",
                  gte: 2000,
                  lte: 2015
                }
              }
            ]
          }
        }
      },
      concurrent: true
    }
  },
  {
    $project: {
      _id: 0,
      title: 1,
      plot: 1,
      score: { $meta: "searchScore" }
    }
  }
])
Example 2: text Prefilter with Fuzzy Matching

Filter by fuzzy text match before running ANN vector search:

db.embedded_movies.aggregate([
  {
    $search: {
      index: "<search-index-name>",
      vectorSearch: {
        path: "plot_embedding",
        queryVector: [<query-vector-2048-dimensions>],
        limit: 10,
        numCandidates: 200,
        filter: {
          text: {
            path: "fullplot",
            query: "charming animal",
            fuzzy: {}
          }
        }
      },
      concurrent: true
    }
  },
  {
    $project: {
      _id: 0,
      title: 1,
      plot: 1,
      score: { $meta: "searchScore" }
    }
  }
])

Best Practices and Limitations

Best Practices

Set limits inside $search sub-pipelines: $search does not limit results by default. Always add $limit inside the input pipeline, or $rankFusion/$scoreFusion evaluates all search results.

textPipeline: [
  { $search: { ... } },
  { $limit: 20 }  // Required
]

Set weights per-query: Tune weights based on which search method is most appropriate for a given query rather than using fixed weights for all queries. This improves relevance and resource utilization.

Handle disjoint results: If most results come from one pipeline and not the other, the two methods are returning largely different documents. Increase per-pipeline limits to improve overlap.

Use $match for non-search filtering: To filter on specific fields without a search pipeline (e.g., boost on a flag field), add a $match pipeline inside input.pipelines. It must contain an explicit $sort to qualify as a ranked pipeline.

Limitations

Single collection only: $rankFusion and $scoreFusion cannot span multiple collections. For cross-collection hybrid search, use $unionWith with $vectorSearch.

Pipelines run serially: Input pipelines do not execute in parallel.

No pagination inside sub-pipelines: $rankFusion and $scoreFusion do not support pagination within input pipelines.

vectorSearch operator restrictions: Cannot be used inside embeddedDocument, compound, or facet operators. Cannot use highlight, sort, or searchSequenceToken with the vectorSearch operator — use $skip and $limit after $search instead.

Requirements and compatibility

Written for: Claude Code

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: Names Claude Code tools, Needs an API key, Needs Python

Security

What our scanner noticed· Low risk

  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

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-search-and-ai · 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 or MongoDB.

Download ZIP

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