Back to Blog

How to Connect Cursor to SQL Server with MCP

Step-by-step guide to connecting Cursor to Microsoft SQL Server using a managed MCP server. Schema-aware answers in chat and Composer — Azure SQL, RDS, on-prem, no local install.

You're already in Cursor. Your Microsoft SQL Server database is somewhere else — Azure SQL, AWS RDS, a VM in the office, SQL Server Express on a box under someone's desk. Every time you want the AI grounded in real rows, you're running a query in SSMS or Azure Data Studio, copying the grid, and pasting it into chat.

Cursor supports the Model Context Protocol (MCP), the same standard Claude Desktop uses — wire SQL Server 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 + SQL Server 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 SQL Server database, the questions you ask stop being guesses about schema:

  • "Write a migration to add a LastLoginAt column to dbo.Users, but only if every existing row has at least one entry in dbo.LoginEvents. Otherwise tell me which user IDs are missing one." — Cursor inspects both tables, runs the count, and only then writes the migration.
  • "Look at dbo.Orders. 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 invoices where Status = 'Overdue' and Amount > 5000, and show me the customer name."

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 SQL Server 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 instance; 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 SQL Server 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 SQL Server Credentials

You'll need:

  • Host — e.g. yourserver.database.windows.net or yourdb.xxxxx.us-east-1.rds.amazonaws.com
  • Port — usually 1433
  • Database name
  • Username and password (SQL Server authentication)
  • Encrypt — leave on for Azure SQL and most modern hosts

Where to find it depending on your provider:

  • Azure SQL Database / Managed Instance — Azure portal → your server → Connection strings (or Overview for the hostname). Hostname ends in .database.windows.net. You'll also need a firewall rule that allows Synra's outbound IPs — Azure blocks unknown clients by default.
  • AWS RDS for SQL Server — Console → your instance → Connectivity & security → endpoint and port, then assemble host / port / database / user / password. Check the security group allows inbound 1433 from Synra.
  • Google Cloud SQL for SQL Server — Instance overview → connection name / public IP, plus the SQL user you created.
  • On-prem / VPS — Hostname or public IP, port (often still 1433), and a SQL login. The instance must be reachable from the public internet, or you'll need a tunnel / allowlisted inbound rule.
  • SQL Server Express / local Docker — Whatever you configured locally. Synra can't reach localhost on your laptop without a tunnel — use a cloud or publicly reachable host for this workflow.

SQL Server 2014 and newer are supported (Express, Standard, and Enterprise). Synra uses SQL authentication only — see the FAQ if you were planning on Windows Auth / Entra ID.

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 Microsoft SQL Server (also labeled MSSQL in some places)
  4. Fill in host / port / database / user / password, and leave encrypt on unless you know you need it off
  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-mssql": {
      "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 or MySQL connector (for example from Connect Cursor to PostgreSQL or Connect Cursor to MySQL), keep those 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-mssql": {
      "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-mssql 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 dbo.Users look like? Show me the columns and types."
  • "How many rows are in dbo.Orders?"

Cursor's agent should pick the right tool, run a query, and return real results. Once you trust it, bigger questions follow naturally — overdue invoices, orphaned foreign keys, 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 SQL Server. 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 SQL Server 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: create a dedicated SQL login with SELECT-only grants on the databases Cursor should see (don't reuse the app's login), allowlist Synra's IPs in Azure SQL / your firewall when you can, and don't share the endpoint URL with people who shouldn't see each other's queries.

Troubleshooting

Cursor doesn't list synra-mssql 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 SQL Server entry → click Test connection. If the test fails, fix the credentials in Synra first, not in Cursor.

Login failed / cannot open database. Confirm you're using a SQL authentication login (not Windows Auth), that the login is mapped to the target database, and that it has at least db_datareader (or equivalent SELECT grants). Create a dedicated read-only login for Synra rather than reusing the app user.

Azure SQL: client IP is not allowed / firewall error. Azure SQL rejects unknown clients by default. Add Synra's outbound IPs to the server firewall (or temporarily enable "Allow Azure services" only while debugging — then tighten to specific IPs). Contact us for the current IP list.

Connection refused / can't reach host. Port 1433 may be blocked, or the instance only listens on a private network. For RDS, check the security group. For on-prem, you'll need a public endpoint or an allowlisted inbound rule — Synra can't reach localhost on your laptop.

Encryption / TLS errors. Leave encrypt on in Synra for Azure SQL and most cloud hosts. If a self-hosted instance uses a self-signed cert and the connection fails, check the encrypt / trust-server-certificate options in the Synra connection settings and re-test.

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.

Does this work with Azure SQL Database? Azure SQL Database, Azure SQL Managed Instance, and SQL Server on Azure VMs all work the same way. Use your hostname ending in .database.windows.net, port 1433, and a SQL authentication login — then allow Synra's outbound IPs in the Azure SQL firewall if the test connection fails.

What about Windows Authentication / Entra ID? Synra connects with SQL Server authentication (username + password). Windows Authentication and Entra ID aren't supported because Synra's servers aren't joined to your domain. Create a SQL login with SELECT-only grants for this connector — most cloud SQL Server deployments already use SQL auth.

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 SQL Server 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 on-prem SQL Server behind a firewall? 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 on port 1433 limited to Synra's outbound IPs (contact us for the current list), put the instance behind a public TLS endpoint, or use Azure SQL / RDS which are already reachable. Local SQL Server Express on your laptop is the same problem — Synra can't reach localhost without a tunnel.

You should now have Cursor talking to your SQL Server 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 SQL Server MCP server product page if you want the overview first.

Related guides:

← Back to Blog