How to connect Claude or Cursor to a managed database (RDS, Cloud SQL, Azure)

What is different about a managed database

Connecting Claude, Cursor or another assistant to a database over MCP works the same on any server: a separate read-only login, limits on time and rows, and a person approving every write. Our guide on connecting AI to a database safely covers those rules. A managed database on Amazon RDS or Aurora, Google Cloud SQL or Azure adds four questions:

• Reach: the database is usually in a private network your laptop cannot reach.
• TLS: the connection should be encrypted and the server's certificate checked.
• Credentials: each provider can replace the password with a short-lived token from your cloud identity. Tokens expire, and MCP configuration files are static.
• Target: a read replica or reader endpoint keeps the assistant's queries off the primary.

The examples use PostgreSQL. MySQL works the same way; the differences are noted.

1. Where the MCP server runs

With Claude Desktop and Cursor, a database MCP server is usually a local program the app starts on your computer. The app passes it a command and environment variables from a JSON file, and the server opens the database connection from your machine. So everything below (network path, certificate file, cloud login) has to work from your laptop, not from the cloud.

{
  "mcpServers": {
    "shop-replica": {
      "command": "/path/to/your-database-mcp-server",
      "env": { "PGHOST": "...", "PGUSER": "mcp_reader" }
    }
  }
}

Claude Desktop reads this from claude_desktop_config.json; Cursor from .cursor/mcp.json in a project or ~/.cursor/mcp.json for all projects. Anything in env sits in that file in plain text, which is one reason to avoid a long-lived password there.

2. Reach the database

Do not open the database to the internet for this. Use a path that already exists for engineers:

• VPN or private connectivity into the network the database lives in, if your company has one.
• An SSH tunnel through a bastion host in the same network:

# local port 5433 -> database port 5432, through the bastion
ssh -N -L 5433:shop-replica.abc123.us-east-1.rds.amazonaws.com:5432 ec2-user@bastion.example.com

• Cloud SQL: the Cloud SQL Auth Proxy opens an encrypted connection using your Google credentials, without an authorized network for your IP. It listens on localhost; add --private-ip when the instance has only a private address (the proxy then has to run where that address is reachable).

cloud-sql-proxy --port 5432 my-project:us-central1:shop-replica

The proxy encrypts traffic to the instance; the hop from your MCP server to the proxy on localhost is plain, which is why the proxy should run on the same machine.

3. Verify TLS

Encryption alone does not prove you reached your database. Ask the client to check the server certificate against the provider's certificate authority:

psql "host=shop-replica.abc123.us-east-1.rds.amazonaws.com port=5432 dbname=shop user=mcp_reader sslmode=verify-full sslrootcert=/path/to/global-bundle.pem"

• global-bundle.pem is the RDS certificate bundle, downloaded from AWS's RDS documentation.
• verify-full checks the certificate and that its name matches the host you connect to.
• Through a tunnel you connect to localhost, which does not match the certificate, so verify-full fails. Either use sslmode=verify-ca (certificate checked, name not), or point the real endpoint name at 127.0.0.1 in your hosts file and keep verify-full.
• For MySQL clients the equivalents are --ssl-mode=VERIFY_IDENTITY and --ssl-ca=/path/to/global-bundle.pem.

Your MCP server has to support these settings too. Check its documentation for an SSL mode and a CA file option before relying on it.

4. Short-lived tokens instead of a password

All three providers can authenticate a database login with your cloud identity and a token that expires, so there is no password to leak from a configuration file.

Amazon RDS and Aurora (IAM database authentication must be enabled on the instance, and your IAM identity needs rds-db:connect for this user):

CREATE USER mcp_reader;
GRANT rds_iam TO mcp_reader;
-- then the read-only grants from the MCP safety guide

export PGPASSWORD="$(aws rds generate-db-auth-token \
  --hostname shop-replica.abc123.us-east-1.rds.amazonaws.com \
  --port 5432 --region us-east-1 --username mcp_reader)"

psql "host=shop-replica.abc123.us-east-1.rds.amazonaws.com port=5432 dbname=shop user=mcp_reader sslmode=verify-full sslrootcert=/path/to/global-bundle.pem"

• The token is valid for 15 minutes and must be generated for the instance endpoint name, not a custom DNS alias.
• On MySQL, create the user with IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS'; the mysql client also needs --enable-cleartext-plugin to send the token.

Azure Database for PostgreSQL (flexible server, with Microsoft Entra authentication enabled):

export PGPASSWORD="$(az account get-access-token --resource-type oss-rdbms --query accessToken -o tsv)"

psql "host=shop.postgres.database.azure.com dbname=shop user=you@example.com sslmode=require"

Entra tokens last between 5 and 60 minutes. The user name is the Entra user or group name, exactly as it appears in Entra.

Cloud SQL: add your Google user or service account to the instance as an IAM database user, then let the proxy handle tokens:

cloud-sql-proxy --auto-iam-authn --port 5432 my-project:us-central1:shop-replica

5. Point it at a replica

• RDS: use a read replica's own endpoint. Aurora: use the cluster's reader endpoint (the name contains cluster-ro-).
• Cloud SQL and Azure: read replicas have their own instance names and host names; connect to those.
• A PostgreSQL replica is read-only at the server, and MySQL replicas on these services are set read-only by default, which protects against writes even if a grant is wrong. Still use a read-only login: a replica can lag and can be promoted to primary later.
• Heavy queries on a replica can delay replication, and on PostgreSQL long queries can be cancelled by replication conflicts. Keep the role's statement_timeout short.

6. Put it together

Instead of a password in the JSON file, point the configuration at a small script that fetches a fresh token and then starts the MCP server:

#!/bin/sh
set -e
HOST=shop-replica.abc123.us-east-1.rds.amazonaws.com

export PGHOST="$HOST" PGPORT=5432 PGDATABASE=shop PGUSER=mcp_reader
export PGSSLMODE=verify-full PGSSLROOTCERT="$HOME/certs/global-bundle.pem"
export PGPASSWORD="$(aws rds generate-db-auth-token --hostname "$HOST" --port 5432 --region us-east-1 --username mcp_reader)"

exec /path/to/your-database-mcp-server

{
  "mcpServers": {
    "shop-replica": {
      "command": "/Users/you/bin/start-db-mcp.sh"
    }
  }
}

• The PG* variables are the standard PostgreSQL client variables. If your MCP server wants a connection URL instead, build it in the script; URL-encode the token, because it contains characters such as & and =.
• The script uses your normal cloud login (for example aws sso login beforehand), so access ends when your session does.
• Make it executable with chmod +x, and keep it out of any repository.

The same rules in Quorum

Quorum exposes your saved connections as MCP tools for Claude, OpenAI, Cursor or your own agent, with the same rules applied to every request, whichever engine is behind the connection.

UPDATE dbo.Cases SET sample_ready = 0
WHERE OrderRef IN ('ORD-48213', 'ORD-48214');

• A review gate for writes: a person approves each write an AI client proposes; no response means no write.
• Masking on every path, including MCP replies, with schema and safe summaries sent to AI by default.
• Budgets for tools, time, rows and cost.
• Bring your own model: Anthropic, OpenAI, Azure OpenAI, or an offline Ollama model.