MCPs are powerful abstractions, but that power also means risk. A misconfigured or overly permissive MCP server can expose sensitive data, execute unintended actions, and simply ruin your day.

We maintain an MCP server at Neon, but we want you to use it safely. Here’s a quick checksheet with advice we’ve gathered from experience:

Keep MCP in dev only

MCP servers are much safer living in development environments and your IDE, not in an environment where they have access to things like a production database. In Neon, the best workflow is to connect the MCP server to a development branch.

Work with anonymized or sample data

Don’t connect your MCP server to a database that contains sensitive user data. This is will be already covered if you’re following the previous rule (staying in dev). In Neon, if you want to connect your agent or IDE to realistic datasets, you can use an anonymized dev branch.

Limit what tools are exposed

Every MCP server exposes a set of tools that define what it can do, from reading schemas to creating or dropping tables. You don’t need to expose all of them: you can keep your configuration minimal for what you’re trying to achieve. The fewer write-capable tools your MCP server exposes, the smaller your risk surface, and the less you’ll need to worry about an AI doing something it shouldn’t.

Use read-only mode

It’s much safer if instead of making sure you’re not giving to much power to your MCP by hand, you have the option to use a pre-packaged read-only mode version. We recently shipped this for the Neon MCP server:

When the read-only mode is enabled, the server will only expose safe, non-destructive commands. Even if an LLM / IDE attempts to run a destructive operation, e.g. CREATE TABLE, ALTER, UPDATE, or DELETE, it will fail with a read-only transaction error. 

Supervise what the MCP does 

Even with good configuration, your MCPs will execute real operations, they’re not simulations. Human reviews are important. When the AI suggests changes before implementing them, make sure it’s something you want. In Neon’s MCP server, every database operation is visible before it runs, giving you the opportunity to inspect and approve the SQL or action first. Don’t let the AI apply changes automatically. 

Protect your credentials

MCP configurations will include API keys / tokens. Treat them like any production secret: store them securely, rotate them regularly, never commit them to repos. If multiple people use MCP, give each their own key with the minimum permissions required.

Monitor and audit usage

Lastly, remember to keep track of how your MCP server is being used: which tools are called, what queries are executed, which branches they touch. This visibility will help you spot issues before they escalate, e.g. if an agent repeatedly querying the wrong database. In Neon, most of this can be monitored directly through the project activity logs and branch history in the console, but if you’re running your MCP server locally, keep your own logs as well. 

Wrap up

MCPs make it possible to bridge the gap between natural language and real infra, but they should be used with the right guardrails.

If you’re exploring ways to let your IDE or agent spin up and manage a real Postgres database, check out Neon and the Neon MCP Server – it’s the easiest way to give your tools a serverless Postgres backend.