ClickHouse MCP Server vs Neon MCP Server

ClickHouse MCP Server

An MCP server for ClickHouse.

The server implements MCP 2026-07-28 and supports legacy initialize handshakes from
2024-11-05 through 2025-11-25. Modern clients use sessionless requests and
server/discover. Existing clients can continue to negotiate the legacy protocol.

[!NOTE]
HTTP requests without MCP-Protocol-Version are routed through legacy handling so
clients from before 2025-06-18 can continue to connect. MCP 2026-07-28 permits
this behavior on servers that support those clients. Modern clients should send the
header on every POST request.

Features

ClickHouse Tools

ClickHouse tool responses are JSON-encoded strings. Integers outside
[-9007199254740991, 9007199254740991] are returned as decimal strings to preserve exact
values in JavaScript clients. This applies to query rows and integer table metadata. Safe-range
integers and booleans keep their JSON types.

• run_query

  • Execute SQL queries on your ClickHouse cluster.
  • Input: query (string): The SQL query to execute.
  • Optional input: params (object): Named values for ClickHouse {name:Type} placeholders. See Query parameters.
  • Queries run in read-only mode by default (CLICKHOUSE_ALLOW_WRITE_ACCESS=false), but writes can be enabled explicitly if needed.
  • DESCRIBE (<query>) and EXPLAIN ESTIMATE <query> run here too and are optional ways to inspect a query's result schema or its estimated reads. See Checking a query before running it.

• list_databases

  • List all databases on your ClickHouse cluster.

• list_tables

  • List tables in a database with pagination.
  • Required input: database (string).
  • Optional inputs:
    • like / not_like (string): Apply LIKE or NOT LIKE filters to table names.
    • page_token (string): Single-use token returned by a previous call. It is retained for up to one hour.
    • page_size (int, default 50): Number of tables returned per page; must be greater than 0.
    • include_detailed_columns (bool, default true): When false, omits column metadata for lighter responses while keeping the full create_table_query.
  • Response shape:
    • tables: Array of table objects for the current page.
    • next_page_token: Pass this single-use value back before it expires to fetch the next page, or null when there are no more tables.
    • total_tables: Total count of tables that match the supplied filters.

Agents Schema discovery

The server instructions suggest reading Agents Schema's
canonical AGENTS.ROOT through run_query when list_databases reveals an AGENTS
database, before writing analytical SQL. This is guidance for the agent: no metadata
is fetched automatically, tool results are unchanged, and existing ClickHouse
permissions still apply. If AGENTS.ROOT is missing or inaccessible, normal discovery
and queries remain available.

Query parameters

Pass values separately from SQL through the optional params object:

{
  "query": "SELECT {id:UInt32} AS id, {name:String} AS name",
  "params": {"id": 13, "name": "O'Reilly"}
}

Use ClickHouse's {name:Type} placeholders without quoting them. Keep the opening
brace, name, and colon adjacent, as in {id:UInt32}. Spaces after the colon and
within the type are supported, as in {id: UInt32} and {amount:Decimal(18, 4)}.
For compatibility across supported driver versions, start names with a letter or
underscore and use only letters, digits, and underscores.
Python-style %s or %(name)s formatting and the driver's $name$ raw binary
parameters are not supported. Calls with only query still work. Omitting params,
passing null, or passing an empty object leaves the query unbound.

Parameter values can be JSON strings, numbers, booleans, null, or arrays, provided
they match the declared ClickHouse type:

• Use null with a Nullable(...) type.
• Pass exact integers outside JavaScript's safe range as decimal strings, for
  example "18446744073709551615" with {id:UInt64}. Dates, timestamps, and exact
  decimals can also be passed as strings with the corresponding ClickHouse type.
• Bind vectors as one array, for example {vector:Array(Float32)} with
  "params": {"vector": [0.25, 0.5, 0.75]}.
• Nulls inside arrays depend on the installed driver. They work with
  clickhouse-connect 1.8.0 but fail with the supported minimum 1.0.0.
• JSON lists and objects cannot bind to ClickHouse Tuple and Map types.

Missing values and incompatible types return query errors. With non-empty params,
a query carrying many unterminated {name: placeholder starts is rejected, including
placeholder-like text in comments or string literals.
Parameterized queries use the same write protection, timeouts, cancellation, and
JSON result encoding as other queries.

Parameter values stay out of the MCP server's normal SQL log messages, but remain
in MCP tool arguments and may appear in backend errors. ClickHouse 26.3.20.7
substitutes values into the query text in system.query_log, system.processes,
and system.text_log. Parameter binding is not a privacy feature and does not
reduce the number of vector values sent in a tool call.

Checking a query before running it

run_query also runs DESCRIBE and EXPLAIN ESTIMATE. Both are optional checks: reach for DESCRIBE when you need a query's output columns and types, and for EXPLAIN ESTIMATE before a SELECT that could be expensive.

DESCRIBE (<query>) inspects the result schema and returns the same output-column metadata as DESCRIBE TABLE:

DESCRIBE (SELECT user, sum(amt) FROM events WHERE ts > now() - INTERVAL 30 DAY GROUP BY user)

user      String
sum(amt)  Decimal(38, 2)

ClickHouse has to analyze the query to answer, so analysis errors surface here, with ClickHouse's own message, instead of part way through execution:

DESCRIBE (SELECT usr FROM events)  -> Code: 47. Unknown expression identifier `usr` ... Maybe you meant: ['user']
DESCRIBE (SELECT * FROM nosuch)    -> Code: 60. Unknown table expression identifier 'nosuch'

A query that describes cleanly can still fail when it runs, on a memory limit or a remote server error, and it says nothing about cost.

EXPLAIN ESTIMATE <query> returns the parts, rows and marks the query would read, one row per table, which is what separates a primary key lookup from a full scan:

EXPLAIN ESTIMATE SELECT count() FROM events WHERE id = 42

database  table   parts  rows   marks
default   events  1      8192   1

Those are estimated reads from MergeTree family tables, after primary key and partition pruning. They are not run time and not result size, and other table engines are not covered.

Neither statement runs the query body, but analysis is not always free: DESCRIBE (SELECT (SELECT sleep(1))) executes the scalar subquery while analyzing. Both are read-only and work under the default CLICKHOUSE_ALLOW_WRITE_ACCESS=false. See the ClickHouse documentation for EXPLAIN ESTIMATE and DESCRIBE.

chDB Tools

• run_chdb_select_query
  • Execute SQL queries using chDB's embedded ClickHouse engine.
  • Input: query (string): The SQL query to execute.
  • Integers outside [-9007199254740991, 9007199254740991] are returned as decimal strings.
  • Query data directly from various sources (files, URLs, databases) without ETL processes.
  • Requires the optional chdb extra: pip install 'mcp-clickhouse[chdb]'

Health Check Endpoint

When running with HTTP or SSE transport, a health check endpoint is available at /health. This endpoint:

• Returns 200 OK (body: OK) if the server is healthy and can connect to ClickHouse
• Returns 503 Service Unavailable with a generic error message if the server cannot connect to ClickHouse
• Returns 503 if a ClickHouse probe does not finish within two seconds. Concurrent requests share one in-flight probe
• Reuses a completed probe result for one second, so probes that arrive in quick succession do not each connect to ClickHouse. A failure or a recovery can therefore be reported up to a second late

GET and HEAD requests to the endpoint are intentionally unauthenticated and exempt from Host and Origin validation so orchestrator probes (e.g. Kubernetes liveness/readiness, load balancers) can use runtime-assigned pod or target IPs without extra configuration. /health is reserved and cannot be used as the MCP transport path. The response body is deliberately minimal to avoid leaking backend version strings or error details; debug failures via the server logs.

Example:

curl http://localhost:8000/health
## Response: OK

Security

Authentication for HTTP/SSE Transports

When using HTTP or SSE transport, authentication is required by default. The stdio transport (default) does not require authentication as it only communicates via standard input/output.

Three authentication modes are supported. Pick one:

Startup fails if none of these are configured for HTTP/SSE transports.

Setting Up Authentication

1. Generate a secure token (can be any random string):

   # Using uuidgen (macOS/Linux)
   uuidgen
   
   # Using openssl
   openssl rand -hex 32
   

   Copy

2. Configure the server with the token:

   export CLICKHOUSE_MCP_AUTH_TOKEN="your-generated-token"
   

   Copy

3. Configure your MCP client to include the token in requests:

   For Claude Desktop with HTTP/SSE transport:

   {
     "mcpServers": {
       "mcp-clickhouse": {
         "url": "http://127.0.0.1:8000",
         "headers": {
           "Authorization": "Bearer your-generated-token"
         }
       }
     }
   }
   

   Copy

   Note: the /health endpoint is intentionally unauthenticated (see Health Check Endpoint above). To verify that bearer-token auth is actually rejecting unauthenticated requests, hit the MCP endpoint itself e.g. with the MCP Inspector, or by POSTing a JSON-RPC request to /mcp with and without the Authorization header and confirming the unauthenticated call returns 401.

OAuth / OIDC via FastMCP

For production deployments with identity providers (Azure Entra, Google, GitHub, WorkOS, etc.), delegate authentication to FastMCP's built-in auth providers instead of using a static token. Set FASTMCP_SERVER_AUTH to the full class path of a FastMCP auth provider, along with the provider-specific FASTMCP_SERVER_AUTH_* variables, and leave CLICKHOUSE_MCP_AUTH_TOKEN unset.

Example (Azure Entra):

export FASTMCP_SERVER_AUTH=fastmcp.server.auth.providers.azure.AzureProvider
export FASTMCP_SERVER_AUTH_AZURE_TENANT_ID="<tenant-id>"
export FASTMCP_SERVER_AUTH_AZURE_CLIENT_ID="<client-id>"
export FASTMCP_SERVER_AUTH_AZURE_CLIENT_SECRET="<client-secret>"
export FASTMCP_SERVER_AUTH_AZURE_BASE_URL="https://mcp.example.com"
export FASTMCP_SERVER_AUTH_AZURE_REQUIRED_SCOPES="read access_as_user"

mcp-clickhouse retains these FastMCP 2.14.7 environment prefixes for the FastMCP 4.0.0
built-in providers:

Append the uppercase provider field name to the prefix. See the
FastMCP docs for each provider's configuration
requirements.

Auth values set directly in the process environment take precedence case-insensitively.
The default .env load starts at the installed mcp_clickhouse package directory,
resolves symlinks first, and walks upward to the filesystem root. It loads the first
.env it finds and loads nothing if there is none. It never reads the working
directory, regardless of how the server is launched. A source checkout normally finds
the repository root .env. That file may also provide FASTMCP_SERVER_AUTH and its
provider fields. Its values take precedence over the explicit or compatibility auth
file.
For FastMCP 2 compatibility, mcp-clickhouse reads missing provider fields from .env
in the working directory, but that compatibility fallback cannot select
FASTMCP_SERVER_AUTH. A process-set FASTMCP_ENV_FILE replaces that compatibility
fallback and may provide both the selector and provider fields. Set it before startup.
The mcp-clickhouse compatibility loader reads only FASTMCP_SERVER_AUTH and
FASTMCP_SERVER_AUTH_* from that file, so it cannot inject CLICKHOUSE_* settings.
FastMCP 4 may use the same file for its own broader settings. A custom provider receives
no environment-derived constructor arguments and must support no-argument construction.

Treat both discovered and working-directory .env files as trusted authentication
configuration. Anyone who can create or write a .env in any directory from the package
directory up to the filesystem root can control which file is discovered, select the
provider, and set its fields. Anyone who can write the working-directory file controls every provider
field absent from the process and discovered configuration, including signing keys,
issuers and endpoints, and client secrets. A process-set FASTMCP_ENV_FILE that points
to an operator-owned file disables the working-directory fallback.

FastMCP 4 changed the default OAuth proxy client store. Deployments that relied on
FastMCP 2's default OAuth proxy storage must have clients register and authorize again.
Compatible custom storage, static bearer tokens, and JWT verification are unaffected.

Development Mode (Disabling Authentication)

For local development and testing only, you can disable authentication by setting:

export CLICKHOUSE_MCP_AUTH_DISABLED=true
export CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:8000,localhost:8000

WARNING: Only use this for local development. Do not disable authentication when the server is exposed to any network.

Configuration

This MCP server supports both ClickHouse and chDB. You can enable either or both depending on your needs.
Python 3.10 through 3.15 are supported. Python 3.12 is recommended for local launches.
chDB supports Python 3.10 through 3.14. On Python 3.15, the chdb extra skips
installing chDB through a dependency marker. Python 3.15 installs currently build
lz4 and PyYAML from source, with or without the chdb extra. A C compiler is
required for lz4.

1. Open the Claude Desktop configuration file located at:

   • On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
   • On Windows: %APPDATA%/Claude/claude_desktop_config.json

2. Add the following:

{
  "mcpServers": {
    "mcp-clickhouse": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "mcp-clickhouse",
        "--python",
        "3.12",
        "mcp-clickhouse"
      ],
      "env": {
        "CLICKHOUSE_HOST": "<clickhouse-host>",
        "CLICKHOUSE_PORT": "<clickhouse-port>",
        "CLICKHOUSE_USER": "<clickhouse-user>",
        "CLICKHOUSE_PASSWORD": "<clickhouse-password>",
        "CLICKHOUSE_ROLE": "<clickhouse-role>",
        "CLICKHOUSE_SECURE": "true",
        "CLICKHOUSE_VERIFY": "true",
        "CLICKHOUSE_CONNECT_TIMEOUT": "30"
      }
    }
  }
}

Update the environment variables to point to your own ClickHouse service.

Or, if you'd like to try it out with the ClickHouse SQL Playground, you can use the following config:

{
  "mcpServers": {
    "mcp-clickhouse": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "mcp-clickhouse",
        "--python",
        "3.12",
        "mcp-clickhouse"
      ],
      "env": {
        "CLICKHOUSE_HOST": "sql-clickhouse.clickhouse.com",
        "CLICKHOUSE_PORT": "8443",
        "CLICKHOUSE_USER": "demo",
        "CLICKHOUSE_PASSWORD": "",
        "CLICKHOUSE_SECURE": "true",
        "CLICKHOUSE_VERIFY": "true",
        "CLICKHOUSE_CONNECT_TIMEOUT": "30"
      }
    }
  }
}

For chDB (embedded ClickHouse engine), add the following configuration:

{
  "mcpServers": {
    "mcp-clickhouse": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "mcp-clickhouse[chdb]",
        "--python",
        "3.12",
        "mcp-clickhouse"
      ],
      "env": {
        "CHDB_ENABLED": "true",
        "CLICKHOUSE_ENABLED": "false",
        "CHDB_DATA_PATH": "/path/to/chdb/data"
      }
    }
  }
}

You can also enable both ClickHouse and chDB simultaneously:

{
  "mcpServers": {
    "mcp-clickhouse": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "mcp-clickhouse[chdb]",
        "--python",
        "3.12",
        "mcp-clickhouse"
      ],
      "env": {
        "CLICKHOUSE_HOST": "<clickhouse-host>",
        "CLICKHOUSE_PORT": "<clickhouse-port>",
        "CLICKHOUSE_USER": "<clickhouse-user>",
        "CLICKHOUSE_PASSWORD": "<clickhouse-password>",
        "CLICKHOUSE_SECURE": "true",
        "CLICKHOUSE_VERIFY": "true",
        "CLICKHOUSE_CONNECT_TIMEOUT": "30",
        "CHDB_ENABLED": "true",
        "CHDB_DATA_PATH": "/path/to/chdb/data"
      }
    }
  }
}

3. Locate the command entry for uv and replace it with the absolute path to the uv executable. This ensures that the correct version of uv is used when starting the server. On a mac, you can find this path using which uv.

4. Restart Claude Desktop to apply the changes.

Optional Write Access

By default, this MCP enforces read-only queries so that accidental mutations cannot happen during exploration. To allow DDL or INSERT statements, set the CLICKHOUSE_ALLOW_WRITE_ACCESS environment variable to true. The server keeps enforcing read-only mode if the ClickHouse instance itself disallows writes.

Read-only mode still permits the ClickHouse user to cancel its own queries, including queries from other connections using the same user. Use a dedicated ClickHouse user even in read-only mode. Use separate ClickHouse users for workloads that must not cancel each other's queries.

Destructive Operation Protection

Even when write access is enabled (CLICKHOUSE_ALLOW_WRITE_ACCESS=true), destructive operations require an additional opt-in flag for safety. The check covers any DROP statement (including the ALTER TABLE ... DROP PARTITION / DROP PART / DROP COLUMN clauses), any TRUNCATE, DELETE and UPDATE (both the lightweight statements and the ALTER TABLE ... DELETE / ALTER TABLE ... UPDATE mutations), REPLACE TABLE, CREATE OR REPLACE, ALTER TABLE ... REPLACE PARTITION, ALTER TABLE ... CLEAR COLUMN / CLEAR INDEX / CLEAR PROJECTION, and DETACH ... PERMANENTLY. Keywords inside string literals, quoted identifiers, SQL comments, and {name:Type} parameter names are ignored, so they neither trigger the check nor hide a statement from it.

This check runs in the MCP server and is a best-effort guard against accidents. It is not a security boundary. The security boundary is the ClickHouse user's grants. Read-only mode (the default) is enforced server-side via readonly=1. The destructive-operation gate is not server-enforced.

For write mode, give the MCP server a dedicated ClickHouse user with only the privileges it needs:

CREATE USER mcp_agent IDENTIFIED BY '...';
GRANT SELECT, INSERT, CREATE TABLE, ALTER ADD COLUMN ON mydb.* TO mcp_agent;

Data-changing operations that require privileges outside these grants fail server-side with ACCESS_DENIED, regardless of MCP flags. The server settings max_table_size_to_drop and max_partition_size_to_drop can also cap blast radius if pinned with settings constraints.

To enable destructive operations, set both flags:

"env": {
  "CLICKHOUSE_ALLOW_WRITE_ACCESS": "true",
  "CLICKHOUSE_ALLOW_DROP": "true"
}

This two-tier approach makes accidental deletion difficult:

• Write operations (INSERT, CREATE, ALTER ADD COLUMN) require CLICKHOUSE_ALLOW_WRITE_ACCESS=true
• Destructive operations (DROP, TRUNCATE, DELETE, UPDATE, and the rest of the list above) additionally require CLICKHOUSE_ALLOW_DROP=true

Running Without uv (Using System Python)

If you prefer to use the system Python installation instead of uv, you can install the package from PyPI and run it directly:

1. Install the package using pip:

   python3 -m pip install mcp-clickhouse
   

   Copy

   To install chDB support as well:

   python3 -m pip install 'mcp-clickhouse[chdb]'
   

   Copy

   To upgrade to the latest version:

   python3 -m pip install --upgrade mcp-clickhouse
   

   Copy

2. Update your Claude Desktop configuration to use Python directly:

{
  "mcpServers": {
    "mcp-clickhouse": {
      "command": "python3",
      "args": [
        "-m",
        "mcp_clickhouse.main"
      ],
      "env": {
        "CLICKHOUSE_HOST": "<clickhouse-host>",
        "CLICKHOUSE_PORT": "<clickhouse-port>",
        "CLICKHOUSE_USER": "<clickhouse-user>",
        "CLICKHOUSE_PASSWORD": "<clickhouse-password>",
        "CLICKHOUSE_SECURE": "true",
        "CLICKHOUSE_VERIFY": "true",
        "CLICKHOUSE_CONNECT_TIMEOUT": "30"
      }
    }
  }
}

Alternatively, you can use the installed script directly:

{
  "mcpServers": {
    "mcp-clickhouse": {
      "command": "mcp-clickhouse",
      "env": {
        "CLICKHOUSE_HOST": "<clickhouse-host>",
        "CLICKHOUSE_PORT": "<clickhouse-port>",
        "CLICKHOUSE_USER": "<clickhouse-user>",
        "CLICKHOUSE_PASSWORD": "<clickhouse-password>",
        "CLICKHOUSE_SECURE": "true",
        "CLICKHOUSE_VERIFY": "true",
        "CLICKHOUSE_CONNECT_TIMEOUT": "30"
      }
    }
  }
}

Note: Make sure to use the full path to the Python executable or the mcp-clickhouse script if they are not in your system PATH. You can find the paths using:

• which python3 for the Python executable
• which mcp-clickhouse for the installed script

Custom Middleware

You can add custom middleware to the MCP server without modifying the source code. FastMCP provides a middleware system that allows you to intercept and process MCP protocol messages (tool calls, resource reads, prompts, etc.).

How to Use

1. Create a Python module with middleware classes extending Middleware and a setup_middleware(mcp) function:

## my_middleware.py
import logging
from fastmcp.server.middleware import Middleware, MiddlewareContext, CallNext

logger = logging.getLogger("my-middleware")

class LoggingMiddleware(Middleware):
    """Log all tool calls."""

    async def on_call_tool(self, context: MiddlewareContext, call_next: CallNext):
        tool_name = context.message.name if hasattr(context.message, 'name') else 'unknown'
        logger.info(f"Calling tool: {tool_name}")
        result = await call_next(context)
        logger.info(f"Tool {tool_name} completed")
        return result

def setup_middleware(mcp):
    """Register middleware with the MCP server."""
    mcp.add_middleware(LoggingMiddleware())

2. Set the MCP_MIDDLEWARE_MODULE environment variable to the module name (without .py extension):

{
  "mcpServers": {
    "mcp-clickhouse": {
      "command": "uv",
      "args": ["run", "--with", "mcp-clickhouse", "--python", "3.12", "mcp-clickhouse"],
      "env": {
        "CLICKHOUSE_HOST": "<clickhouse-host>",
        "CLICKHOUSE_USER": "<clickhouse-user>",
        "CLICKHOUSE_PASSWORD": "<clickhouse-password>",
        "MCP_MIDDLEWARE_MODULE": "my_middleware"
      }
    }
  }
}

3. Ensure your middleware module is in Python's import path (e.g., in the same directory where the MCP server runs, or installed as a package).

Example Middleware

An example middleware module is provided in example_middleware.py showing common patterns:

• Logging all MCP requests
• Logging tool calls specifically
• Measuring request processing time

To use the example:

"env": {
  "MCP_MIDDLEWARE_MODULE": "example_middleware"
}

Middleware Capabilities

The Middleware base class provides hooks for different MCP operations:

• on_message(context, call_next) - Called for all messages
• on_request(context, call_next) - Called for all requests
• on_notification(context, call_next) - Called for all notifications
• on_call_tool(context, call_next) - Called when a tool is executed
• on_read_resource(context, call_next) - Called when a resource is read
• on_get_prompt(context, call_next) - Called when a prompt is retrieved
• on_list_tools(context, call_next) - Called when listing tools
• on_list_resources(context, call_next) - Called when listing resources
• on_list_resource_templates(context, call_next) - Called when listing resource templates
• on_list_prompts(context, call_next) - Called when listing prompts

Each hook receives a MiddlewareContext object containing the message and metadata, and a call_next function to continue the pipeline.

Dynamic Client Configuration via Context State

Middleware can override ClickHouse client configuration on a per-request basis using the CLIENT_CONFIG_OVERRIDES_KEY context state key. The server merges these overrides with the base configuration from environment variables.

from fastmcp.server.dependencies import get_context
from fastmcp.server.middleware import CallNext, Middleware, MiddlewareContext
from mcp_clickhouse.mcp_server import CLIENT_CONFIG_OVERRIDES_KEY

class ClientConfigMiddleware(Middleware):
    async def on_call_tool(self, context: MiddlewareContext, call_next: CallNext):
        ctx = get_context()
        await ctx.set_state(
            CLIENT_CONFIG_OVERRIDES_KEY,
            {
                "connect_timeout": 60,
                "send_receive_timeout": 120,
            },
            serializable=False,
        )
        return await call_next(context)

This enables advanced use cases like dynamic timeout adjustments, tenant-specific routing, or per-user connection settings.

The state value must be a dictionary. Nested settings and generic_args values must be
mappings and are merged with the base configuration. Invalid values fail the tool call before
a ClickHouse client is created. CLICKHOUSE_ROLE remains active unless the override explicitly
supplies settings.role. Top-level role and ch_role keys, plus the same keys under
generic_args, are rejected.

Set verify, ca_cert, client_cert, client_cert_key, tls_mode, server_host_name,
and pool_mgr only as top-level overrides. They cannot be nested under generic_args. A
custom pool_mgr cannot be combined with managed CA or client certificate settings. DSN query
parameters cannot set these keys, and a DSN cannot select the chdb backend. Use explicit
top-level host, port, username, password, database, and secure overrides to change
the connection. A forwarded DSN does not replace populated base connection fields or select
TLS. It can fill empty fields and supply supported query parameters such as query_limit.
secure and verify overrides accept booleans or the strings true and false.
verify also accepts proxy, which behaves as
tls_mode: proxy when tls_mode is unset and therefore uses Basic authentication with the
environment password. A secure override selects the matching https or http interface and
does not change the port. An explicit interface override must be http or https and agree
with secure. After merging overrides, default and mutual client certificate modes omit the
password. proxy and strict modes use Basic authentication with the environment password
unless the override supplies its own credentials.

Treat these overrides as trusted middleware input. Middleware must authenticate and authorize
request-derived values before setting them. Use serializable=False so FastMCP keeps the
value in request-local state. The default serializable=True stores session state and is
rejected by the server. The server snapshots the value before dispatching blocking database
work. Do not store tenant data in session-scoped Context state. A rejected session-scoped
override remains attached to a legacy MCP session and causes later tool calls in that session
to fail until the client reconnects. A per-request ClickHouse role is connection configuration,
not a tenant authorization boundary. Enforce tenant isolation with ClickHouse users, roles,
and grants.

Development

1. In test-services directory run docker compose up -d to start the ClickHouse cluster.

2. Add the following variables to a .env file in the root of the repository.

Note: The use of the default user in this context is intended solely for local development purposes.

CLICKHOUSE_HOST=localhost
CLICKHOUSE_PORT=8123
CLICKHOUSE_USER=default
CLICKHOUSE_PASSWORD=clickhouse

3. Run uv sync --locked --extra dev to install the dependencies. On Python 3.10 through 3.14, add --extra chdb for chDB development. To install uv follow the instructions here. Then do source .venv/bin/activate.

4. For easy testing with the MCP Inspector, run uv run fastmcp dev inspector mcp_clickhouse/mcp_server.py:mcp to start the MCP server.

5. To test with HTTP transport and the health check endpoint:

   # For development, disable authentication
   CLICKHOUSE_MCP_SERVER_TRANSPORT=http CLICKHOUSE_MCP_AUTH_DISABLED=true CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:8000,localhost:8000 python -m mcp_clickhouse.main
   
   # Or with authentication (generate a token first)
   CLICKHOUSE_MCP_SERVER_TRANSPORT=http CLICKHOUSE_MCP_AUTH_TOKEN="your-token" python -m mcp_clickhouse.main
   
   # Then in another terminal:
   curl http://localhost:8000/health
   

   Copy

Code layout

The package uses a flat module layout. Start with mcp_server.py
for server assembly and registration, then follow the implementation into its owning module.

Each server assembly owns its worker pools, client cache, active queries, pagination cache,
health state, and chDB backend. Worker and client cleanup runs at process exit. Package imports
initialize the default server, including when first importing an extracted module.

In tests, patch the module or owner instance where the code reads a dependency. For example,
patch mcp_clickhouse.clients.clickhouse_connect.get_client for client creation. Compatibility
imports in mcp_server.py can be separate bindings from the ones an implementation uses.

Environment Variables

Configuration is split into independent groups. Mixing them up is a common cause of hard-to-debug connection failures:

[!IMPORTANT]
CLICKHOUSE_SECURE, CLICKHOUSE_VERIFY, CLICKHOUSE_CA_CERT, CLICKHOUSE_CLIENT_CERT, CLICKHOUSE_CLIENT_CERT_KEY, CLICKHOUSE_TLS_MODE, and CLICKHOUSE_PORT apply to the outbound ClickHouse database connection only. They do not configure TLS, client certificates, ports, or authentication for the inbound MCP HTTP/SSE endpoint.

Example: if the MCP server runs in Kubernetes behind an ingress that terminates TLS, that is an MCP transport concern. Keep CLICKHOUSE_SECURE aligned with how the pod reaches ClickHouse itself (HTTPS → true, plain HTTP → false). Setting CLICKHOUSE_SECURE=false because the MCP server is behind an ingress will make the server dial ClickHouse over HTTP—often against an HTTPS-only port—and produce opaque HTTP/TLS errors in the server logs.

ClickHouse database connection

These variables configure the clickhouse-connect HTTP client and the behavior of ClickHouse-backed tools such as run_query, list_databases, and list_tables.
mcp-clickhouse requires clickhouse-connect 1.x, starting with 1.0.0.

Required Variables

• CLICKHOUSE_HOST: The hostname of your ClickHouse server (database endpoint, not the MCP server bind address)
• CLICKHOUSE_USER: The username for ClickHouse authentication
• CLICKHOUSE_PASSWORD: The password for ClickHouse authentication
  • Required unless CLICKHOUSE_CLIENT_CERT uses the default or "mutual" TLS mode
  • In default or "mutual" mode, certificate authentication is used and the password is not sent

[!CAUTION]
It is important to treat your MCP database user as you would any external client connecting to your database, granting only the minimum necessary privileges required for its operation. The use of default or administrative users should be strictly avoided at all times.

Optional Variables

