trackmcp
Back to directory
furey

mongodb-lens

View on GitHub

🍃🔎 MongoDB Lens: Full Featured MCP Server for MongoDB Databases JavaScript-based implementation.

189 stars JavaScriptAI & Machine Learning Updated Nov 1, 2025
aiclaudedatabasellmmcpmodel-context-protocolmongodb

Documentation

MongoDB Lens

License
Docker Hub Version
NPM Version
Buy Me a Coffee

MongoDB Lens is a local Model Context Protocol (MCP) server with full featured access to MongoDB databases using natural language via LLMs to perform queries, run aggregations, optimize performance, and more.

Contents

Quick Start

Features

Tools

Resources

Prompts

Other Features

Other Features: Overview

MongoDB Lens includes numerous other features:

  • **Config File**: Custom configuration via `~/.mongodb-lens.[jsonc|json]`
  • **Env Var Overrides**: Override config settings via `process.env.CONFIG_*`
  • **Confirmation System**: Two-step verification for destructive operations
  • **Multiple Connections**: Define and switch between named URI aliases
  • **Component Disabling**: Selectively disable tools, prompts or resources
  • Connection Resilience: Auto-reconnection with exponential backoff
  • Query Safeguards: Configurable limits and performance protections
  • Error Handling: Comprehensive JSONRPC error codes and messages
  • Schema Inference: Efficient schema analysis with intelligent sampling
  • Credential Protection: Connection string password obfuscation in logs
  • Memory Management: Auto-monitoring and cleanup for large operations
  • Smart Caching: Optimized caching for schema, indexes, fields and collections
  • Backwards Compatible: Support both modern and legacy MongoDB versions

Other Features: New Database Metadata

MongoDB Lens inserts a `metadata` collection into each database it creates.

This `metadata` collection stores a single document containing contextual information serving as a permanent record of the database's origin while ensuring the new and otherwise empty database persists in MongoDB's storage system.

Example metadata document

js
{
    "_id" : ObjectId("67d5284463788ec38aecee14"),
    "created" : {
        "timestamp" : ISODate("2025-03-15T07:12:04.705Z"),
        "tool" : "MongoDB Lens v5.0.7",
        "user" : "anonymous"
    },
    "mongodb" : {
        "version" : "3.6.23",
        "connectionInfo" : {
            "host" : "unknown",
            "readPreference" : "primary"
        }
    },
    "database" : {
        "name" : "example_database",
        "description" : "Created via MongoDB Lens"
    },
    "system" : {
        "hostname" : "unknown",
        "platform" : "darwin",
        "nodeVersion" : "v22.14.0"
    },
    "lens" : {
        "version" : "5.0.7",
        "startTimestamp" : ISODate("2025-03-15T07:10:06.084Z")
    }
}

Once you've added your own collections to your new database, you can safely remove the `metadata` collection via the `drop-collection` tool:

  • _"Drop the new database's metadata collection"_

➥ Uses `drop-collection` tool (with confirmation)

Installation

MongoDB Lens can be installed and run in several ways:

Installation: NPX

> [!NOTE]

> NPX requires Node.js installed and running on your system (suggestion: use Volta).

The easiest way to run MongoDB Lens is using NPX.

First, ensure Node.js is installed:

console
node --version # Ideally >= v22.x but MongoDB Lens is >= v18.x compatible

Then, run MongoDB Lens via NPX:

console
# Using default connection string mongodb://localhost:27017
npx -y mongodb-lens

# Using custom connection string
npx -y mongodb-lens mongodb://your-connection-string

# Using "@latest" to keep the package up-to-date
npx -y mongodb-lens@latest

> [!TIP]

> If you encounter permissions errors with `npx` try running `npx clear-npx-cache` prior to running `npx -y mongodb-lens` (this clears the cache and re-downloads the package).

Installation: Docker Hub

> [!NOTE]

> Docker Hub requires Docker installed and running on your system.

First, ensure Docker is installed:

console
docker --version # Ideally >= v27.x

Then, run MongoDB Lens via Docker Hub:

console
# Using default connection string mongodb://localhost:27017
docker run --rm -i --network=host furey/mongodb-lens

# Using custom connection string
docker run --rm -i --network=host furey/mongodb-lens mongodb://your-connection-string

# Using "--pull" to keep the Docker image up-to-date
docker run --rm -i --network=host --pull=always furey/mongodb-lens

Installation: Node.js from Source

> [!NOTE]

> Node.js from source requires Node.js installed and running on your system (suggestion: use Volta).

1. Clone the MongoDB Lens repository:

console
git clone https://github.com/furey/mongodb-lens.git

1. Navigate to the cloned repository directory:

console
cd /path/to/mongodb-lens

1. Ensure Node.js is installed:

console
node --version # Ideally >= v22.x but MongoDB Lens is >= v18.x compatible

1. Install Node.js dependencies:

console
npm ci

1. Start the server:

console
# Using default connection string mongodb://localhost:27017
    node mongodb-lens.js

    # Using custom connection string
    node mongodb-lens.js mongodb://your-connection-string

Installation: Docker from Source

> [!NOTE]

> Docker from source requires Docker installed and running on your system.

1. Clone the MongoDB Lens repository:

console
git clone https://github.com/furey/mongodb-lens.git

1. Navigate to the cloned repository directory:

console
cd /path/to/mongodb-lens

1. Ensure Docker is installed:

console
docker --version # Ideally >= v27.x

1. Build the Docker image:

console
docker build -t mongodb-lens .

1. Run the container:

console
# Using default connection string mongodb://localhost:27017
    docker run --rm -i --network=host mongodb-lens

    # Using custom connection string
    docker run --rm -i --network=host mongodb-lens mongodb://your-connection-string

Installation Verification

To verify the installation, paste and run the following JSONRPC message into the server's stdio:

json
{"method":"resources/read","params":{"uri":"mongodb://databases"},"jsonrpc":"2.0","id":1}

The server should respond with a list of databases in your MongoDB instance, for example:

json
{"result":{"contents":[{"uri":"mongodb://databases","text":"Databases (12):\n- admin (180.00 KB)\n- config (108.00 KB)\n- local (40.00 KB)\n- sample_airbnb (51.88 MB)\n- sample_analytics (9.46 MB)\n- sample_geospatial (980.00 KB)\n- sample_guides (40.00 KB)\n- sample_mflix (108.90 MB)\n- sample_restaurants (7.73 MB)\n- sample_supplies (968.00 KB)\n- sample_training (40.85 MB)\n- sample_weatherdata (2.69 MB)"}]},"jsonrpc":"2.0","id":1}

MongoDB Lens is now installed and ready to accept MCP requests.

Installation: Older MongoDB Versions

If connecting to a MongoDB instance with a version `

console
git clone https://github.com/furey/mongodb-lens.git

1. Navigate to the cloned repository directory:

console
cd /path/to/mongodb-lens

1. Modify `package.json`:

diff
"dependencies": {
      ...
    -  "mongodb": "^6.15.0",  // Or whatever newer version is listed
    +  "mongodb": "^3.7.4",   // Or whatever 3.x version is compatible with your older MongoDB instance
      ...
    }

1. Install Node.js dependencies:

console
npm install

1. Start MongoDB Lens:

console
node mongodb-lens.js mongodb://older-mongodb-instance

This will use the older driver version compatible with your MongoDB instance.

> [!NOTE]

> You may also need to revert this commit to add back `useNewUrlParser` and `useUnifiedTopology` MongoDB configuration options.

Older MongoDB Versions: Using NPX or Docker

If you prefer to use NPX or Docker, you'll need to use an older version of MongoDB Lens that was published with a compatible driver.

For example, MongoDB Lens `8.3.0` uses MongoDB Node.js driver `3.7.4` (see: `package-lock.json`).

To run an older version of MongoDB Lens using NPX, specify the version tag:

console
npx -y mongodb-lens@8.3.0

Similarly for Docker:

console
docker run --rm -i --network=host furey/mongodb-lens:8.3.0

Configuration

Configuration: MongoDB Connection String

The server accepts a MongoDB connection string as its only argument.

Example NPX usage:

console
npx -y mongodb-lens@latest mongodb://your-connection-string

MongoDB connection strings have the following format:

txt
mongodb://[username:password@]host[:port][/database][?options]

Example connection strings:

  • Local connection:

`mongodb://localhost:27017`

  • Connection to `mydatabase` with credentials from `admin` database:

`mongodb://username:password@hostname:27017/mydatabase?authSource=admin`

  • Connection to `mydatabase` with various other options:

`mongodb://hostname:27017/mydatabase?retryWrites=true&w=majority`

If no connection string is provided, the server will attempt to connect via local connection.

Configuration: Config File

MongoDB Lens supports extensive customization via JSON configuration file.

> [!NOTE]

> The config file is optional. MongoDB Lens will run with default settings if no config file is provided.

> [!TIP]

> You only need to include the settings you want to customize in the config file. MongoDB Lens will use default settings for any omitted values.

> [!TIP]

> MongoDB Lens supports both `.json` and `.jsonc` (JSON with comments) config file formats.

Example configuration file

