Cómo conectar tu base de datos a un agente de IA (PostgreSQL, SQLite, APIs)
TL;DR
Las tres vías para darle datos a un agente: servidor MCP, API propia y texto embebido con RAG, con criterios para elegir según el tipo de consulta; permisos de solo lectura, ejemplo práctico con SQLite y MCP, y la verificación que confirma que el agente lee lo correcto y nunca escribe lo indebido.

Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Un agente sin datos es un generador de texto con opiniones: puede sonar seguro y estar inventando. Conectarlo a tu base de datos lo convierte en algo verificable: responde con tus registros, calcula con tus números y consulta lo que realmente tienes. La pregunta que define el proyecto no es "qué modelo usar", sino cómo darle los datos. Hay tres vías —MCP, API propia y RAG— y cada una resuelve un tipo de problema distinto. Esta guía te dice cuál usar, con permisos de solo lectura por defecto y un ejemplo completo con SQLite.
Las tres vías para darle datos a un agente
| Vía | Cómo funciona | Ideal para |
|---|---|---|
| Servidor MCP | El agente llama funciones que consultan la base | Consultas estructuradas y frecuentes |
| API propia | Un endpoint HTTP con autenticación expone tus datos | Control fino de acceso y auditoría |
| Texto embebido (RAG) | Documentos convertidos en fragmentos buscables | Conocimiento no estructurado (PDFs, docs) |
La regla de decisión: si la pregunta se responde con un SELECT o una llamada a API, usa MCP o API propia; si se responde con un párrafo de un documento, usa RAG. Mezclar las dos cosas sin necesidad es el error más común: agrega latencia, costo y mantenimiento.
Vía 1: servidor MCP (la más directa)
Un servidor MCP expone la base como herramientas que el agente invoca. Con el SDK oficial de Python, el ejemplo más corto conecta SQLite en modo solo lectura:
from mcp.server.fastmcp import FastMCP
import sqlite3
mcp = FastMCP("datos-negocio")
@mcp.tool()
def ventas_por_dia(fecha: str) -> list[dict]:
"""Ventas de una fecha (YYYY-MM-DD): producto y monto."""
conn = sqlite3.connect("file:datos.db?mode=ro", uri=True)
try:
rows = conn.execute(
"SELECT producto, monto FROM ventas WHERE fecha = ?", (fecha,)
).fetchall()
return [{"producto": r[0], "monto": r[1]} for r in rows]
finally:
conn.close()
if __name__ == "__main__":
mcp.run()
Dos decisiones de seguridad están en el código: mode=ro hace imposible la escritura, y las consultas parametrizadas neutralizan la inyección SQL incluso si el agente genera un argumento malicioso. La conexión con el agente se hace con claude mcp add datos-negocio -- python servidor.py (o el equivalente de tu cliente), y las herramientas aparecen disponibles en la sesión.

Para PostgreSQL el patrón es idéntico: cambia el conector a psycopg y crea un usuario de base de datos dedicado al agente, con permisos de solo lectura sobre las vistas que necesite. Nunca conectes el agente con el usuario administrador.
Vía 2: API propia (control y auditoría)
Cuando necesitas control fino —quién llama, cuántas veces, qué devuelve— una API propia es mejor que exponer la base directamente:
- Autenticación: el agente usa una API key propia; si se filtra, se revoca sin tocar la base.
- Contratos estables: el agente consume un schema fijo, no la estructura interna de tus tablas.
- Límites: rate limits por agente y por usuario, registro de cada consulta.
- Transformación: la API puede enmascarar campos sensibles antes de responder.
El costo es desarrollo y mantenimiento de un servicio extra. Para una o dos consultas, el servidor MCP directo gana; para un producto con varios clientes, la API propia se paga sola.
Vía 3: RAG (cuando el conocimiento no es estructurado)
Si tus datos son documentos —políticas, manuales, contratos— la consulta estructurada no aplica. RAG convierte los documentos en fragmentos, los indexa en una base vectorial y recupera los relevantes para cada pregunta. La comparativa completa de RAG vs workflow automatizado te da el criterio exacto, pero la señal más simple es: si la respuesta correcta está en un párrafo de un documento, es RAG; si está en una fila de una tabla, es SQL.
Permisos: el principio de solo lectura
La configuración por defecto de cualquier conexión agente-base debe ser:
- Usuario dedicado al agente, con los permisos mínimos (lectura de las tablas/vistas que necesita).
- Solo lectura salvo que exista un caso explícito y supervisado de escritura.
- Vistas en vez de tablas: exponer solo las columnas necesarias.
- Sin credenciales en el prompt: todo vive en variables de entorno del servidor.
- Logs: registrar consultas para detectar patrones anómalos.
PostgreSQL en producción: el patrón completo
Cuando el agente pasa de SQLite a PostgreSQL, el patrón de seguridad se vuelve explícito:
- Crea un rol dedicado al agente:
CREATE ROLE agente_lectura LOGIN PASSWORD '...'— nunca uses el superusuario. - Otorga solo lectura sobre las vistas que necesita:
GRANT SELECT ON vistas_agente TO agente_lectura. - Define vistas que expongan solo las columnas necesarias, con filtros aplicados (por ejemplo, sin columnas de costo interno o datos personales).
- Guarda la cadena de conexión en variables de entorno del servidor MCP; el agente nunca la ve.
- Registra consultas con
log_statement = 'all'durante las primeras semanas para auditar qué pide realmente el agente.
Este patrón escala igual para MySQL, MariaDB o cualquier base con usuarios y permisos. La diferencia con SQLite no es técnica: es que en producción el rol del agente es un actor más de tu sistema, y se trata como tal.
Verificación: cómo sabes que quedó bien

- Pregúntale al agente un dato que solo exista en tu base (una fecha, un monto) y confirma que responde con el valor real.
- Pregúntale algo que no exista y confirma que dice que no lo sabe en lugar de inventar.
- Intenta una consulta de escritura desde el agente y confirma que falla (modo ro).
- Revisa el log del servidor: las consultas ejecutadas coinciden con las preguntas.
- Verifica que ninguna credencial aparece en la conversación ni en los logs.
Cuándo NO conectar la base
Hay dos casos donde conviene no hacerlo: datos extremadamente sensibles sin sandbox (primero lee seguridad en MCP y fugas de datos en agentes), y prototipos de una tarde donde un archivo exportado alcanza. Para el resto, el patrón de esta guía escala de SQLite a PostgreSQL sin cambiar la arquitectura. Para el camino completo —de la base a un agente productivo— el hub de construcción de agentes sigue con memoria y herramientas, y el curso gratuito de instalación te deja el primer agente funcionando hoy.
Artículos relacionados
Sigue explorando Datos y otras lecturas para builders.

AlloyDB Remote MCP ya está GA: agentes con SQL, IAM y Model Armor sobre datos operacionales

Cloud Storage MCP convierte buckets en contexto para agentes: remoto cuando quieres gobierno, local cuando necesitas tools propias

MongoDB quiere que el agente también administre la base: Atlas, MCP y menos fricción para pasar del prompt a producción