• CLICKHOUSE_PORT: HTTP interface port of your ClickHouse server
  • Default: 8443 if CLICKHOUSE_SECURE=true, 8123 if CLICKHOUSE_SECURE=false
  • Usually doesn't need to be set unless using a non-standard port
  • Must be an HTTP interface port, not the native TCP protocol port used by clickhouse-client
  • Common values:
    • HTTP: 8123 (plain) / 8443 (TLS) — used by this server and ClickHouse Cloud HTTPS
    • Native TCP (not supported here): 9000 (plain) / 9440 (TLS) — used by clickhouse-client
  • If the server responds with Port 9000 is for clickhouse-client program, you are pointed at the native protocol; switch to the HTTP port (8123/8443 or your deployment's HTTP mapping)
• CLICKHOUSE_ROLE: The ClickHouse role to use for authentication
  • Default: None
  • Set this if your user requires a specific role
• CLICKHOUSE_SECURE: Enable HTTPS for the ClickHouse database connection (not for MCP clients)
  • Default: "true"
  • Set to "false" only when the MCP server reaches ClickHouse over plain HTTP (typical for local Docker Compose on port 8123)
  • Leave "true" for ClickHouse Cloud and any HTTPS database endpoint—even if the MCP server itself is exposed via HTTP, stdio, or an ingress that terminates TLS separately
  • Mismatching this flag with the database port (e.g. CLICKHOUSE_SECURE=false against port 8443) is a frequent setup mistake and usually surfaces as confusing HTTP client errors rather than a clear "wrong scheme" message
• CLICKHOUSE_VERIFY: Enable/disable SSL certificate verification for the ClickHouse HTTPS connection
  • Default: "true"
  • Set to "false" to disable certificate verification (not recommended for production)
  • TLS certificates: The package uses your operating system trust store via truststore.inject_into_ssl() at startup. Python's default SSL handling is used if injection is disabled with MCP_CLICKHOUSE_TRUSTSTORE_DISABLE=1 or fails.
• MCP_CLICKHOUSE_TRUSTSTORE_DISABLE: Disable the process-wide operating system trust store integration for TLS
  • Default: unset (trust store integration is enabled)
  • Set to exactly "1" before startup to skip truststore.inject_into_ssl() and use Python's default SSL certificate handling. Other values do not disable the integration.
  • This does not disable certificate verification. CLICKHOUSE_VERIFY still controls verification for the ClickHouse HTTPS connection.
• CLICKHOUSE_CA_CERT: Path to a PEM CA certificate bundle for the ClickHouse HTTPS connection
  • Default: None (uses the operating system trust store unless truststore injection is disabled or fails)
  • Use this by itself when a ClickHouse server or private proxy presents a certificate signed by a private CA. This changes server certificate verification and does not enable client certificate authentication.
  • Requires CLICKHOUSE_SECURE=true and CLICKHOUSE_VERIFY=true
• CLICKHOUSE_CLIENT_CERT: Path to a PEM client certificate for the ClickHouse HTTPS connection
  • Default: None
  • The file may also contain the private key. Otherwise set CLICKHOUSE_CLIENT_CERT_KEY.
  • The ClickHouse user still comes from CLICKHOUSE_USER.
• CLICKHOUSE_CLIENT_CERT_KEY: Path to the PEM private key for CLICKHOUSE_CLIENT_CERT
  • Default: None
  • Optional when the private key is included in the client certificate file
  • Cannot be used without CLICKHOUSE_CLIENT_CERT
• CLICKHOUSE_TLS_MODE: How clickhouse-connect uses CLICKHOUSE_CLIENT_CERT
  • Default: None, which behaves as "mutual" when a client certificate is set
  • "mutual": Use the client certificate for ClickHouse X.509 user authentication. CLICKHOUSE_PASSWORD is optional and is not sent.
  • "proxy": Present the client certificate to a TLS-terminating proxy, then use ClickHouse Basic authentication. CLICKHOUSE_PASSWORD is required.
  • "strict": Present the client certificate because the ClickHouse server requires one at the TLS layer, then use ClickHouse Basic authentication. CLICKHOUSE_PASSWORD is required. This mode does not strengthen server certificate verification. CLICKHOUSE_VERIFY controls that verification.
  • clickhouse-connect treats "proxy" and "strict" identically. The two names document intent.
  • Values are trimmed and case-insensitive. A blank value is treated as unset. Other values are rejected before a ClickHouse client is created, on the first ClickHouse tool call or /health probe.
  • Requires CLICKHOUSE_CLIENT_CERT. All client certificate options require CLICKHOUSE_SECURE=true.
• CLICKHOUSE_SERVER_HOST_NAME: Server hostname for SNI override and certificate validation on the ClickHouse connection
  • Default: None (uses the connection hostname)
  • This is useful when connecting through proxies or load balancers where the certificate hostname differs from the connection hostname. When set, this hostname will be used for both SNI (Server Name Indication) during the TLS handshake and for certificate hostname validation.
• CLICKHOUSE_PROXY_PATH: URL path prefix for the ClickHouse HTTP endpoint
  • Default: None
  • Set this when the ClickHouse HTTP interface is exposed behind a reverse proxy under a path prefix (for example, /clickhouse)
• CLICKHOUSE_CONNECT_TIMEOUT: Connection timeout in seconds for the ClickHouse client
  • Default: "30"
  • Increase this value if you experience connection timeouts
• CLICKHOUSE_SEND_RECEIVE_TIMEOUT: Send/receive timeout in seconds for the ClickHouse client
  • Default: the lower of 300 or CLICKHOUSE_MCP_QUERY_TIMEOUT + 5, so worker threads unblock shortly after a query timeout
  • If explicitly set, the value is used as-is (e.g. "300" for long-running queries)
• CLICKHOUSE_DATABASE: Default ClickHouse database to use
  • Default: None (uses server default)
  • Set this to automatically connect to a specific database
• CLICKHOUSE_ENABLED: Enable/disable ClickHouse database tools
  • Default: "true"
  • Set to "false" to disable ClickHouse tools when using chDB only
• CLICKHOUSE_ALLOW_WRITE_ACCESS: Allow write operations (DDL and DML) against ClickHouse
  • Default: "false"
  • Set to "true" to allow non-destructive DDL and DML (CREATE, INSERT, ALTER ADD COLUMN). Destructive statements additionally need CLICKHOUSE_ALLOW_DROP=true
  • When disabled (default), queries run with readonly=1 setting to prevent data modifications
• CLICKHOUSE_ALLOW_DROP: Allow destructive operations (any DROP or TRUNCATE, DELETE and UPDATE including the ALTER TABLE variants, REPLACE TABLE / REPLACE PARTITION / CREATE OR REPLACE, CLEAR COLUMN / CLEAR INDEX / CLEAR PROJECTION, and DETACH ... PERMANENTLY)
  • Default: "false"
  • Only takes effect when CLICKHOUSE_ALLOW_WRITE_ACCESS=true is also set
  • This gate is a best-effort accident guard in the MCP server, not a security boundary. Restrict the ClickHouse user's grants for real enforcement (see Destructive Operation Protection)

ClickHouse TLS certificate files

The certificate variables contain file paths, not PEM contents. mcp-clickhouse passes these
paths to clickhouse-connect. For Docker or Kubernetes, mount the certificate and private key
as read-only files and use their paths inside the container. Do not bake a private key into an
image, commit it to source control, or put its contents in an environment variable.

In mutual mode, the configured client certificate identifies this mcp-clickhouse process as
CLICKHOUSE_USER. It does not authenticate inbound MCP clients or pass their identities to
ClickHouse. Configure MCP transport authentication separately.

Restart mcp-clickhouse after replacing a certificate or key at the same path when immediate
rotation or revocation is required. Cached clients can retain existing TLS connections, and
the cache does not track file contents or modification times.

ClickHouse Cloud does not support X.509 client certificate authentication for database users.
Use CLICKHOUSE_USER and CLICKHOUSE_PASSWORD for ClickHouse Cloud. A CA certificate can
still be useful when a private proxy in front of an endpoint presents a certificate signed by
a private CA.

MCP server and transport

These variables control the MCP process itself, including transport, authentication, and query-tool execution limits. They are independent of the ClickHouse database settings above. See also Authentication for HTTP/SSE Transports.

• CLICKHOUSE_MCP_SERVER_TRANSPORT: Sets the transport method for the MCP server
  • Default: "stdio"
  • Valid options: "stdio", "http", "sse". This is useful for local development with tools like MCP Inspector.
  • stdio is typical for Claude Desktop; http/sse expose a network listener (bind host/port below)
  • "sse" selects the deprecated standalone HTTP+SSE transport and logs a warning. Use "http" for Streamable HTTP in new deployments.
• CLICKHOUSE_MCP_BIND_HOST: Host to bind the MCP server to when using HTTP or SSE transport
  • Default: "127.0.0.1"
  • Set to "0.0.0.0" to bind to all network interfaces (useful for Docker or remote access)
  • Only used when transport is "http" or "sse" — not related to CLICKHOUSE_HOST
• CLICKHOUSE_MCP_BIND_PORT: Port to bind the MCP server to when using HTTP or SSE transport
  • Default: "8000"
  • Only used when transport is "http" or "sse" — not related to CLICKHOUSE_PORT
• CLICKHOUSE_MCP_QUERY_TIMEOUT: Timeout in seconds for query tool calls
  • Default: "30"
  • Increase this if you see Query timed out after ... errors for heavy queries
  • When a query times out, the server attempts to cancel it with KILL QUERY
  • Unless CLICKHOUSE_SEND_RECEIVE_TIMEOUT is explicitly set, the HTTP read timeout is capped at this value plus five seconds
• CLICKHOUSE_MCP_MAX_WORKERS: Maximum number of concurrent query worker threads
  • Default: "10"
  • Increase if your workload requires many concurrent tool calls
  • Metadata tools use a separate pool with min(4, CLICKHOUSE_MCP_MAX_WORKERS) threads so schema discovery cannot delay queries
• CLICKHOUSE_MCP_AUTH_TOKEN: Static bearer token for HTTP/SSE transports
  • Default: None
  • One of CLICKHOUSE_MCP_AUTH_TOKEN, FASTMCP_SERVER_AUTH, or CLICKHOUSE_MCP_AUTH_DISABLED=true is required for HTTP/SSE transports
  • Generate using uuidgen or openssl rand -hex 32
  • Clients must send this token in the Authorization: Bearer <token> header
• FASTMCP_SERVER_AUTH: Delegate authentication to a FastMCP auth provider
  • Default: None
  • Value is the full class path of an AuthProvider subclass, e.g. fastmcp.server.auth.providers.azure.AzureProvider or fastmcp.server.auth.providers.google.GoogleProvider
  • When set, mcp-clickhouse loads the provider from the existing FASTMCP_SERVER_AUTH_* environment variables; leave CLICKHOUSE_MCP_AUTH_TOKEN unset in this mode
  • Custom providers receive no environment-derived constructor arguments and must support no-argument construction
  • FastMCP 4 no longer supports Supabase HS256 verification. Supabase deployments must use RS256 or ES256.
• FASTMCP_ENV_FILE: Optional file containing FASTMCP_SERVER_AUTH and provider-specific environment variables
  • Default: None. When unset, the compatibility loader reads missing provider fields from .env in the working directory. It does not read FASTMCP_SERVER_AUTH from that fallback
  • Set it in the process environment before startup. A value loaded from the default .env cannot redirect the compatibility loader
  • If process-set, this file may provide both FASTMCP_SERVER_AUTH and provider fields and replaces the working-directory fallback
  • Process environment values take precedence case-insensitively
  • The mcp-clickhouse compatibility loader reads this file only when building HTTP/SSE authentication and reads only FASTMCP_SERVER_AUTH and FASTMCP_SERVER_AUTH_* entries. FastMCP 4 may read the same file for its broader settings
  • The default .env load is separate. It starts at the installed mcp_clickhouse package directory, resolves symlinks, walks upward to the filesystem root, and loads the first .env found or nothing. It never reads the working directory, regardless of launch method. That file may provide FASTMCP_SERVER_AUTH and provider fields along with other server settings. A source checkout normally finds the repository root .env
• CLICKHOUSE_MCP_AUTH_DISABLED: Disable authentication for HTTP/SSE transports
  • Default: "false" (authentication is enabled)
  • Set to "true" to disable authentication for local development/testing only
  • WARNING: Only use for local development. Do not disable when exposed to networks
• CLICKHOUSE_MCP_ALLOWED_HOSTS: Comma separated Host header values the HTTP/SSE server answers for
  • Default for a loopback bind: bare and any-port forms of 127.0.0.1, localhost, and [::1]
  • If set, the value must contain at least one Host entry.
  • A concrete non-loopback bind address defaults to that address and the configured port. A wildcard bind such as 0.0.0.0 or :: requires an explicit non-empty value because the public Host cannot be inferred.
  • Host validation is a defense in depth against DNS rebinding. Origin validation below is required separately by MCP.
  • Entries are exact (localhost:8000) or accept any port (localhost:*). Example: CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:8000,localhost:8000
  • The host:* form matches only values that carry a port. A port-less Host (a standard-port deployment where the client omits :80/:443) must be listed as a bare exact entry (example.com) as well.
  • Requests with a non-matching or missing Host header get 421 Misdirected Request. GET and HEAD requests to /health are exempt from Host and Origin validation so orchestrator probes keep working.
  • Behind a reverse proxy, prefer preserving the original Host header. You can instead list the upstream Host value the proxy sends. Set an explicit list when a launcher such as fastmcp run overrides the bind address for remote access.
  • mcp-clickhouse forces FastMCP's separate Host and Origin guard off. FASTMCP_HTTP_HOST_ORIGIN_PROTECTION, FASTMCP_HTTP_ALLOWED_HOSTS, and FASTMCP_HTTP_ALLOWED_ORIGINS do not apply. CLICKHOUSE_MCP_ALLOWED_HOSTS and CLICKHOUSE_MCP_ALLOWED_ORIGINS are authoritative.
• CLICKHOUSE_MCP_TRUSTED_PROXIES: Proxy IP addresses or CIDR networks whose X-Forwarded-* headers are trusted
  • Default: None. X-Forwarded-Host is ignored. Existing Uvicorn handling of X-Forwarded-For and X-Forwarded-Proto is unchanged.
  • Entries must be IP addresses or CIDR networks, such as 127.0.0.1,10.20.0.0/24,2001:db8::1. CIDRs must use their network address, so 10.20.0.1/24 is rejected. Host names, scoped IPv6 addresses, *, 0.0.0.0/0, and ::/0 are also rejected.
  • Trust is based on the immediate raw socket peer. A request from any other peer, or a request without a client address, ignores X-Forwarded-Host and validates Host.
  • A trusted peer may send exactly one X-Forwarded-Host header containing one non-empty value. Duplicate fields, empty values, and comma separated lists get 421 Misdirected Request. If the header is absent, Host is validated.
  • Use the narrowest possible address or network. The MCP server must only be reachable through proxies in the configured ranges. Every trusted proxy must strip and overwrite client supplied X-Forwarded-Host and X-Forwarded-Proto values, and construct X-Forwarded-For from the verified connection peer.
  • The built-in server and fastmcp run disable Uvicorn's outer proxy-header handling, validate Host from the raw peer, then apply X-Forwarded-For and X-Forwarded-Proto. Explicitly enabling uvicorn_config["proxy_headers"] fails startup in this mode.
  • Direct ASGI embedding must disable proxy-header handling in the outer ASGI server and call mcp.http_app(raw_client_address_preserved=True). Without that explicit assertion, app construction fails when trusted proxies are configured.
• CLICKHOUSE_MCP_ALLOWED_ORIGINS: Comma separated Origin header values accepted on HTTP/SSE
  • Default: None, which rejects every request that carries an Origin header
  • MCP requires Origin validation for HTTP/SSE transport connections. Requests without an Origin are accepted because non-browser MCP clients normally omit it. A non-matching Origin gets 403 Forbidden. The /health endpoint is exempt as described above.
  • Entries are exact (http://localhost:3000) or accept any port (http://localhost:*). As with hosts, the any-port form matches only origins that carry a port; a standard-port origin (https://app.example.com) must be listed exactly.

Reverse proxy Host handling

Preserve Host when possible. This keeps forwarded Host trust disabled:

location / {
    proxy_pass http://mcp-clickhouse:8000;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Host "";
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Sanitize X-Forwarded-For and X-Forwarded-Proto independently of X-Forwarded-Host trust. Uvicorn may trust those headers based on the proxy peer even when CLICKHOUSE_MCP_TRUSTED_PROXIES is unset.

CLICKHOUSE_MCP_ALLOWED_HOSTS=mcp.example.com

Stock nginx changes Host to the upstream name for proxied requests. It does not create or overwrite X-Forwarded-Host. If preserving Host is not possible, overwrite the forwarded header at the trusted edge:

location / {
    proxy_pass http://mcp-clickhouse:8000;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
}

CLICKHOUSE_MCP_ALLOWED_HOSTS=mcp.example.com
CLICKHOUSE_MCP_TRUSTED_PROXIES=10.20.0.8

The second configuration is safe only when 10.20.0.8 is the proxy's immediate source address, the server port is isolated from other clients, and nginx overwrites the incoming forwarding headers as shown. For a proxy chain, each trusted hop must discard unverified incoming values before constructing the new forwarding headers.

On an IPv6 or dual-stack bind, IPv4 proxies may appear as IPv4-mapped addresses such as ::ffff:10.20.0.8; these are matched against IPv4 entries automatically. Envoy's append_x_forwarded_host appends to an existing X-Forwarded-Host rather than overwriting it, producing a comma separated list that is rejected, so configure the trusted hop to overwrite the header instead. On Kubernetes with source NAT (for example externalTrafficPolicy: Cluster) the observed peer may be a node IP rather than the proxy pod, so trust the pod or node CIDR as appropriate; ingress-nginx overwrites both Host and X-Forwarded-Host itself.

Middleware Variables

• MCP_MIDDLEWARE_MODULE: Python module name containing custom middleware to inject into the MCP server
  • Default: None (no middleware loaded)
  • Set to the module name (without .py extension) of your middleware module
  • The module must provide a setup_middleware(mcp) function
  • See Custom Middleware for details and examples

chDB Variables

• CHDB_ENABLED: Enable/disable chDB functionality
  • Default: "false"
  • Set to "true" to enable chDB tools
  • Requires installing the optional extra: mcp-clickhouse[chdb]
  • On Python 3.15, an independently installed chDB can terminate the process when CHDB_ENABLED=true.
• CHDB_DATA_PATH: The path to the chDB data directory
  • Default: ":memory:" (in-memory database)
  • Use :memory: for in-memory database
  • Use a file path for persistent storage (e.g., /path/to/chdb/data)

Common configuration pitfalls

• CLICKHOUSE_SECURE vs MCP / ingress TLS — Turning off CLICKHOUSE_SECURE because the MCP server sits behind Kubernetes ingress, a reverse proxy, or is reached over plain HTTP does not disable database TLS; it only changes how this process connects to ClickHouse. Configure ingress TLS separately from the database client settings.
• Native protocol ports — CLICKHOUSE_PORT must target ClickHouse's HTTP interface (8123/8443 by default). Ports 9000/9440 are for the native TCP protocol (clickhouse-client) and will not work with this server.
• Host confusion — CLICKHOUSE_HOST is the database hostname. CLICKHOUSE_MCP_BIND_HOST is only the address the MCP HTTP/SSE server listens on.

Example Configurations

For local development with Docker:

## Required variables
CLICKHOUSE_HOST=localhost
CLICKHOUSE_USER=default
CLICKHOUSE_PASSWORD=clickhouse

## Optional: Override defaults for local development
CLICKHOUSE_SECURE=false  # Uses port 8123 automatically
CLICKHOUSE_VERIFY=false

For ClickHouse Cloud:

## Required variables
CLICKHOUSE_HOST=your-instance.clickhouse.cloud
CLICKHOUSE_USER=default
CLICKHOUSE_PASSWORD=your-password

## Optional: These use secure defaults
## CLICKHOUSE_SECURE=true  # Uses port 8443 automatically
## CLICKHOUSE_DATABASE=your_database

For ClickHouse SQL Playground:

CLICKHOUSE_HOST=sql-clickhouse.clickhouse.com
CLICKHOUSE_USER=demo
CLICKHOUSE_PASSWORD=
## Uses secure defaults (HTTPS on port 8443)

For a private server CA without client certificate authentication:

CLICKHOUSE_HOST=your-secure-clickhouse.example.com
CLICKHOUSE_USER=your-user
CLICKHOUSE_PASSWORD=your-password
CLICKHOUSE_SECURE=true
CLICKHOUSE_VERIFY=true
CLICKHOUSE_CA_CERT=/run/secrets/clickhouse-ca.pem

For ClickHouse X.509 client certificate authentication:

CLICKHOUSE_HOST=your-secure-clickhouse.example.com
CLICKHOUSE_USER=your-certificate-user
CLICKHOUSE_SECURE=true
CLICKHOUSE_CLIENT_CERT=/run/secrets/clickhouse-client.pem
CLICKHOUSE_CLIENT_CERT_KEY=/run/secrets/clickhouse-client-key.pem
## CLICKHOUSE_CA_CERT=/run/secrets/clickhouse-ca.pem  # Only for a private server CA
## CLICKHOUSE_TLS_MODE=mutual  # Optional. This is the default with a client certificate.

For a client certificate required by a strict TLS server while ClickHouse uses Basic
authentication:

CLICKHOUSE_HOST=your-secure-clickhouse.example.com
CLICKHOUSE_USER=your-user
CLICKHOUSE_PASSWORD=your-password
CLICKHOUSE_SECURE=true
CLICKHOUSE_CLIENT_CERT=/run/secrets/clickhouse-client.pem
CLICKHOUSE_CLIENT_CERT_KEY=/run/secrets/clickhouse-client-key.pem
CLICKHOUSE_TLS_MODE=strict

Use CLICKHOUSE_TLS_MODE=proxy instead when a TLS-terminating proxy requires the client
certificate and ClickHouse still uses Basic authentication.

For chDB only (in-memory):

## chDB configuration
CHDB_ENABLED=true
CLICKHOUSE_ENABLED=false
## CHDB_DATA_PATH defaults to :memory:

For chDB with persistent storage:

## chDB configuration
CHDB_ENABLED=true
CLICKHOUSE_ENABLED=false
CHDB_DATA_PATH=/path/to/chdb/data

For MCP Inspector or remote access with HTTP transport:

CLICKHOUSE_HOST=localhost
CLICKHOUSE_USER=default
CLICKHOUSE_PASSWORD=clickhouse
CLICKHOUSE_MCP_SERVER_TRANSPORT=http
CLICKHOUSE_MCP_BIND_HOST=0.0.0.0  # Bind to all interfaces
CLICKHOUSE_MCP_BIND_PORT=4200  # Custom port (default: 8000)
CLICKHOUSE_MCP_AUTH_TOKEN=your-generated-token  # One auth mode required for HTTP/SSE (or FASTMCP_SERVER_AUTH, or CLICKHOUSE_MCP_AUTH_DISABLED=true)
CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:4200,localhost:4200,mcp.example.com:4200  # Include every Host value clients and proxies send

For local development with HTTP transport (authentication disabled):

CLICKHOUSE_HOST=localhost
CLICKHOUSE_USER=default
CLICKHOUSE_PASSWORD=clickhouse
CLICKHOUSE_MCP_SERVER_TRANSPORT=http
CLICKHOUSE_MCP_AUTH_DISABLED=true  # Only for local development!
CLICKHOUSE_MCP_ALLOWED_HOSTS=127.0.0.1:8000,localhost:8000

When using HTTP transport, the server will run on the configured port (default 8000). For example, with the above configuration:

• MCP endpoint: http://localhost:8000/mcp
• Health check: http://localhost:8000/health

You can set these variables in your environment, in a .env file, or in the Claude Desktop configuration:

{
  "mcpServers": {
    "mcp-clickhouse": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "mcp-clickhouse",
        "--python",
        "3.12",
        "mcp-clickhouse"
      ],
      "env": {
        "CLICKHOUSE_HOST": "<clickhouse-host>",
        "CLICKHOUSE_USER": "<clickhouse-user>",
        "CLICKHOUSE_PASSWORD": "<clickhouse-password>",
        "CLICKHOUSE_DATABASE": "<optional-database>",
        "CLICKHOUSE_MCP_SERVER_TRANSPORT": "stdio",
        "CLICKHOUSE_MCP_BIND_HOST": "127.0.0.1",
        "CLICKHOUSE_MCP_BIND_PORT": "8000"
      }
    }
  }
}

Note: The bind host and port settings are only used when transport is set to "http" or "sse".

Running tests

uv sync --locked --extra dev # install dev dependencies
uv run ruff check . # run linting

docker compose -f test-services/docker-compose.yaml up -d # start ClickHouse
uv run pytest -v tests
uv run pytest -v tests/test_tool.py # ClickHouse only
## Python 3.10 through 3.14 only:
CHDB_ENABLED=true uv run --extra chdb pytest -v tests/test_chdb_tool.py # chDB only

YouTube Overview

Neon MCP Server

Neon MCP Server is an open-source tool that lets you interact with your Lakebase Postgres databases on Neon in natural language.

The Model Context Protocol (MCP) is a standardized protocol designed to manage context between large language models (LLMs) and external systems. This repository provides a remote MCP Server for Neon.

Neon's MCP server acts as a bridge between natural language requests and the Neon API. Built upon MCP, it translates your requests into the necessary API calls, enabling you to manage tasks such as creating projects and branches, running queries, and performing database migrations seamlessly.

Some of the key features of the Neon MCP server include:

• Natural language interaction: Manage Neon databases using intuitive, conversational commands.
• Simplified database management: Perform complex actions without writing SQL or directly using the Neon API.
• Accessibility for non-developers: Empower users with varying technical backgrounds to interact with Neon databases.
• Database migration support: Leverage Neon's branching capabilities for database schema changes initiated via natural language.

For example, in Claude Code, or any MCP Client, you can use natural language to accomplish things with Neon, such as:

• Let's create a new Postgres database, and call it "my-database". Let's then create a table called users with the following columns: id, name, email, and password.
• I want to run a migration on my project called "my-project" that alters the users table to add a new column called "created_at".
• Can you give me a summary of all of my Neon projects and what data is in each one?

[!WARNING]
Neon MCP Server Security Considerations
The Neon MCP Server grants powerful database management capabilities through natural language requests. Always review and authorize actions requested by the LLM before execution. Ensure that only authorized users and applications have access to the Neon MCP Server.

The Neon MCP Server is intended for local development and IDE integrations only. We do not recommend using the Neon MCP Server in production environments. It can execute powerful operations that may lead to accidental or unauthorized changes.

For more information, see MCP security guidance →.

Setting up Neon MCP Server

There are a few options for setting up the Neon MCP Server:

1. Quick Setup with API Key (Cursor, VS Code, and Claude Code): Run neon@latest init to automatically configure Neon's MCP Server, agent skills, and VS Code extension with one command.
2. Remote MCP Server (OAuth Based Authentication): Connect to Neon's managed MCP server using OAuth for authentication. This method is more convenient as it eliminates the need to manage API keys. Additionally, you will automatically receive the latest features and improvements as soon as they are released.
3. Remote MCP Server (API Key Based Authentication): Connect to Neon's managed MCP server using API key for authentication. This method is useful if you want to connect a remote agent to Neon where OAuth is not available. Additionally, you will automatically receive the latest features and improvements as soon as they are released.

Prerequisites

• An MCP Client application.
• A Neon account.
• Node.js (>= v18.0.0): Download from nodejs.org.
• If IP Allow is enabled, add 34.192.103.46 and 23.22.233.166 to your allowlist (mcp.neon.tech static IPs).

For development, you'll need Node.js 22+ (pnpm is provided via Corepack — run corepack enable to activate it).

Option 1. Quick Setup with API Key

Don't want to manually create an API key?

Run neon@latest init to automatically configure Neon's MCP Server with one command:

npx neon@latest init

This works with Cursor, VS Code (GitHub Copilot), and Claude Code. It will authenticate via OAuth, create a Neon API key for you, and configure your editor automatically.

Option 2. Remote Hosted MCP Server (OAuth Based Authentication)

Connect to Neon's managed MCP server using OAuth for authentication. This is the easiest setup, requires no local installation of this server, and doesn't need a Neon API key configured in the client.

Run the following command to add the Neon MCP Server for all detected agents and editors in your workspace:

npx add-mcp "https://mcp.neon.tech/mcp?category=projects&category=branches&category=endpoints&category=querying&category=schema"

That URL publishes projects, branches, compute endpoints, querying, and schema. Preview it with /api/list-tools?category=projects&category=branches&category=endpoints&category=querying&category=schema. The unfiltered URL publishes every category:

npx add-mcp https://mcp.neon.tech/mcp

Add the -g flag to add the Neon MCP Server to the global MCP server list instead of project-scoped.

Alternatively, you can add the following "Neon" entry to your client's MCP server configuration file (e.g., mcp.json, mcp_config.json):

{
  "mcpServers": {
    "Neon": {
      "type": "http",
      "url": "https://mcp.neon.tech/mcp?category=projects&category=branches&category=endpoints&category=querying&category=schema"
    }
  }
}

Kiro: Add the following to your Kiro MCP config file (~/.kiro/settings/mcp.json for global, or .kiro/settings/mcp.json for project-scoped):

{
  "mcpServers": {
    "Neon": {
      "url": "https://mcp.neon.tech/mcp?category=projects&category=branches&category=endpoints&category=querying&category=schema"
    }
  }
}

Or use the one-click install button at the top of this README. For more information, see the Kiro MCP documentation.

• Restart or refresh your MCP client.
• An OAuth window will open in your browser. Follow the prompts to authorize your MCP client to access your Neon account.

With OAuth-based authentication, the MCP server will, by default, operate on projects under your personal Neon account. To access or manage projects that belong to an organization, you must explicitly provide either the org_id or the project_id in your prompt to MCP client.

Option 3. Remote Hosted MCP Server (API Key Based Authentication)

Remote MCP Server also supports authentication using an API key in the Authorization header if your client supports it.

Create a Neon API key in the Neon Console. Next, run the following command to add the Neon MCP Server for all detected agents and editors in your workspace:

npx add-mcp "https://mcp.neon.tech/mcp?category=projects&category=branches&category=endpoints&category=querying&category=schema" --header "Authorization: Bearer <$NEON_API_KEY>"

Alternatively, you can add the following "Neon" entry to your client's MCP server configuration file (e.g., mcp.json, mcp_config.json):

{
  "mcpServers": {
    "Neon": {
      "type": "http",
      "url": "https://mcp.neon.tech/mcp?category=projects&category=branches&category=endpoints&category=querying&category=schema",
      "headers": {
        "Authorization": "Bearer <$NEON_API_KEY>"
      }
    }
  }
}

Provide an organization's API key to limit access to projects under the organization only.

Scopes and Read-Only Mode

Neon MCP advertises OAuth scopes read and write. Your MCP client can request these, or you can make the selection in the OAuth permissions UI. * is treated as write if a client still sends it.

Read-only mode restricts which tools are available, disabling write operations like creating projects, branches, or running migrations. Read-only tools include listing projects, describing schemas, querying data, and viewing performance metrics.

You can set read-only mode in two ways:

1. Default MCP URL (editable consent): Connect with https://mcp.neon.tech/mcp and uncheck Allow writes on the authorization page. You can also choose one project, a Postgres role for SQL, and a subset of tool categories there.
2. Parameterized MCP URL (fixed consent): Put readonly, projectId, category, and/or roleName on the MCP server URL. The authorization page confirms that grant and does not offer editors. Change the URL and authorize again to change the grant.

{
  "mcpServers": {
    "Neon": {
      "url": "https://mcp.neon.tech/mcp?readonly=true"
    }
  }
}

How the query param behaves:

• API key flow: readonly=true is the way to enable read-only mode (there is no OAuth scope exchange in this flow). URL changes apply on the next request.
• OAuth flow: projectId, category, readonly, and roleName on the MCP URL are a fixed grant confirmed at authorization. readonly=true cannot be widened to writes on that page. After a token is issued, changing the URL does not widen that token; authorize again.

For OAuth registration, x-read-only is an initial Allow-writes default on editable consent. It does not lock confirmation, and it does not reduce a parameterized URL that includes readonly=false. API-key requests still honor x-read-only per request, below the readonly query param.

Note: Read-only mode restricts which tools are available. run_sql stays available and runs each query in a READ ONLY transaction. run_sql_transaction is not available; run each statement with run_sql. Those calls run separately and do not share a transaction. For transaction semantics, use a connection with writes allowed.

URL Query Params for Access Control

Grant context (scope categories, project scoping, read-only mode, pinned Postgres role) is configured via URL query params on the MCP server URL. API-key requests apply those params on each request. OAuth tokens store the grant confirmed or edited at authorization.

Read-only + project-scoped example:

{
  "mcpServers": {
    "Neon": {
      "url": "https://mcp.neon.tech/mcp?readonly=true&projectId=my-project-id"
    }
  }
}

Category-filtered example (only querying and schema tools):

{
  "mcpServers": {
    "Neon": {
      "url": "https://mcp.neon.tech/mcp?category=querying&category=schema"
    }
  }
}

Pinned Postgres role example (read-only, one project, SQL as app_reader):

{
  "mcpServers": {
    "Neon": {
      "url": "https://mcp.neon.tech/mcp?readonly=true&projectId=my-project-id&roleName=app_reader"
    }
  }
}

roleName pins the Postgres login role for the whole connection. Every SQL the server runs for you (run_sql, run_sql_transaction, explain_sql_statement, get_database_tables, describe_table_schema, describe_branch, list_slow_queries, inspect_database, and the SQL inside migrations and query tuning) logs in as that role, so Postgres grants decide what the agent can read or change. Without it, SQL runs as the database owner. Read-only mode still wraps queries in a READ ONLY transaction; the pinned role adds a limit that Postgres enforces on the login itself, so SQL that gets out of the transaction still has only the role's privileges.

• The server resolves the role's credentials internally and never returns them. get_connection_string is not available on a pinned connection.
• A role_name tool argument that differs from the pinned role is rejected. Omitting it uses the pinned role, never the owner.
• If the role does not exist or cannot log in (for example ALTER ROLE … NOLOGIN), the call fails before any SQL runs. It does not retry as another role.
• The value must be one exact Postgres role name: letters, digits, _ or $, starting with a letter or _, at most 63 characters. Anything else (empty, repeated, quoted, hyphenated) is rejected with 400, not ignored.
• The role must be able to log in (LOGIN) and must exist on each branch you query. Roles created in SQL (CREATE ROLE app_reader LOGIN PASSWORD '…') work, as do roles created in the Neon Console or API. A role with the privileges it needs, and no more, is what makes the pin useful: for read-only agents, grant SELECT on the tables they should see and do not add it to neon_superuser. create_postgres_role with access: "read_only" creates such a role from a connection without roleName; roles it creates without access join neon_superuser.
• OAuth: roleName on the MCP URL makes a fixed grant. The authorization page shows the role, and the issued token keeps it through refresh. Changing the URL later does not change the token; authorize again. With the default URL (editable consent), enter the role in the optional Postgres role field instead; leave it empty to keep the database owner. Tokens issued before this option have no pinned role and behave as before.
• API key: the role is read from the URL on each request. Anyone who can edit the connection URL and holds the API key can change or remove it, so keep the URL in configuration the agent does not control.
• The pin applies to SQL connections only. Management API tools still act with the API key or OAuth token's own access; compare_database_schema, for example, is computed by the Neon API and is not limited by the role's grants. Combine roleName with readonly=true and category to limit those tools too.

You can preview which tools are visible for any configuration using the /api/list-tools endpoint (no auth required):

curl "https://mcp.neon.tech/api/list-tools?readonly=true&category=querying"

Transport compatibility

https://mcp.neon.tech/mcp uses stateless Streamable HTTP. It supports the
MCP 2026-07-28 protocol and a stateless fallback for 2025-era clients. The
deprecated HTTP+SSE /sse and /message endpoints return 410 Gone.

Connect Streamable HTTP clients to https://mcp.neon.tech/mcp. For clients
that only support local stdio servers, put this in the client config so
mcp-remote bridges to Streamable
HTTP:

{
  "mcpServers": {
    "Neon": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.neon.tech/mcp"]
    }
  }
}

