MongoDB MCP Server

The server acts with whatever MongoDB credential the operator puts in the connection string and never narrows it: read-only mode only hides tools, it does not swap in a read-only credential. The connect tool also accepts any connection string the model supplies, so credentials found in data or chat can be used to open further deployments. The Atlas path is better designed (each Atlas cluster connection mints a temporary, cluster-scoped database user that expires after four hours), but it is off unless Atlas API credentials are configured, and in that mode the atlas-create-db-user tool can mint users with any built-in role, including atlasAdmin.

The server ships its own confirmation step: a configurable list of tools (drop-database, drop-collection, delete-many, drop-index, Atlas user and access-list creation, stream changes) asks the user through MCP elicitation, and aggregation pipelines that write ($out/$merge) are confirmed separately. But many state-changing tools are not on the list (update-many, insert-many, rename-collection, create-index, Atlas cluster creation, pause and upgrade, Atlas Local deployment deletion), the confirmation gate does not cover every path, and some risk annotations are inaccurate. A wrongly allowed call can permanently destroy data with no undo.

Tools are narrow and typed: separate find, count, insert, update, delete and drop tools, each with a strict schema that rejects unknown arguments, and Atlas arguments (project IDs, IPs, CIDRs, role names) are validated with patterns. Reads are capped (100 documents and 16 MB by default). However, the connect tool takes any connection string, so a hijacked model can reach arbitrary hosts, and the write tools take arbitrary filters with no bound on how many documents they affect. Everything, including write and delete tools, is enabled by default unless the operator passes --readOnly.

The server runs no shell or local code, but it does send model-written MongoDB queries and aggregation pipelines to the database, the equivalent of raw SQL. Server-side JavaScript operators ($where, $function, $accumulator) are rejected by default, through a recursive scan applied to every filter and pipeline the tools forward. Beyond that filter there is no isolation primitive: queries run with the connection's full database role, and the JavaScript block can be turned off with an ordinary config value.

Documents, schemas, logs and Atlas data returned to the model are wrapped by default in randomly named 'untrusted-user-data' tags with a warning, and structured results are kept separate from the summary text. That is labelling, not a barrier. In the default configuration, a model hijacked by text stored in the database can, with no human involved, copy data out by connecting to an attacker's MongoDB server and inserting it there, and can irreversibly overwrite data with update-many, which needs no confirmation. Read-only mode removes the write leg but is off by default.

The server keeps no memory the model can write to and loads no instruction or settings files from a working directory. Configuration comes only from environment variables, command-line flags or an explicitly named config file, and connections and exports live in memory or expire within minutes.

The server has no plugin system and launches no third-party MCP servers or packages at runtime. Its only dynamic imports are its own bundled dependencies. The optional Atlas Local tools pull MongoDB's own container image, the product being managed, not a third-party extension.

Secrets from configuration (connection string, Atlas client secret, AWS and TLS values, Voyage key) go into an immutable redaction keychain, and every logger (disk, stderr and the log stream sent to the MCP client) redacts by default, as do tool error messages and the config resource. Temporary Atlas user credentials are scrubbed from errors too. Gaps: secrets are stored as plain env or config values, anonymous usage telemetry is on by default, atlas-create-db-user returns generated passwords to the model by design, and the connect tool has the model handle full connection strings.

Every tool call goes through one invoke path that writes JSON log lines (tool name and request ID) to a disk log in the user's home directory with 30-day retention, and confirmation requests and outcomes are logged. The record does not include the arguments of the call, so after an incident you can see that delete-many ran but not which filter it used. Logging is best effort and does not block actions.

Reads are bounded by the server: find and aggregate return at most 100 documents and 16 MB by default (with a 1 MB default per-response limit the model cannot push beyond the configured maximum), and the count phase has time caps. The export tool, update-many and delete-many have no bound, no server-side time limit is set by default, and there is no rate limiting. Cancellation signals are passed to the driver, but a long-running server-side write may continue after the client stops waiting.