Skip to content

Conversation

@nirinchev
Copy link
Collaborator

Proposed changes

This adds support for creating atlas search indexes. Dropping and listing is already supported, so needed no changes.

@nirinchev nirinchev requested a review from a team as a code owner October 27, 2025 15:11
@nirinchev nirinchev requested a review from Copilot October 27, 2025 16:03
Base automatically changed from ni/feature-flags to main October 27, 2025 16:03
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR adds support for creating Atlas Search (lexical) indexes through the MCP server. The changes enable users to create Atlas Search indexes with both dynamic and explicit field mappings, complementing the existing support for listing and dropping search indexes.

Key changes:

  • Added Atlas Search index creation support to create-index tool with comprehensive schema validation
  • Enhanced testing to differentiate between search and vector search indexes
  • Added accuracy tests for various Atlas Search index creation scenarios

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
src/tools/mongodb/create/createIndex.ts Adds atlasSearchIndexDefinition schema and implements search index creation logic
tests/integration/tools/mongodb/create/createIndex.test.ts Adds comprehensive integration tests for Atlas Search index creation scenarios
tests/integration/tools/mongodb/delete/dropIndex.test.ts Refactors tests to handle both search and vector search indexes separately
tests/accuracy/createIndex.test.ts Adds accuracy test cases for Atlas Search index creation with various configurations
tests/accuracy/sdk/accuracyTestingClient.ts Removes deprecated --connectionString flag from CLI arguments
README.md Updates documentation to remove deprecated --connectionString flag
Comments suppressed due to low confidence (1)

tests/integration/tools/mongodb/create/createIndex.test.ts:1

  • The index names are being evaluated at test definition time rather than test execution time. If getSearchIndexName() and getVectorIndexName() depend on beforeEach setup, these calls will execute before the setup runs, potentially returning undefined or stale values. Wrap these in functions: { description: "search", indexName: () => getSearchIndexName() } and update the test to call the function.
import { describeWithMongoDB, validateAutoConnectBehavior, waitUntilSearchIsReady } from "../mongodbHelpers.js";

@coveralls
Copy link
Collaborator

coveralls commented Oct 27, 2025

Pull Request Test Coverage Report for Build 18909991547

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

Details

  • 140 of 140 (100.0%) changed or added relevant lines in 1 file are covered.
  • 57 unchanged lines in 2 files lost coverage.
  • Overall coverage increased (+0.2%) to 80.378%

Files with Coverage Reduction New Missed Lines %
src/tools/mongodb/read/aggregate.ts 26 88.72%
src/common/search/vectorSearchEmbeddingsManager.ts 31 81.79%
Totals Coverage Status
Change from base Build 18847594160: 0.2%
Covered Lines: 6435
Relevant Lines: 7861

💛 - Coveralls

import { quantizationEnum, similarityEnum } from "../../../common/search/vectorSearchEmbeddingsManager.js";

export class CreateIndexTool extends MongoDBToolBase {
private vectorSearchIndexDefinition = z.object({
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is best viewed with the "Hide whitespace" option - it's just prettier reformatting the indents.

});

const args = [MCP_SERVER_CLI_SCRIPT, "--connectionString", mdbConnectionString, ...additionalArgs];
const args = [MCP_SERVER_CLI_SCRIPT, mdbConnectionString, ...additionalArgs];
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--connectionString is deprecated so using the positional argument.

@nirinchev nirinchev changed the title feat: add ability to create atlas search indexes feat: add ability to create atlas search indexes MCP-275 Oct 28, 2025
})
.describe("Definition for a Vector Search index.");

private atlasSearchIndexDefinition = z
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why aren't we supporting custom analyzers?

https://www.mongodb.com/docs/atlas/atlas-search/analyzers/custom/

private atlasSearchIndexDefinition = z
.object({
type: z.literal("search"),
analyzer: z
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably this should be an enum of the analyzers.

"The analyzer to use for the index. Can be one of the built-in lucene analyzers (`lucene.standard`, `lucene.simple`, `lucene.whitespace`, `lucene.keyword`), a language-specific analyzer, such as `lucene.cjk` or `lucene.czech`, or a custom analyzer defined in the Atlas UI."
),
mappings: z
.object({
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lack support of:

  • numPartitions
  • searchAnalyzer vs analyze
  • custom analyzers
  • storedSources
  • synonyms
  • typeSets

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://www.mongodb.com/docs/atlas/atlas-search/index-definitions/?deployment-type=atlas&interface=driver&language=nodejs#std-label-ref-index-definitions

We could say that custom analyzers are not that important, but storedSources is actually relevant most of the times.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The args shape is based on the POC the search team did for index support and I was going off of the assumption that they've selected the fields that they see the most value in exposing to LLMs. I realize there's a lot more configuration that's possible, I'm just not sure how much of that is stuff we expect agents to configure vs an actual human who wants to fine-tune the index.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A POC to see the feasibility to create search indexes and production code are likely to have different requirements.

mappings: z
.object({
dynamic: z
.boolean()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dynamic can be an object of typeSets.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is in preview though, so I don't expect there's sufficient docs or training data for general-purpose models to accurately choose which one to use.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The preview is for vector search though, FTS is explicitly out of scope of the vector search project.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The typeSets functionality is in preview.

Copy link
Collaborator

@kmruiz kmruiz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current implementation lacks support for multiple important fields, and it should be discussed if we want to support them or not.

z.string().describe("The field name"),
z
.object({
type: z
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Objects will require additional fields depending on the type. I know passthrough will keep them, but we should document them so the agent knows which ones to use and how. For example, autocomplete supports defining a custom analyzer, how to tokenize (which is really important) and similarity functions.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The exact shape is extremely complex to represent in a json schema. I'm worried that being overly specific will result in this being more harmful than helpful, especially if we expect the majority of the use cases to revolve around just specifying the type.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, the schema is complicated, it has a lot of options that are not compatible even between them. We should have proper documentation of which ones we want to expose and which ones not, something that we haven't discussed yet because supporting the most used bits of Atlas Search is already a substantial effort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants