Format and normalize SQL across 19 dialects (PostgreSQL, MySQL, BigQuery, Snowflake, Spark, etc.) via @mukundakatta/sqlfmt-mcp

@mukundakatta/sqlfmt-mcp v latest — verified recipe

Install & run: npm install @mukundakatta/sqlfmt-mcp @modelcontextprotocol/sdk, then connect via StdioClientTransport to node node_modules/@mukundakatta/sqlfmt-mcp/src/index.js.

Tools (2)

19 supported dialects

sql, bigquery, db2, db2i, duckdb, hive, mariadb, mysql, n1ql, plsql, postgresql, redshift, singlestoredb, snowflake, spark, sqlite, tidb, transactsql, trino

Key findings from 12 calls

1. Dialect-aware: each dialect handles its own syntax (BigQuery backtick-quoted tables, Spark EXPLODE, Snowflake CTEs, T-SQL PARTITION BY, MySQL INTERVAL, SQLite AUTOINCREMENT).
2. All SQL statement types work: SELECT, INSERT...SELECT, UPDATE...CASE, CREATE TABLE, CTEs (WITH), window functions (ROW_NUMBER, AVG OVER), JOINs (INNER/LEFT).
3. Keyword case control: upper (default) uppercases keywords; lower lowercases them; preserve keeps original. Only SQL keywords are affected — identifiers stay untouched.
4. Indentation: tab_width: 4 correctly widens indent. use_tabs available but not tested.
5. Return format: always {formatted, dialect, line_count} — formatted string uses \n newlines.
6. Performance: first call ~61ms, complex queries 100-540ms, simple queries ~120ms. CTE + window function queries are slowest.
7. No validation: the formatter does not reject invalid SQL — it formats whatever you give it. Syntax errors may produce unexpected formatting rather than errors.

Gotchas

• Default dialect is "sql" (ANSI) — always specify dialect for non-trivial queries to get correct formatting
• Window function OVER() clauses get their own indentation block with inner ORDER BY/PARTITION BY
• BigQuery backtick-quoted table names (` project.dataset.table `) are preserved correctly
• line_count in response tells you how many lines the formatted output spans
• The formatter uppercases TRUE/FALSE as keywords by default