Renbase frente al dbt MCP server¶
El dbt MCP server es el vecino más cercano que tiene Renbase, y la comparación es amistosa: Renbase lee los artefactos de dbt como fuente. Si usas dbt, esta página va de qué sirve cada herramienta a tus agentes — no de elegir bando.
La versión corta: el dbt MCP server expone lo que vive en dbt; Renbase gobierna lo que no cabe en dbt. Métricas, modelos, lineage y metadatos por un lado; documentos, reglas condicionales, definiciones entre sistemas y un ciclo de aprobación por el otro.
Qué hace bien el dbt MCP server¶
- Tu proyecto de dbt, por MCP. Los agentes pueden descubrir modelos, consultar métricas a través del Semantic Layer, inspeccionar el lineage y leer metadatos — directo de la fuente de verdad, por el protocolo abierto que los agentes ya hablan.
- Cero deriva respecto al repo. Lo que el servidor expone es el proyecto. Si la métrica cambió en el último merge, el agente ve la nueva.
- Open source y de primera parte. Mantenido por dbt Labs, funciona con dbt Core y con la plataforma de dbt.
Si la pregunta del agente es «qué modelos existen, qué calcula esta métrica, qué alimenta a qué», esta es la herramienta correcta, y Renbase no intenta sustituirla.
Lo que no cabe en el YAML¶
El conocimiento que nunca llega al repo. La regla de que los deals nuevos de USCAN viven en Affinity desde 2025 no es una propiedad de un modelo; la política de descuentos es un PDF; el motivo por el que una tabla está deprecada es un hilo de Slack. dbt no puede guardarlos — Renbase ingiere documentos y almacena entradas rule condicionales junto a las definiciones de métricas que destila de tus artefactos de dbt.
Un significado que pertenece a gente que no escribe YAML. En dbt, cambiar una definición exige un ingeniero y un pull request. En Renbase, los conectores proponen borradores y cualquier aprobador —finanzas, operaciones, legal— los revisa en el panel, con versiones, procedencia y un nombre. Quien posee el significado de «revenue» rara vez es quien posee el repo.
Los conflictos entre sistemas. dbt guarda una definición por métrica: la que se mergeó. Cuando finanzas y producto discrepan con razón, Renbase devuelve las dos definiciones aprobadas, marcadas como conflicto y con su procedencia — un estado que el modelo de repo no puede representar.
Respuestas, no solo metadatos. El dbt MCP server devuelve hechos del proyecto y resultados de consulta. Renbase añade encima el contrato de respuesta: ask devuelve respuestas completas con citas tipadas, y se abstiene cuando el contexto falta, ha caducado o está en conflicto — incluido el contexto que salió de dbt pero se ha desviado de él, que el conector marca como caducado al resincronizar.
Lado a lado¶
| dbt MCP server | Renbase | |
|---|---|---|
| Expone | Modelos, métricas, lineage y metadatos de dbt | Documentos y definiciones de muchas fuentes, dbt incluido |
| Documentos | No | De primera clase, indexados con las definiciones |
| Reglas condicionales | Sin YAML para ellas | Entradas rule con ámbito, versión y aprobación |
| Quién edita el significado | Ingenieros, vía pull requests | Cualquier aprobador, en el panel |
| Conflictos | Una definición mergeada | Se devuelven ambas, marcadas, con procedencia |
| Caducidad | N/A — siempre el repo actual | Rastreada contra las fuentes; marcada en las respuestas |
| Contrato de respuesta | Resultados y metadatos | Respuestas citadas con abstención |
| Tenancy | Tu proyecto | Multi-tenant; embebible |
Cuándo basta el dbt MCP server solo¶
- Las preguntas de tus agentes son sobre el propio proyecto de dbt: qué modelos, qué métricas, qué lineage.
- Todo lo que tus agentes necesitan saber está de verdad en el repo, y quien lo mantiene es quien posee el significado.
- Quieres herramienta de primera parte, open source y sin nada nuevo que comprar.
Y cuando no basta: usa los dos. Los agentes le preguntan al dbt MCP server qué calcula el proyecto, y a Renbase qué quiere decir la organización — con los documentos, las excepciones y las aprobaciones que nunca llegaron al YAML. La comparativa con la capa semántica cubre la misma frontera desde el lado del modelado.
Fuentes¶
- dbt MCP server (GitHub)
- Documentación del dbt Semantic Layer
- Your Data Agents Need Context (a16z) — sobre el conocimiento tribal como el componente que falta