jsonc
{
  "mongoUri": "mongodb://localhost:27017",         // Default MongoDB connection string or object of alias-URI pairs
  "connectionOptions": {
    "maxPoolSize": 20,                             // Maximum number of connections in the pool
    "retryWrites": false,                          // Whether to retry write operations
    "connectTimeoutMS": 30000,                     // Connection timeout in milliseconds
    "socketTimeoutMS": 360000,                     // Socket timeout in milliseconds
    "heartbeatFrequencyMS": 10000,                 // How often to ping servers for status
    "serverSelectionTimeoutMS": 30000              // Timeout for server selection
  },
  "defaultDbName": "admin",                        // Default database if not specified in URI
  "connection": {
    "maxRetries": 5,                               // Maximum number of initial connection attempts
    "maxRetryDelayMs": 30000,                      // Maximum delay between retries
    "reconnectionRetries": 10,                     // Maximum reconnection attempts if connection lost
    "initialRetryDelayMs": 1000                    // Initial delay between retries
  },
  "disabled": {
    "tools": [],                                   // Array of tools to disable or true to disable all
    "prompts": [],                                 // Array of prompts to disable or true to disable all
    "resources": []                                // Array of resources to disable or true to disable all
  },
  "enabled": {
    "tools": true,                                 // Array of tools to enable or true to enable all
    "prompts": true,                               // Array of prompts to enable or true to enable all
    "resources": true                              // Array of resources to enable or true to enable all
  },
  "cacheTTL": {
    "stats": 15000,                                // Stats cache lifetime in milliseconds
    "fields": 30000,                               // Fields cache lifetime in milliseconds
    "schemas": 60000,                              // Schema cache lifetime in milliseconds
    "indexes": 120000,                             // Index cache lifetime in milliseconds
    "collections": 30000,                          // Collections list cache lifetime in milliseconds
    "serverStatus": 20000                          // Server status cache lifetime in milliseconds
  },
  "enabledCaches": [                               // List of caches to enable
    "stats",                                       // Statistics cache
    "fields",                                      // Collection fields cache
    "schemas",                                     // Collection schemas cache
    "indexes",                                     // Collection indexes cache
    "collections",                                 // Database collections cache
    "serverStatus"                                 // MongoDB server status cache
  ],
  "memory": {
    "enableGC": true,                              // Whether to enable garbage collection
    "warningThresholdMB": 1500,                    // Memory threshold for warnings
    "criticalThresholdMB": 2000                    // Memory threshold for cache clearing
  },
  "logLevel": "info",                              // Log level (info or verbose)
  "disableDestructiveOperationTokens": false,      // Whether to skip confirmation for destructive ops
  "watchdogIntervalMs": 30000,                     // Interval for connection monitoring
  "defaults": {
    "slowMs": 100,                                 // Threshold for slow query detection
    "queryLimit": 10,                              // Default limit for query results
    "allowDiskUse": true,                          // Allow operations to use disk for large datasets
    "schemaSampleSize": 100,                       // Sample size for schema inference
    "aggregationBatchSize": 50                     // Batch size for aggregation operations
  },
  "security": {
    "tokenLength": 4,                              // Length of confirmation tokens
    "tokenExpirationMinutes": 5,                   // Expiration time for tokens
    "strictDatabaseNameValidation": true           // Enforce strict database name validation
  },
  "tools": {
    "transaction": {
      "readConcern": "snapshot",                   // Read concern level for transactions
      "writeConcern": {
        "w": "majority"                            // Write concern for transactions
      }
    },
    "bulkOperations": {
      "ordered": true                              // Whether bulk operations execute in order
    },
    "export": {
      "defaultLimit": -1,                          // Default limit for exports (-1 = no limit)
      "defaultFormat": "json"                      // Default export format (json or csv)
    },
    "watchChanges": {
      "maxDurationSeconds": 60,                    // Maximum duration for change streams
      "defaultDurationSeconds": 10                 // Default duration for change streams
    },
    "queryAnalysis": {
      "defaultDurationSeconds": 10                 // Default duration for query analysis
    }
  }
}

By default, MongoDB Lens looks for the config file at:

  • `~/.mongodb-lens.jsonc` first, then falls back to
  • `~/.mongodb-lens.json` if the former doesn't exist

To customize the config file path, set the environment variable `CONFIG_PATH` to the desired file path.

Example NPX usage:

console
CONFIG_PATH='/path/to/config.json' npx -y mongodb-lens@latest

Example Docker Hub usage:

console
docker run --rm -i --network=host --pull=always -v /path/to/config.json:/root/.mongodb-lens.json furey/mongodb-lens

Configuration: Config File Generation

You can generate a configuration file automatically using the `config:create` script:

console
# NPX Usage (recommended)
npx -y mongodb-lens@latest config:create

# Node.js Usage
npm run config:create

# Force overwrite existing files
npx -y mongodb-lens@latest config:create -- --force
npm run config:create -- --force

This script extracts the example configuration file above and saves it to: `~/.mongodb-lens.jsonc`

Config File Generation: Custom Path

You can specify a custom output location using the `CONFIG_PATH` environment variable.

  • If `CONFIG_PATH` has no file extension, it's treated as a directory and `.mongodb-lens.jsonc` is appended
  • If `CONFIG_PATH` ends with `.json` (not `.jsonc`) comments are removed from the generated file

Example NPX usage:

console
# With custom path
CONFIG_PATH=/path/to/config.jsonc npx -y mongodb-lens@latest config:create

# Save to directory (will append .mongodb-lens.jsonc to the path)
CONFIG_PATH=/path/to/directory npx -y mongodb-lens@latest config:create

# Save as JSON instead of JSONC
CONFIG_PATH=/path/to/config.json npx -y mongodb-lens@latest config:create

Example Node.js usage:

console
# With custom path
CONFIG_PATH=/path/to/config.jsonc node mongodb-lens.js config:create

# Save to directory (will append .mongodb-lens.jsonc to the path)
CONFIG_PATH=/path/to/directory node mongodb-lens.js config:create

# Save as JSON instead of JSONC
CONFIG_PATH=/path/to/config.json node mongodb-lens.js config:create

Configuration: Multiple MongoDB Connections

MongoDB Lens supports multiple MongoDB URIs with aliases in your config file, allowing you to easily switch between different MongoDB instances using simple names.

To configure multiple connections, set the `mongoUri` config setting to an object with alias-URI pairs:

json
{
  "mongoUri": {
    "main": "mongodb://localhost:27017",
    "backup": "mongodb://localhost:27018",
    "atlas": "mongodb+srv://username:password@cluster.mongodb.net/mydb"
  }
}

With this configuration:

  • The first URI in the list (e.g. `main`) becomes the default connection at startup
  • You can switch connections using natural language: `"Connect to backup"` or `"Connect to atlas"`
  • The original syntax still works: `"Connect to mongodb://localhost:27018"`
  • The `list-connections` tool shows all available connection aliases

> [!NOTE]

> When using the command-line argument to specify a connection, you can use either a full MongoDB URI or an alias defined in your configuration file.

> [!TIP]

> To add connection aliases at runtime, use the `add-connection-alias` tool.

Configuration: Environment Variable Overrides

MongoDB Lens supports environment variable overrides for configuration settings.

Environment variables take precedence over config file settings.

Config environment variables follow the naming pattern:

txt
CONFIG_[SETTING PATH, SNAKE CASED, UPPERCASED]

Example overrides:

