Neon MCP
Manage Neon projects, branches, databases, and development workflows.
Verdict
Common use cases
- Query user metrics during product reviews
- Inspect schema before deploying migrations
- Generate SQL from natural language requests
- Audit recent database changes in standups
- Prototype table designs with the team
Integration
- Vendor
- Neon MCP
- Category
- other
- Auth
- OAUTH2
- Composio slug
neon_mcp
Tools
Setup
Setup guide
- 11. In Switchy, open your workspace settings and navigate to the Integrations tab. 2. Click 'Add Integration' and select Neon MCP from the list. 3. You'll be redirected to Neon's authorization page — sign in with your Neon credentials if prompted. 4. Grant Switchy read and write access to the databases you want your team to query (you can revoke specific databases later in Neon's dashboard). 5. After authorizing, you'll return to Switchy and see Neon MCP listed as connected. 6. Open any Project, type '@Neon' in the chat, and ask it to list your databases or describe a table schema — if it responds with real data, the connection is live. 7. To test a write operation, ask it to create a test table in a development database and confirm the table appears in your Neon console.
What teammates see: by default, memories from Neon MCP are scoped to the Project (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
Compatibility data appears once enough Projects have used this MCP together with a given model.
How Switchy teams use it
Starter prompts
List All Databases
@Neon list all databases in my account and show me the region and creation date for each one.
Describe Table Schema
@Neon describe the schema for the 'users' table in the production database, including column names, types, and any indexes.
Run Analytics Query
@Neon run this query on the analytics database: SELECT DATE(created_at), COUNT(*) FROM signups WHERE created_at > NOW() - INTERVAL '7 days' GROUP BY DATE(created_at);
Check Recent Migrations
@Neon show me the five most recent migration scripts applied to the staging database, with timestamps and author info if available.
Generate CREATE TABLE
@Neon generate a CREATE TABLE statement for a 'subscriptions' table with columns for user_id, plan_name, start_date, end_date, and status.
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@neon show me all databases in my project and their current storage usage
Based on your Neon account, you have 3 databases across 2 projects. Project 'production-api' contains databases 'main' (2.4 GB) and 'analytics' (890 MB). Project 'staging' contains database 'test' (340 MB). All databases are currently active with compute endpoints running. Total storage across projects: 3.63 GB of your 10 GB plan limit.
This example demonstrates read access to project and database metadata. Requires OAuth2 connection with read permissions on projects and databases. Storage figures reflect point-in-time snapshots and may lag by several minutes during active write operations.
@neon create a new branch called 'feature-auth-refactor' from my main database for testing schema changes
Created branch 'feature-auth-refactor' from database 'main' in project 'production-api'. The branch includes a full copy of your current schema and data as of 2 minutes ago. Connection string: postgres://user:pass@ep-branch-123.us-east-2.aws.neon.tech/main. This branch has its own isolated compute and will not affect your production database. Branch will auto-suspend after 5 minutes of inactivity.
This example shows Neon's branching capability for safe schema experimentation. Creates a real database branch with associated compute resources. Be aware that branches count toward your project's storage quota and compute hour limits. Requires write permissions on the target project.
@neon analyze the query performance on my production database over the last 24 hours and suggest which indexes might help
Reviewed query logs from 'production-api/main' over the past 24 hours. Found 3 slow query patterns: (1) User lookup by email (avg 340ms, 2,400 executions) would benefit from an index on users.email. (2) Order history joins (avg 890ms, 450 executions) could use a composite index on orders(user_id, created_at). (3) Product search (avg 1.2s, 180 executions) might improve with a GIN index on products.search_vector if you're using full-text search. Total slow query time: ~47 minutes of compute.
This example pairs Neon's query metrics with AI reasoning to surface optimization opportunities. Effectiveness depends on query log retention settings and whether your plan includes performance insights. Suggestions are heuristic — always test index changes on a branch before applying to production.
Use-case deep-dives
When OAuth2 overhead pays off for ephemeral dev databases
A 6-person engineering team runs internal hackathons every quarter. They need fresh Postgres instances spun up in minutes, then torn down two days later. Neon MCP fits this pattern if your team already uses OAuth2 for other integrations—the auth flow is one-time setup, and the MCP can provision branches or databases on demand without manual console work. The trade-off: if you're only using Neon for one or two long-lived staging databases, the OAuth2 ceremony is overkill compared to just using Neon's dashboard. This MCP wins when you're creating and destroying databases frequently enough that API access saves more time than the initial auth setup costs. If your team spins up fewer than 5 databases a month, skip the MCP and use the web UI.
Why this MCP matters for debugging production schema drift
A 3-person support team at a SaaS startup needs to verify customer-reported data issues without direct database access. Neon MCP can expose read-only schema inspection—table lists, column types, index health—through Switchy's shared workspace, so support engineers confirm schema state before escalating to engineering. The constraint: this only works if Neon's API surfaces schema metadata (not just CRUD operations). If the MCP is limited to database lifecycle management (create, delete, branch), it won't help here. Check the tool list once it's populated—if you see schema introspection endpoints, this is a clean win for support workflows. If not, you're better off with a direct Postgres MCP that connects to Neon instances.
When Neon's branching model justifies MCP automation
A 10-person product team runs feature branches in CI, and each branch needs an isolated Postgres instance for integration tests. Neon's copy-on-write branching is fast enough to create a database per PR in seconds. The MCP automates this: Switchy triggers branch creation when a PR opens, runs tests against that branch, then deletes it on merge. This workflow assumes the MCP exposes branch lifecycle tools and your CI can call Switchy's API. The boundary: if your test suite runs in under 2 minutes and you open fewer than 10 PRs a day, the branching overhead isn't worth the MCP setup—just use a single shared test database. Above that threshold, Neon MCP turns branch-per-PR from a manual chore into a one-line automation.
Frequently asked
What does the Neon MCP integration do in Switchy?
It connects your Switchy workspace to Neon's serverless Postgres platform, letting AI agents query database schemas, run read-only SQL, and retrieve connection strings without leaving the chat. You authenticate once via OAuth2, then any team member with access can ask questions about your database structure or pull specific data sets for analysis.
Do I need admin rights in Neon to connect this MCP?
Yes. The OAuth2 flow requires permissions to list projects, access connection details, and read database schemas. If you're not an admin in your Neon organisation, you'll hit a permissions error during setup. Ask whoever manages your Neon account to either connect it themselves or grant you the necessary role first.
Can this MCP write data to my Neon database?
No. The integration is read-only by design. AI agents can query tables, inspect schemas, and pull connection strings, but they cannot insert, update, or delete rows. If you need to modify data, you'll still use Neon's console, your application code, or a direct SQL client with write credentials.
Why use this instead of just querying Neon directly in my code?
You skip the context-switching. Instead of opening the Neon console, finding the right project, copying a connection string, then pasting it into a SQL client, you ask Switchy's AI to pull the schema or run a query inline. It's faster for exploratory work and keeps the conversation in one place when you're debugging with teammates.
Does connecting Neon count against my Switchy plan limits?
The OAuth2 connection itself doesn't count as a seat or user. However, every message that invokes the Neon MCP consumes tokens from your plan's usage allowance, just like any other AI interaction. If your team runs heavy SQL queries through Switchy daily, monitor your token spend in the billing dashboard.