Agentes de IA (MCP).
Conecta tu agente de código a Vericto con el Model Context Protocol para que valide cada migración y query contra las reglas de tu workspace mientras la escribe, antes de que exista un commit.
Resumen
Vericto expone un servidor MCP remoto en https://mcp.vericto.com/mcp. Un agente conectado (Claude Code u otro cliente MCP compatible) llama a check_sql mientras genera SQL y recibe el mismo veredicto que el CLI o la API: BLOCKED, FLAGGED, MONITORED o ALLOWED, con la regla que se disparó y una corrección sugerida.
Es el punto más temprano del ciclo: el CLI valida antes de mergear y el proxy TCP bloquea en producción; MCP valida mientras el código todavía se está escribiendo. Los tres usan el mismo motor AST determinístico y las mismas reglas de tu workspace.
No hay nada que instalar. El servidor es remoto (Streamable HTTP) y se autentica con una API key de tu workspace en el header Authorization.
Configuración
1. Crea una API key
En Dashboard → API Keys → New API key, crea una key solo con el scope ci_dryrun:execute (el mismo que usa el CLI) y, si quieres, una fecha de expiración. Cópiala: se muestra una sola vez. Guárdala en una variable de entorno, no en un archivo del repositorio:
# ~/.zshrc or ~/.bashrc
export VERICTO_API_KEY="vtro_..."
2. Conecta tu cliente
claude mcp add --scope user --transport http vericto https://mcp.vericto.com/mcp \
--header 'Authorization: Bearer ${VERICTO_API_KEY}'
Las comillas simples dejan ${VERICTO_API_KEY} sin expandir: la configuración guarda la referencia y Claude Code la resuelve al arrancar, así que la key nunca queda escrita en ~/.claude.json. Abre una sesión nueva y ejecuta /mcp: vericto debe aparecer conectado con 6 herramientas.
Probado con Claude Code.
No pegues la API key en archivos que se commitean, como un .mcp.json del proyecto. Usa la referencia a variables de entorno que ofrezca tu cliente.
Herramientas
| Herramienta | Qué hace | Cuota |
|---|---|---|
check_sql | Evalúa SQL contra las reglas del workspace y devuelve un veredicto por statement. | 1 check por llamada con sql; 1 por query con queries |
whoami | Plan, checks restantes del mes, versión del ruleset y las bases del workspace con su dialecto. | Gratis |
list_rules | Catálogo efectivo de reglas (estándar y personalizadas) con la acción resuelta. | Gratis |
show_rule | Detalle de una regla por código, incluida la condición AST que evalúa. | Gratis |
list_reports | Historial de checks del workspace, del más reciente al más antiguo. | Gratis |
show_report | El resultado completo de un check anterior, query por query. | Gratis |
Al conectarse, el servidor envía instrucciones de uso, así que el agente sabe cuándo llamar a cada herramienta sin que tengas que explicárselo.
Cómo funciona check_sql
Acepta una de dos entradas:
sql: el script completo, por ejemplo un archivo de migración. Vericto lo divide en statements y reporta cada uno con la línea donde empieza. Cuesta un check, igual que ese archivo con el CLI.queries: statements ya separados, cada uno con unlineopcional. Cuesta un check por query.
Pasa siempre el dialect de la base a la que apunta el SQL: postgres (por defecto), mysql, oracle o mssql. whoami lista las bases del workspace con su dialecto.
La respuesta es compacta: un resumen y, por cada statement que no sea ALLOWED, su línea, estado, regla, severidad y la corrección sugerida. Con verbose: true devuelve el resultado completo del CLI.
BLOCKED: 1 of 3 statements must not ship as written.
- line 4 BLOCKED VERICTO-001 (critical): DELETE FROM users Fix: DELETE FROM users WHERE id = $1
Ruleset v1.0.0-3f2a9c1b7d4e · 999 checks left this month
Si el script tiene cuerpos procedurales (CREATE PROCEDURE … BEGIN … END, BEGIN ATOMIC o DELIMITER de MySQL), Vericto no lo divide: lo evalúa como una sola unidad, igual que el CLI con un archivo, y reporta su hallazgo más grave.
El ruleset_version de la respuesta cambia solo cuando cambia una regla del workspace. Mientras coincida con el de whoami, un veredicto anterior sigue siendo válido.
Cada llamada queda en el historial de checks del workspace (Dashboard → Validaciones SQL, o list_reports), con un extracto de hasta 100 caracteres de cada statement.
Cuota y límites
| Plan | Checks por mes (CLI y MCP) |
|---|---|
| Free | 1.000 |
| Builder | 10.000 |
| Team | Ilimitados |
| Enterprise | Ilimitados |
La cuota mensual es compartida entre el CLI y MCP. Las herramientas de solo lectura no la consumen.
Además hay un límite de ritmo por API key, en todos los planes: 30 llamadas a check_sql por minuto y 300 por hora, y 60 por minuto a las herramientas de solo lectura. Si se supera, la herramienta responde con cuántos segundos esperar.
Seguridad
- La API key determina el workspace. El agente no puede elegir ni ver otro.
- Una key con solo
ci_dryrun:executeno puede leer el audit trail ni cambiar reglas: quien la obtenga, a lo sumo, gasta tu cuota de checks. - Vericto solo analiza el texto del SQL. No se conecta a tu base de datos ni ejecuta nada.
- Si revocas la key en Dashboard → API Keys, el agente pierde el acceso de inmediato.
Solución de problemas
| Síntoma | Causa | Qué hacer |
|---|---|---|
401 | Falta el header Authorization, o la variable de entorno está vacía. | Verifica que VERICTO_API_KEY esté exportada en el shell desde el que abres el cliente, y abre una sesión nueva. |
403 | La key no tiene el scope ci_dryrun:execute. | Crea una key con ese scope. |
Rate limited | Demasiadas llamadas en poco tiempo. | Espera los segundos que indica el mensaje. |
Monthly CI-check allowance used up | Se agotó la cuota del mes. | Espera al mes siguiente o sube de plan. Las herramientas de solo lectura siguen funcionando. |
PARSE_ERROR | Casi siempre, el dialecto equivocado. | Pasa el dialect correcto; whoami lo muestra por base. |