Config SettingEnvironment Variable Override
`mongoUri``CONFIG_MONGO_URI`
`logLevel``CONFIG_LOG_LEVEL`
`defaultDbName``CONFIG_DEFAULT_DB_NAME`
`defaults.queryLimit``CONFIG_DEFAULTS_QUERY_LIMIT`
`tools.export.defaultFormat``CONFIG_TOOLS_EXPORT_DEFAULT_FORMAT`
`connectionOptions.maxPoolSize``CONFIG_CONNECTION_OPTIONS_MAX_POOL_SIZE`
`connection.reconnectionRetries``CONFIG_CONNECTION_RECONNECTION_RETRIES`

For environment variable values:

  • For boolean settings, use string values `'true'` or `'false'`.
  • For numeric settings, use string representations.
  • For nested objects or arrays, use JSON strings.

Example NPX usage:

console
CONFIG_DEFAULTS_QUERY_LIMIT='25' npx -y mongodb-lens@latest

Example Docker Hub usage:

console
docker run --rm -i --network=host --pull=always -e CONFIG_DEFAULTS_QUERY_LIMIT='25' furey/mongodb-lens

Configuration: Cross-Platform Environment Variables

For consistent environment variable usage across Windows, macOS, and Linux, consider using `cross-env`:

1. Install cross-env globally:

console
# Using NPM
   npm install -g cross-env

   # Using Volta (see: https://volta.sh)
   volta install cross-env

1. Prefix any NPX or Node.js environment variables in this document's examples:

console
# Example NPX usage with cross-env
   cross-env CONFIG_DEFAULTS_QUERY_LIMIT='25' npx -y mongodb-lens@latest

   # Example Node.js usage with cross-env
   cross-env CONFIG_DEFAULTS_QUERY_LIMIT='25' node mongodb-lens.js

Client Setup

Client Setup: Claude Desktop

To use MongoDB Lens with Claude Desktop:

1. Install Claude Desktop

1. Open `claude_desktop_config.json` (create if it doesn't exist):

    1. Add the MongoDB Lens server configuration as per configuration options

    1. Restart Claude Desktop

    1. Start a conversation with Claude about your MongoDB data

    Claude Desktop Configuration Options

    For each option:

    • Replace `mongodb://your-connection-string` with your MongoDB connection string or omit it to use the default `mongodb://localhost:27017`.
    • To use a custom config file, set `CONFIG_PATH` environment variable.
    • To include environment variables:
      • For NPX or Node.js add `"env": {}` with key-value pairs, for example:
    json
    "command": "/path/to/npx",
    "args": [
      "-y",
      "mongodb-lens@latest",
      "mongodb://your-connection-string"
    ],
    "env": {
      "CONFIG_LOG_LEVEL": "verbose"
    }
      json
      "command": "docker",
    "args": [
      "run", "--rm", "-i",
      "--network=host",
      "--pull=always",
      "-e", "CONFIG_LOG_LEVEL=verbose",
      "furey/mongodb-lens",
      "mongodb://your-connection-string"
    ]
      Option 1: NPX (Recommended)
      json
      {
  "mcpServers": {
    "mongodb-lens": {
      "command": "/path/to/npx",
      "args": [
        "-y",
        "mongodb-lens@latest",
        "mongodb://your-connection-string"
      ]
    }
  }
}
      Option 2: Docker Hub Image
      json
      {
  "mcpServers": {
    "mongodb-lens": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "--network=host",
        "--pull=always",
        "furey/mongodb-lens",
        "mongodb://your-connection-string"
      ]
    }
  }
}
      Option 3: Local Node.js Installation
      json
      {
  "mcpServers": {
    "mongodb-lens": {
      "command": "/path/to/node",
      "args": [
        "/path/to/mongodb-lens.js",
        "mongodb://your-connection-string"
      ]
    }
  }
}
      Option 4: Local Docker Image
      json
      {
  "mcpServers": {
    "mongodb-lens": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "--network=host",
        "mongodb-lens",
        "mongodb://your-connection-string"
      ]
    }
  }
}

      Client Setup: MCP Inspector

      MCP Inspector is a tool designed for testing and debugging MCP servers.

      > [!NOTE]

      > MCP Inspector starts a proxy server on port 3000 and web client on port 5173.

      Example NPX usage:

      1. Run MCP Inspector:

      console
      # Using default connection string mongodb://localhost:27017
    npx -y @modelcontextprotocol/inspector npx -y mongodb-lens@latest

    # Using custom connection string
    npx -y @modelcontextprotocol/inspector npx -y mongodb-lens@latest mongodb://your-connection-string

    # Using custom ports
    SERVER_PORT=1234 CLIENT_PORT=5678 npx -y @modelcontextprotocol/inspector npx -y mongodb-lens@latest

      1. Open MCP Inspector: http://localhost:5173

      MCP Inspector should support the full range of MongoDB Lens capabilities, including autocompletion for collection names and query fields.

      For more, see: MCP Inspector

      Client Setup: Other MCP Clients

      MongoDB Lens should be usable with any MCP-compatible client.

      For more, see: MCP Documentation: Example Clients

      Data Protection

      To protect your data while using MongoDB Lens, consider the following:

      Data Protection: Read-Only User Accounts

      When connecting MongoDB Lens to your database, the permissions granted to the user in the MongoDB connection string dictate what actions can be performed. When the use case fits, a read-only user can prevent unintended writes or deletes, ensuring MongoDB Lens can query data but not alter it.

      To set this up, create a user with the `read` role scoped to the database(s) you're targeting. In MongoDB shell, you'd run something like:

      js
      use admin

