AI agents (MCP).

Overview

Vericto runs a remote MCP server at https://mcp.vericto.com/mcp. A connected agent (Claude Code or another compatible MCP client) calls check_sql while it generates SQL and gets the same verdict as the CLI or the API: BLOCKED, FLAGGED, MONITORED or ALLOWED, with the rule that fired and a suggested fix.

It is the earliest point in the cycle: the CLI checks before merge and the TCP proxy blocks in production; MCP checks while the code is still being written. All three use the same deterministic AST engine and your workspace rules.

Setup

1. Create an API key

In Dashboard → API Keys → New API key, create a key with only the ci_dryrun:execute scope (the one the CLI uses) and, optionally, an expiry date. Copy it: it is shown only once. Keep it in an environment variable, not in a file in your repository:

# ~/.zshrc or ~/.bashrc
export VERICTO_API_KEY="vtro_..."

2. Connect your client

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

Tools

On connect the server sends usage instructions, so the agent knows when to call each tool without you having to explain it.

How check_sql works

It takes one of two inputs:

• sql: the whole script, such as a migration file. Vericto splits it into statements and reports each one with the line it starts on. It costs one check, the same as that file through the CLI.
• queries: statements already split, each with an optional line. It costs one check per query.

Always pass the dialect of the database the SQL targets: postgres (the default), mysql, oracle or mssql. whoami lists the workspace's databases with their dialect.

The answer is compact: a summary and, for every statement that is not ALLOWED, its line, status, rule, severity and suggested fix. With verbose: true it returns the full CLI result.

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

The ruleset_version in the answer changes only when a workspace rule changes. While it matches the one from whoami, an earlier verdict still holds.

Every call is recorded in the workspace's check history (Dashboard → SQL checks, or list_reports), with an excerpt of up to 100 characters of each statement.

Quota and limits

The monthly quota is shared between the CLI and MCP. The read-only tools do not use it.

There is also a per-API-key rate limit on every plan: 30 check_sql calls per minute and 300 per hour, and 60 per minute for the read-only tools. When exceeded, the tool answers with how many seconds to wait.

Security

• The API key determines the workspace. The agent cannot pick or see another one.
• A key with only ci_dryrun:execute cannot read the audit trail or change rules: whoever gets it can, at most, spend your check quota.
• Vericto only analyzes the SQL text. It does not connect to your database or run anything.
• Revoke the key in Dashboard → API Keys and the agent loses access immediately.

Troubleshooting

See also

• Guide
• API Keys
• AST rules reference