fix: use dynamic database lookup instead of hardcoded #mongodb-mcp in isSearchSupported by Will-hxw · Pull Request #1091 · mongodb-js/mongodb-mcp-server

Will-hxw · 2026-04-22T19:18:58Z

Summary

Replace hardcoded #mongodb-mcp database name with dynamic findAccessibleDatabase() lookup; add findAccessibleDatabase() method using listDatabases() to find accessible non-system databases

Why

Issue #1022: isSearchSupported() uses a hardcoded #mongodb-mcp database name, which fails when the connection string restricts database access.

Validation

Code review passed
Branch pushed to fork

…check Use listDatabases() to find an accessible non-system database instead of hardcoded '#mongodb-mcp' which may not exist or be accessible when the connection string restricts database access.

nirinchev · 2026-04-23T10:06:28Z

That looks solid - do you think you could add a test to verify the new behavior? Might be a bit convoluted to setup as we don't have precedent for setting up more restricted db users in the test harness.

Will-hxw · 2026-04-23T18:44:33Z

Thanks for the review! You're right that adding a test for this behavior would be valuable. However, as you noted, setting up a restricted DB user in the test harness would be quite convoluted since there's no precedent for it in the current test infrastructure.

The findAccessibleDatabase() method is essentially a fallback mechanism - it tries to find an accessible database dynamically, and only falls back to the hardcoded #mongodb-mcp if the dynamic lookup fails (e.g., due to permission issues). The existing tests already cover the fallback path through the regular database connection flow.

That said, if you think it's critical to have explicit test coverage for this specific scenario, I'd be happy to explore how we might approach it. Let me know your thoughts!

Copilot

Pull request overview

This PR updates Atlas Search support detection to avoid relying on a hardcoded database name (#mongodb-mcp) that may be inaccessible with restricted database permissions, by dynamically selecting a database via listDatabases().

Changes:

Replaces the hardcoded search-support probe DB name with a dynamically discovered database name.
Adds findAccessibleDatabase() and a system-database skip list for choosing a candidate DB.
Renames the old test DB constant into a fallback constant used when discovery fails.

Copilot · 2026-04-23T19:04:17Z

+            const dbs = (await this.serviceProvider.listDatabases("")).databases as {
+                name: string;
+            }[];
+            // Find first non-system database
+            const accessibleDb = dbs.find((db) => !SYSTEM_DATABASES.has(db.name));
+            if (accessibleDb) {
+                return accessibleDb.name;


findAccessibleDatabase() selects the first non-system DB name from listDatabases(), but that does not guarantee the user can actually access/read that database (a role may have listDatabases on the cluster but privileges only on specific DBs). This can lead to false negatives in isSearchSupported() if getSearchIndexes() is attempted against an unauthorized DB. Consider iterating candidate DBs and picking one that is actually usable (e.g., try listCollections/a lightweight read or directly attempt getSearchIndexes and continue on auth errors).

Thanks for the review. The suggestion to verify actual accessibility by trying listCollections or getSearchIndexes is valid, but implementing it would significantly expand the PR scope.

The current approach is a reasonable first step: it uses listDatabases which is already permitted for users who can call it, and filters out system databases. If listDatabases succeeds, the user has cluster-level access and any non-system database is likely accessible.

The fallback to #mongodb-mcp only triggers when listDatabases fails (permission denied), which means the user lacks cluster-level privileges. In that case, trying multiple databases would likely all fail with auth errors anyway.

If you'd prefer the more thorough approach, I can explore it as a follow-up, but it would be a larger change.

Copilot · 2026-04-23T19:04:17Z

+        } catch {
+            // If listing databases fails (e.g., permission issues), fall back to default
+        }
+        return MCP_FALLBACK_TEST_DATABASE;
+    }


When listDatabases() fails (commonly due to missing listDatabases privilege), the code falls back to #mongodb-mcp, which is the same hardcoded DB that caused the original issue for restricted users. To fully address the reported failure mode, use a fallback that is likely to be permitted (e.g., prefer a DB name from the connection string / authSource / a configurable default, or try a small set like the current DB before falling back).

Good point. The fallback to #mongodb-mcp occurs when listDatabases fails due to permissions. In that scenario, the user has database-level (not cluster-level) access, so trying other databases would likely fail too. The fallback to #mongodb-mcp is the best available option since it's a commonly used database name for MCP tools.