db.createUser({
  user: 'readonly',
  pwd: 'eXaMpLePaSsWoRd',
  roles: [{ role: 'read', db: 'mydatabase' }]
})

      Then, apply those credentials to your MongoDB connection string:

      txt
      mongodb://readonly:eXaMpLePaSsWoRd@localhost:27017/mydatabase

      Using read-only credentials is a simple yet effective way to enforce security boundaries, especially when you're poking around schemas or running ad-hoc queries.

      Data Protection: Working with Database Backups

      When working with MongoDB Lens, consider connecting to a backup copy of your data hosted on a separate MongoDB instance.

      Start by generating the backup with `mongodump`. Next, spin up a fresh MongoDB instance (e.g. on a different port like `27018`) and restore the backup there using `mongorestore`. Once it's running, point MongoDB Lens to the backup instance's connection string (e.g. `mongodb://localhost:27018/mydatabase`).

      This approach gives you a sandbox to test complex or destructive operations against without risking accidental corruption of your live data.

      Data Protection: Data Flow Considerations

      Data Flow Considerations: How Your Data Flows Through the System

      When using an MCP Server with a remote LLM provider (such as Anthropic via Claude Desktop) understanding how your data flows through the system is key to protecting sensitive information from unintended exposure.

      When you send a MongoDB related query through your MCP client, here’s what happens:

      > [!NOTE]

      > While this example uses a local MongoDB instance, the same principles apply to remote MongoDB instances.

      mermaid
      sequenceDiagram
    actor User
    box Local Machine #d4f1f9
        participant Client as MCP Client
        participant Lens as MongoDB Lens
        participant MongoDB as MongoDB Instance
    end
    box Remote Server #ffe6cc
        participant LLM as Remote LLM Provider
    end

    User->>Client: 1. Submit request"Show me all users older than 30"
    Client->>LLM: 2. User request + available tools
    Note over LLM: Interprets requestChooses appropriate tool
    LLM->>Client: 3. Tool selection (find-documents)
    Client->>Lens: 4. Tool run with parameters
    Lens->>MongoDB: 5. Database query
    MongoDB-->>Lens: 6. Database results
    Lens-->>Client: 7. Tool results (formatted data)
    Client->>LLM: 8. Tool results
    Note over LLM: Processes resultsFormats response
    LLM-->>Client: 9. Processed response
    Client-->>User: 10. Final answer

      1. You submit a request➥ e.g. "Show me all users older than 30"

      1. Your client sends the request to the remote LLM➥ The LLM provider receives your exact words along with a list of available MCP tools and their parameters.

      1. The remote LLM interprets your request➥ It determines your intent and instructs the client to use a specific MCP tool with appropriate parameters.

      1. The client asks MongoDB Lens to run the tool➥ This occurs locally on your machine via stdio.

      1. MongoDB Lens queries your MongoDB database

      1. MongoDB Lens retrieves your MongoDB query results

      1. MongoDB Lens sends the data back to the client➥ The client receives results formatted by MongoDB Lens.

      1. The client forwards the data to the remote LLM➥ The LLM provider sees the exact data returned by MongoDB Lens.

      1. The remote LLM processes the data➥ It may summarize or format the results further.

      1. The remote LLM sends the final response to the client➥ The client displays the answer to you.

      The remote LLM provider sees both your original request and the full response from MongoDB Lens. If your database includes sensitive fields (e.g. passwords, personal details, etc) this data could be unintentionally transmitted to the remote provider unless you take precautions.

      Data Flow Considerations: Protecting Sensitive Data with Projection

      To prevent sensitive data from being sent to the remote LLM provider, use the concept of projection when using tools like `find-documents`, `aggregate-data`, or `export-data`. Projection allows you to specify which fields to include or exclude in query results, ensuring sensitive information stays local.

      Example projection usage:

      • _"Show me all users older than 30, but use projection to hide their passwords."_

      ➥ Uses `find-documents` tool with projection

      Data Flow Considerations: Connection Aliases and Passwords

      When adding new connection aliases using the `add-connection-alias` tool, avoid added aliases to URIs that contain passwords if you're using a remote LLM provider. Since your request is sent to the LLM, any passwords in the URI could be exposed. Instead, define aliases with passwords in the MongoDB Lens config file, where they remain local and are not transmitted to the LLM.

      Data Flow Considerations: Local Setup for Maximum Safety

      While outside the scope of this document, for the highest level of data privacy, consider using a local MCP client paired with a locally hosted LLM model. This approach keeps all requests and data within your local environment, eliminating the risk of sensitive information being sent to a remote provider.

      Data Protection: Confirmation for Destructive Operations

      MongoDB Lens implements a token-based confirmation system for potentially destructive operations, requiring a two-step process to execute tools that may otherwise result in unchecked data loss:

      1. First tool invocation: Returns a 4-digit confirmation token that expires after 5 minutes

      1. Second tool invocation: Executes the operation if provided with the valid token

      For an example of the confirmation process, see: Working with Confirmation Protection

      Tools that require confirmation include:

      • `drop-user`: Remove a database user
      • `drop-index`: Remove an index (potential performance impact)
      • `drop-database`: Permanently delete a database
      • `drop-collection`: Delete a collection and all its documents
      • `delete-document`: Delete one or multiple documents
      • `bulk-operations`: When including delete operations
      • `rename-collection`: When the target collection exists and will be dropped

      This protection mechanism aims to prevent accidental data loss from typos and unintended commands. It's a safety net ensuring you're aware of the consequences before proceeding with potentially harmful actions.

      > [!NOTE]

      > If you're working in a controlled environment where data loss is acceptable, you can configure MongoDB Lens to bypass confirmation and perform destructive operations immediately.

      Bypassing Confirmation for Destructive Operations

      You might want to bypass the token confirmation system.

      Set the environment variable `CONFIG_DISABLE_DESTRUCTIVE_OPERATION_TOKENS` to `true` to execute destructive operations immediately without confirmation:

      console
      # Using NPX
