Neon

mcp

MCP server for interacting with Neon Management API and databases.

4.4K

19 Tools

Packaged by

Requires Secrets

Add to Docker Desktop

Version 4.43 or later needs to be installed to add the server automatically

Overview Tools (19)Config Manual installation

Docker Hub⁠Github repository⁠

Tools

Name Description

complete_database_migration Complete a database migration when the user confirms the migration is ready to be applied to the main branch. This tool also lets the client know that the temporary branch created by the prepare_database_migration tool has been deleted.

prepare_database_migration <use_case> This tool performs database schema migrations by automatically generating and executing DDL statements. Supported operations: CREATE operations: - Add new columns (e.g., "Add email column to users table") - Create new tables (e.g., "Create posts table with title and content columns") - Add constraints (e.g., "Add unique constraint on users.email") ALTER operations: - Modify column types (e.g., "Change posts.views to bigint") - Rename columns (e.g., "Rename user_name to username in users table") - Add/modify indexes (e.g., "Add index on posts.title") - Add/modify foreign keys (e.g., "Add foreign key from posts.user_id to users.id") DROP operations: - Remove columns (e.g., "Drop temporary_field from users table") - Drop tables (e.g., "Drop the old_logs table") - Remove constraints (e.g., "Remove unique constraint from posts.slug") The tool will: 1. Parse your natural language request 2. Generate appropriate SQL 3. Execute in a temporary branch for safety 4. Verify the changes before applying to main branch Project ID and database name will be automatically extracted from your request. If the database name is not provided, the default neondb or first available database is used. </use_case> <workflow> 1. Creates a temporary branch 2. Applies the migration SQL in that branch 3. Returns migration details for verification </workflow> <important_notes> After executing this tool, you MUST: 1. Test the migration in the temporary branch using the 'run_sql' tool 2. Ask for confirmation before proceeding 3. Use 'complete_database_migration' tool to apply changes to main branch </important_notes> <example> For a migration like: ALTER TABLE users ADD COLUMN last_login TIMESTAMP; You should test it with: SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'users' AND column_name = 'last_login'; You can use 'run_sql' to test the migration in the temporary branch that this tool creates. </example> <next_steps> After executing this tool, you MUST follow these steps: 1. Use 'run_sql' to verify changes on temporary branch 2. Follow these instructions to respond to the client: <response_instructions> <instructions> Provide a brief confirmation of the requested change and ask for migration commit approval. You MUST include ALL of the following fields in your response: - Migration ID (this is required for commit and must be shown first) - Temporary Branch Name (always include exact branch name) - Temporary Branch ID (always include exact ID) - Migration Result (include brief success/failure status) Even if some fields are missing from the tool's response, use placeholders like "not provided" rather than omitting fields. </instructions> <do_not_include> IMPORTANT: Your response MUST NOT contain ANY technical implementation details such as: - Data types (e.g., DO NOT mention if a column is boolean, varchar, timestamp, etc.) - Column specifications or properties - SQL syntax or statements - Constraint definitions or rules - Default values - Index types - Foreign key specifications Keep the response focused ONLY on confirming the high-level change and requesting approval. <example> INCORRECT: "I've added a boolean is_published column to the posts table..." CORRECT: "I've added the is_published column to the posts table..." </example> </do_not_include> <example> I've verified that [requested change] has been successfully applied to a temporary branch. Would you like to commit the migration [migration_id] to the main branch? Migration Details: - Migration ID (required for commit) - Temporary Branch Name - Temporary Branch ID - Migration Result </example> </response_instructions> 3. If approved, use 'complete_database_migration' tool with the migration_id </next_steps> <error_handling> On error, the tool will: 1. Automatically attempt ONE retry of the exact same operation 2. If the retry fails: - Terminate execution - Return error details - DO NOT attempt any other tools or alternatives Error response will include: - Original error details - Confirmation that retry was attempted - Final error state Important: After a failed retry, you must terminate the current flow completely. Do not attempt to use alternative tools or workarounds. </error_handling>

