Skip to content
Monghoul

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.

· ·updated 13 September 2026 ·checked against Monghoul 1.12.0
A small solid black square at the left with hairlines fanning out to the right. Most end at outlined squares inside a bold rectangle. Three carry on past its right edge to three solid amber squares standing alone.
The flag decides how many of these tools exist at all. The MongoDB user decides what any of them can reach, and only the second one is enforced by the database.

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.

Setting it up, both ways.