andyWang1688/sql-query-mcp

中文版
A general-purpose MCP server that lets AI work with multiple databases within
clear boundaries.
Current database support
| Database | Status | Current availability |
| --- | --- | --- |
| PostgreSQL | Supported | Available today |
| MySQL | Supported | Available today |
| Hive | Supported | Available today |
| SQLite | Candidate | Not supported yet |
| SQL Server | Candidate | Not supported yet |
| ClickHouse | Candidate | Not supported yet |
Product value
sql-query-mcp helps AI clients discover schema, sample data, and analyze
read-only queries through one controlled MCP interface.
It keeps connection handling, namespace rules, SQL validation, and audit
logging on the server side, so you can expose useful database context to AI
without exposing raw connection strings or flattening engine-specific concepts.
What AI can do with it
The current tool set focuses on database discovery, controlled query workflows,
asynchronous read-only queries, batched query result exports, and one narrow
local file import path. You can use it to help an AI assistant understand
structure before it generates SQL, runs a bounded query, starts a long-running
read-only query, exports PostgreSQL or MySQL results to a local file, or imports
a prepared CSV/XLSX file into an existing table.
MySQL and Hive support explain_query. Hive uses EXPLAIN and
EXPLAIN ANALYZE for explain_query.
| Tool | PostgreSQL | MySQL | Hive | Purpose |
| --- | --- | --- | --- | --- |
| list_connections() | Yes | Yes | Yes | List configured connections |
| list_schemas(connection_id) | Yes | No | No | List visible PostgreSQL schemas |
| list_databases(connection_id) | No | Yes | Yes | List visible MySQL or Hive databases |
| list_tables(connection_id, schema?, database?) | Yes | Yes | Yes | List tables and views |
| describe_table(connection_id, table_name, schema?, database?) | Yes | Yes | Yes | Inspect columns, keys, and indexes |
| run_select(connection_id, sql, limit?) | Yes | Yes | Yes | Run short bounded read-only queries |
| start_query(connection_id, sql, limit?) | Yes | Yes | Yes | Start long-running read-only queries |
| get_query(query_id, offset?, limit?) | Yes | Yes | Yes | Fetch async query status and paginated results |
| cancel_query(query_id) | Yes | Yes | Yes | Cancel running async queries |
| explain_query(connection_id, sql, analyze?) | Yes | Yes | Yes | Inspect query plans |
| get_table_sample(connection_id, table_name, schema?, database?, limit?) | Yes | Yes | Yes | Fetch small table samples |
| export_query_file(connection_id, sql, output_path, format?, limit?, export_all?, file_name?, overwrite?) | Yes | Yes | No | Export query results to local CSV/XLSX files |
| import_table_file(connection_id, table_name, file_path, schema?, database?, sheet_name?) | Yes | Yes | Yes | Import local CSV/XLSX files |
These tools are useful for tasks such as listing namespaces, inspecting table
definitions, reviewing indexes, sampling records, running short read-only
queries with run_select, running long read-only queries with start_query,
get_query, and cancel_query, analyzing read-only queries with EXPLAIN, and
exporting PostgreSQL or MySQL query results to local CSV/XLSX files. You can
also import prepared local files. For full request and response details, see
docs/api-reference.md (Chinese).
How boundaries are constrained
The product boundary is intentionally narrow today. PostgreSQL, MySQL, and Hive
are available today. Query tools remain read-only, PostgreSQL and MySQL query
results can be exported to local files, and the only database write path is a