Conectar Devin a MongoDB

Devin puede trabajar con tus datos de MongoDB igual que lo haría un ingeniero con una cadena de conexión de solo lectura: ver qué contienen realmente las colecciones, averiguar por qué una consulta es lenta, ensayar una migración en una base de datos sandbox y abrir una PR (pull request). Esta guía explica cómo configurarlo con identidades que creas específicamente para Devin, de modo que nunca actúe en nombre de uno de tus ingenieros.

Todo se queda en tu cuenta de Atlas: un usuario de base de datos, una cuenta de servicio, las herramientas de MongoDB instaladas mediante un blueprint de entorno y, opcionalmente, un servidor MCP. Empieza con permisos mínimos (solo lectura en producción) y amplía los roles más adelante: los roles marcan el límite, y puedes cambiarlos en Atlas sin tocar Devin.

Dos planos, dos identidades

Plano	A qué accede	Identidad de Devin	Credencial
Plano de datos	Bases de datos, documentos, índices, `explain()`	Un usuario de base de datos	Nombre de usuario y contraseña en una cadena de conexión
Plano de control	Clústeres, índices de Search, Performance Advisor, registros de consultas lentas, usuarios de base de datos, listas de acceso	Una cuenta de servicio de Atlas	Client ID y client secret de OAuth 2.0

Un usuario de base de datos no puede llamar a la Atlas Administration API, y una cuenta de servicio no puede leer documentos a través de la API. La mayoría de los equipos empiezan solo con el plano de datos y agregan la cuenta de servicio cuando Devin necesita Performance Advisor o los registros de consultas lentas (clústeres dedicados, M10 o superior). Dos salvedades:

Una cuenta de servicio que puede crear usuarios de base de datos (GROUP_OWNER, GROUP_DATABASE_ACCESS_ADMIN) puede crearse a sí misma una identidad en el plano de datos. Es justo lo que hace el servidor MCP de MongoDB cuando se le pide que se conecte a un clúster (Opción B).
Los datos de consultas lentas incluyen los valores literales de las consultas.

Elige cómo se conecta Devin

Las tres opciones usan el mismo acceso de red (Paso 1) y las mismas identidades (Paso 2); la diferencia está en lo que Devin llega a tener en su poder.

Opción	Ideal para	Configuración
Opción A: CLI en un blueprint	Tareas que Devin ejecuta y repite en un repositorio: migraciones, backfills, datos iniciales y pruebas con datos de estructura realista	Cuatro secretos de Devin y un blueprint breve. Empieza por aquí.
Opción B: servidor MCP de MongoDB	Descubrimiento de esquemas y análisis de consultas e índices como herramientas, con las salvaguardas `--readOnly` y `--indexCheck`	Un servidor MCP STDIO personalizado que usa las mismas credenciales. Complementa la Opción A.
Opción C: plugin de MongoDB Atlas	Consultas sobre Atlas y lecturas a nivel de proyecto, sin almacenar ninguna credencial de MongoDB en la sesión	Plugin del marketplace, inicio de sesión OAuth con un usuario dedicado de Atlas; modo de acceso a la org configurado como Read.

¿Por qué conectar Devin a MongoDB?

El esquema está en los propios documentos. MongoDB no tiene information_schema, y los modelos de Mongoose o Prisma acaban desalineándose de lo que realmente está almacenado. Devin toma muestras de las colecciones en vivo y trabaja a partir de su estructura real.
El ciclo de consultas lentas se resuelve en una sola sesión. Devin lee Performance Advisor y el registro de consultas lentas, ejecuta explain() sobre la colección real, localiza el código que lanza la consulta y abre un PR con la corrección y el índice propuesto.
Los roles del usuario de la base de datos determinan a qué puede acceder Devin. Empieza con acceso de solo lectura en producción y un sandbox devin_dev para las escrituras; cada acción queda registrada en los registros de Atlas con la propia identidad de Devin.

Requisitos previos

Atlas

Un proyecto con un clúster.
Organization Owner para crear una cuenta de servicio; Project Owner para el usuario de la base de datos y las listas de acceso.

