You can connect Neon to Claude in a few minutes using the Model Context Protocol (MCP), and once it’s connected, Claude can query your Postgres databases, inspect schemas, and manage Neon projects without you copying SQL results in and out of a terminal. Neon’s OAuth also just works with a new client, unlike several other dev tools in this series. This guide covers both ways to do it: Neon’s official remote MCP server connected directly, and connecting it through a gateway if you use more than one AI client.
What the Neon MCP server actually does
Neon publishes an official remote MCP server at mcp.neon.tech/mcp. It exposes your Neon projects, branches, and Postgres databases as tools Claude can call directly. In practice that means prompts like:
- “List every table in the production database and how many rows each has.”
- “Create a new branch off main so I can test a migration safely.”
- “Run this query against the staging database and explain the result.”
- “What indexes exist on the orders table?”
Claude reads and writes through the same permissions your Neon account already has — it isn’t a read-only export or a cached copy of your schema, it’s your account acting on your behalf, project by project. That includes running arbitrary SQL if you ask it to, which is the part worth pausing on before you connect a production database.
Option 1: Connect Neon to Claude directly
Claude supports remote MCP servers natively. The short version of the setup:
- Open Claude’s connector or MCP settings.
- Add a remote server pointing at Neon’s MCP endpoint.
- Sign in with your Neon account when prompted — this is standard OAuth, so Claude never sees your Neon password, and you can revoke access from Neon’s own account settings at any time.
That’s enough for one person using Neon inside Claude. The tradeoffs show up once you add a second tool or a second person: every additional AI client (ChatGPT, Cursor, an agent) needs its own copy of that same connection, its own OAuth grant, and its own place where the config can go stale or get lost.
Option 2: Connect it once, through a gateway
If you’re already juggling more than one MCP server, or more than one AI client, wiring each pair directly gets old fast — that’s the connection sprawl we wrote about in what an MCP gateway is. The alternative is connecting Neon (and everything else) to one gateway URL, then pointing every AI client at that single URL instead of reconfiguring each one.
With gate specifically, connecting Neon looks like this: add gate’s gateway URL to Claude once, then pick Neon from the Neon server page in the directory and sign in with OAuth the same way you would directly. From then on, Neon’s tools are available in every client connected to your gate URL — Claude, ChatGPT, or Cursor — without a second setup step. You can see the full list of servers set up this way on the MCP servers page.
Why the connection method matters for a database
A database MCP server is a different risk shape than most — it isn’t just reading content, it can run queries that change or delete data. A few things worth checking before or right after you connect:
- Is it the official endpoint? Connect Neon’s documented server (
mcp.neon.tech), not a third-party mirror claiming to proxy it. - Which projects can it actually reach? An MCP connection to Neon typically covers every project your account can open, not just the one you had in mind — including production, if that’s on the same account.
- Can it run arbitrary SQL, or just the tools it exposes? Check whether the server’s query tool takes free-form SQL versus a fixed set of read operations. Free-form SQL means a prompt-injected instruction from somewhere else in a conversation could, in theory, get turned into a query against your database.
- Who else on your team can reach it? If more than one teammate connects Neon to their own AI client, you likely want a shared, revocable setup rather than everyone holding their own token — the same access-control question we cover in MCP access control for teams.
You can run a quick, no-signup check on any server’s tool list — including ones that require OAuth, once connected — with gate’s free MCP security scanner, which looks for prompt injection and hidden instructions in tool descriptions before you rely on a server day to day.
Troubleshooting the connection
A few things that commonly go wrong when connecting any remote MCP server, Neon included:
- OAuth loop or sign-in fails. Make sure you’re signed into the right Neon account and organization in your browser before authorizing — a mismatched organization is the most common cause.
- Claude can’t find a project you know exists. Neon’s tools respect your permissions in Neon itself — if a project lives in an organization you don’t have access to, Claude won’t see it either.
- Tools disappear after a Neon update. Remote servers can change their tool list without warning. If you’re connected through a gateway, that kind of change is exactly what drift detection is meant to catch.
The bottom line
Connecting Neon to Claude with MCP takes a few minutes either way: point Claude directly at Neon’s server and sign in, or connect it once through a gateway if you want the same Neon access available in every AI client you use, with the server’s tools checked before they go live. Either way, treat query access to a real database the same way you’d treat a production credential — worth a minute’s thought before you say yes.