MCP SQL verification for AI agents
Every model can write SQL; none can know its SQL is correct. Verification requires execution, and execution is exactly what a language model cannot do internally — so it's a tool call. This page IS the tool (browser edition); the same engine runs as a paid MCP server.
press RUN (or Ctrl+Enter) — everything executes in your browser, nothing is uploaded
What the server does
Five tools, one engine: run_sql (execute, get rows), validate_sql
(parse+bind without executing), explain_plan (query plan + full-scan warnings),
run_sql_batch (up to 10 isolated runs), and diff_results (are two
queries' result sets equal — the refactor self-check). Each call builds a fresh in-memory SQLite
from the agent's DDL, executes, returns strict JSON, and destroys the sandbox. Errors are a
stable taxonomy (unknown_column, syntax, type_mismatch, …)
with positions and rule-based suggestions, so agents branch on error.type and
self-correct in one round trip.
Payment: x402, no accounts
The server speaks x402: 20 free
calls per day per client, then HTTP 402 with payment requirements; agents holding a wallet pay
fractions of a cent per call (prices on the homepage) and retry with an
X-PAYMENT header. No API keys, no signup, no subscription. A failed query after
payment is a delivered product — the error is the answer your agent needed.
Add it to your agent
{ "mcpServers": { "sql-verifier": { "type": "http", "url": "https://mcp.sqlai.dev/mcp" } } }There's also a plain HTTP interface (POST /api/run_sql etc.) documented in the
docs, plus openapi.yaml and
llms.txt for framework auto-discovery.
FAQ
Why can't the LLM just check its own SQL?
Checking requires executing against the actual schema semantics — parsing, binding, constraint evaluation. A model predicts text; it cannot instantiate a database engine internally. This is a capability gap, not a prompting gap.
What engine does the server run?
SQLite 3.49 (WASM) in an ephemeral per-call sandbox. dialect_notes flag constructs that behave differently on Postgres/MySQL/DuckDB. It does not execute native Postgres or MySQL.
Is submitted SQL stored?
No. The sandbox is destroyed after each call and only anonymous per-tool counters are kept. Schemas, queries, and seed data are never persisted.
How do agents pay?
Via x402: the 402 response carries machine-readable payment requirements; x402-capable clients sign a USDC transfer authorization and retry. Free tier first — agents can evaluate before any wallet is involved.
Related: Validate a SQL query against your schema · Do these two queries return the same thing? · Test SQL without a database