Neon MCP Server vs Redis MCP Server

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.

Redis MCP Server

Overview

The Redis MCP Server is a natural language interface designed for agentic applications to efficiently manage and search data in Redis. It integrates seamlessly with MCP (Model Content Protocol) clients, enabling AI-driven workflows to interact with structured and unstructured data in Redis. Using this MCP Server, you can ask questions like:

• "Store the entire conversation in a stream"
• "Cache this item"
• "Store the session with an expiration time"
• "Index and search this vector"

Table of Contents

• Overview
• Features
• Tools
• Installation
  • From PyPI (recommended)
  • Testing the PyPI package
  • From GitHub
  • Development Installation
  • With Docker
• Configuration
  • Redis ACL
  • Configuration via command line arguments
  • Configuration via Environment Variables
  • EntraID Authentication for Azure Managed Redis
  • Logging
• Integrations
  • OpenAI Agents SDK
  • Augment
  • Claude Desktop
  • VS Code with GitHub Copilot
• Testing
• Example Use Cases
• Contributing
• License
• Badges
• Contact

Features

• Natural Language Queries: Enables AI agents to query and update Redis using natural language.
• Seamless MCP Integration: Works with any MCP client for smooth communication.
• Full Redis Support: Handles hashes, lists, sets, sorted sets, streams, and more.
• Search & Filtering: Supports efficient data retrieval and searching in Redis.
• Scalable & Lightweight: Designed for high-performance data operations.
• EntraID Authentication: Native support for Azure Active Directory authentication with Azure Managed Redis.
• The Redis MCP Server supports the stdio transport. Support to the stremable-http transport will be added in the future.

Tools

This MCP Server provides tools to manage the data stored in Redis.

• string tools to set, get strings with expiration. Useful for storing simple configuration values, session data, or caching responses.
• hash tools to store field-value pairs within a single key. The hash can store vector embeddings. Useful for representing objects with multiple attributes, user profiles, or product information where fields can be accessed individually.
• list tools with common operations to append and pop items. Useful for queues, message brokers, or maintaining a list of most recent actions.
• set tools to add, remove and list set members. Useful for tracking unique values like user IDs or tags, and for performing set operations like intersection.
• sorted set tools to manage data for e.g. leaderboards, priority queues, or time-based analytics with score-based ordering.
• pub/sub functionality to publish messages, create stateful channel or pattern subscriptions, and read queued messages using returned subscription handles. Useful for real-time notifications, chat applications, or distributing updates to multiple clients.
• streams tools to add, read, delete, create and destroy consumer groups, and acknowledge processed entries in data streams. Useful for event sourcing, activity feeds, and worker-based event processing with Redis Streams consumer groups.
• JSON tools to store, retrieve, and manipulate JSON documents in Redis. Useful for complex nested data structures, document databases, or configuration management with path-based access.

Additional tools.

• docs tool to search Redis documentation, tutorials, and best practices using natural language questions (backed by the MCP_DOCS_SEARCH_URL HTTP API).
• query engine tools to manage vector indexes and perform vector search
• server management tool to retrieve information about the database

Installation

The Redis MCP Server is available as a PyPI package and as direct installation from the GitHub repository.

From PyPI (recommended)

Configuring the latest Redis MCP Server version from PyPI, as an example, can be done importing the following JSON configuration in the desired framework or tool.
The uvx command will download the server on the fly (if not cached already), create a temporary environment, and then run it.

{
  "mcpServers": {
    "RedisMCPServer": {
      "command": "uvx",
      "args": [
        "--from",
        "redis-mcp-server@latest",
        "redis-mcp-server",
        "--url",
        "\"redis://localhost:6379/0\""
      ]
    }
  }
}

URL specification

The format to specify the --url argument follows the redis and rediss schemes:

redis://user:secret@localhost:6379/0?foo=bar&qux=baz

As an example, you can easily connect to a localhost server with:

redis://localhost:6379/0

Where 0 is the logical database you'd like to connect to.

