What can you do with this server?

Summary: This MCP server exposes 7 read-only SQL analysis tools — validate, parse, format, lint, extract metadata, security scan, and a composite analyze — for SQL sent by the client, with no dialect execution or data access. * analyze_sql — runs all 6 analysis tools concurrently and returns one composite report (validate, parse, metadata, security, lint, format). * validate_sql — checks syntax, returning {valid, error?, dialect?}; dialect can be generic, mysql, postgresql, sqlite, sqlserver, oracle, or snowflake. * parse_sql — parses SQL and returns an AST summary (statement count and types). * format_sql — pretty-prints SQL with configurable indent size, keyword uppercasing, and optional trailing semicolon. * lint_sql — checks SQL against the GoSQLX style rules (L001–L010, per the schema). * security_scan — flags injection patterns such as tautologies, UNION attacks, stacked queries, and comment bypasses. * extract_metadata — lists tables, columns, and functions referenced in a query. * Safe to call freely — every tool is annotated read-only, idempotent, non-destructive, and closed-world, and each takes sql as its only required input.

Which integrations are available for this server?

Enables parsing, formatting, validation, and analysis of MySQL SQL queries, providing tools for linting, metadata extraction, and identifying potential security vulnerabilities. Enables parsing, formatting, validation, and analysis of PostgreSQL SQL queries, providing tools for linting, metadata extraction, and identifying potential security vulnerabilities. Enables parsing, formatting, validation, and analysis of Snowflake SQL queries, providing tools for linting, metadata extraction, and identifying potential security vulnerabilities. Enables parsing, formatting, validation, and analysis of SQLite SQL queries, providing tools for linting, metadata extraction, and identifying potential security vulnerabilities.

de en es ja ko ru zh

GoSQLX

by ajitpratap0

Overview Schema Source Related Servers Discussions Admin

Remote

GoSQLX

Pure-Go SQL parser, formatter, linter and security scanner for 8 dialects.

Go Reference Release License OpenSSF Scorecard

Playground  ·  Docs  ·  Benchmarks  ·  VS Code  ·  MCP server

~2.9M parses/sec†

349 ns parse latency†

~80–85% SQL-99 (est.)

8 dialects

0 race conditions

† Parse stage only (pre-tokenized input to AST), SELECT id, name FROM users, Apple M4, Go 1.27, median of 20 runs of BenchmarkPerformanceBaseline. Complex queries take longer (see performance_baselines.json). Reproduce: go test -run ^$ -bench BenchmarkPerformanceBaseline -benchmem -count=20 ./pkg/sql/parser/.

What is GoSQLX?

GoSQLX is a production-ready SQL parsing SDK for Go. It tokenizes, parses, and generates ASTs from SQL with zero-copy optimizations and intelligent object pooling - parsing a simple SELECT in about 349 ns (~2.9M parses/sec).

Why GoSQLX?

Not an ORM - a parser. You get the AST, you decide what to do with it.
Not slow - zero-copy tokenization, sync.Pool recycling, no allocations on hot paths.
Not limited - PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, SQLite, Snowflake, ClickHouse. CTEs, window functions, MERGE, set operations.
Not just a library - CLI, VS Code extension, GitHub Action, MCP server, WASM playground, Python bindings.

Related MCP server: mcp-server-duckdb

Install

Go library

go get github.com/ajitpratap0/GoSQLX

CLI

go install github.com/ajitpratap0/GoSQLX/cmd/gosqlx@latest

VS Code

code --install-extension ajitpratap0.gosqlx

The extension bundles the binary, so there is no extra setup. Learn more.

MCP server

claude mcp add --transport http gosqlx https://mcp.gosqlx.dev/mcp

7 SQL tools in Claude, Cursor, or any MCP client. MCP guide.

Claude Code plugin (skills, slash commands, SQL reviewer agent): /plugin marketplace add ajitpratap0/GoSQLX then /plugin install gosqlx@gosqlx - details.

ChatGPT app: add https://mcp.gosqlx.dev/mcp as a connector in developer mode for an interactive analysis widget - details.

MCP Glama MCP Server

GitHub Action

- uses: ajitpratap0/GoSQLX@v1
  with:
    files: '**/*.sql'
    validate: true

Quick start