Devin

Permiso para editar el blueprint del entorno y agregar Secrets.
Para las opciones con MCP, el permiso Manage MCP Servers.

Red

Las IP de Devin incluidas en la lista de acceso IP del proyecto (Paso 1).
Si usas una política de red de Devin, permite *.mongodb.net y cloud.mongodb.com, además de los hosts desde los que el blueprint instala paquetes: pgp.mongodb.com y repo.mongodb.org (Opción A), registry.npmjs.org y nodejs.org (Opción B). El driver se conecta por el puerto 27017, no por el 443; las entradas de la política son nombres de host o CIDR, así que no hace falta configurar ningún puerto. Las compilaciones de instantáneas se ejecutan con la misma política.

Paso 1: Habilitar el acceso de red

Atlas rechaza las conexiones desde IP que no figuran en la lista de acceso IP del proyecto. Agrega las IP indicadas en Lista de permitidos de IP; no las agregues de memoria. Los tenants dedicados tienen su propio tráfico de salida; confírmalo con tu equipo de cuenta.

atlas accessLists create <ip> --type ipAddress --comment "Devin" --projectId <project-id>
atlas accessLists create <cidr> --type cidrBlock --comment "Devin" --projectId <project-id>

La lista incluye tanto direcciones individuales como un rango CIDR; usa --type ipAddress para las direcciones individuales y --type cidrBlock para el rango. Si tu organización exige una lista de acceso a la API en las cuentas de servicio, agrega las mismas IP en la página de la cuenta de servicio en Atlas. Las llamadas desde una IP que no esté en la lista fallan con un error 403.

Paso 2: Crear las identidades de Devin

Usuario de base de datos

Acceso de lectura en las bases de datos de producción, de lectura/escritura en un sandbox y con ámbito limitado a clústeres específicos:

atlas dbusers create \
  --username devin-sessions \
  --password "<generated-password>" \
  --role read@analytics,read@billing,readWrite@devin_dev \
  --scope <cluster-name> \
  --projectId <project-id>

Sin --scope, el usuario puede acceder a todos los clústeres del proyecto. Usa un rol de base de datos personalizado cuando los roles integrados no permitan definir ese límite. Genera la contraseña con un gestor de contraseñas y no la dejes en el historial del shell. Copia la cadena de conexión de este usuario; no le des a Devin el usuario admin del clúster.

Cuenta de servicio (solo si Devin necesita el plano de control)

En Atlas, ve a Identity & Access > Applications a nivel de organización. Empieza con acceso de solo lectura y elige la vida útil más corta para el secreto de cliente que permita tu política de rotación.

	Roles	Motivo
Otorgar	`ORG_MEMBER` en la organización; `GROUP_READ_ONLY` y `GROUP_DATA_ACCESS_READ_ONLY` en cada proyecto	Base de solo lectura
Agregar solo si es necesario	`GROUP_SEARCH_INDEX_EDITOR`	Devin gestiona índices de Search
Nunca	`GROUP_OWNER`, `GROUP_DATABASE_ACCESS_ADMIN`	Cualquiera de los dos permite que Devin amplíe su propio acceso

La fila Nunca es especialmente importante con la Opción B. Si la cuenta de servicio puede crear usuarios de base de datos, la herramienta atlas-connect-cluster del servidor MCP crea un usuario temporal con acceso a todo el clúster (readAnyDatabase, o readWriteAnyDatabase sin --readOnly) y así elude los roles por base de datos de devin-sessions. Ese usuario permanece activo durante 4 horas, a menos que la herramienta de desconexión del MCP lo elimine antes.

Paso 3: Conecta Devin

Opción A: CLI en un blueprint

Agregar secretos de Devin

En la pestaña Secrets del blueprint:

Secreto	Valor
`MONGODB_URI`	La cadena de conexión de `devin-sessions`, por ejemplo, `mongodb+srv://devin-sessions:<password>@cluster0.abcde.mongodb.net/`. Aplica codificación porcentual a la contraseña.
`MONGODB_ATLAS_CLIENT_ID`	Client ID de la cuenta de servicio (`mdb_sa_id_...`), si usas el plano de control
`MONGODB_ATLAS_CLIENT_SECRET`	Client secret de la cuenta de servicio
`MONGODB_ATLAS_PROJECT_ID`	Project ID predeterminado