A request with a malformed Origin header receives 403 Forbidden. Any
serialized origin is accepted, including web pages, browser extensions, desktop
webviews and null, so browser-based clients can connect. Requests without an
Origin are unaffected.

Remote Server Architecture

The remote server runs as a Next.js App Router application on Vercel at mcp.neon.tech.

[!NOTE]
The root / path redirects to Neon MCP Server docs. There is no landing page.

Core implementation areas:

• app/api/[transport]/route.ts: stateless Streamable HTTP endpoint (/mcp)
• app/api/authorize/, app/callback/, app/api/token/, app/api/revoke/: OAuth flow endpoints
• app/.well-known/: OAuth discovery metadata endpoints
• mcp/: MCP server, tools, handlers, analytics, and Sentry integration
• lib/: Next.js-compatible helpers (OAuth, configuration, error handling)
• mcp/utils/read-only.ts: read-only mode and scope handling

Guides

• Neon MCP Server Guide
• Connect MCP Clients to Neon
• Cursor with Neon MCP Server
• Claude Code with Neon MCP Server
• Claude Desktop with Neon MCP Server
• Cline with Neon MCP Server
• Windsurf with Neon MCP Server
• Zed with Neon MCP Server

Features

Supported Tools

The Neon MCP Server provides the following actions, which are exposed as "tools" to MCP Clients. You can use these tools to interact with your Neon projects and databases using natural language commands.

