MongoDB Is Live in Cogny: Let Your Agent Query Your Own Collections, Read-Only

Plenty of companies keep the numbers that decide marketing budgets (sign-ups, orders, subscriptions, which customers came back) in their own MongoDB, not in an ad platform or a SaaS tool. An agent that can only see the ad platforms has to guess what happened after the click.

Now it doesn't have to. MongoDB is a live MCP integration: connect an Atlas cluster or your own server with a read-only user, and Claude can find the collections that matter, see what fields they hold, and answer questions with aggregations that run inside your database.

This one came from Wish for an MCP, and it follows the same read-only shape as the Azure SQL connector.

---

TL;DR

• MongoDB is live now, Atlas (mongodb+srv://) and self-hosted (mongodb://). Connect it from Settings → Integrations with one connection string.
• Eight tools, all reads: get_server_info, list_databases, list_collections, describe_collection, find_documents, count_documents, run_aggregation, get_distinct_values.
• Read-only twice over: the user you create can only read, and Cogny only ever runs reads. Pipeline stages that write ($out, $merge) and server-side JavaScript ($where, $function, $accumulator) are refused before they reach your server.
• One IP to allow: every Cogny connection comes from 207.175.17.47.
• TLS is required. Every query stops after 60 seconds; aggregations return up to 2,000 rows and find_documents up to 1,000 documents.

---

What the agent can do

MongoDB has no fixed schema, so describe_collection is the step that makes the rest work: it shows the agent that the lead source lives in utm.source on some documents and source on others, or that purchases are an array inside each customer rather than their own collection. The intended loop is list_collections → describe_collection on the two or three collections that matter → a run_aggregation that groups and sums in the database, rather than pulling raw documents into the conversation.

Filters and pipelines are written as JSON in MongoDB's Extended JSON, so a date is {"$date": "2026-10-01T00:00:00Z"} and an ObjectId is {"$oid": "…"}. Agents get this right on their own; it's in the tool descriptions.

The Ad Leads → CRM Outcomes report template now works with MongoDB as well as Metabase: it takes the leads each ad platform claims, finds them in your own contact and order data, and reports which were new, which bought within 7, 30 and 90 days, and what each paying customer cost per campaign.

---

Setting it up

1. Create a read-only user. In Atlas: Security → Database & Network Access → Database Users → Add New Database User, Password, built-in role Only read any database. To limit Cogny to some databases, give it the read role on just those under Specific Privileges instead. On your own server:

   db.getSiblingDB("admin").createUser({
     user: "cogny_reader",
     pwd: "<strong password>",
     roles: [{ role: "read", db: "shop" }]
   })
   

2. Allow Cogny's IP. In Atlas, open IP Access List on the same page, click Add IP Address and enter 207.175.17.47. On your own server, allow that address in the firewall. The server has to be reachable from the internet and use TLS with a certificate from a public certificate authority (Atlas does both by default).

3. Connect. On the cluster, click Connect → Drivers and copy the connection string. In Settings → Integrations → MongoDB, paste it with the user's password in place of <db_password>. Add a database name after the host (…mongodb.net/shop) to make it the default. If the password contains @, : or /, write them as %40, %3A and %2F. The connection string is stored encrypted and scoped to the workspace.

4. Ask. "Which signup month has the best 90-day repeat-purchase rate, and which channel brought those customers?" is now a question the agent can answer from your own collections.

If something is wrong, the error says what: a blocked IP names the access list to add 207.175.17.47 to, a failed login names the user (and Cogny marks the connection for reconnecting), a missing permission says which database the user can't read, and a slow query says how to narrow it.

---

What it doesn't do

• No writes. Nothing inserts, updates or deletes documents, or creates collections, indexes or users.
• Password users only. X.509 certificates, AWS IAM, OIDC and Kerberos/LDAP logins can't be connected.
• Public endpoints only. A cluster reachable only through VPC peering or a private endpoint can't be connected.
• No Atlas administration. Clusters, backups, alerts and search-index management are out of scope.

The full tool list is on the MongoDB tools page. If your data lives in another database, wish for it: databases go into the build queue like any other integration.