Source: examples/readme_quickstart/main.go, compiled in CI against HEAD and the latest release.

package main

import (
	"context"
	"errors"
	"fmt"
	"log"

	"github.com/ajitpratap0/GoSQLX/pkg/gosqlx"
	"github.com/ajitpratap0/GoSQLX/pkg/sql/ast"
)

func main() {
	ctx := context.Background()

	// ParseTree is the recommended entry point. It returns an
	// opaque handle with built-in helpers.
	tree, err := gosqlx.ParseTree(ctx, "SELECT id, name FROM users WHERE active = true",
		gosqlx.WithDialect("postgresql"))
	if err != nil {
		// Sentinel errors work with errors.Is
		if errors.Is(err, gosqlx.ErrSyntax) {
			log.Fatalf("syntax error: %v", err)
		}
		log.Fatal(err)
	}
	fmt.Println("Tables:", tree.Tables())
	fmt.Println(tree.Format(gosqlx.WithIndent(2), gosqlx.WithUppercaseKeywords(true)))

	// Walk the AST - typed walkers avoid the type-assertion dance:
	tree.WalkSelects(func(s *ast.SelectStatement) bool {
		fmt.Printf("  SELECT with %d columns\n", len(s.Columns))
		return true
	})

	// The legacy Parse/Format/Validate API still works for v1.x code.
	// See docs/MIGRATION.md for the Tree migration guide.
}

Output:

Tables: [users]
SELECT id, name
FROM users
WHERE active = true
  SELECT with 2 columns

Formatting turns one-line SQL into a readable query:

Features

Parser - zero-copy tokenizer, recursive descent parser and full AST generation.
Analysis - SQL injection scanner, 30 lint rules (L001-L030), 20 optimizer rules and metadata extraction.
Tooling - AST-based formatter, query transforms API, VS Code extension and GitHub Action.
Syntax highlighting - dialect-aware highlighting for terminals (ANSI), HTML/CSS, JSON spans, LSP semantic tokens and WASM; gosqlx highlight query.sql or gosqlx.HighlightANSI(sql).
Multi-dialect - 8 dialects with dedicated grammar support: PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, SQLite, Snowflake, ClickHouse. The --dialect flag and WithDialect accept 11 names: those 8 (postgresql, mysql, mariadb, sqlserver, oracle, sqlite, snowflake, clickhouse) plus generic, bigquery and redshift. BigQuery and Redshift have no dialect-specific keyword set (they use the generic keywords) and only capability-gated grammar, such as BigQuery's QUALIFY, PIVOT/UNPIVOT, UNNEST in FROM and (struct).field access.
AI-ready - MCP server with 7 tools, public remote endpoint, Streamable HTTP.
Tested - race-detector clean in CI, ~80-85% SQL-99 (estimated).

Documentation

Getting Started - parse your first SQL in 5 minutes
Usage Guide - comprehensive patterns and examples
API Reference - complete API documentation
CLI Guide - command-line tool reference
SQL Compatibility - dialect support matrix
MCP Guide - AI assistant integration
Architecture - system design deep-dive
Benchmarks - performance data and methodology
Changelog - what changed in each version

Contributing

GoSQLX is built by contributors like you. Whether it's a bug fix, new feature, documentation improvement, or just a typo - every contribution matters.

git clone https://github.com/ajitpratap0/GoSQLX.git && cd GoSQLX
task check    # fmt → vet → lint → test (with race detection)

Fork & branch from main
Write tests - we use TDD and require race-free code
Run task check - must pass before PR
Open a PR - we review within 24 hours

Contributing Guide · Code of Conduct · Governance

Community

Questions or ideas: Discussions. Found a bug or want a feature: Issues.

License

Apache License 2.0 - see LICENSE for details.

gosqlx.dev · Playground · Docs · MCP Server · VS Code

Available Tools

7 tools

analyze_sqlA

Read-onlyIdempotent

Inspect

Use this when the user wants a complete review of a SQL query. Runs validate, parse, metadata, security, lint, and format concurrently and returns one composite report; hosts that support MCP Apps render it as an interactive report.

Name	Required	Description	Default
`sql`	Yes	The SQL string to analyze

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish the read-only, idempotent, non-destructive profile, so the bar is lower, but the description adds real value: the six analyses run concurrently and results are merged into a single composite report. The MCP Apps interactive-rendering note is useful host-dependent behavior. It does not mention latency/cost of fanning out six analyses, so not a 5.

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?