Los secretos se inyectan en cada sesión, por lo que rotar un valor no requiere recompilar. La CLI de Atlas lee el client ID y el client secret de estas variables de entorno, así que no hace falta ejecutar atlas auth login. La primera vez que se usa, almacena en caché un token de acceso en ~/.config/atlascli/config.toml. Esto no es un problema dentro de una sesión, pero nunca crees ese archivo en initialize.

Agrega el blueprint

initialize:
  - name: Install the Atlas CLI and mongosh
    run: |
      curl -fsSL https://pgp.mongodb.com/server-8.0.asc \
        | sudo gpg --batch --yes -o /usr/share/keyrings/mongodb-server-8.0.gpg --dearmor
      echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/8.0 multiverse" \
        | sudo tee /etc/apt/sources.list.d/mongodb-org-8.0.list
      sudo apt-get update
      sudo apt-get install -y mongodb-atlas-cli mongodb-mongosh
      atlas --version && mongosh --version

knowledge:
  - name: mongodb-access
    contents: |
      Connect to MongoDB with `mongosh "$MONGODB_URI"`; the URI is a Devin Secret. The Atlas CLI
      authenticates as a service account from MONGODB_ATLAS_CLIENT_ID and MONGODB_ATLAS_CLIENT_SECRET,
      with MONGODB_ATLAS_PROJECT_ID as the default project. Do not run `atlas auth login`, do not ask
      for a username, password, or API key, and never write the connection string into a file, script,
      log, or PR. Production databases are read-only; write only to the devin_dev database. Ship
      schema, index, and migration changes through a pull request.

Sustituye jammy si tu imagen no es Ubuntu 22.04. El bloque knowledge es más importante que la instalación: sin él, las sesiones ejecutan atlas auth login (un flujo de navegador que nadie puede completar) o piden una cadena de conexión que ya está en el entorno.

No guardes credenciales en disco en initialize. Un ~/.mongoshrc.js, un ~/.config/atlascli/config.toml o una URI exportada en ~/.bashrc terminan en la instantánea, compartida por todas las sesiones futuras.

Compila la instantánea

Guarda el blueprint, espera a que el estado sea Éxito y, después, inicia una nueva sesión. Las sesiones abiertas siguen usando la instantánea anterior.

Opción B: servidor MCP de MongoDB

El mongodb-mcp-server oficial se ejecuta como un proceso local dentro de la sesión y utiliza las identidades del Paso 2. Para aprovechar sus mecanismos de protección, agrégalo como servidor MCP personalizado (Customize > MCPs > Add MCP > Add custom MCP, transporte STDIO) en lugar de usar el plugin mongodb del marketplace, cuyo manifest no expone --readOnly ni --indexCheck.

Campo	Valor
Command	`npx`
Arguments	`-y mongodb-mcp-server@<version> --readOnly --indexCheck`
Environment	`MDB_MCP_CONNECTION_STRING` (mismo valor que `MONGODB_URI`); opcionalmente, `MDB_MCP_API_CLIENT_ID` y `MDB_MCP_API_CLIENT_SECRET` para las herramientas de Atlas

Fija <version> en una versión que hayas probado, ya que npx descarga el package cada vez que se inicia una sesión. Con la cuenta de servicio de solo lectura del Paso 2, atlas-connect-cluster devuelve 401; Devin accede a los datos a través de la conexión preconfigured de MDB_MCP_CONNECTION_STRING, que es la vía prevista.

--readOnly evita que se registren las herramientas de creación, actualización y eliminación, y rechaza las agregaciones que contienen $out o $merge. Sin esta opción, esas agregaciones se ejecutan tras un prompt de confirmación, o directamente sin confirmación si el cliente MCP no admite prompts. Úsala siempre que apuntes a producción.
--indexCheck rechaza las consultas cuyo plan implique un análisis completo de la colección. Es un mecanismo de protección del rendimiento; si el propio explain falla, la consulta se ejecuta igualmente.