CONFIG_DISABLE_DESTRUCTIVE_OPERATION_TOKENS=true npx -y mongodb-lens@latest

# Using Docker
docker run --rm -i --network=host --pull=always -e CONFIG_DISABLE_DESTRUCTIVE_OPERATION_TOKENS='true' furey/mongodb-lens

      > [!WARNING]

      > Disabling confirmation tokens removes an important safety mechanism. It's strongly recommended to only use this option in controlled environments where data loss is acceptable, such as development or testing. Disable at your own risk.

      Data Protection: Disabling Destructive Operations

      Disabling Tools

      MongoDB Lens includes several tools that can modify or delete data. To disable specific tools, add them to the `disabled.tools` array in your configuration file:

      json
      {
  "disabled": {
    "tools": [
      "drop-user",
      "drop-index",
      "drop-database",
      "drop-collection",
      "delete-document",
      "bulk-operations",
      "rename-collection"
    ]
  }
}

      > [!NOTE]

      > Resources and prompts can also be disabled via `disabled.resources` and `disabled.prompts` settings.

      High-Risk Tools

      These tools can cause immediate data loss and should be considered for disabling in sensitive environments:

      • `drop-user`: Removes database users and their access permissions
      • `drop-index`: Removes indexes (can impact query performance)
      • `drop-database`: Permanently deletes entire databases
      • `drop-collection`: Permanently deletes collections and all their documents
      • `delete-document`: Removes documents matching specified criteria
      • `bulk-operations`: Can perform batch deletions when configured to do so
      • `rename-collection`: Can overwrite existing collections when using the drop target option

      Medium-Risk Tools

      These tools can modify data but typically don't cause immediate data loss:

      • `create-user`: Creates users with permissions that could enable further changes
      • `transaction`: Executes multiple operations in a transaction (potential for complex changes)
      • `update-document`: Updates documents which could overwrite existing data

      Read-Only Configuration

      For a complete read-only configuration, disable all potentially destructive tools:

      json
      {
  "disabled": {
    "tools": [
      "drop-user",
      "drop-index",
      "create-user",
      "transaction",
      "create-index",
      "drop-database",
      "drop-collection",
      "insert-document",
      "update-document",
      "delete-document",
      "bulk-operations",
      "create-database",
      "gridfs-operation",
      "create-collection",
      "rename-collection",
      "create-timeseries"
    ]
  }
}

      This configuration allows MongoDB Lens to query and analyze data while preventing any modifications, providing multiple layers of protection against accidental data loss.

      Selective Component Enabling

      In addition to disabling components, specify exactly which components should be enabled (implicitly disabling all others) using the `enabled` settings in your configuration file:

      json
      {
  "enabled": {
    "tools": [
      "use-database",
      "find-documents",
      "count-documents",
      "aggregate-data"
    ]
  },
  "disabled": {
    "resources": true,
    "prompts": true
  }
}

      > [!IMPORTANT]

      > If a component appears in both `enabled` and `disabled` lists, the `enabled` setting takes precedence.

      Tutorial

      This following tutorial guides you through setting up a MongoDB container with sample data, then using MongoDB Lens to interact with it through natural language queries:

      1. Start Sample Data Container

      1. Import Sample Data

      1. Connect MongoDB Lens

      1. Example Queries

      1. Working With Confirmation Protection

      Tutorial: 1. Start Sample Data Container

      > [!NOTE]

      > This tutorial assumes you have Docker installed and running on your system.

      > [!IMPORTANT]

      > If Docker is already running a container on port 27017, stop it before proceeding.

      1. Initialise the sample data container:

      console
      docker run --name mongodb-sampledata -d -p 27017:27017 mongo:6

      1. Verify the container is running without issue:

      console
      docker ps | grep mongodb-sampledata

      Tutorial: 2. Import Sample Data

      MongoDB provides several sample datasets which we'll use to explore MongoDB Lens.

      1. Download the sample datasets:

      console
      curl -LO https://atlas-education.s3.amazonaws.com/sampledata.archive

      1. Copy the sample datasets into your sample data container:

      console
      docker cp sampledata.archive mongodb-sampledata:/tmp/

      1. Import the sample datasets into MongoDB:

      console
      docker exec -it mongodb-sampledata mongorestore --archive=/tmp/sampledata.archive

      This will import several databases:

      • `sample_airbnb`: Airbnb listings and reviews
      • `sample_analytics`: Customer and account data
      • `sample_geospatial`: Geographic data
      • `sample_mflix`: Movie data
      • `sample_restaurants`: Restaurant data
      • `sample_supplies`: Supply chain data
      • `sample_training`: Training data for various applications
      • `sample_weatherdata`: Weather measurements

      Tutorial: 3. Connect MongoDB Lens

      Install MongoDB Lens as per the Quick Start instructions.

      Set your MCP Client to connect to MongoDB Lens via: `mongodb://localhost:27017`

      > [!TIP]

      > Omitting the connection string from your MCP Client configuration will default the connection string to `mongodb://localhost:27017`.

      Example Claude Desktop configuration:

      json
      {
  "mcpServers": {
    "mongodb-lens": {
      "command": "/path/to/npx",
      "args": [
        "-y",
        "mongodb-lens@latest"
      ]
    }
  }
}

      Tutorial: 4. Example Queries

      With your MCP Client running and connected to MongoDB Lens, try the following example queries:

      Example Queries: Basic Database Operations

      • _"List all databases"_

      ➥ Uses `list-databases` tool

      • _"What db am I currently using?"_

      ➥ Uses `current-database` tool

      • _"Switch to the sample_mflix database"_

      ➥ Uses `use-database` tool

      • _"Create a new db called test_db"_

      ➥ Uses `create-database` tool

      • _"Create another db called analytics_db and switch to it"_

      ➥ Uses `create-database` tool with switch=true

      • _"Drop test_db"_

      ➥ Uses `drop-database` tool (with confirmation)

      Example Queries: Collection Management

      • _"What collections are in the current database?"_

      ➥ Uses `list-collections` tool

      • _"Create user_logs collection"_

      ➥ Uses `create-collection` tool

      • _"Rename user_logs to system_logs"_

      ➥ Uses `rename-collection` tool

      • _"Drop system_logs"_

      ➥ Uses `drop-collection` tool (with confirmation)

      • _"Check the data consistency in the movies collection"_

      ➥ Uses `validate-collection` tool

      Example Queries: User Management

      • _"Create a read-only user for analytics"_

      ➥ Uses `create-user` tool

      • _"Drop the inactive_user account"_

      ➥ Uses `drop-user` tool (with confirmation)

      Example Queries: Querying Data

      • _"Count all docs in the movies collection"_

      ➥ Uses `count-documents` tool

      • _"Find the top 5 movies with the highest IMDB rating"_

      ➥ Uses `find-documents` tool

      • _"Show me aggregate data for movies grouped by decade"_

      ➥ Uses `aggregate-data` tool

      • _"List all unique countries where movies were produced"_

      ➥ Uses `distinct-values` tool

      • _"Search for movies containing godfather in their title"_

      ➥ Uses `text-search` tool

      • _"Find German users with last name müller using proper collation"_

      ➥ Uses `collation-query` tool

      Example Queries: Schema Analysis

      • _"What's the schema structure of the movies collection?"_

      ➥ Uses `analyze-schema` tool

      • _"Compare users and comments schemas"_

      ➥ Uses `compare-schemas` tool

      • _"Generate a schema validator for the movies collection"_

      ➥ Uses `generate-schema-validator` tool

      • _"Analyze common query patterns for the movies collection"_

      ➥ Uses `analyze-query-patterns` tool

      Example Queries: Data Modification

      • _"Insert new movie document: \"_

      ➥ Uses `insert-document` tool

      • _"Update all movies from 1994 to add a 'classic' flag"_

      ➥ Uses `update-document` tool

      • _"Delete all movies with zero ratings"_

      ➥ Uses `delete-document` tool (with confirmation)

      • _"Run these bulk operations on the movies collection: \"_

      ➥ Uses `bulk-operations` tool

      > [!TIP]

      > For specialized MongoDB operations (like array operations, bitwise operations, or other complex updates), use MongoDB's native operators via the `update-document` tool's `update` and `options` parameters.

      Example Queries: Performance & Index Management

      • _"Create an index on the title field in the movies collection"_

      ➥ Uses `create-index` tool

      • _"Drop the ratings_idx index"_

      ➥ Uses `drop-index` tool (with confirmation)

      • _"Explain the execution plan for finding movies from 1995"_

      ➥ Uses `explain-query` tool

      • _"Get statistics for the current db"_

      ➥ Uses `get-stats` tool with target=database

      • _"Show collection stats for the movies collection"_

      ➥ Uses `get-stats` tool with target=collection

      Example Queries: Geospatial & Special Operations

      • _"Switch to sample_geospatial db, then find all shipwrecks within 10km of coordinates [-80.12, 26.46]"_

      ➥ Uses `geo-query` tool

      • _"Switch to sample_analytics db, then execute a transaction to move funds between accounts: \"_

      ➥ Uses `transaction` tool

      • _"Create a time series collection for sensor readings"_

      ➥ Uses `create-timeseries` tool

      • _"Watch for changes in the users collection for 30 seconds"_

      ➥ Uses `watch-changes` tool

      • _"List all files in the images GridFS bucket"_

      ➥ Uses `gridfs-operation` tool with operation=list

      Example Queries: Export, Administrative & Other Features

      • _"Switch to sample_mflix db, then export the top 20 movies based on 'tomatoes.critic.rating' as a CSV with title, year and rating fields (output in a single code block)"_

      ➥ Uses `export-data` tool

      • _"Switch to sample_analytics db, then check its sharding status"_

      ➥ Uses `shard-status` tool

      • _"Clear the collections cache"_

      ➥ Uses `clear-cache` tool with target=collections

      • _"Clear all caches"_

      ➥ Uses `clear-cache` tool

      • _"Switch to sample_weatherdata db then generate an interactive report on its current state"_

      ➥ Uses numerous tools

      Example Queries: Connection Management

      • _"Connect to mongodb://localhost:27018"_

      ➥ Uses `connect-mongodb` tool

      • _"Connect to mongodb+srv://username:password@cluster.mongodb.net/mydb"_

      ➥ Uses `connect-mongodb` tool

      • _"Connect back to the original mongodb instance"_

      ➥ Uses `connect-original` tool

      • _"Connect to replica set without validating the connection: \"_

      ➥ Uses `connect-mongodb` tool with validateConnection=false

      • _"Add connection alias 'prod' for mongodb://username:password@prod-server:27017/mydb"_

      ➥ Uses `add-connection-alias` tool

      Tutorial: 5. Working With Confirmation Protection

      MongoDB Lens includes a safety mechanism for potentially destructive operations. Here's how it works in practice:

      1. Request to drop a collection:

      code
      "Drop the collection named test_collection"

      1. MongoDB Lens responds with a warning and confirmation token:

      code
      ⚠️ DESTRUCTIVE OPERATION WARNING ⚠️

    You've requested to drop the collection 'test_collection'.

    This operation is irreversible and will permanently delete all data in this collection.

    To confirm, you must type the 4-digit confirmation code EXACTLY as shown below:

    Confirmation code: 9876

    This code will expire in 5 minutes for security purposes.

      1. Confirm the operation by submitting the confirmation token:

      code
      "9876"

      1. MongoDB Lens executes the operation:

      code
      Collection 'test_collection' has been permanently deleted.

      This two-step process prevents accidental data loss by requiring explicit confirmation.

      > [!NOTE]

      > If you're working in a controlled environment where data loss is acceptable, you can configure MongoDB Lens to bypass confirmation and perform destructive operations immediately.

      Test Suite

      MongoDB Lens includes a test suite to verify functionality across tools, resources, and prompts.

      Test Suite: Running Tests

      The test suite requires a `CONFIG_MONGO_URI` environment variable which can be set to:

      • a MongoDB connection string (e.g. `mongodb://localhost:27017`)
      • `mongodb-memory-server` (for in-memory testing)
      console
      # Run Tests with MongoDB Connection String
