Back to Blog

How to Connect Cursor to MySQL with MCP

Step-by-step guide to connecting Cursor to your MySQL database using a managed MCP server. Schema-aware answers in chat and Composer, real query results, no local install.

You're already in Cursor. Your MySQL database is somewhere else — PlanetScale, AWS RDS, Railway, a Docker container on your laptop. Every time you want the AI grounded in real rows, you're running a query in TablePlus or the mysql CLI, copying the output, and pasting it into chat.

Cursor supports the Model Context Protocol (MCP), the same standard Claude Desktop uses — wire MySQL in once, and the agent can read your schema, run queries, and reason about your actual rows inside the editor, next to the code that uses them.

This guide gets you from zero to a working Cursor + MySQL MCP setup in a couple of minutes. If you want the outcome story first (why live queries beat copy-paste), read Ask Cursor About Your Database. New to MCP? Start with what is an MCP server.

What This Actually Unlocks

Once Cursor can see your MySQL database, the questions you ask stop being guesses about schema:

  • "Write a migration to add a last_login_at column to users, but only if every existing row has at least one entry in login_events. Otherwise tell me which user IDs are missing one." — Cursor inspects both tables, runs the count, and only then writes the migration.
  • "Look at the orders table. The amount column has some negative values. List those rows with the customer email joined in, then explain what business logic might've allowed it."
  • "This test expects three orgs in seed data. Compare the seed to what's actually in staging — what's different?"
  • "Find orders where status = 'pending' older than 7 days and show me the customer email."

Cursor can check the database itself instead of waiting on whatever you pasted last.

The Two Ways to Connect

Option 1 — Self-hosted. Install a local MySQL MCP server from GitHub, put your connection string in a JSON config on your machine, restart Cursor whenever credentials change. Fine for a solo laptop against a local DB; it falls apart when you want shared team access, or when production credentials shouldn't live in plaintext on every developer's machine.

Option 2 — Managed gateway (Synra). Save your MySQL connection once in a secure dashboard. Synra encrypts it with AES-256, generates a personal MCP endpoint URL, and sits between Cursor and your database on every query. On Synra, read-only is the default — no INSERT, UPDATE, DELETE, or DROP gets through, even if the agent tries — and every query is logged, with no local install and no config drift across machines.

For the longer comparison, see self-hosted vs managed MCP server. For most people — especially teams — the managed path is the right call.

Step 1 — Get Your MySQL Credentials

You'll need:

  • Host — e.g. mysql.example.com or your-db.us-east-1.rds.amazonaws.com
  • Port — usually 3306
  • Database name
  • Username and password

Or a single connection URL in the usual format:

mysql://username:password@host:port/database