Two sentences, zero waste: the usage trigger is front-loaded, followed by the mechanical behavior. No restatement of the tool name or filler.

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

Completeness4/5

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

With no output schema, the description carries the burden of describing returns, and 'one composite report' plus the list of constituent analyses covers that adequately. The only gap is the report's internal structure, which is implied but not specified.

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

Parameters3/5

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

Single parameter with 100% schema description coverage, so the schema already documents 'sql' fully. The description adds no syntax, dialect, or size guidance beyond what the schema provides; baseline 3 is correct.

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 ('complete review of a SQL query') and enumerates exactly which six sibling capabilities it composes (validate, parse, metadata, security, lint, format). An agent can instantly tell this apart from the single-purpose siblings without opening any schema.

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

Usage Guidelines4/5

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

'Use this when the user wants a complete review' gives a clear triggering condition, and the enumeration of the six sub-analyses implicitly signals that the individual sibling tools exist for narrower needs. It stops short of explicitly saying when to prefer validate_sql or lint_sql alone, so no true exclusion guidance.

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

extract_metadataA

Read-onlyIdempotent

Inspect

Use this when the user wants the tables, columns, and functions a SQL query references (e.g. for lineage or impact analysis). Returns {tables, columns, functions}.

Name	Required	Description	Default
`sql`	Yes	The SQL string to analyze

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the return contract {tables, columns, functions}, which is the only place the agent learns output shape since there is no output schema. It does not say what happens with unparseable or dialect-specific SQL.

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?

Two sentences, zero filler: the trigger condition comes first and the return shape second. Nothing is repeated from the schema or annotations.

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

Completeness4/5

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

For a one-parameter, read-only, idempotent extraction tool this is nearly sufficient: usage trigger, output keys, and a fully documented parameter. The only missing element is failure behavior for invalid SQL, which is minor given the low complexity and full annotation coverage.

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

Parameters3/5

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

Schema description coverage is 100%, so the single "sql" parameter is already fully documented as "The SQL string to analyze." The description adds no syntax, dialect, or size guidance beyond that, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource: it extracts the tables, columns, and functions a SQL query references. The output-key enumeration makes it distinguishable from siblings like format_sql or lint_sql, though it never explicitly contrasts itself with parse_sql or analyze_sql, which could sound similar to an agent.

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

Usage Guidelines4/5

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

"Use this when the user wants ... (e.g. for lineage or impact analysis)" gives a clear triggering condition plus concrete scenarios. It does not, however, name an alternative tool or state when NOT to use this one versus parse_sql/analyze_sql.

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

format_sqlA

Read-onlyIdempotent

Inspect

Use this when the user wants SQL pretty-printed or reformatted: one clause per line, optional upper-case keywords and trailing semicolon. Comments are not kept. Returns {formatted_sql, options}.

Name	Required	Description
`sql`	Yes	The SQL string to format
`indent_size`	No	Spaces per indent level for nested blocks such as CREATE TABLE columns; clauses always start at column 0. 0 puts each statement on one line (default: 2)
`add_semicolon`	No	Append a trailing semicolon (default: false)
`uppercase_keywords`	No	true upper-cases all SQL keywords (AND, IN, CASE, ...), but not data type names. false keeps the formatter's casing: clause keywords (SELECT, FROM, WHERE, ...) upper-case, other keywords (e.g. and, or) may keep their input case (default: false)

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered; the description adds genuinely new behavior in 'Comments are not kept' and the return shape {formatted_sql, options}, which no structured field supplies. It omits what happens on malformed SQL input.

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?

Two sentences, front-loaded with the trigger, then the observable behaviors and return shape. No filler, and the useful return-value note is included despite the absence of an output schema.

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

Completeness4/5

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

With no output schema, the description compensates by naming the returned object; parameters are covered by a 100%-coverage schema. The only notable gap is error/edge-case behavior (e.g., invalid SQL or comment-only input).

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

Parameters3/5

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

Schema description coverage is 100%, so all four parameters are already fully documented in the schema; the description's restatement of the upper-case and semicolon options adds little syntax or format detail beyond that baseline.

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