Tool Scope Metadata

Each tool definition includes a scope category used for grant-based tool filtering and consent UX. Current categories are:

• projects
• branches
• endpoints
• snapshots
• schema
• querying
• neon_auth
• data_api
• observability
• docs
• functions
• storage
• realtime
• null (tools without a scope category: search, fetch, send_feedback)

Notes:

• Management API tools come from @neon/tools. Selectors are SDK paths (projects.list); published MCP names are verb-first (list_projects, delete_project, query_logs). Historical names stay where they already existed (describe_project, create_branch, reset_from_parent, compare_database_schema, provision_neon_auth, provision_neon_data_api, list_branch_computes).
• ?category=branches includes branch, role, and database tools (list_postgres_roles, create_postgres_database, …). A token already issued for branches gains those writes. Compute listing is ?category=endpoints. Snapshot restore is ?category=snapshots.
• Project member and permission writes are not published. list_project_members and list_project_permissions are reads.
• Schema tools (?category=schema) are get_database_tables and describe_table_schema, plus generated compare_database_schema.
• Read-only enforcement still relies on readOnlySafe and server-side read-only logic; scope is category metadata, not a standalone read/write switch.
• In project-scoped mode (?projectId=...), tools without a project path (list_projects, count_projects, create_project, get_project_consumption, get_branch_consumption, list_organizations, list_regions, search, fetch, …) are hidden. delete_project is also hidden.