Name	Description
`complete_database_migration`	Complete a database migration when the user confirms the migration is ready to be applied to the main branch. This tool also lets the client know that the temporary branch created by the prepare_database_migration tool has been deleted.
`prepare_database_migration`	<use_case> This tool performs database schema migrations by automatically generating and executing DDL statements. Supported operations: CREATE operations: - Add new columns (e.g., "Add email column to users table") - Create new tables (e.g., "Create posts table with title and content columns") - Add constraints (e.g., "Add unique constraint on users.email") ALTER operations: - Modify column types (e.g., "Change posts.views to bigint") - Rename columns (e.g., "Rename user_name to username in users table") - Add/modify indexes (e.g., "Add index on posts.title") - Add/modify foreign keys (e.g., "Add foreign key from posts.user_id to users.id") DROP operations: - Remove columns (e.g., "Drop temporary_field from users table") - Drop tables (e.g., "Drop the old_logs table") - Remove constraints (e.g., "Remove unique constraint from posts.slug") The tool will: 1. Parse your natural language request 2. Generate appropriate SQL 3. Execute in a temporary branch for safety 4. Verify the changes before applying to main branch Project ID and database name will be automatically extracted from your request. If the database name is not provided, the default neondb or first available database is used. </use_case> <workflow> 1. Creates a temporary branch 2. Applies the migration SQL in that branch 3. Returns migration details for verification </workflow> <important_notes> After executing this tool, you MUST: 1. Test the migration in the temporary branch using the 'run_sql' tool 2. Ask for confirmation before proceeding 3. Use 'complete_database_migration' tool to apply changes to main branch </important_notes> <example> For a migration like: ALTER TABLE users ADD COLUMN last_login TIMESTAMP; You should test it with: SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'users' AND column_name = 'last_login'; You can use 'run_sql' to test the migration in the temporary branch that this tool creates. </example> <next_steps> After executing this tool, you MUST follow these steps: 1. Use 'run_sql' to verify changes on temporary branch 2. Follow these instructions to respond to the client: <response_instructions> <instructions> Provide a brief confirmation of the requested change and ask for migration commit approval. You MUST include ALL of the following fields in your response: - Migration ID (this is required for commit and must be shown first) - Temporary Branch Name (always include exact branch name) - Temporary Branch ID (always include exact ID) - Migration Result (include brief success/failure status) Even if some fields are missing from the tool's response, use placeholders like "not provided" rather than omitting fields. </instructions> <do_not_include> IMPORTANT: Your response MUST NOT contain ANY technical implementation details such as: - Data types (e.g., DO NOT mention if a column is boolean, varchar, timestamp, etc.) - Column specifications or properties - SQL syntax or statements - Constraint definitions or rules - Default values - Index types - Foreign key specifications Keep the response focused ONLY on confirming the high-level change and requesting approval. <example> INCORRECT: "I've added a boolean is_published column to the posts table..." CORRECT: "I've added the is_published column to the posts table..." </example> </do_not_include> <example> I've verified that [requested change] has been successfully applied to a temporary branch. Would you like to commit the migration [migration_id] to the main branch? Migration Details: - Migration ID (required for commit) - Temporary Branch Name - Temporary Branch ID - Migration Result </example> </response_instructions> 3. If approved, use 'complete_database_migration' tool with the migration_id </next_steps> <error_handling> On error, the tool will: 1. Automatically attempt ONE retry of the exact same operation 2. If the retry fails: - Terminate execution - Return error details - DO NOT attempt any other tools or alternatives Error response will include: - Original error details - Confirmation that retry was attempted - Final error state Important: After a failed retry, you must terminate the current flow completely. Do not attempt to use alternative tools or workarounds. </error_handling>

Manual installation

You can install the MCP server using:

Installation for

Neon

Related servers

Couchbase

MongoDB

Astra DB

Atlan MCP Server