Purpose4/5

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

States a specific verb+resource (reformat/pretty-print SQL) and characterizes the transformation (one clause per line, optional upper-case keywords, trailing semicolon), which separates it from parse/lint/validate siblings without naming them explicitly.

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

Usage Guidelines4/5

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

Gives a clear trigger condition ('Use this when the user wants SQL pretty-printed or reformatted'), but does not explicitly exclude alternatives such as lint_sql or analyze_sql, leaving the routing decision partly to inference.

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

lint_sqlA

Read-onlyIdempotent

Inspect

Use this when the user wants SQL style feedback. Applies the same 10 rules as gosqlx lint: L001 trailing whitespace, L002 mixed indentation, L003 consecutive blank lines, L004 indentation depth, L005 line length (>100), L006 column alignment, L007 keyword case (upper), L008 comma placement (trailing), L009 aliasing consistency, L010 redundant whitespace. Returns {violation_count, violations}.

Name	Required	Description	Default
`sql`	Yes	The SQL string to lint

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds value by enumerating the exact rule set applied and by specifying the return shape '{violation_count, violations}', which is otherwise undocumented since no output schema exists.

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 usage trigger, followed by scope (the rule set) and then the return contract in a compact form. The L001-L010 enumeration is long but each entry is terse and genuinely informative, so it earns its space.

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

Completeness4/5

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

For a single-input, read-only lint tool with no output schema, the description supplies the missing return shape and the rule scope, which is most of what an agent needs. It omits only minor items such as SQL dialect handling and output ordering.

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

Parameters3/5

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

Schema description coverage is 100% for the single `sql` parameter, so the schema already carries the semantics and the baseline is 3. The description adds no syntax, size, or dialect constraints beyond what the schema states.

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 operation (SQL style linting) with an explicit rule inventory (L001-L010) and scoping to the `gosqlx lint` rule set. This clearly separates it from siblings like validate_sql (correctness), security_scan (vulnerabilities), and format_sql (mutation of the SQL), so an agent can route without opening schemas.

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

Usage Guidelines4/5

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

Opens with a clear trigger condition, 'Use this when the user wants SQL style feedback,' which is a genuine when-to-use statement. It does not, however, explicitly name the alternatives (format_sql/validate_sql) or state when not to use it, so the agent must infer the boundary from the sibling names.

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

parse_sqlA

Read-onlyIdempotent

Inspect

Use this when the user wants to know how SQL parses: returns an AST summary with the statement count and the type of each statement.

Name	Required	Description	Default
`sql`	Yes	The SQL string to parse

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. Beyond that, the description discloses the return shape (AST summary, statement count, per-statement types), which matters because there is no output schema. It omits parse-failure behavior, which keeps it short of a 5.

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?

A single sentence with the usage trigger front-loaded and the return content following immediately; nothing is wasted. The phrasing 'how SQL parses' is slightly circular, but the sentence earns its place.

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

Completeness4/5

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

For a one-parameter, read-only tool with annotations covering the safety profile, the description supplies enough: the trigger to use it and the shape of what comes back. Only error/edge behavior on unparseable input is left unspecified.

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

Parameters3/5

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

There is one parameter, 'sql', and schema description coverage is 100%, so the schema already documents it fully. The description adds no syntax, dialect, or multi-statement guidance beyond what the schema provides, so the baseline 3 applies.

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

Purpose4/5

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

The description states a specific verb (parse) and resource (SQL) and goes further by naming the output payload: an AST summary with statement count and statement types. It does not, however, distinguish itself from the close sibling analyze_sql, leaving an agent to infer the boundary.

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

Usage Guidelines3/5

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

'Use this when the user wants to know how SQL parses' is a usage trigger, but it essentially restates the purpose rather than defining when this tool beats analyze_sql, validate_sql, or lint_sql. No exclusions or alternatives are named.

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

security_scanA

Read-onlyIdempotent

Inspect

Use this when the user wants SQL checked for injection patterns: tautologies, UNION attacks, stacked queries, comment bypasses, and more. Returns findings with severity counts.

Name	Required	Description	Default
`sql`	Yes	The SQL string to scan

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by naming the detection categories and stating the response shape (findings with severity counts), which 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?