Project Management:

• list_projects: Lists Neon projects. limit caps how many items come back.
• count_projects: Returns the number of active projects in an organization. org_id is optional and resolves the same way as on list_projects.
• describe_project: Fetches a Neon project by id ({ "project_id": "…" }).
• get_project_consumption, get_branch_consumption: Consumption metrics per project or per branch, grouped by billing period. Take org_id, metrics, from, to, and granularity, and need a Launch, Scale, Agent, Business, or Enterprise plan. get_branch_consumption also requires project_ids, rejects the extra_branches_month and snapshot_storage_bytes_month metrics, and is not available on the Business plan. The legacy-plan endpoint /consumption_history/projects is not published.
• create_project: Creates a Neon project and waits for the default compute. Does not return a connection string. Arguments are { "name": "…", "org_id": "…", "region_id": "…" }. Call get_connection_string after it succeeds.
• delete_project: Deletes an existing Neon project. Arguments are { "project_id": "…" }.
• list_organizations: Lists all organizations that the current user has access to. Optionally filter by organization name or ID using the search parameter.

Branch Management:

• list_branches: Lists branches in a project. Use it to resolve a branch name to a br-… id.
• list_credentials, create_credential, revoke_credential, rotate_credential: Branch-scoped credentials for Object Storage and the AI Gateway. reveal is not a tool; rotation replaces secrets in place and is not idempotent.
• create_branch: Creates a branch with a read-write compute and waits until it is ready. Does not return a connection string. Arguments are { "project_id": "…", "name": "feature-x" }. Pass no_compute: true to skip the endpoint. Call get_connection_string after it succeeds.
• reset_from_parent: Resets a branch to its parent's current HEAD ({ "project_id": "…", "branch_id": "br-…" }). Discards writes since the branch diverged. preserve_under_name is required when the branch has children; those children move to the new branch. Parent HEAD only; point-in-time restore is restore_snapshot.
• delete_branch: Deletes a branch ({ "project_id": "…", "branch_id": "br-…" }).
• describe_branch: Retrieves a tree of databases, schemas, tables, views, and functions on a branch.
• Generated branch tools take branch_id as a branch id (br-...), not a name.
• restore_snapshot: Restores a snapshot. Pass target_branch_id to restore onto an existing branch; omit it to create a new one.