CONFIG_MONGO_URI=mongodb://localhost:27017 node mongodb-lens.test.js

# Run Tests with In-Memory MongoDB (requires mongodb-memory-server)
CONFIG_MONGO_URI=mongodb-memory-server node mongodb-lens.test.js

      For convenience, the following scripts are available for running tests:

      console
      npm test                        # Fails if no CONFIG_MONGO_URI provided
npm run test:localhost          # Uses mongodb://localhost:27017
npm run test:localhost:verbose  # Runs with DEBUG=true for verbose output
npm run test:in-memory          # Uses mongodb-memory-server
npm run test:in-memory:verbose  # Runs with DEBUG=true for verbose output

      > [!NOTE]

      > The test suite creates temporary databases and collections that are cleaned up after test completion.

      Test Suite: Command Line Options

      OptionDescription
      `--list`List all available tests without running them
      `--test=`Run specific test(s) by name (comma-separated)
      `--group=`Run all tests in specific group(s) (comma-separated)
      `--pattern=`Run tests matching pattern(s) (comma-separated)

      Test Suite: Examples

      console
      # List All Available Tests
npm test -- --list

# Run Only Connection-Related Tests (:27017)
npm run test:localhost -- --group=Connection\ Tools

# Test Specific Database Operations (In-Memory)
npm run test:in-memory -- --test=create-database\ Tool,drop-database\ Tool