Two tight sentences, with the use condition front-loaded and the return summary appended. 'and more' is mildly vague filler, but overall nothing is wasted.

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

Completeness4/5

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

For a single-parameter, read-only, closed-world scan with full annotation coverage and a stated return summary, the description is nearly complete. The only gap is the absence of any dialect/input-size caveat or a note on how it differs from the lint/validate siblings.

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

Parameters3/5

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

Only one parameter and schema description coverage is 100%, so the schema fully documents 'sql'. The description adds no syntax, size, or dialect constraints (e.g. whether multi-statement input is allowed), leaving the baseline 3 appropriate.

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

Purpose4/5

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

States a specific verb+resource ('SQL checked for injection patterns') and enumerates the detection classes (tautologies, UNION attacks, stacked queries, comment bypasses). It is clearly distinct from format_sql/parse_sql, though it doesn't explicitly draw the boundary against the closest siblings lint_sql, validate_sql, and analyze_sql.

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

Usage Guidelines4/5

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

'Use this when the user wants SQL checked for injection patterns' gives a concrete trigger condition tied to user intent. It offers no when-not guidance and never names the adjacent siblings (validate_sql, lint_sql), so an agent must infer that security scanning is separate from correctness linting.

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

validate_sqlA

Read-onlyIdempotent

Inspect

Use this when the user wants to know whether a SQL statement is syntactically valid, optionally for a specific dialect. Returns {valid: bool, error?: string, dialect?: string}.

Name	Required	Description	Default
`sql`	Yes	The SQL string to validate
`dialect`	No	SQL dialect: generic, postgresql, mysql, mariadb, sqlserver, oracle, sqlite, snowflake, bigquery, redshift, clickhouse

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description goes further by disclosing the return shape {valid, error?, dialect?}, which is genuinely useful behavioral context given there is no output schema.

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?

Two tight sentences: the usage condition comes first and the return contract second, with no filler or repetition. Every clause earns its place.

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

Completeness4/5

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

For a two-parameter read-only tool with no output schema, the description supplies the missing piece: the response structure and its optional fields. Nothing essential for correct invocation is absent, though a note on how invalid SQL is reported (vs. an error thrown) would close the last gap.

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

Parameters3/5

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

Schema description coverage is 100% and the enum for dialect is fully enumerated in the schema, so the parameters are already documented. The description only echoes that the dialect is optional ('optionally for a specific dialect'), adding no syntax or format detail beyond the schema. Baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource ('validate' a 'SQL statement') plus the scoping detail 'syntactically valid' and optional dialect targeting. It clearly differs in intent from siblings like format_sql or parse_sql, though it never names an alternative to sharpen the boundary.

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

Usage Guidelines4/5

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

Gives an explicit trigger: 'Use this when the user wants to know whether a SQL statement is syntactically valid.' This is a clear context for invocation. It stops short of exclusions or naming the neighboring tools (lint_sql, parse_sql) that an agent might otherwise confuse it with.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv1.16.1Oct 22, 2026

Changedformat_sql2 fields changed

changedInput schema / properties / indent_size / description

Previous value: -"Spaces per indent level (default: 2)"New value: +"Spaces per indent level for nested blocks such as CREATE TABLE columns; clauses always start at column 0. 0 puts each statement on one line (default: 2)"

changedInput schema / properties / uppercase_keywords / description

Previous value: -"Uppercase SQL keywords (default: false)"New value: +"true upper-cases all SQL keywords (AND, IN, CASE, ...), but not data type names. false keeps the formatter's casing: clause keywords (SELECT, FROM, WHERE, ...) upper-case, other keywords (e.g. and, or) may keep their input case (default: false)"

Changedvalidate_sql2 fields changed

changedInput schema / properties / dialect / description

Previous value: -"SQL dialect: generic, mysql, postgresql, sqlite, sqlserver, oracle, snowflake"New value: +"SQL dialect: generic, postgresql, mysql, mariadb, sqlserver, oracle, sqlite, snowflake, bigquery, redshift, clickhouse"

changedInput schema / properties / dialect / enum

