Vericto account (OAuth)

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. Needs the sql:check scope. The report is stored under this connection, as this person.

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.

First observedNov 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), which alone would leave the agent guessing. It discloses that each statement costs one check from a monthly allowance, that an over-budget call is rejected whole rather than partially, that findings carry rule codes and suggested fixes, that next_steps encodes run/fix/stop decisions, and that the report is recorded per connection and per user. That billing, atomicity and side-effect persistence are exactly the traits annotations cannot express.

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

Conciseness4/5

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

Front-loaded with the purpose, then cost, then return shape, then the key behavioral instruction — a sensible ordering. It is dense but nearly every clause carries decision-relevant information; the 'stored under this connection, as this person' clause is slightly abrupt but not wasted.

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, billing-metered evaluation tool with an output schema, the description covers prerequisites (sql:check scope), cost/atomicity, the two input modes, default dialect caveat, and how to act on results. Nothing needed to call it correctly or interpret the verdict is missing, and return-value detail is appropriately left to the output schema.

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 coverage is 100% so the baseline is 3, but the description adds real meaning on top: it explains why a whole script is preferable (migration file, server-side splitting with line numbers) and frames the verdict shape tied to `queries`/`sql` choice. It leaves the verbose/ticket/database_id semantics to the schema, which already handles them well.

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 workspace rules before it runs — and distinguishes itself from siblings (explain_block, show_report, list_rules) by being the pre-execution evaluator. A reader knows exactly what it does without opening the schema.

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 (whole script as `sql` vs pre-split `queries`), states the cost model and the all-or-nothing rejection rule, and gives a directive behavioral instruction: follow next_steps instead of rephrasing a blocked statement and re-checking. It names the sql:check scope prerequisite, which is what actually gates the call.

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

All Vericto account (OAuth) 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?