Skip to main content
Your agent can run commands against your MongoDB database — finding documents, running aggregations, inserting records, and updating data — all in plain English. Point it at your database with a connection string and ask in natural language; the agent translates your request into MongoDB commands and returns the results. Unlike read-only data integrations, what the agent can do is governed entirely by the database user in your connection string. Connect with a read-only user and the agent can only read; connect with a read-write user and it can also insert, update, and delete. You stay in control by choosing the permissions of the user you connect with.

​
How to enable

Go to Settings → Capabilities and enable MongoDB, then link a workspace secret containing your connection string. The same secret can be reused across agents and teams. To give the agent several connections, link several secrets — see Several connections.

​
What you need

All the agent needs is a standard MongoDB connection string (URI), for example:
The connection must use TLS: use a mongodb+srv:// connection string, or add tls=true to a mongodb:// string. Plaintext connections are rejected. MongoDB Atlas connection strings already meet this requirement. The connection string is stored as an encrypted workspace secret. It includes the database user’s credentials, so the user’s permissions determine exactly what the agent is allowed to do.
Create a dedicated database user for the agent with only the permissions it needs. If the agent should only answer questions about your data, give it a read-only user. If it should also maintain records, give it read-write access to the relevant database.

​
Default database

The capability card has an optional Default Database field. This is the database the agent uses when a request doesn’t name one explicitly.
  • If set — the agent works against that database by default, so you can just ask “how many orders do we have?” without naming the database every time.
  • If left empty — the agent uses the database named in the connection string, such as orders in mongodb+srv://user:password@cluster.mongodb.net/orders. If the connection string doesn’t name one either, the agent names a database on every command, and can look up which databases the connection can reach.
The agent can always target a different database when you ask it to, regardless of the default. Neither the default nor the database in the connection string limits access: the agent can reach every database its database user can. To keep the agent away from a database, such as production, connect with a database user that has no access to it.
In a mongodb:// connection string, the database in the path is also the database the user logs in against, unless the string sets authSource. If your database user was created in the admin database, add ?authSource=admin. mongodb+srv:// strings from MongoDB Atlas already handle this.

​
Several connections

You can link several secrets to the same agent, each with its own connection string. A common setup is one database user per database or per collection: create one secret for each, then give each agent the combination it needs, instead of a separate database user for every combination.
The MongoDB capability panel with two linked secrets, Orders (read-only) and Billing (read-only), an Add another secret button, and an empty Default Database field
When the agent has more than one connection, it picks one for every command, using the secret names to tell them apart. Give your secrets clear names, like “Orders (read-only)”, and describe in the agent’s instructions which connection to use for what — for example “use Orders for order questions and Billing for invoices”. If your secrets point at different databases, leave Default Database empty so each connection uses the database in its own connection string.

​
Which MongoDB can I use?

Any MongoDB database that accepts a standard connection string over TLS works — self-hosted, MongoDB Atlas, or any managed provider. If you don’t have a database yet, you can start for free with MongoDB Atlas, MongoDB’s hosted service, which offers a free tier that’s plenty for getting started. You’re not locked in — the same connection string approach works with any MongoDB instance, so you can move to a paid tier or your own infrastructure later.

​
IP allowlisting

If your database restricts access by IP address (for example, MongoDB Atlas network access rules), allow Abundly’s outbound IP address:
Enterprise customers connect from a different, dedicated IP address. If you’re an enterprise customer and need to allowlist Abundly, contact us and we’ll provide your specific address.

​
Example use cases

  • Ask questions about your data — “How many active users signed up in the last 30 days? Use the analytics database in MongoDB”
  • Reporting — “Every Monday, count last week’s orders by status and post a summary to Slack”
  • Maintaining records — “Add this support ticket to the tickets collection” (with a read-write user)
  • Exploration — “List the collections in our app database and show me a sample document from the users collection”
  • Data checks — “Find any orders in MongoDB with a missing customer ID and flag them”

​
How to connect MongoDB

1

Create a database user

In your MongoDB provider (e.g. Atlas) or your self-hosted instance, create a database user for the agent. Grant only the permissions it needs — read-only if the agent should only query, read-write if it should also modify data.
2

Allowlist Abundly's IP (if required)

If your database restricts access by IP, add Abundly’s outbound IP 34.51.233.91 to the allowlist. Enterprise customers should contact Abundly for their dedicated address.
3

Configure in Abundly

Go to Settings → Capabilities, enable MongoDB, and create a new workspace secret of type MongoDB containing your connection string. Use Add another secret on the card to add more connections. Optionally set a Default Database so the agent doesn’t need it specified on every request.

​
Learn more

Agent databases

Store and query structured data inside Abundly — no external database needed.

BigQuery

Query and explore your Google BigQuery data from the agent.

Snowflake

Query and explore your Snowflake data warehouse from the agent.