Compute endpoints (?category=endpoints):

• list_postgres_endpoints, list_branch_computes, get_postgres_endpoint, create_postgres_endpoint, update_postgres_endpoint, delete_postgres_endpoint, start_postgres_endpoint, suspend_postgres_endpoint, restart_postgres_endpoint

Snapshots (?category=snapshots):

• list_snapshots, get_snapshot_schedule, set_snapshot_schedule, create_snapshot, update_snapshot, delete_snapshot, restore_snapshot

Schema (?category=schema):

• get_database_tables, describe_table_schema
• compare_database_schema: SQL schema diff of one database against another branch. database_name is required. Omitting base_branch_id compares against the parent. Optional lsn, timestamp, base_lsn, base_timestamp are point-in-time only.

SQL Query Execution:

• get_connection_string: Returns your database connection string.
• run_sql: Executes a single SQL query against a specified Neon database. Supports both read and write operations. Optional role_name logs in as that Postgres role instead of the database owner, and compute_id picks the compute; credentials stay on the server. On a connection with ?roleName=, role_name must be omitted or match it. Returns the row array with at most max_rows rows (default 100, up to 10,000); when rows were cut, a second content block holds { totalRowCount, truncated, note }. A failed query returns the Postgres SQLSTATE, error position, and any detail, hint, or context.
• run_sql_transaction: Executes a series of SQL queries within a single transaction against a Neon database. Takes the same optional role_name, compute_id, and max_rows as run_sql. max_rows applies per statement; when any statement was cut, the second block holds one summary per statement.
• get_database_tables: Lists all tables within a specified Neon database.
• describe_table_schema: Retrieves the schema definition of a specific table, detailing columns, data types, and constraints.

Database Migrations (Schema Changes):

• prepare_database_migration: Initiates a database migration process. Critically, it creates a temporary branch to apply and test the migration safely before affecting the main branch.
• complete_database_migration: Finalizes and applies a prepared database migration to the main branch. This action merges changes from the temporary migration branch and cleans up temporary resources.

SQL Querying and Optimization:

• inspect_database: Runs one of 15 predefined read-only Postgres diagnostics against a branch — relation and index sizes, index and sequential-scan usage, active queries and locks, the heaviest and most frequent queries, cache hit rate and working-set size, autovacuum and bloat estimates, and replication state. Same checks as the neon inspect db CLI command. Omit database_name to cover every database on the branch; pass a name to inspect one. Four of them need the pg_stat_statements or neon extension.
• list_slow_queries: Identifies performance bottlenecks by finding the slowest queries in a database. Requires the pg_stat_statements extension.
• explain_sql_statement: Provides detailed execution plans for SQL queries to help identify performance bottlenecks.
• prepare_query_tuning: Analyzes query performance and suggests optimizations, like index creation. Creates a temporary branch for safely testing these optimizations.
• complete_query_tuning: Finalizes query tuning by either applying optimizations to the main branch or discarding them. Cleans up the temporary tuning branch.

Neon Auth (?category=neon_auth):

• provision_neon_auth, get_auth, disable_auth, update_auth_config
• get_neon_auth_config: Secrets redacted. Reads trusted origins, localhost access, email and password, OAuth providers, the email provider, the organization, magic link, and phone number plugins, the webhook, and logs export.
• update_auth_allow_localhost, update_auth_email_and_password, update_auth_email_provider, send_auth_test_email, update_auth_plugins_organization, update_auth_plugins_magic_link, update_auth_plugins_phone_number, update_auth_webhooks, update_auth_logs_export: Change those settings. update_auth_webhooks replaces the whole webhook configuration. update_auth_logs_export turns the export of Neon Auth events to Neon Platform logs on or off; a project without logs export accepts only enabled: false.
• list_auth_oauth_providers, add_auth_oauth_provider, update_auth_oauth_provider, delete_auth_oauth_provider
• get_auth_oauth_server, update_auth_oauth_server: Configure Neon Auth as an OAuth 2.1 authorization server (including for MCP servers). Separate from the social login providers above.
• list_auth_oauth_clients, get_auth_oauth_client, create_auth_oauth_client, update_auth_oauth_client, delete_auth_oauth_client, rotate_auth_oauth_client_secret: Manage the OAuth clients of that server. create_auth_oauth_client and rotate_auth_oauth_client_secret return the client_secret once.
• list_auth_trusted_domains, add_auth_trusted_domain, delete_auth_trusted_domain
• create_auth_user, delete_auth_user, update_auth_user_role

Neon Data API (?category=data_api):

• provision_neon_data_api, get_data_api, update_data_api, delete_data_api: Manage the Data API for a branch database.

Search and Discovery:

• search: Searches across organizations, projects, and branches matching a query. Returns IDs, titles, and direct links to the Neon Console.
• fetch: Fetches detailed information about a specific organization, project, or branch using an ID (typically from the search tool).

Feedback (always available, including the no-login ?category=docs endpoint):

• send_feedback: Sends anonymous feedback to the Neon team. Only the feedback text is sent, with no account, project, or connection details. Messages are limited to 10,000 characters.

Observability (?category=observability): these tools require the Neon Platform Beta and are currently only available for projects in the aws-us-east-2 region. A branch without logs access returns HTTP 404 with reason telemetry_not_enabled.

• query_logs: Queries OpenTelemetry logs for a branch. POST in the Management API; treated as read-only by this server.
• query_loki_logs: Runs a LogQL range query on the branch's Loki-compatible read API and returns Loki's response: lines grouped by stream labels, with nanosecond timestamps.
• list_log_fields: Lists the log fields you can enumerate values for on a branch.
• list_log_field_values: Lists the distinct values of a log field within a branch and time window.

Documentation and Resources (?category=docs):

• search_docs: Searches neon.com (docs, API reference, PostgreSQL tutorial, guides, FAQs, changelog, and blog) with the same search as the neon.com search box. Takes query, optional categories (docs, api, postgresql, guides, faqs, blog, changelog), and optional limit (1-40, default 10). Returns ranked pages with title, url, slug, category, breadcrumb, heading, and excerpt; pass slug to get_doc to read the page.
• get_doc: Fetches one neon.com page as markdown. Takes slug from a search_docs hit (for example docs/guides/prisma or postgresql/tutorial/inner-join).

Functions (?category=functions):

• list_functions, get_function, update_function, delete_function, deploy_function
• list_functions_custom_domains, register_functions_custom_domain, delete_functions_custom_domain
• list_triggers, get_trigger, create_trigger, update_trigger, delete_trigger: Scheduled function triggers (type: "schedule", five-field UTC cron).

Storage (?category=storage):

• list_storage_buckets, create_storage_bucket, delete_storage_bucket
• list_storage_objects, delete_storage_object, delete_storage_objects_by_prefix
• presign_storage_object, get_storage

Realtime (?category=realtime):

• get_realtime, enable_realtime, disable_realtime: Branch Realtime state, enable (optional allowed_origins), and disable. Enable and disable wait until the change is applied.
• get_realtime_secret: The shared secret the application backend issues Realtime tokens with. Not available in read-only mode.
• rotate_realtime_secret: Replaces the shared secret and waits until the change is applied. Not idempotent. Call get_realtime_secret afterwards for the new value.

Migrations

Migrations are a way to manage changes to your database schema over time. With the Neon MCP server, LLMs are empowered to do migrations safely with separate "Start" (prepare_database_migration) and "Commit" (complete_database_migration) commands.

The "Start" command accepts a migration and runs it in a new temporary branch. Upon returning, this command hints to the LLM that it should test the migration on this branch. The LLM can then run the "Commit" command to apply the migration to the original branch.

Development

This project uses pnpm as the package manager, pinned via Corepack.

Project Structure

The MCP server code lives at the repository root, a Next.js application deployed to Vercel at mcp.neon.tech.

corepack enable
pnpm install

See CONTRIBUTING.md for how to add tools. Tool arguments are snake_case.

Local Development

## Start the Next.js dev server (for the remote MCP server)
pnpm dev

Linting and Type Checking

pnpm lint
pnpm typecheck

Environment Variables

Required for remote server runtime:

Optional:

Testing Pyramid

All tests run from the repository root.

## Unit tests
pnpm test:unit

## Integration tests
pnpm test:integration

## MCP protocol end-to-end tests (real MCP client/server tool calls)
pnpm test:e2e:mcp

## Website end-to-end tests (Playwright; provisions/validates ephemeral DB first)
pnpm test:e2e:web

## Full end-to-end suite
pnpm test:e2e

## Full test pyramid (unit + integration + e2e; used in CI)
pnpm test

Testing strategy:

• Prefer E2E for transport/protocol and user-visible behavior.
• Use integration tests for deterministic tool contracts and workflow behavior.
• Use unit tests for pure logic and edge cases.
• Avoid relying on third-party uptime in merge-gating tests; mock external dependencies in integration/unit tiers.

Deployment

Vercel deploys the remote server automatically from the repository branch configuration. Preview environments are available for pull requests.

Telemetry

The Neon MCP server collects product analytics and error reports to help us understand usage and improve reliability:

• Product analytics (Segment): when you connect with an authenticated account, the server sends an identify event with your Neon account ID, name, and email address. It also tracks session start (server_init), each tool call (tool_call), and unexpected server errors (server_error). A tool-call event includes the tool name, auth method, and client, not the tool arguments or query results. Docs-only tool calls without an account are tracked anonymously. The page shown after authorization reports that it was shown (auth_complete_viewed, with the outcome and client) and which of its buttons and links were used (auth_complete_action); the browser only sends a random page view ID, never the authorization code or your identity. Events go to track.neon.tech, Neon's own analytics endpoint.
• Error reporting, traces, and logs (Sentry): unexpected server errors are reported with stack traces and the request's method and path. Request headers, bodies, cookies, and query strings are not sent. Each request and tool call is traced with the tool name, client name, account ID, and whether the call failed, plus the session id the server assigns to 2025-era clients and the conversation id a client sends in _meta.threadId. Traces carry no tool arguments or results. The server's logs go to Sentry as well.

This collection is covered by the Neon Privacy Policy. To disable analytics when running the server yourself, set NEON_MCP_DISABLE_ANALYTICS=1. That flag does not disable Sentry.