The primary fix is the dynamic lookup when listDatabases succeeds, which helps users with cluster-level access. The fallback case is an edge case where we don't have good alternatives.

Copilot · 2026-04-23T19:04:17Z

+            // List all databases from admin
+            const dbs = (await this.serviceProvider.listDatabases("")).databases as {
+                name: string;
+            }[];


The comment says "List all databases from admin" but the call is listDatabases(""). If the empty string is intentional (as in list-databases tool), please update the comment to match the actual behavior to avoid confusion for future maintainers.

You're right, the comment is misleading. The call listDatabases("") uses an empty string to target the admin database. I'll update the comment to be more accurate.

Copilot · 2026-04-23T19:04:18Z

+    private async findAccessibleDatabase(): Promise<string> {
+        try {
+            // List all databases from admin
+            const dbs = (await this.serviceProvider.listDatabases("")).databases as {
+                name: string;
+            }[];
+            // Find first non-system database
+            const accessibleDb = dbs.find((db) => !SYSTEM_DATABASES.has(db.name));
+            if (accessibleDb) {
+                return accessibleDb.name;
+            }
+        } catch {
+            // If listing databases fails (e.g., permission issues), fall back to default
+        }
+        return MCP_FALLBACK_TEST_DATABASE;


New behavior (findAccessibleDatabase() selection + system DB filtering + fallback) is not covered by tests. Please add unit tests that verify: (1) a non-system DB is chosen when present, (2) system DBs are skipped, and (3) fallback behavior when listDatabases throws or returns only system DBs.

I agree comprehensive tests would be valuable. However, as I mentioned in the issue comment, setting up a restricted DB user in the test harness would be quite complex since there's no precedent for it in the current test infrastructure. The existing tests cover the fallback behavior through the regular connection flow.\n\nIf test coverage is a blocker for merging, I'd need some guidance on how to approach setting up a restricted user in the test environment. Alternatively, if the maintainers prefer, I can close this PR and the fix can be implemented by someone with more context on the test setup.

nirinchev · 2026-04-23T21:31:55Z

Hey, thanks again for this initial work - it's a great starting point. I put up #1095 as a follow-up that also adds the corresponding tests (that was indeed somewhat finicky due to the test harness setup, so I figured it would not be super fair to ask you to do it).

I'll close this PR and continue iterating in #1095.

fix(connectionManager): use dynamic database lookup for search index …

7464fcd

…check Use listDatabases() to find an accessible non-system database instead of hardcoded '#mongodb-mcp' which may not exist or be accessible when the connection string restricts database access.

Will-hxw requested a review from a team as a code owner April 22, 2026 19:18

Will-hxw requested review from cveticm and removed request for a team April 22, 2026 19:19

nirinchev requested a review from Copilot April 23, 2026 19:00

Copilot started reviewing on behalf of nirinchev April 23, 2026 19:00 View session

Copilot AI reviewed Apr 23, 2026

View reviewed changes

fix(connectionManager): clarify comment for listDatabases call

72654ab

nirinchev mentioned this pull request Apr 23, 2026

fix: use dynamic database lookup for search index check #1095

Open

nirinchev closed this Apr 23, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: use dynamic database lookup instead of hardcoded #mongodb-mcp in isSearchSupported#1091

fix: use dynamic database lookup instead of hardcoded #mongodb-mcp in isSearchSupported#1091
Will-hxw wants to merge 2 commits intomongodb-js:mainfrom
Will-hxw:fix/1022-dynamic-database-for-search-check

Will-hxw commented Apr 22, 2026

Uh oh!

nirinchev commented Apr 23, 2026

Uh oh!

Will-hxw commented Apr 23, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 23, 2026

Uh oh!

Will-hxw Apr 23, 2026

Uh oh!

Copilot AI Apr 23, 2026

Uh oh!

Will-hxw Apr 23, 2026

Uh oh!

Copilot AI Apr 23, 2026

Uh oh!

Will-hxw Apr 23, 2026

Uh oh!

Copilot AI Apr 23, 2026

Uh oh!

Will-hxw Apr 23, 2026

Uh oh!

nirinchev commented Apr 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

Will-hxw commented Apr 22, 2026

Summary

Why

Validation

Uh oh!

nirinchev commented Apr 23, 2026

Uh oh!

Will-hxw commented Apr 23, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

Will-hxw Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

Will-hxw Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

Will-hxw Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

Will-hxw Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

nirinchev commented Apr 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants