Vericto: database guardrails for AI agents

Check SQL

check_sql

Evaluate SQL against this workspace's rules before it runs. Pass a whole script (e.g. a migration file) as sql and the server splits it into statements, reporting each with the line it starts on. Or pass pre-split queries. Each statement evaluated costs one check from the monthly allowance; a call that needs more checks than remain is rejected whole. Returns a compact verdict: findings for every statement that is not ALLOWED, each with its rule code and a suggested fix, and next_steps: what to do next for each statement (run it, run the approved_query, apply the fix and check again, or stop and ask the user). Follow next_steps instead of rephrasing a blocked statement and checking it again.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_sql"
  }
}

Input Schema

Name	Required	Description
`sql`	No	A whole SQL script. Split server-side; costs one check per statement. Use this OR queries.
`ticket`	No	The change ticket this SQL runs under (e.g. OPS-123). Declared, not verified; recorded with the check.
`dialect`	No	Dialect of the database the SQL targets. Defaults to postgres — pass it explicitly; whoami lists this workspace's databases and their dialects. Common aliases (postgresql, pg, mariadb, sqlserver…) are accepted and reported as the canonical id.
`queries`	No	Pre-split statements; costs one check each. Use this OR sql.
`verbose`	No	Return the full CLI-compatible result (every query, latencies) instead of the compact verdict.
`file_name`	No	Source file, shown in the report history.
`database_id`	No	The database the SQL targets (whoami lists them). Its sensitive-column tags apply; without it, every database tag in the workspace does. This key's agent access policy on that database applies too; required when the key has policies on several databases.

Output Schema

Name	Required	Description
`passed`	Yes
`dialect`	Yes
`summary`	Yes
`findings`	Yes
`report_id`	No	/mcp/account: the stored report (show_report).
`next_steps`	Yes	What to do next, by statement line: which tool to call, or that no call will help. Follow it instead of retrying.
`kill_switch`	No
`next_action`	Yes	The most important next step: the first of next_steps.
`evaluated_as`	Yes
`ruleset_version`	Yes
`ci_checks_remaining`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 2, 2026

changedInput schema / properties / dialect / description

Previous value: -"Dialect of the database the SQL targets. Defaults to postgres — pass it explicitly; whoami lists this workspace's databases and their dialects."New value: +"Dialect of the database the SQL targets. Defaults to postgres — pass it explicitly; whoami lists this workspace's databases and their dialects. Common aliases (postgresql, pg, mariadb, sqlserver…) are accepted and reported as the canonical id."

changedInput schema / properties / dialect / enum

Previous value: -[
-  "postgres",
-  "mysql",
-  "oracle",
-  "mssql",
-  "snowflake",
-  "sqlite"
-]New value: +[
+  "postgres",
+  "mysql",
+  "oracle",
+  "mssql",
+  "snowflake",
+  "sqlite",
+  "postgresql",
+  "pg",
+  "psql",
+  "pgsql",
+  "mariadb",
+  "sqlserver",
+  "sql_server",
+  "sql-server",
+  "tsql",
+  "sqlite3"
+]

changedOutput schema / properties / findings / items / properties / next_action / enum

Previous value: -[
-  "stop",
-  "request_access",
-  "do_not_run",
-  "apply_fix_and_recheck",
-  "fix_and_recheck",
-  "run_approved_query",
-  "mention_to_user",
-  "run_as_written"
-]New value: +[
+  "stop",
+  "request_access",
+  "do_not_run",
+  "apply_fix_and_recheck",
+  "fix_and_recheck",
+  "run_approved_query",
+  "mention_to_user",
+  "run_as_written",
+  "done",
+  "refine_query",
+  "request_write_access",
+  "await_approval",
+  "request_new_approval",
+  "fix_sql_error",
+  "retry_later"
+]

changedOutput schema / properties / next_action / enum

Previous value: -[
-  "stop",
-  "request_access",
-  "do_not_run",
-  "apply_fix_and_recheck",
-  "fix_and_recheck",
-  "run_approved_query",
-  "mention_to_user",
-  "run_as_written"
-]New value: +[
+  "stop",
+  "request_access",
+  "do_not_run",
+  "apply_fix_and_recheck",
+  "fix_and_recheck",
+  "run_approved_query",
+  "mention_to_user",
+  "run_as_written",
+  "done",
+  "refine_query",
+  "request_write_access",
+  "await_approval",
+  "request_new_approval",
+  "fix_sql_error",
+  "retry_later"
+]

changedOutput schema / properties / next_steps / items / properties / action / enum

Previous value: -[
-  "stop",
-  "request_access",
-  "do_not_run",
-  "apply_fix_and_recheck",
-  "fix_and_recheck",
-  "run_approved_query",
-  "mention_to_user",
-  "run_as_written"
-]New value: +[
+  "stop",
+  "request_access",
+  "do_not_run",
+  "apply_fix_and_recheck",
+  "fix_and_recheck",
+  "run_approved_query",
+  "mention_to_user",
+  "run_as_written",
+  "done",
+  "refine_query",
+  "request_write_access",
+  "await_approval",
+  "request_new_approval",
+  "fix_sql_error",
+  "retry_later"
+]

First observedNov 1, 2026

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing the quota model ('Each statement evaluated costs one check from the monthly allowance') and the all-or-nothing rejection when allowance is short — critical cost behavior an agent cannot infer. It also explains the compact verdict and next_steps semantics. It stops short of stating latency/retry behavior, so not a 5, but the annotation-covered safety profile plus this added cost context is strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the action and the pre-execution timing, then the two input modes, then cost, then return shape, then the follow-up rule — a logical decision order with no filler sentences. Dense but every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with an output schema, the description covers the non-obvious pieces: cost accounting, rejection semantics, verdict shape, and how to act on next_steps. Return values needn't be enumerated since the output schema exists, and nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3; the description adds real value by stating the sql/queries mutual exclusivity and the per-statement cost implied by each mode, plus that line numbers are reported per statement. The verbose toggle is left entirely to the schema, so it doesn't fully subsume the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Evaluate SQL against this workspace's rules') plus the timing constraint ('before it runs'), which no sibling tool does. An agent can immediately distinguish this evaluation tool from the inspection siblings (list_rules, show_report, whoami).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes between the two input modes ('Pass a whole script... Or pass pre-split queries') and names whoami as the way to discover dialects/databases. It also gives a negative instruction — 'Follow next_steps instead of rephrasing a blocked statement and checking it again' — which prevents a specific wrong behavior rather than leaving usage to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Vericto: database guardrails for AI agents tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?