Lo innovador, en cuatro líneas
- El modelo explora el catálogo antes de consultar. Las herramientas se exponen en el orden natural de una investigación —catálogos, esquemas, tablas, y solo entonces SQL—, así que la consulta se construye sobre nombres que existen de verdad en lugar de sobre lo que el modelo cree recordar.
- Es MCP, no un plugin. El servidor habla un protocolo abierto, así que no está casado con un chat concreto: cualquier cliente que hable MCP se conecta al mismo sitio sin escribir nada nuevo.
- La superficie es deliberadamente pequeña. El modelo no recibe una conexión al warehouse: recibe cuatro herramientas con parámetros tipados y con lo que pueden hacer decidido de antemano.
- El formateo es parte de la herramienta. Devolver filas en crudo obliga al modelo a gastar contexto reordenándolas; devolverlas ya tabuladas deja ese contexto para razonar sobre el dato.
Qué resuelve
Preguntarle algo a un warehouse tiene un coste que no está en la consulta sino en todo lo anterior: saber en qué catálogo vive el dato, cómo se llama la tabla, qué columnas tiene, y recordar el dialecto exacto. Para quien no escribe SQL a diario, ese coste es la barrera entera — y acaba convertido en un ticket a ingeniería de datos.
Esta integración pone al modelo de IA en medio: quien pregunta lo hace en su idioma, y el modelo recorre el catálogo, encuentra la tabla, escribe el SQL y devuelve el resultado ya presentado.
Cómo funciona
Un servidor MCP publica un puñado de herramientas contra un workspace de Databricks. El modelo las va llamando en cadena, y cada llamada devuelve algo que le sirve para decidir la siguiente:
| Herramienta | Para qué |
|---|---|
| Listar catálogos | Situarse: qué hay disponible en el workspace |
| Listar esquemas | Acotar el catálogo elegido |
| Describir tablas | Nombres reales de columnas y tipos antes de escribir nada |
| Ejecutar SQL | La consulta, con el resultado devuelto ya formateado |
La secuencia importa más de lo que parece. Un modelo al que solo le das “ejecuta SQL” inventa nombres de tabla plausibles y falla; un modelo que puede mirar primero escribe una consulta que corre a la primera. Es la misma idea que hace funcionar cualquier agente decente: darle forma de explorar antes de actuar.
Decisiones que definen el proyecto
- Herramientas, no una conexión. El modelo nunca recibe credenciales ni una sesión abierta contra el warehouse: recibe funciones con parámetros tipados. Lo que no está expuesto como herramienta, sencillamente no se puede hacer.
- Un protocolo abierto antes que una integración a medida. MCP significa que el día que cambie el cliente de chat, el servidor sigue igual. Una integración propietaria habría que reescribirla entera.
- El formateo vive en el servidor. Es tentador devolver JSON y dejar que el modelo lo presente, pero eso gasta contexto y tokens en un trabajo que una función hace mejor y siempre igual.
Lo que aporta
Esto no sustituye a un analista: le quita la parte que no es análisis. La exploración del catálogo, recordar el nombre exacto de la tabla y teclear la sintaxis dejan de ser trabajo humano, y la conversación se queda en la pregunta de negocio — que es lo único que un modelo no puede hacer por ti.