# Test All Document-Related Tools (:27017)
npm run test:localhost -- --pattern=document

# Run Resource Tests Only (In-Memory)
npm run test:in-memory -- --group=Resources

# Run Specific Tests Only (In-Memory)
npm run test:in-memory -- --test=aggregate-data\ Tool,find-documents\ Tool

      Disclaimer

      MongoDB Lens:

      • is licensed under the MIT License.
      • is not affiliated with or endorsed by MongoDB, Inc.
      • is written with the assistance of AI and may contain errors.
      • is intended for educational and experimental purposes only.
      • is provided as-is with no warranty—please use at your own risk.

      Support

      If you've found MongoDB Lens helpful consider supporting my work through:

      Buy Me a Coffee | GitHub Sponsorship

      Contributions help me continue developing and improving this tool, allowing me to dedicate more time to add new features and ensuring it remains a valuable resource for the community.

      Frequently asked questions

      What is mongodb-lens?

      mongodb-lens is 🍃🔎 MongoDB Lens: Full Featured MCP Server for MongoDB Databases JavaScript-based implementation.

      How do I install mongodb-lens?

      Open the GitHub repository and follow its README. Most MCP servers are added to your client's MCP config, then called by your agent.

      Is mongodb-lens open source?

      Yes — it is hosted on GitHub at https://github.com/furey/mongodb-lens and has 189 stars.

      Related MCP tools

      sonnylazuardicursor-talk-to-figma-mcp

      CTTF: MCP integration between Cursor and Figma, allowing Cursor Agentic AI to communicate with Figma for reading designs and modifying them programmatically.

      5,539 JavaScript
      agentagenticagentic-ai+11
      justinpbarnettunity-mcp

      An MCP server that allows MCP clients like Claude Desktop or Cursor to perform actions in the Unity Editor C#-based implementation.

      3,727 C#
      aiai-integrationanthropic+15
      mendableaifirecrawl-mcp-server

      🔥 Official Firecrawl MCP Server - Adds powerful web scraping and search to Cursor, Claude and any other LLM clients. JavaScript-based implementation.

      4,847 JavaScript
      batch-processingclaudecontent-extraction+11
      joniglmcp-client-for-ollama

      A text-based user interface (TUI) client for interacting with MCP servers using Ollama. Features include multi-server, dynamic model switching, streaming res...

      351 Python
      aicommand-line-toolgenerative-ai+17
      yamadashyrepomix

      📦 Repomix is a powerful tool that packs your entire repository into a single, AI-friendly file. Perfect for when you need to feed your codebase to Large Lan...

      19,761 TypeScript
      aianthropicartificial-intelligence+17
      tadata-orgfastapi_mcp

      Expose your FastAPI endpoints as Model Context Protocol (MCP) tools, with Auth! Python-based implementation. Trusted by 11000+ developers.

      11,002 Python
      aiauthenticationauthorization+10

      Run your own MCP server? See who uses it and what to fix.

      Measure it with TrackMCP