1. Conduid
  2. Data
  3. gigamori/mcp-run-sql-connectorx
MCP server · Data

gigamori/mcp-run-sql-connectorx

An MCP server that executes SQL via ConnectorX and streams (using Arrow RecordBatch) the result to CSV or Parquet. Supports PostgreSQL, MySQL, MariaDB, SQLite, MS SQL Server, Amazon Redshift, Google BigQuery

Unclaimed MIT last commit 12 months ago data
49Fair

Scored 4 months ago · breakdown

About gigamori/mcp-run-sql-connectorx

gigamori/mcp-run-sql-connectorx is an MCP server published by gigamori in the Data category: an MCP server that executes SQL via ConnectorX and streams (using Arrow RecordBatch) the result to CSV or Parquet. Supports PostgreSQL, MySQL, MariaDB, SQLite, MS SQL Server, Amazon Redshift, Google BigQuery. It has been installed 0 times through Conduid.

The repository has 1 stars and 1 forks, with the last commit 12 months ago. Six months or more without a commit doesn't mean the server is broken, but check the open issues (0) before depending on it in production.

Install

Install
npx mcp-run-sql-connectorx

This server has no ConduID identity, so agent calls to it are not receipted. Pin the version you install and review the source before granting it credentials.

Ask AI

Ask AI about gigamori/mcp-run-sql-connectorx

Powered by Claude · Grounded in docs

I know everything about gigamori/mcp-run-sql-connectorx. Ask me about installation, configuration, usage, or troubleshooting.

Security checks

  • ·README presentNot checked yet.
  • ·License declaredNot checked yet.
  • ·Tests presentNot checked yet.
  • ·Dependencies pinnedNot checked yet.
  • ·No dynamic code executionNot checked yet.
  • !Scoped permissionsDoesn't declare a permission scope. Assume it can do anything its process can.

README

run-sql-connectorx

An MCP server that executes SQL via ConnectorX and streams the result to CSV or Parquet in PyArrow RecordBatch chunks.

  • Output formats: csv or parquet
  • CSV: UTF-8, header row is always written
  • Parquet: PyArrow defaults; schema mismatch across batches raises an error
  • Return value: the string "OK" on success, or "Error: <message>" on failure
  • On failure the partially written output file is deleted
  • CSV token counting (optional): per-line token counting via tiktoken (o200k_base) with a warning threshold

Why this library?

  • Efficient streaming: handles large results in Arrow RecordBatch chunks
  • Token-efficient for MCP: exchanges data via files instead of inline payloads
  • Cross-database via ConnectorX: one tool works across many backends
  • Robust I/O: CSV header handling, Parquet schema validation, safe cleanup on errors

Supported data sources (ConnectorX)

ConnectorX supports many databases. Common examples include:

  • PostgreSQL
  • MySQL / MariaDB
  • SQLite
  • Microsoft SQL Server
  • Amazon Redshift
  • Google BigQuery

For the complete and up-to-date list of supported databases and connection-token (conn) formats, see the official docs:

Getting Started

uvx run-sql-connectorx \
  --conn "<connection_token>" \
  --csv-token-threshold 500000

<connection_token> is the connection token (conn) used by ConnectorX—SQLite, PostgreSQL, BigQuery, and more.

CLI options

  • --conn <connection_token> (required): ConnectorX connection token (conn)
  • --csv-token-threshold <int> (default 0): when > 0, enable CSV per-line token counting using tiktoken(o200k_base); the value is a warning threshold

Further reading

Running from mcp.json

To launch the server from an MCP-aware client such as Cursor, add the following snippet to .cursor/mcp.json at the project root:

{
  "mcpServers": {
    "run-sql-connectorx": {
      "command": "uvx",
      "args": [
        "--from", "git+https://github.com/gigamori/mcp-run-sql-connectorx",
        "run-sql-connectorx",
        "--conn", "<connection_token>"
      ]
    }
  }
}

Behaviour and Limits

  • Streaming: Results are streamed from ConnectorX in RecordBatch chunks; the default batch_size is 100 000 rows.
  • Empty result:
    • CSV – an empty file is created
    • Parquet – an empty table is written
  • Error handling: the output file is removed on any exception.
  • CSV token counting (when --csv-token-threshold > 0):
    • Counted text: exactly what csv.writer writes (including header row when present, delimiters, quotes, and newlines), UTF-8
    • Streaming approach: tokenized with tiktoken(o200k_base) per written CSV line

Call output

The tool returns a single text message.

  • On success:
    • Parquet: OK
    • CSV:
      • If --csv-token-threshold = 0: OK
      • If --csv-token-threshold > 0: OK N tokens (or OK N tokens. Too many tokens may impair processing. Handle appropriately when N >= threshold)
      • Empty result with counting enabled: OK 0 tokens
  • On failure: Error: <message> (any partial output file is deleted)

MCP Tool Specification

The server exposes a single MCP tool run_sql.

Argument Type Required Description
sql_file string yes Path to a file that contains the SQL text to execute
output_path string yes Destination file for the query result
output_format enum yes One of "csv" or "parquet"
batch_size int no RecordBatch size (default 100000)

Example Call

{
  "tool": "run_sql",
  "arguments": {
    "sql_file": "sql/queries/sales.sql",
    "output_path": "output/sales.parquet",
    "output_format": "parquet",
    "batch_size": 200000
  }
}

License

Distributed under the MIT License. See LICENSE for details.

README mirrored from the source repository 4 months ago. The original is authoritative.

Questions

About gigamori/mcp-run-sql-connectorx

How do I install gigamori/mcp-run-sql-connectorx?

Run npx mcp-run-sql-connectorx, then add the server to your MCP client's configuration. Conduid has recorded 0 installs, so the command is known to work with current clients.

Is gigamori/mcp-run-sql-connectorx safe to use with an AI agent?

Its trust score is 49 out of 100 (fair). It passes 0 of 1 static security checks; the failures are listed above. It has no ConduID identity yet, so agent calls to it are not receipted.

Is gigamori/mcp-run-sql-connectorx still maintained?

The last commit was 12 months ago, with 0 open issues. That's long enough that you should check whether the maintainer is responding to issues before depending on it.