El servidor requiere Node ^20.19.0 || ^22.13.0 || >=24.0.0. Comprueba node --version en una sesión; si la versión es anterior, o si npx no está en la ruta que ve el proceso MCP, agrega Node al blueprint:

initialize:
  - name: Install Node.js for the MongoDB MCP server
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "22"

Mantén el usuario de base de datos de solo lectura aunque uses --readOnly. Devin también puede ejecutar mongosh "$MONGODB_URI" con el mismo usuario, así que son los roles del usuario los que realmente imponen el límite.

Opción C: plugin de MongoDB Atlas

El plugin MongoDB Atlas conecta Devin al servidor MCP alojado de MongoDB (mcp.mongodb.com) e instala las skills de agente de MongoDB. Devin actúa con los roles de Atlas del usuario que inicia sesión, con el límite que impone el modo de acceso de clientes de IA de la organización.

Un Organization Owner habilita el acceso de clientes de IA (Organization Settings > App Connections) y establece el modo de acceso en Read para que no se registren herramientas de escritura. Esta configuración se aplica a todos los clientes de IA de la organización, no solo a Devin.
Crea un usuario de Atlas dedicado para Devin con GROUP_READ_ONLY y GROUP_DATA_ACCESS_READ_ONLY, únicamente en los proyectos que pueda leer. GROUP_DATA_ACCESS_READ_ONLY permite leer documentos de todas las bases de datos del proyecto, por lo que su alcance es mayor que el del usuario devin-sessions.
Instala el plugin y completa una vez el inicio de sesión de OAuth en Customize > MCPs, autenticado como ese usuario y no con tu propia cuenta.
Cuando funcione, fija el plugin a un commit.

El tráfico proviene de la infraestructura alojada de MongoDB y de Devin, no de la sesión, por lo que las listas de IP del Paso 1 y tu política de red no se aplican. El acceso caduca tras 7 días de inactividad o 30 días desde el inicio de sesión, lo que ocurra primero; en ese caso, vuelve a iniciar sesión. Revocar el acceso no elimina los usuarios de base de datos ni otros artefactos que haya creado el cliente, así que conviene auditarlos.

Recompilaciones y fijación de versiones

El blueprint instala la versión que apt resuelva en el momento de la compilación, y el npx de la Opción B descarga mongodb-mcp-server cada vez que se inicia una sesión. Fija las versiones de ambos (mongodb-atlas-cli=<version>, mongodb-mongosh=<version>, mongodb-mcp-server@<version>) en cuanto funcionen y actualízalas solo de forma intencionada. Rotar un secreto no requiere recompilar; cambiar una herramienta instalada, sí.

Paso 4: Configura los permisos

La autenticación determina quién es Devin; los roles de la base de datos y de Atlas determinan a qué puede acceder. Las opciones de MCP y las instrucciones de Knowledge son facilidades adicionales, no el límite de seguridad.

Perfil	Trabajo típico	Roles del usuario de la base de datos	Roles de la cuenta de servicio
Explore (empieza aquí)	Documentar el esquema, explicar una consulta lenta, proponer un índice en un PR	`read` en las bases de datos de producción	`GROUP_READ_ONLY` + `GROUP_DATA_ACCESS_READ_ONLY`
Build	Escribir y probar migraciones, procesos y datos iniciales con datos de estructura realista	Explore, más `readWrite@devin_dev`	Igual que Explore
Operate	Crear índices o índices de Atlas Search en colecciones concretas	Explore, más un rol personalizado que otorgue `createIndex` sobre esas colecciones	Explore, más `GROUP_SEARCH_INDEX_EDITOR`

Para Explore, los índices sugeridos solo requieren GROUP_READ_ONLY (los valores de las consultas se devuelven enmascarados). La lista de consultas lentas, los valores de consultas de ejemplo y la descarga de registros también requieren GROUP_DATA_ACCESS_READ_ONLY; no hace falta el rol GROUP_DATA_ACCESS_READ_WRITE que pide la ayuda de la CLI de Atlas. Con solo GROUP_READ_ONLY, la herramienta atlas-get-performance-advisor de MCP devuelve «No slow query logs found» en lugar del error 401, así que un resultado vacío puede deberse a un problema de roles.