For an encrypted connection to the database (e.g., connecting to a Redis Cloud database), you'd use the rediss scheme.

rediss://user:secret@localhost:6379/0?foo=bar&qux=baz

To verify the server's identity, specify ssl_ca_certs.

rediss://user:secret@hostname:port?ssl_cert_reqs=required&ssl_ca_certs=path_to_the_certificate

For an unverified connection, set ssl_cert_reqs to none

rediss://user:secret@hostname:port?ssl_cert_reqs=none

Configure your connection using the available options in the section "Available CLI Options".

Testing the PyPI package

You can install the package as follows:

pip install redis-mcp-server

And start it using uv the package in your environment.

uv python install 3.14
uv sync
uv run redis-mcp-server --url redis://localhost:6379/0

However, starting the MCP Server is most useful when delegate to the framework or tool where this MCP Server is configured.

From GitHub

You can configure the desired Redis MCP Server version with uvx, which allows you to run it directly from GitHub (from a branch, or use a tagged release).

It is recommended to use a tagged release, the main branch is under active development and may contain breaking changes.

As an example, you can execute the following command to run the 0.2.0 release:

uvx --from git+https://github.com/redis/mcp-redis.git@0.2.0 redis-mcp-server --url redis://localhost:6379/0

Check the release notes for the latest version in the Releases section.
Additional examples are provided below.

## Run with Redis URI
uvx --from git+https://github.com/redis/mcp-redis.git redis-mcp-server --url redis://localhost:6379/0

## Run with Redis URI and SSL
uvx --from git+https://github.com/redis/mcp-redis.git redis-mcp-server --url "rediss://<USERNAME>:<PASSWORD>@<HOST>:<PORT>?ssl_cert_reqs=required&ssl_ca_certs=<PATH_TO_CERT>"

## Run with individual parameters
uvx --from git+https://github.com/redis/mcp-redis.git redis-mcp-server --host localhost --port 6379 --password mypassword

## See all options
uvx --from git+https://github.com/redis/mcp-redis.git redis-mcp-server --help

Development Installation

For development or if you prefer to clone the repository:

## Clone the repository
git clone https://github.com/redis/mcp-redis.git
cd mcp-redis

## Install dependencies using uv
uv venv
source .venv/bin/activate
uv sync

## Run with CLI interface
uv run redis-mcp-server --help

## Or run the main file directly (uses environment variables)
uv run src/main.py

Once you cloned the repository, installed the dependencies and verified you can run the server, you can configure Claude Desktop or any other MCP Client to use this MCP Server running the main file directly (it uses environment variables). This is usually preferred for development.
The following example is for Claude Desktop, but the same applies to any other MCP Client.

1. Specify your Redis credentials and TLS configuration
2. Retrieve your uv command full path (e.g. which uv)
3. Edit the claude_desktop_config.json configuration file
   • on a MacOS, at ~/Library/Application\ Support/Claude/

{
    "mcpServers": {
        "redis": {
            "command": "<full_path_uv_command>",
            "args": [
                "--directory",
                "<your_mcp_server_directory>",
                "run",
                "src/main.py"
            ],
            "env": {
                "REDIS_HOST": "<your_redis_database_hostname>",
                "REDIS_PORT": "<your_redis_database_port>",
                "REDIS_PWD": "<your_redis_database_password>",
                "REDIS_SSL": True|False,
                "REDIS_SSL_CA_PATH": "<your_redis_ca_path>",
                "REDIS_CLUSTER_MODE": True|False
            }
        }
    }
}

You can troubleshoot problems by tailing the log file.

tail -f ~/Library/Logs/Claude/mcp-server-redis.log

With Docker

You can use a dockerized deployment of this server. You can either build your own image or use the official Redis MCP Docker image.

If you'd like to build your own image, the Redis MCP Server provides a Dockerfile. Build this server's image with:

docker build -t mcp-redis .

Finally, configure the client to create the container at start-up. An example for Claude Desktop is provided below. Edit the claude_desktop_config.json and add:

{
  "mcpServers": {
    "redis": {
      "command": "docker",
      "args": ["run",
                "--rm",
                "--name",
                "redis-mcp-server",
                "-i",
                "-e", "REDIS_HOST=<redis_hostname>",
                "-e", "REDIS_PORT=<redis_port>",
                "-e", "REDIS_USERNAME=<redis_username>",
                "-e", "REDIS_PWD=<redis_password>",
                "mcp-redis"]
    }
  }
}

To use the official Redis MCP Docker image, just replace your image name (mcp-redis in the example above) with mcp/redis.

Configuration

The Redis MCP Server can be configured in two ways: via command line arguments or via environment variables.
The precedence is: command line arguments > environment variables > default values.

Redis ACL

You can configure Redis ACL to restrict the access to the Redis database. For example, to create a read-only user:

127.0.0.1:6379> ACL SETUSER readonlyuser on >mypassword ~* +@read -@write

Configure the user via command line arguments or environment variables.

Configuration via command line arguments

When using the CLI interface, you can configure the server with command line arguments:

## Basic Redis connection
uvx --from redis-mcp-server@latest redis-mcp-server \
  --host localhost \
  --port 6379 \
  --password mypassword

## Using Redis URI (simpler)
uvx --from redis-mcp-server@latest redis-mcp-server \
  --url redis://user:pass@localhost:6379/0

## SSL connection
uvx --from redis-mcp-server@latest redis-mcp-server \
  --url rediss://user:pass@redis.example.com:6379/0

## See all available options
uvx --from redis-mcp-server@latest redis-mcp-server --help

Available CLI Options:

• --url - Redis connection URI (redis://user:pass@host:port/db)
• --host - Redis hostname (default: 127.0.0.1)
• --port - Redis port (default: 6379)
• --db - Redis database number (default: 0)
• --username - Redis username
• --password - Redis password
• --ssl - Enable SSL connection
• --ssl-ca-path - Path to CA certificate file
• --ssl-keyfile - Path to SSL key file
• --ssl-certfile - Path to SSL certificate file
• --ssl-cert-reqs - SSL certificate requirements (default: required)
• --ssl-ca-certs - Path to CA certificates file
• --cluster-mode - Enable Redis cluster mode

Configuration via Environment Variables

If desired, you can use environment variables. Defaults are provided for all variables.

EntraID Authentication for Azure Managed Redis

The Redis MCP Server supports EntraID (Azure Active Directory) authentication for Azure Managed Redis, enabling OAuth-based authentication with automatic token management.

Authentication Providers

Service Principal Authentication - Application-based authentication using client credentials:

export REDIS_ENTRAID_AUTH_FLOW=service_principal
export REDIS_ENTRAID_CLIENT_ID=your-client-id
export REDIS_ENTRAID_CLIENT_SECRET=your-client-secret
export REDIS_ENTRAID_TENANT_ID=your-tenant-id

Managed Identity Authentication - For Azure-hosted applications:

## System-assigned managed identity
export REDIS_ENTRAID_AUTH_FLOW=managed_identity
export REDIS_ENTRAID_IDENTITY_TYPE=system_assigned

## User-assigned managed identity
export REDIS_ENTRAID_AUTH_FLOW=managed_identity
export REDIS_ENTRAID_IDENTITY_TYPE=user_assigned
export REDIS_ENTRAID_USER_ASSIGNED_CLIENT_ID=your-identity-client-id

Default Azure Credential - Automatic credential discovery (recommended for development):

export REDIS_ENTRAID_AUTH_FLOW=default_credential
export REDIS_ENTRAID_SCOPES=https://redis.azure.com/.default

EntraID Configuration Variables

Key Features

• Automatic token renewal - Background token refresh with no manual intervention
• Graceful fallback - Falls back to standard Redis authentication when EntraID not configured
• Multiple auth flows - Supports Service Principal, Managed Identity, and Default Azure Credential
• Enterprise ready - Designed for Azure Managed Redis with centralized identity management

Example Configuration

For local development with Azure CLI:

## Login with Azure CLI
az login

## Configure MCP server
export REDIS_ENTRAID_AUTH_FLOW=default_credential
export REDIS_URL=redis://your-azure-redis.redis.cache.windows.net:6379

For production with Service Principal:

export REDIS_ENTRAID_AUTH_FLOW=service_principal
export REDIS_ENTRAID_CLIENT_ID=your-app-client-id
export REDIS_ENTRAID_CLIENT_SECRET=your-app-secret
export REDIS_ENTRAID_TENANT_ID=your-tenant-id
export REDIS_URL=redis://your-azure-redis.redis.cache.windows.net:6379

For Azure-hosted applications with Managed Identity:

export REDIS_ENTRAID_AUTH_FLOW=managed_identity
export REDIS_ENTRAID_IDENTITY_TYPE=system_assigned
export REDIS_URL=redis://your-azure-redis.redis.cache.windows.net:6379

There are several ways to set environment variables:

1. Using a .env File:
   Place a .env file in your project directory with key-value pairs for each environment variable. Tools like python-dotenv, pipenv, and uv can automatically load these variables when running your application. This is a convenient and secure way to manage configuration, as it keeps sensitive data out of your shell history and version control (if .env is in .gitignore).
   For example, create a .env file with the following content from the .env.example file provided in the repository:

cp .env.example .env

Then edit the .env file to set your Redis configuration:

OR,

2. Setting Variables in the Shell:
   You can export environment variables directly in your shell before running your application. For example:

export REDIS_HOST=your_redis_host
export REDIS_PORT=6379
## Other variables will be set similarly...

This method is useful for temporary overrides or quick testing.

Logging

The server uses Python's standard logging and is configured at startup. By default it logs at WARNING and above. You can change verbosity with the MCP_REDIS_LOG_LEVEL environment variable.

• Accepted values (case-insensitive): DEBUG, INFO, WARNING, ERROR, CRITICAL, NOTSET
• Aliases supported: WARN → WARNING, FATAL → CRITICAL
• Numeric values are also accepted, including signed (e.g., "10", "+20")
• Default when unset or unrecognized: WARNING

Handler behavior

• If the host (e.g., uv, VS Code, pytest) already installed console handlers, the server will NOT add its own; it only lowers overly-restrictive handler thresholds so your chosen level is not filtered out. It will never raise a handler's threshold.
• If no handlers are present, the server adds a single stderr StreamHandler with a simple format.

Examples

## See normal lifecycle messages
MCP_REDIS_LOG_LEVEL=INFO uv run src/main.py

## Very verbose for debugging
MCP_REDIS_LOG_LEVEL=DEBUG uvx --from redis-mcp-server@latest redis-mcp-server --url redis://localhost:6379/0

In MCP client configs that support env, add it alongside your Redis settings. For example:

{
  "mcpServers": {
    "redis": {
      "command": "uvx",
      "args": ["--from", "redis-mcp-server@latest", "redis-mcp-server", "--url", "redis://localhost:6379/0"],
      "env": {
        "REDIS_HOST": "localhost",
        "REDIS_PORT": "6379",
        "MCP_REDIS_LOG_LEVEL": "INFO"
      }
    }
  }
}

Integrations

Integrating this MCP Server to development frameworks like OpenAI Agents SDK, or with tools like Claude Desktop, VS Code, or Augment is described in the following sections.

OpenAI Agents SDK

Integrate this MCP Server with the OpenAI Agents SDK. Read the documents to learn more about the integration of the SDK with MCP.

Install the Python SDK.

pip install openai-agents

Configure the OpenAI token:

export OPENAI_API_KEY="<openai_token>"

And run the application.

python3.14 redis_assistant.py

You can troubleshoot your agent workflows using the OpenAI dashboard.

Augment

The preferred way of configuring the Redis MCP Server in Augment is to use the Easy MCP feature.

You can also configure the Redis MCP Server in Augment manually by importing the server via JSON:

{
  "mcpServers": {
    "Redis MCP Server": {
      "command": "uvx",
      "args": [
        "--from",
        "redis-mcp-server@latest",
        "redis-mcp-server",
        "--url",
        "redis://localhost:6379/0"
      ]
    }
  }
}

Claude Desktop

The simplest way to configure MCP clients is using uvx. Add the following JSON to your claude_desktop_config.json, remember to provide the full path to uvx.

Basic Redis connection:

{
  "mcpServers": {
    "redis-mcp-server": {
        "type": "stdio",
        "command": "/Users/mortensi/.local/bin/uvx",
        "args": [
            "--from", "redis-mcp-server@latest",
            "redis-mcp-server",
            "--url", "redis://localhost:6379/0"
        ]
    }
  }
}

Azure Managed Redis with EntraID authentication:

{
  "mcpServers": {
    "redis-mcp-server": {
        "type": "stdio",
        "command": "/Users/mortensi/.local/bin/uvx",
        "args": [
            "--from", "redis-mcp-server@latest",
            "redis-mcp-server",
            "--url", "redis://your-azure-redis.redis.cache.windows.net:6379"
        ],
        "env": {
            "REDIS_ENTRAID_AUTH_FLOW": "default_credential",
            "REDIS_ENTRAID_SCOPES": "https://redis.azure.com/.default"
        }
    }
  }
}

VS Code with GitHub Copilot

To use the Redis MCP Server with VS Code, you must nable the agent mode tools. Add the following to your settings.json:

{
  "chat.agent.enabled": true
}

You can start the GitHub desired version of the Redis MCP server using uvx by adding the following JSON to your mcp.json file:

"servers": {
  "redis": {
    "type": "stdio",
    "command": "uvx",
    "args": [
      "--from", "redis-mcp-server@latest",
      "redis-mcp-server",
      "--url", "redis://localhost:6379/0"
    ]
  },
}

Suppressing uvx Installation Messages

If you want to suppress uvx installation messages that may appear as warnings in MCP client logs, use the -qq flag:

"servers": {
  "redis": {
    "type": "stdio",
    "command": "uvx",
    "args": [
      "-qq",
      "--from", "redis-mcp-server@latest",
      "redis-mcp-server",
      "--url", "redis://localhost:6379/0"
    ]
  },
}

The -qq flag enables silent mode, which suppresses "Installed X packages" messages that uvx writes to stderr during package installation.

Alternatively, you can start the server using uv and configure your mcp.json. This is usually desired for development.

// mcp.json
{
  "servers": {
    "redis": {
      "type": "stdio",
      "command": "<full_path_uv_command>",
      "args": [
        "--directory",
        "<your_mcp_server_directory>",
        "run",
        "src/main.py"
      ],
      "env": {
        "REDIS_HOST": "<your_redis_database_hostname>",
        "REDIS_PORT": "<your_redis_database_port>",
        "REDIS_USERNAME": "<your_redis_database_username>",
        "REDIS_PWD": "<your_redis_database_password>",
      }
    }
  }
}

For more information, see the VS Code documentation.

Tip: You can prompt Copilot chat to use the Redis MCP tools by including #redis in your message.

Note: Starting with VS Code v1.102,
MCP servers are now stored in a dedicated mcp.json file instead of settings.json.

Testing

You can use the MCP Inspector for visual debugging of this MCP Server.

npx @modelcontextprotocol/inspector uv run src/main.py

Example Use Cases

• AI Assistants: Enable LLMs to fetch, store, and process data in Redis.
• Chatbots & Virtual Agents: Retrieve session data, manage queues, and personalize responses.
• Data Search & Analytics: Query Redis for real-time insights and fast lookups.
• Event Processing: Manage event streams with Redis Streams.

Contributing

1. Fork the repo
2. Create a new branch (feature-branch)
3. Commit your changes
4. Push to your branch and submit a PR!

License

This project is licensed under the MIT License.

Badges

Contact

For questions or support, reach out via GitHub Issues.

Alternatively, you can join the Redis Discord server and ask in the #redis-mcp-server channel.