Where to find it depending on your provider:

  • PlanetScale — Project dashboard → Connect → copy the connection string (Synra can parse it directly).
  • AWS RDS — Console → your instance → Connectivity & security → grab the endpoint, then assemble host / port / database / user / password (or a mysql:// URL).
  • Railway — Click your MySQL service → Variables → copy MYSQL_URL or DATABASE_URL.
  • DigitalOcean / Render — Database dashboard → Connection details → copy the external host and credentials.
  • MariaDB — Same fields as MySQL; pick MySQL in Synra and use your MariaDB host.
  • Local Docker — Whatever you set in docker-compose.yml, often mysql://root:password@localhost:3306/app.

You'll paste those details into Synra once and not touch them again from Cursor.

Step 2 — Save the Connection in Synra

  1. Sign in at mcpserver.design (free tier covers getting started)
  2. Go to Connections → Add new connection
  3. Pick MySQL
  4. Paste your connection string, or fill in host / port / database / user / password
  5. Click Test connection — Synra opens a one-shot query against your database and confirms it works
  6. Click Save

Your credentials are encrypted at rest with AES-256, and the plaintext password never leaves Synra's vault.

Step 3 — Copy Your MCP Endpoint URL

After saving, head to the Endpoints tab. You'll see a URL that looks like this:

https://app.mcpserver.design/api/mcp/aB3xY7zQ9mNpLkRv2wTs

The trailing token is unique to your account and acts as the authorization. Treat it like a password — anyone with that URL can read from the database you connected — and copy it somewhere safe (you can rotate it from the same screen if it ever leaks).

Step 4 — Add the MCP Server to Cursor

Cursor reads MCP configuration from ~/.cursor/mcp.json (global, applies to every project) or .cursor/mcp.json inside a specific project. Global is fine for personal use; per-project is better if your team checks the config into git (without committing the real token — use a secret or local override).

Open the file (create it if it doesn't exist) and add:

{
  "mcpServers": {
    "synra-mysql": {
      "url": "https://app.mcpserver.design/api/mcp/aB3xY7zQ9mNpLkRv2wTs"
    }
  }
}

Replace the URL with your own from Step 3, then save the file.

If you already have a Postgres connector (for example synra-postgres from Connect Cursor to PostgreSQL), keep both entries under mcpServers — Cursor will list each as a separate tool source.

On older Cursor versions that don't support the "url" field directly, use a stdio bridge instead:

{
  "mcpServers": {
    "synra-mysql": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://app.mcpserver.design/api/mcp/aB3xY7zQ9mNpLkRv2wTs"]
    }
  }
}

mcp-remote is a small published package that proxies a remote HTTP MCP server over stdio — same effect, slightly more setup, and unnecessary if your Cursor is up to date.

Step 5 — Restart Cursor and Verify

Quit Cursor fully (Cmd+Q on Mac, not just closing the window) and reopen it. Then:

  1. Open Cursor Settings → MCP (or Features → MCP in older builds)
  2. You should see synra-mysql listed with a green status indicator
  3. Click it to see the tools it exposes — typically list_tables, describe_table, query_table, execute_sql

If the entry shows a red status or "no tools found", jump to the troubleshooting section below.

What to Try First

Open Cursor's chat (Cmd+L). Try one of these to confirm it's working:

  • "List the tables in my database."
  • "What does the users table look like? Show me the columns and types."
  • "How many rows are in orders?"

Cursor's agent should pick the right tool, run a query, and return real results. Once you trust it, bigger questions follow naturally — top products by revenue, pending orders older than a week, orphaned rows, average order value by month — and when you ask for code that touches the database, it'll often check the schema first instead of guessing column names.

Security: What's Actually Happening

A few things worth knowing if you're connecting a real database (you should still prefer staging or a read replica first):

  • Read-only by default. On Synra, write statements are blocked at the gateway: INSERT, UPDATE, DELETE, DROP, ALTER, TRUNCATE, CREATE, GRANT. Even if Cursor's agent generates an UPDATE, the gateway rejects it before it reaches MySQL. You can override this per-connection from the dashboard if you genuinely want write access, but the default is safe.
  • Credentials never reach Cursor. Cursor only ever sees the MCP endpoint URL. The actual MySQL password lives encrypted in Synra's vault. If your laptop is stolen, your DB password isn't on it.
  • Every query is logged. The audit log in your Synra dashboard shows every SQL statement that ran, who triggered it, when, and how long it took.
  • The endpoint token rotates. If you accidentally commit mcp.json to a public repo, regenerate the endpoint URL from the dashboard and the old URL stops working immediately.

For production data: connect to a read replica when you can, use a dedicated MySQL user with SELECT-only grants, and don't share the endpoint URL with people who shouldn't see each other's queries.

Troubleshooting

Cursor doesn't list synra-mysql after restart. The mcp.json file probably has a syntax error. Run cat ~/.cursor/mcp.json | jq . (or paste into jsonlint.com) to validate. The single most common mistake is a trailing comma after the URL line.

Status shows red, "Server transport closed" or similar. Open the URL from your config in a browser. You should see a JSON response (something like {"jsonrpc":"2.0","error":{...}} is normal — the browser made a GET without the right MCP headers). If you get a 404 or a connection error, the endpoint URL is wrong — recopy it from Synra's Endpoints tab.

Tools list shows nothing, or queries return "credentials not configured". The connection in Synra is probably in a failed state. Go to Connections → click your MySQL entry → click Test connection. If the test fails, fix the credentials in Synra first, not in Cursor.

Connection refused / can't reach host. Your MySQL host may block external IPs. For RDS, check the security group inbound rules. For local Docker, you'll need a tunnel or a publicly reachable host — Synra can't reach localhost on your laptop.

Access denied for user. The MySQL user needs SELECT privileges on the database. You don't need (and shouldn't give) write access for this workflow.

SSL errors. Synra supports SSL connections. If your MySQL requires SSL, enable it in the connection settings in Synra and re-test. Managed hosts (PlanetScale, many RDS setups) often require TLS by default.

Cursor's agent refuses to use the database tools. In Cursor's chat, type @ and pick the MCP server explicitly the first time. Once it's seen the tool surface, the agent will use it automatically on subsequent prompts.

Frequently Asked Questions

Does this work with Cursor Composer / Agent mode? Composer and the autonomous agent use the same MCP tool surface as chat, so once the server is registered, every Cursor mode can use it.

Can I connect MySQL and PostgreSQL at the same time? Add additional entries under mcpServers in your mcp.json, each pointing at a different Synra endpoint URL — Cursor will list all of them as available tools.

Does this work with MariaDB or PlanetScale? MariaDB is MySQL-compatible, so pick MySQL in Synra and use your MariaDB host. PlanetScale works the same way: paste the connection string from your project dashboard.

Does Cursor's agent send my database contents to Anthropic / OpenAI? When Cursor uses the MCP tools, it sends query results back to the underlying model so it can reason over them — same as if you'd pasted them into chat manually. If that's not acceptable for your data, connect a sanitized staging copy instead of production.

Can Cursor delete or change my MySQL data? That depends on how the connector is configured — read-only is not a property of MCP itself. On Synra, INSERT, UPDATE, DELETE, DROP, ALTER, and TRUNCATE are blocked at the gateway before they reach your database, even if the model generates a destructive query. If you self-host a connector or wire one up directly with write-capable credentials, nothing in MCP stops that; you're responsible for that layer yourself.

Will this work with MySQL behind a VPN / no public IP? Synra needs network access to your database, so a host that only accepts VPN or private-network traffic won't work out of the box. You can open an inbound rule limited to Synra's outbound IPs (contact us for the current list), or use a provider with a public TLS endpoint such as RDS, PlanetScale, or Railway. Local Docker on your laptop is the same problem — Synra can't reach localhost without a tunnel.

You should now have Cursor talking to your MySQL database with no local server to babysit.

Ready to try it? Free tier at mcpserver.design covers one database connection — plenty for exploring whether this fits your workflow. Or start from the MySQL MCP server product page if you want the overview first.

Related guides:

← Back to Blog