El código se sigue entregando mediante pull requests. Devin lee producción para comprender el problema y valida la corrección en devin_dev; la migración o el índice se incorporan a través de tu proceso de revisión habitual.

Paso 5: Verificar

Inicia una nueva sesión y pide a Devin que ejecute: Conectividad. Qué usuario y qué roles se usan y (si está configurada) si la CLI de Atlas se autentica correctamente:

mongosh "$MONGODB_URI" --quiet --eval 'JSON.stringify(db.runCommand({connectionStatus: 1}), null, 2)'
atlas clusters list --projectId "$MONGODB_ATLAS_PROJECT_ID"

Límite. La primera inserción debería fallar (not authorized on <prod-db> to execute command en clústeres dedicados, user is not allowed to do action [insert] on [<prod-db>.devin_probe] en M0/Flex); la segunda debería completarse correctamente:

mongosh "$MONGODB_URI" --quiet --eval 'db.getSiblingDB("<prod-db>").devin_probe.insertOne({probe: 1})'
mongosh "$MONGODB_URI" --quiet --eval 'db.getSiblingDB("devin_dev").devin_probe.insertOne({probe: 1}); db.getSiblingDB("devin_dev").devin_probe.drop()'

Comprueba que los roles de connectionStatus coincidan con el perfil que concediste; que la conexión esté abierta no basta para demostrar mucho. Para el servidor MCP, pide a Devin que liste las bases de datos mediante las herramientas MCP (usa la conexión preconfigured) y, después, que inserte un documento: con --readOnly no existe la herramienta insert-many, y cualquier agregación con $out se rechaza.

Solución de problemas

Síntoma	Se aplica a	Causa y solución
Se agota el tiempo de espera de la conexión o el error menciona la lista de acceso IP	A, B	Faltan las IP de Devin en la lista de acceso IP del proyecto (el fallo más habitual) o tu política de red bloquea `*.mongodb.net` en el puerto TCP 27017.
`querySrv ENOTFOUND _mongodb._tcp.<host>`	A, B	El DNS está bloqueado o el nombre de host es incorrecto. Permite `*.mongodb.net` en la política de red.
`Authentication failed` o `bad auth : authentication failed`	A, B	La contraseña o el `authSource` son incorrectos.
`MongoParseError: Protocol and host list are required`	A, B	La contraseña del URI contiene `@`, `/` o `+` y no está codificada como porcentaje. Codifícala; no se trata de un error de autenticación.
`not authorized on <db> to execute command` o `user is not allowed to do action`	A, B	La sesión se inició, pero no hay permisos suficientes. Es lo esperado cuando Devin escribe en producción; en otros casos, amplía los roles del usuario.
La CLI de Atlas indica `unauthorized` o sugiere `atlas auth login`	A, B	Los secretos de la cuenta de servicio faltan, son incorrectos o han caducado, o bien el rol de la cuenta de servicio no permite esa acción (el servidor MCP también lo notifica como credenciales no válidas). Revisa el rol antes de rotar los secretos. No ejecutes `atlas auth login`.
La CLI de Atlas devuelve `403` tras la autenticación	A, B	Faltan las IP de Devin en la lista de acceso a la API de la cuenta de servicio (paso 1).
Devin ejecuta `atlas auth login` o pide una cadena de conexión	A	Falta el bloque `knowledge` o los secretos no están en el blueprint que usa la sesión.
La compilación del blueprint falla en `apt-get` o el servidor MCP no se inicia	A, B	Falta `pgp.mongodb.com`, `repo.mongodb.org`, `registry.npmjs.org` o `nodejs.org` en la política de red, o la versión de Node es anterior a la 20.19 (ejecuta `node --version`).
MCP rechaza una consulta por no usar un índice	B	`--indexCheck` está haciendo su trabajo. Agrega el índice en un PR o ejecuta la consulta con `mongosh` contra `devin_dev`. Las consultas que requieren un índice con intercalación siempre se rechazan, ya que la herramienta `find` de MCP no admite un argumento de intercalación.
Faltan herramientas de Atlas o aparecen herramientas de escritura	C	El acceso de clientes de IA está deshabilitado, el modo de acceso es Read and write o el usuario de Atlas que inició sesión tiene roles más amplios de lo previsto. Revisa el modo en App Connections y comprueba quién completó el inicio de sesión de OAuth.
Las credenciales funcionan en una sesión, pero no en la siguiente	A	La instantánea contiene un archivo de configuración obsoleto de un `initialize` anterior. Elimínalo del blueprint y vuelve a compilar.

