MCP Server for SQL Server: The Options

There is no official MCP server for SQL Server, but three community servers connect it well: DBHub for a plain multi-engine query tool, MCP Alchemy if you're already a Python shop, and CentralMind Gateway when the database is shared infrastructure rather than your own laptop. Microsoft ships no first-party server for MS SQL, so this is community territory — pick by your setup, install one, and run it read-only.

All three run locally over stdio, which is the norm: roughly 90% of MCP servers do. That means the server is a small process on your machine that connects to whatever SQL Server instance your machine can reach — localhost, a Docker container, or an Azure SQL host you already have a route to. No hosted middleman sees your credentials.

The three that actually connect SQL Server

Start from your setup, not from GitHub stars. Two of these speak many engines and one wraps your database in a gateway, so the right pick depends on whether you're wiring one client to one database or serving a database to many consumers.

Server	Engines	Language	Best for
DBHub	SQL Server, Postgres, MySQL, MariaDB, SQLite	TypeScript	Most people; one server for many DBs
MCP Alchemy	Any SQLAlchemy DB (MS SQL, Postgres, Oracle, MySQL, SQLite)	Python	Polyglot stacks already on Python
CentralMind Gateway	Many, via generated gateway	Go	Serving a shared DB with access controls

All three are community-maintained, not official, and all connect over stdio. One name to ignore in this context: the MySQL MCP Server is MySQL-only despite the generic-sounding label — it does not speak SQL Server, so skip it here even though it shows up when you search for database servers.

DBHub: the default for a raw SQL Server

For a plain SQL Server connection, DBHub is what I'd install first. It's a zero-dependency, token-efficient server from Bytebase that speaks SQL Server, Postgres, MySQL, MariaDB, and SQLite through one binary, so you learn one tool surface instead of one per engine. You point it at a database with a DSN and it exposes schema and query tools — nothing more, which is exactly what you want sitting next to an LLM.

The token-efficiency claim is not marketing: DBHub trims and shapes results so a SELECT * against a wide table doesn't dump ten thousand tokens into the model's context window. Every column a server hands back competes with your actual conversation for the same budget, and a server that returns raw rows verbatim will quietly wreck a long agent session.

Run it over stdio with a single command, using the sqlserver:// DSN scheme:

{
  "mcpServers": {
    "sqlserver": {
      "command": "npx",
      "args": ["@bytebase/dbhub@latest", "--transport", "stdio", "--dsn", "sqlserver://user:password@localhost:1433/mydb"]
    }
  }
}

One caveat before you deploy it anywhere shared: DBHub's HTTP transport defaults to binding 0.0.0.0 and does not authenticate clients. On stdio that's a non-issue — the process only talks to your local client. If you ever switch to HTTP, bind 127.0.0.1 and front it with a reverse proxy. Stick to stdio and a least-privilege login and you're fine.

MCP Alchemy: when you're already on Python

Reach for MCP Alchemy when your stack is Python and your database mix is genuinely polyglot. It connects Claude to anything with a SQLAlchemy driver — MS SQL, Postgres, Oracle, MySQL, SQLite — so you inherit SQLAlchemy's broad driver support and its connection-string conventions. If you touch four engines from one codebase, that's one config entry instead of four.

The SQL Server catch is the driver. SQLAlchemy needs an actual MSSQL dialect installed — pyodbc (with the Microsoft ODBC driver) or pymssql — and your DB_URL has to name it, e.g. mssql+pyodbc://.... That's more moving parts than DBHub's single binary. It runs over stdio via uvx:

{
  "mcpServers": {
    "mssql": {
      "command": "uvx",
      "args": ["--from", "mcp-alchemy", "--with", "pymssql", "mcp-alchemy"],
      "env": { "DB_URL": "mssql+pymssql://user:password@localhost:1433/mydb" }
    }
  }
}

Mind that MCP Alchemy exposes an execute_query tool that runs arbitrary SQL, so the least-privilege login is doing the real work here — the LLM can only do what that credential permits. If you're SQL-Server-only and not already living in Python, DBHub is less machinery for the same job.

CentralMind Gateway: when the database is shared infrastructure

Use CentralMind Gateway when you're serving one database to many consumers with real access controls, not wiring a single laptop to a single DB. It auto-generates a secure, LLM-optimized MCP server or REST API in front of your database, and it ships the controls that a shared endpoint needs: PII filtering and redaction (regex or Microsoft Presidio), row-level security via Lua scripts, and OpenTelemetry auditing.

That feature set is the tell. If you're an individual developer connecting your own client, this is overkill — the gateway binary, a YAML config, and Docker are a lot of ceremony to read a few tables. But when a data team needs auditable, redacted, access-controlled AI access to a production SQL Server, a generated gateway is the right shape and DBHub is not.

It runs the gateway binary over stdio pointed at a gateway.yaml that holds the connection string. Because it's built for shared use, treat that config and its scopes as production access — the same care you'd give any service in front of your database.

What to skip and how to wire it up

Skip installing more than one of these. They overlap, and every extra server eats into the roughly 40-tool budget most clients handle before tool selection gets unreliable — that's real math, walked through in Cursor's tool limit. One server, read-only by default, a least-privilege SQL login: that covers the vast majority of real use.

The safety boundary that matters is the credential, not a config flag. Connect with a SQL Server login that has SELECT and nothing else, and the AI client physically cannot DROP, DELETE, or ALTER regardless of what tool it calls. If a task genuinely needs writes, hand it a second, tightly-scoped login rather than widening the read one.

Adding any of these is the same three steps in any client — server command, credentials, restart — covered in how to add an MCP server, and the config generator will write the JSON for you. To compare the wider field or filter by engine, start from the best MCP servers, browse capabilities, or check alternatives if none of these fit.