MongoDB probe

The MongoDB probe connects to a MongoDB deployment, runs one operation, and returns the result: the matching documents, a write summary (matched/modified/inserted/deleted counts), or a server error. It is a database protocol, so it closes the same integration loop as the SQL probe: after an HTTP call writes a record, a MongoDB step can confirm the document actually landed.

Like the MySQL probe, the MongoDB probe is library-backed. It wraps the official MongoDB Java driver, which handles the protocol, SCRAM authentication, TLS, and connection pooling. The query/extract/chain path has no need to control individual bytes, so a driver is the right tool.

Engineering tier

The MongoDB probe is available on Engineering tier and above.

Connection settings

Field	Description
Host	Hostname or IP of the MongoDB server (default port 27017)
Port	Server port (default: 27017)
Database	The database the operation targets
Connection string	A full mongodb:// or mongodb+srv:// URI. When set, it overrides host/port/auth/TLS, which is the idiom for Atlas and replica sets.
Auth source	The authentication database for the credential (default: admin)
TLS mode	Disabled, Required (encrypt without verifying the hostname), or Verify full (verify the certificate chain and hostname)

Authentication

MongoDB logins use the credential store, so the username and password never live on the probe. A login is a username + password, which maps to a Basic credential (username in config, password in secrets). Select an existing credential or create a Basic one in the probe’s Auth row; the effective-credential panel, on-demand secret reveal, and per-run override work exactly as for the MySQL probe. If no credential is selected, the connection is attempted anonymously.

Operations

Pick the Operation; the editor shows only the fields that operation needs. JSON fields accept MongoDB Extended-JSON / shell syntax.

Operation	Fields	Does
Find	collection, filter, projection, limit	Read documents matching the filter
Insert	collection, document	Insert one document, or many when the document is a JSON array
Update	collection, filter, update	updateMany with an update document (e.g. {"$set":{…}})
Delete	collection, filter	deleteMany matching the filter
Aggregate	collection, pipeline	Run an aggregation pipeline (a JSON array of stages)
Count	collection, filter	Count matching documents
Run command	command	Run a database command, e.g. {"ping":1} or {"serverStatus":1}
List collections	none	List the collection names in the database

A blank filter means {} (match everything). {{variable}} placeholders in the collection and the JSON bodies are resolved from the active environment before the operation runs. That deliberately includes substitution into the query bodies, which enables both data-driven chaining and NoSQL-injection testing.

Form or Shell

The operation section has a Form / Shell toggle:

• Form: the structured fields above (operation type, collection, filter, projection, …). Best for simple, single-shape operations.
• Shell: one editor where you paste a query exactly as you’d type it in the mongo shell. The structured form can’t express a full query (sort, skip, chained cursor modifiers); Shell mode can.

db.users.find({ status: "active" }, { _id: 0, name: 1 }).sort({ createdAt: -1 }).skip(10).limit(20)
db.users.find({ _id: ObjectId("5f2b…") })
db.orders.aggregate([{ $match: { paid: true } }, { $group: { _id: "$cust", n: { $sum: 1 } } }])
db.users.updateMany({ active: false }, { $set: { active: true } })
db.runCommand({ ping: 1 })
db.getCollectionNames()

Supported: find / findOne, aggregate, count / countDocuments, insertOne / insertMany, updateOne / updateMany, deleteOne / deleteMany, runCommand, getCollectionNames, plus the cursor modifiers .sort(), .skip(), .limit() and .projection(). Shell helpers such as ObjectId(…), ISODate(…), NumberLong(…) and /regex/ literals are understood. {{variable}} placeholders resolve into the whole query string (same chaining + NoSQL-injection use as Form mode). Press Ctrl+Enter to send.

A malformed query (missing db., an unbalanced bracket, an unsupported method) is reported as a clean failed result with a message. It never crashes, and no connection is opened.

Response panel

• Reads (Find / Aggregate / Run command / List collections) → the returned documents, pretty-printed as JSON, with a document count.
• Writes → a summary chip: inserted, matched/modified, or deleted counts.
• Server error → a red panel with the message and MongoDB error code / code name. A rejected operation is a valid failed result, not a crash.

The status bar shows the operation type, the relevant counts, and the client-side round-trip duration.

Extractors

Use these in chain steps to pull values out of a MongoDB result:

Extractor	Returns
MONGO_SUCCESS	"true" / "false"
MONGO_DOC_COUNT	number of documents returned (or matched, for Count)
MONGO_FIELD	a field out of the returned documents, with expression field, [n].field or [*].field
MONGO_ERROR_CODE	the MongoDB error code (0 on success)
MONGO_JSON	the whole result as a JSON array

MONGO_FIELD is not limited to the first document: name reads the first document’s field (the convenient default), [2].email reaches document 2, and [*].email returns the field from every document, newline-joined and ready to feed an ITERATE step. See Extractors for the full list.

Chains

MongoDB is a first-class chain step. A common pattern is HTTP → MongoDB: call an API that creates a record, then run a Find and ASSERT on a MONGO_FIELD value to prove the write. {{variable}} values (including extractor output from earlier steps) resolve into the host, database, collection, and JSON bodies. Credentials resolve at the moment the query runs, never from the stored probe.

History

Each send is recorded as a history entry with the operation as sent (resolved variables), the full result, and a timestamp. Click an entry to restore it.

Implementation notes

• Driver: the official MongoDB Java driver (mongodb-driver-sync). Hand-rolling the protocol (OP_MSG framing + a full BSON codec + the SCRAM-SHA-256 handshake) would be a large effort with no fuzzing payoff, so as with MySQL a driver is the right tool.
• Connection pooling: one driver client per connection signature (host/port/database/credential/TLS); the driver pools sockets internally.
• Documents as JSON: results are captured as relaxed-JSON strings, so they are trivially comparable in ASSERT steps and navigable by MONGO_FIELD without per-type BSON handling.