Previous value: -[
-  "generic",
-  "mysql",
-  "postgresql",
-  "sqlite",
-  "sqlserver",
-  "oracle",
-  "snowflake"
-]New value: +[
+  "generic",
+  "postgresql",
+  "mysql",
+  "mariadb",
+  "sqlserver",
+  "oracle",
+  "sqlite",
+  "snowflake",
+  "bigquery",
+  "redshift",
+  "clickhouse"
+]

7 tool updatesv1.12.1Mar 17, 2026
- First observedanalyze_sql
- First observedextract_metadata
- First observedformat_sql
- First observedlint_sql
- First observedparse_sql
- First observedsecurity_scan
- First observedvalidate_sql

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4/5.0

Scored 2026-10-23 10:10 across 7 tools

Disambiguation4/5

Each tool targets a distinct SQL analysis concern such as linting, security scanning, validation, parsing, metadata extraction, and formatting. analyze_sql is a composite that overlaps all of them, but its description makes the aggregate role clear, so misselection risk is low.

Naming Consistency4/5

All names are snake_case and mostly follow an action_sql or action_object pattern: lint_sql, validate_sql, parse_sql, format_sql, analyze_sql, extract_metadata. security_scan is the one deviation, naming the concern before the action, but it remains readable and consistent enough.

Tool Count5/5

Seven tools fit the scope of a SQL quality toolkit; each covers a distinct operation, and the composite analyze_sql provides a convenient aggregate. There are no filler tools.

Completeness4/5

The surface covers validation, parsing, linting, security scanning, metadata extraction, formatting, and a combined review, which is strong domain coverage. A minor gap is the lack of a dedicated auto-fix or remediation tool for lint/format findings, though agents can work around it.

Maintenance

ActivityMaintained

ResponsivenessResponsive

Resources

Related MCP Connectors

AI2SQLOAuth
io.ai2sql
Text-to-SQL MCP server: read-only queries on PostgreSQL, MySQL and SQL Server with your real schema
Databases Developer Tools
1
https://builder.ai2sql.io/api/chatgpt-mcp
sixta-connect AOAuth
ai.sixta
DBRE-grade SQL analysis inside any MCP client. No connection. No install. Paste a query.
Databases Code Analysis
132
https://connect.sixta.ai/mcp
DevOps & Cloud Code Auditor
io.github.Ansarii
Detects database migration table locks, terraform cost leaks, and OWASP API flaws.
Cloud Platforms Code Analysis Security
1
https://neon_innovation_lab--devops-code-auditor.apify.actor/mcp
Frogeye Security Scanner A
io.github.frogeye-ai
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security Penetration Testing
2
https://mcp.frogeye.ai/mcp

Related MCP Servers

MySQL MCP Server
Databases Developer Tools
designcomputer
A
license
A
quality
B
maintenance
Allows AI assistants to list tables, read data, and execute SQL queries through a controlled interface, making database exploration and analysis safer and more structured.
Updated 3 months ago (2026-08-02 13:36 UTC)
3
24,187 PyPI
1,403
MIT
mcp-server-duckdb
Databases Developer Tools
ktanaka101
A
license
Not graded
quality
C
maintenance
A Model Context Protocol (MCP) server implementation for DuckDB, providing database interaction capabilities through MCP tools. It would be interesting to have LLM analyze it. DuckDB is suitable for local analysis.
Updated a year ago (2025-05-05 11:02 UTC)
6,300 PyPI
179
MIT
mcp-clickhouseofficial
Databases Developer Tools
ClickHouse
A
license
A
quality
A
maintenance
ClickHouse database integration with schema inspection and query capabilities
Updated 5 days ago (2026-10-27 19:10 UTC)
3
899
Apache 2.0
mysql_mcp_server
Databases Developer Tools
wenb1n-dev
A
license
B
quality
C
maintenance
Added support for STDIO mode and SSE mode Added support for multiple SQL execution, separated by ";" Added ability to query database table names and fields based on table comments Added SQL Execution Plan Analysis Added Chinese field to pinyin conversion
Updated a year ago (2025-08-28 13:50 UTC)
5
57 PyPI
250
MIT

Appeared in Searches

A search for a string containing SQL injection and XSS payload characters

GoSQLX

What is GoSQLX?

Why GoSQLX?

Install

Go library

CLI

VS Code

MCP server

GitHub Action

Quick start

Features

Documentation

Contributing

Community

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

mcp-clickhouseofficial

Appeared in Searches