What a MongoDB MCP server can reach, before you point one at production
The official server writes unless you pass --readOnly, its confirmations depend on the client supporting elicitation, and its Atlas tools create users.
A Model Context Protocol server turns a database into a set of tools an assistant can call. For MongoDB that means the assistant can list your databases, read a collection’s shape, run a find or an aggregation, and, depending on how the server was started, write.
The setup is a few lines of JSON, which is the problem. It takes about a minute, and at the end of that minute something that writes its own queries has a connection to your data. This is what to read before you get there.
Everything below about the official server was read from its own documentation on 13 September 2026. Check it again before you trust this page: the defaults are the kind of thing that changes.
Writing is on unless you turn it off
mongodb-mcp-server takes a --readOnly flag that restricts it to read, connect and metadata
operations. The default is off.
Without the flag, the tool list includes insert-many, update-many, delete-many,
create-collection and drop-collection. An assistant that decides a collection is redundant has
a tool for that, and the only thing between the decision and the database is whatever the client
asks you first.
So start with the flag on:
"args": ["-y", "mongodb-mcp-server@latest", "--readOnly"]
Turning it off later is a decision you will have made on purpose, which is the point.
The confirmation is the client’s, not the database’s
The server asks before drop-database, drop-collection and delete-many, when the client
supports elicitation. Elicitation is the part of the protocol that lets a server ask the user a
question mid-call, and not every client implements it.
That is worth reading twice, because it inverts where the safety lives. The prompt you saw in one assistant is not a property of the server or of your database. Swap the client for one without elicitation and the same server with the same flags does the same destructive call without asking.
A check that depends on the caller is not a boundary. It is a courtesy.
The credential goes in env, not in args
The project’s own guidance is to pass the connection string and any API credentials as environment variables rather than command-line arguments, because arguments show up in process lists and get written into logs in several places.
"env": { "MDB_MCP_CONNECTION_STRING": "mongodb://localhost:27017/shop" }
A MongoDB connection string usually carries a username and password. Putting it in args publishes
it to anything that can run ps.
Atlas credentials widen it past your data
Give the server Atlas credentials and the tool list grows past the database. It exposes
atlas-create-cluster, atlas-create-db-user, atlas-inspect-cluster and
atlas-pause-resume-cluster, among others.
--readOnly covers these too, and it covers them the same way it covers everything else: it filters
by operation type, so tools typed create, update or delete are never registered with the client at
all. A creation tool is a creation tool whether it makes a document or a cluster.
Which means this section is about the server you get when the flag comes off. atlas-create-db-user
is the one to sit with then. A tool that creates database users can open a path into the data that
does not go through the assistant at all, and it is reached with the credentials you handed over for
convenience.
If the assistant does not need to manage infrastructure, do not give it infrastructure credentials. That holds whichever way the flag is set, because the flag is a setting and the credential is not.
What actually bounds it
Three things, in increasing order of how much they are worth.
The flag. --readOnly is real and you should use it. It is also a setting, and a setting can be
changed by whoever edits the config file next.
The MongoDB user. Connect with a user that holds only the roles the assistant needs. This is the boundary the server cannot talk its way past, because it is enforced by the database rather than by the thing asking. If you do one thing from this page, do this one.
Where the write check runs. A read-only mode that decides by reading the query text can be walked past by writing the same call differently, and we showed that in four lines. A check that runs as the driver executes the call cannot be, whatever the text looked like.
The scoped version of the same idea
Monghoul runs its own MCP server, and the differences are in those three places rather than in the tool count. The connections an assistant may reach are chosen before the server starts rather than after. Write protection is enforced at the driver rather than over the query text. Destructive operations ask every time, and the asking belongs to the app rather than to whichever client attached.
None of that removes the second item on the list above. Use a restricted MongoDB user anyway.