sql-query-mcp

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 controlled local CSV/XLSX import into existing tables.

The service keeps those boundaries explicit in a few ways.

• Connections declare engine explicitly, so the server never guesses from

connection_id.

• PostgreSQL uses schema, while MySQL and Hive use database, without

collapsing both into one vague namespace field.

• Real DSNs stay in environment variables, while config files store only the

environment variable names.

• Query execution passes through sqlglot validation before reaching the

database. Use run_select for short bounded read-only queries, and use start_query, get_query, and cancel_query for long-running read-only queries.

• The server accepts only SELECT and WITH ... SELECT, rejects comments and

multi-statement input, and records audit logs for each call.

• export_query_file writes files on the MCP server machine. It is synchronous

but reads database rows and writes CSV/XLSX files in batches. Large exports can still hit your MCP client's tool timeout. For XLSX output, UUID values are written as text and timezone-aware datetime values are written without the timezone. Hive export is not supported yet.

• import_table_file doesn't accept raw SQL. It inserts only file columns whose

headers exactly match existing table columns.

• Hive import_table_file is intended for small files only and rejects files

with more than 1000 data rows. Hive imports write rows one by one, so they can be slow and can hit your MCP client's tool timeout. For bulk Hive loads, use Hive-native LOAD DATA, external tables, or your existing data ingestion pipeline.

For Hive, explain_query uses EXPLAIN and EXPLAIN ANALYZE.

Quick start

sql-query-mcp supports two official PyPI-based setup modes. Both are intended for real usage, not just local testing.

1. Choose how you want your MCP client to start the server.

Use installed command mode if you want a simple local command after one install.

pipx install sql-query-mcp

Use managed launch mode if you want the package source declared directly in your MCP client config.

pipx run --spec sql-query-mcp sql-query-mcp

Pin a version with pipx install 'sql-query-mcp==X.Y.Z' or pipx run --spec 'sql-query-mcp==X.Y.Z' sql-query-mcp. Upgrade installed command mode with pipx upgrade sql-query-mcp.

1. Create a config file.

The server configuration should live outside the repository so the same file works with either startup mode.

mkdir -p ~/.config/sql-query-mcp

Then save the example JSON later in this section as ~/.config/sql-query-mcp/connections.json.

1. Register the server in your MCP client.

• Codex: docs/codex-setup.md (Chinese)
• OpenCode: docs/opencode-setup.md (Chinese)

Installed command mode means your client runs sql-query-mcp directly. Managed launch mode means your client starts the server through pipx run.

In both modes, put SQL_QUERY_MCP_CONFIG and your real database DSNs in the MCP client's environment block instead of exporting them in your shell.

The console entry point is sql-query-mcp, which maps to sql_query_mcp.app:main.

The PyPI install name is sql-query-mcp, and the Python package import path is sql_query_mcp.

For pipx install and pipx run, set SQL_QUERY_MCP_CONFIG explicitly to your config file path. The default config/connections.json path is mainly for source checkouts and local development.

The example config looks like this.

{
  "settings": {
    "default_limit": 200,
    "max_limit": 1000,
    "audit_log_path": "logs/audit.jsonl"
  },
  "connections": [
    {
      "connection_id": "crm_prod_main_ro",
      "engine": "postgres",
      "label": "CRM PostgreSQL production / Main / read-only",
      "env": "prod",
      "tenant": "main",
      "role": "ro",
      "dsn_env": "PG_CONN_CRM_PROD_MAIN_RO",
      "enabled": true,
      "default_schema": "public"
    },
    {
      "connection_id": "crm_mysql_prod_main_ro",
      "engine": "mysql",
      "label": "CRM MySQL production / Main / read-only",
      "env": "prod",
      "tenant": "main",
      "role": "ro",
      "dsn_env": "MYSQL_CONN_CRM_PROD_MAIN_RO",
      "enabled": true,
      "default_database": "crm"
    },
    {
      "connection_id": "warehouse_hive_prod_main_ro",
      "engine": "hive",
      "label": "Warehouse Hive production / Main / read-only",
      "env": "prod",
      "tenant": "main",
      "role": "ro",
      "dsn_env": "HIVE_CONN_WAREHOUSE_PROD_MAIN_RO",
      "enabled": true,
      "default_database": "default"
    }
  ]
}

Set DSNs in the MCP client environment. For Hive, use a Hive DSN such as:

export HIVE_CONN_WAREHOUSE_PROD_MAIN_RO='hive://user:password@hive.example.com:10000/default?auth=CUSTOM'

Documentation

If you want implementation details, setup guidance, or internal structure, use these docs as your starting points.

• docs/project-overview.md: project goals, concepts, and code structure (Chinese)
• docs/api-reference.md: MCP tool reference (Chinese)
• docs/codex-setup.md: Codex setup steps (Chinese)
• docs/opencode-setup.md: OpenCode setup steps (Chinese)
• docs/release-process.md: PyPI and GitHub Release workflow (Chinese)
• docs/git-workflow.md: repository collaboration workflow (Chinese)

Development

If you want to modify or verify the project locally, use this shortest path. Editable install remains the development path, and the local environment still requires Python 3.10+.

python3.10 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
pip install -e .
PYTHONPATH=. python3 -m unittest discover -s tests

The main entry point is sql_query_mcp/app.py. Core modules include:

• sql_query_mcp/config.py: config loading and validation
• sql_query_mcp/validator.py: read-only SQL validation
• sql_query_mcp/introspection.py: metadata inspection
• sql_query_mcp/executor.py: query execution and limits
• sql_query_mcp/adapters/: PostgreSQL, MySQL, and Hive adapters

Contributing

If you want to contribute or review the repository workflow, start with these pages.

• CONTRIBUTING.md
• docs/roadmap.md
• docs/git-workflow.md (Chinese)

Run PYTHONPATH=. python3 -m unittest discover -s tests before you submit changes.

License

This project is released under the MIT License. See LICENSE.