Agentes de IA (MCP).

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.

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}'

{
  "mcpServers": {
    "vericto": {
      "url": "https://mcp.vericto.com/mcp",
      "headers": { "Authorization": "Bearer ${VERICTO_API_KEY}" }
    }
  }
}

{
  "mcpServers": {
    "vericto": {
      "serverUrl": "https://mcp.vericto.com/mcp",
      "headers": { "Authorization": "Bearer vtro_..." }
    }
  }
}

{
  "inputs": [
    { "type": "promptString", "id": "vericto-api-key", "description": "Vericto API key", "password": true }
  ],
  "servers": {
    "vericto": {
      "type": "http",
      "url": "https://mcp.vericto.com/mcp",
      "headers": { "Authorization": "Bearer ${input:vericto-api-key}" }
    }
  }
}

{
  "mcpServers": {
    "vericto": {
      "url": "https://mcp.vericto.com/mcp",
      "headers": { "Authorization": "Bearer <API key, or your client's env-var reference>" }
    }
  }
}

Herramientas

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 por statement, igual que ese archivo con el CLI.
• queries: statements ya separados, cada uno con un line opcional. Cuesta un check por statement.

Pasa siempre el dialect de la base a la que apunta el SQL: postgres (por defecto), mysql, oracle, mssql, snowflake o sqlite. 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.

Columnas sensibles. Pasa el database_id de la base (lo lista whoami) para que se apliquen sus columnas sensibles; sin él se aplican las de todas las bases del workspace, con la política más estricta por columna. Si un hallazgo trae approved_query, la query lee una columna enmascarada: esa es la única query aprobada y el agente debe ejecutarla en lugar de la original. MCP no puede obligarlo; solo el proxy TCP aplica el enmascaramiento.

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

El ruleset_version de la respuesta cambia solo cuando cambia una regla o una columna sensible del workspace. Mientras coincida con el de whoami (que corresponde a un check sin database_id), 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

La cuota mensual es compartida entre el CLI, la API de validación y MCP, y cada statement evaluado cuenta como un check. Si una llamada necesita más checks de los que quedan, se rechaza entera, sin evaluar nada, y el mensaje indica cuántos quedan: divide el script o espera al mes siguiente. Las herramientas de solo lectura no consumen la cuota.

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:execute no 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

Ver también

• Guía
• API Keys
• Referencia de reglas AST