Limitaciones

Se requieren credenciales almacenadas. Por ahora, el token OIDC de corta duración de Devin no se puede usar con MongoDB: la Administration API solo acepta secretos de cuentas de servicio o claves de API. Workload Identity Federation de Atlas cubre el plano de datos en clústeres dedicados, pero requiere un callback de token a nivel del driver y aún no se ha probado con el emisor de Devin. Si quieres probarlo, avisa a tu equipo de cuenta. MongoDB autohospedado. Los pasos del plano de datos (usuario de la base de datos, MONGODB_URI, mongosh, servidor MCP) se aplican sin cambios. No hay cuenta de servicio de Atlas ni lista de acceso IP; el acceso a la red se gestiona a través de tu VPN o de tu propia lista de permitidos.

Soporte

Para lo relativo a Atlas, consulta la documentación de seguridad de Atlas y la documentación del servidor MCP de MongoDB. Para lo relativo a Devin, ponte en contacto con support@cognition.ai o con tu equipo de cuenta.

Primeros pasos

Conceptos clave

Incorporación de Devin

Trabajar con Devin

Guías de producto

Integraciones

Admin

Notas de la versión

Conectar Devin a MongoDB

Dos planos, dos identidades

Elige cómo se conecta Devin

¿Por qué conectar Devin a MongoDB?

Requisitos previos

Paso 1: Habilitar el acceso de red

Paso 2: Crear las identidades de Devin

Usuario de base de datos

Cuenta de servicio (solo si Devin necesita el plano de control)

Paso 3: Conecta Devin

Opción A: CLI en un blueprint

Agregar secretos de Devin

Agrega el blueprint

Compila la instantánea

Opción B: servidor MCP de MongoDB

Opción C: plugin de MongoDB Atlas

Recompilaciones y fijación de versiones

Paso 4: Configura los permisos

Paso 5: Verificar

Solución de problemas

Limitaciones

Soporte

​Dos planos, dos identidades

​Elige cómo se conecta Devin

​¿Por qué conectar Devin a MongoDB?

​Requisitos previos

​Paso 1: Habilitar el acceso de red

​Paso 2: Crear las identidades de Devin

​Usuario de base de datos

​Cuenta de servicio (solo si Devin necesita el plano de control)

​Paso 3: Conecta Devin

​Opción A: CLI en un blueprint

​ Agregar secretos de Devin

​ Agrega el blueprint

​ Compila la instantánea

​Opción B: servidor MCP de MongoDB

​Opción C: plugin de MongoDB Atlas

​Recompilaciones y fijación de versiones

​Paso 4: Configura los permisos

​Paso 5: Verificar

​Solución de problemas

​Limitaciones

​Soporte

Dos planos, dos identidades

Elige cómo se conecta Devin

¿Por qué conectar Devin a MongoDB?

Requisitos previos

Paso 1: Habilitar el acceso de red

Paso 2: Crear las identidades de Devin

Usuario de base de datos

Cuenta de servicio (solo si Devin necesita el plano de control)

Paso 3: Conecta Devin

Opción A: CLI en un blueprint

Agregar secretos de Devin

Agrega el blueprint

Compila la instantánea

Opción B: servidor MCP de MongoDB

Opción C: plugin de MongoDB Atlas

Recompilaciones y fijación de versiones

Paso 4: Configura los permisos

Paso 5: Verificar

Solución de problemas

Limitaciones

Soporte