Your agent needs to talk to Neon. Neon ships a hosted MCP server that speaks natural language and a REST API you have probably scripted against before. They are not two doors to the same room. One runs SQL and manages branches through an LLM; the other is a control plane for projects, branches, and compute. They put you on different auth paths and carry very different blast radii in production. Here is how to choose.
Both surfaces sit in front of the same serverless Postgres platform. What differs is who they were built for: the MCP server targets an LLM, the REST API targets your code. Establish the two objects before comparing them.
The Neon MCP server is Neon's official, open-source implementation, exposed as a hosted remote server at https://mcp.neon.tech/mcp over Streamable HTTP. It authenticates with OAuth (a browser consent flow, where you can pick read-only scope) or a Neon API key passed in the Authorization header for headless use. It is an official Claude connector, and it groups its tools into twelve categories spanning projects, branches, compute endpoints, snapshots, schema, SQL, Managed Better Auth, the Data API, observability, docs, functions, and object storage. The details are on the official Neon MCP server page.
One line in Neon's own documentation shapes this entire decision. Neon recommends MCP for development and testing only, and advises against connecting MCP agents to production databases. That is not boilerplate. The server grants broad database management capabilities, and it asks you to review and authorize every LLM-requested action before it runs. Treat that recommendation as a design constraint, not a disclaimer you can skip past.
The Neon API is a REST control plane at https://console.neon.tech/api/v2, authenticated with Bearer API keys; the CLI adds a browser OAuth option through neon auth. It manages projects, branches, compute endpoints, Postgres roles, databases, operations, and consumption. It does not run arbitrary SQL against your data: query execution happens over a Postgres connection, the serverless driver, or the separate Data API. Rate limits are 700 requests per minute per account, with bursts to 40 per second per route. The full surface is documented on the official Neon API reference.
The comparison that matters is not feature counts; it is what your production agent can do, under whose identity, and who owns the failure modes. Four dimensions carry it: capability coverage, the auth path, per-user isolation, and operational ownership.
The MCP server owns the data plane and the developer-workflow surface. The REST API owns the control plane and the operational surface the MCP server leaves alone.
This is the split that makes Neon different from a Slack or Notion comparison. The REST API is almost entirely control plane: it provisions and configures, but it never sees a SELECT. To read or write rows through the API path, you open a Postgres connection or enable the Data API and query that. The MCP server collapses both planes into one natural-language surface; neonmcp_run_sql opens a connection on your behalf and returns rows, while neonmcp_create_branch calls the same control plane the REST API exposes. That unification is the MCP server's real advantage, and its real risk.
The MCP path is OAuth-first. A user completes a browser consent flow, and by default the grant operates on that user's personal Neon account; acting on an organization's projects requires passing an org_id or project_id. A Neon API key in a Bearer header is the headless alternative on the same endpoint. The REST API path is API-key-first, and the keys are scoped: personal, organization, or project. Each key is shown once at creation, and revoking one takes effect immediately. Neither default is wrong; they simply hand you different credential shapes to manage.
For a single developer, either path is fine. For a multi-tenant B2B agent, which is the default, the structural problem is identical on both paths. MCP OAuth gives you a token per user. Scoped API keys give you a key per user or per organization. In neither case does the path itself store the credential outside the agent runtime, rotate it before expiry, or revoke it when a customer churns or an employee is offboarded. The token type differs; the per-tenant isolation requirement does not.
With the MCP server, Neon owns the hosting, the tool schemas, and the endpoint. You still own token storage, refresh, revocation, and tenant isolation. You also own the blast radius: because the server can run SQL, a wrong tool call reaches your data, which is exactly why Neon scopes it to development. With the REST API, you own the full stack, endpoint selection, error handling, retries, pagination, and the API key lifecycle, but the surface is control plane, so a mistaken call reprovisions a branch rather than dropping a table. That difference in worst-case outcome is the heart of the decision.
Use Neon MCP when:
Use the Neon API when:
Recommended reading: MCP is up to 32× more expensive than CLI. Here's why we still use it. and Difference Between MCP and APIs work through the same tradeoffs for adjacent surfaces.
Underneath the OAuth-versus-API-key divergence sits a single problem that neither path solves. It is the reason a database agent that demos cleanly still fails a security review months later.
Both paths produce a credential per user or per organization. Neither gives you a token vault, rotation logic, or a revocation flow. Storage has to live outside the agent runtime, encrypted at rest and isolated per tenant. Refresh has to be proactive, not reactive; waiting for a 401 to fire creates race conditions across concurrent agent threads. Revocation has to surface and invalidate every credential tied to a departing identity. In a multi-tenant product that is N credentials, each with its own lifecycle, and the path you chose only changes the token type.
Scalekit's Neon MCP connector resolves a per-user connected account on every tool call, so credentials never touch the agent runtime and every action is attributable to the user who authorized it. The same connected-account model handles storage, refresh, and revocation regardless of which path you build against. Note that Scalekit ships a single Neon connector, and it wraps the vendor MCP server; there is no separate REST connector, because the connected-account layer is what makes the MCP path safe enough to use beyond a laptop.
Scalekit's connector, neonmcp, exposes 35 LLM-optimized Neon tools behind OAuth 2.1 with Dynamic Client Registration (DCR). The pattern is always the same: resolve the current user, load only the tools their connected account is authorized to call, then execute. The sequence below follows that order.
Install the SDK and set your credentials. The connection name you create in the Scalekit dashboard must match the string in your code, character for character; a mismatch is the most common reason list_scoped_tools returns nothing.
The agent is not loading a flat Neon catalog. It is loading the tools this user's connected account is authorized to call, which is what separates a per-user agent from a shared-credential one. Resolve the identifier from your authenticated session, never from the client.
The tool definitions come back in Anthropic's native format, so they pass straight into client.messages.create. When Claude emits a tool_use block, execute_tool runs it under the user's connected account; Scalekit looks up the stored token and makes the real Neon call.
If you are on LangChain or LangGraph, the adapter returns tools already bound to one user's connected account. Instantiate them per request so a revoked grant is never served from a stale, module-level cache.
Neon's warning about production is really a warning about tool surface: a summarizer agent does not need neonmcp_delete_project. The tool_names filter above already narrows the surface, and a Virtual MCP server makes that structural. You define one server per agent role, declaring exactly which tools it can see, and each run receives a short-lived session token scoped to that user's connected accounts. A read-only analytics agent gets neonmcp_run_sql, neonmcp_inspect_database, and neonmcp_get_database_tables; a migration agent gets the branch and migration tools; neither sees the other's. One server definition serves every user, and there is no MCP server for you to deploy, host, or maintain. That is how the MCP path serves multi-tool, multi-tenant agents without inheriting the full connector's reach.
Because each call runs under a resolved connected account, every downstream Neon action is attributable to a specific user rather than a shared service account. Scalekit's auth logs record the token and connection events behind those calls, and pairing them with agent tool-call logging gives you a queryable trail of who ran which tool against which branch. For a database agent, that trail is the difference between an audit you can answer and one you cannot.
The decision is not about which surface is more capable; it is about worst-case outcome and who holds the credential.
If your agent is developer-facing, branch-scoped, and used with a person present to authorize actions, the MCP path is the faster route, and Scalekit's connector plus a scoped Virtual MCP makes it safe past the prototype stage. If your agent is headless, deterministic, and control-plane heavy, or if it must run data-plane SQL through a pinned connection rather than an LLM, build against the REST API directly. Either way, the credential management problem is identical, and that is the part that needs production-grade auth infrastructure.
Connect Neon once, then point an agent at a single user's scoped tools. Start from the Scalekit Neon MCP connector docs, browse the Neon connector overview, and compare plans on the pricing page. If you are building a database-touching agent, the DevOps assistant, incident response, and engineering standup templates are good starting points.
Building and have a question? Join the Scalekit community on Slack, or talk to an engineer for a walkthrough.
