How to Connect Claude to SQL Server, Safely

To connect Claude to SQL Server safely, give Claude an MCP server that holds a dedicated SQL Server login with only SELECT permission on the tables it needs. Then add that server to Claude as a custom connector. Because SQL Server has no read-only session, the server must also refuse anything that is not a single read: EXEC, MERGE, SELECT ... INTO, WAITFOR and OPENROWSET among them. This guide covers the login, the network, the MCP server and the Claude side, with a do-it-yourself route and the Datablare route.

How Claude talks to SQL Server

Claude does not open database connections. It calls tools through MCP (Model Context Protocol), the open standard for connecting AI tools to outside systems. A SQL Server MCP server offers a tool such as “run this query”. Claude writes T-SQL, the server runs it, and the rows come back into the conversation.

So “connecting Claude to SQL Server” really means three decisions:

1. Which login the MCP server uses, and what that login may do.
2. Where the server runs: on one person’s computer, or as a hosted service that Claude reaches over HTTPS.
3. What the server refuses before a query ever reaches SQL Server.

Step 1: Create a login that can only read

Start in SSMS or Azure Data Studio, connected as an administrator.

-- On the server
CREATE LOGIN ai_reader WITH PASSWORD = 'Choose-a-strong-password1';

-- In the database Claude should read
USE SalesDb;
CREATE USER ai_reader FOR LOGIN ai_reader;

-- Narrow: one schema, including tables added to it later
GRANT SELECT ON SCHEMA::sales TO ai_reader;

-- Keep sensitive columns out
DENY SELECT ON sales.Customers (Email, Phone) TO ai_reader;

If Claude should read every table and view in the database, ALTER ROLE db_datareader ADD MEMBER ai_reader; does that in one line, and covers tables created later. Prefer the schema grant when only part of the database is relevant.

On Azure SQL Database you can skip the server login and create a contained user instead: CREATE USER ai_reader WITH PASSWORD = '...'; in the database itself.

What not to do: do not add the login to db_owner, do not reuse the application’s login, and do not grant EXECUTE, VIEW SERVER STATE or CONTROL. A login that can only SELECT is the one protection that holds no matter what software connects with it. For the same steps on other engines, see create a read-only database user for AI agents.

Step 2: Understand SQL Server’s missing read-only session

PostgreSQL, MySQL and Oracle can mark a session read-only, so the server refuses writes from that connection. SQL Server cannot. Your options are:

Option	What it does	Catch
ALTER DATABASE ... SET READ_ONLY	The whole database refuses writes	Affects every user, including your app
ApplicationIntent=ReadOnly	Routes the connection to a readable secondary in an availability group	Needs Always On with a readable secondary
A login with only SELECT	Writes fail with a permission error	Still reads everything it was granted
A transaction that is always rolled back	Nothing the query changed survives	Needs the server to refuse DDL and EXEC too

If you run an availability group with a readable secondary, point Claude’s connection at it with ApplicationIntent=ReadOnly. Questions then never touch the primary. To cap CPU and memory for the login, SQL Server’s Resource Governor (an Enterprise edition feature) can put it in a workload group of its own.

Step 3: Decide what the MCP server must refuse

Because the session cannot be made read-only, the MCP server’s own checks matter more on SQL Server than anywhere else. Before you use one, confirm it refuses:

1. More than one statement. SELECT 1; DROP TABLE x must fail as a whole.
2. Anything that is not a read. INSERT, UPDATE, DELETE, MERGE (which can follow a WITH), TRUNCATE, CREATE, ALTER, GRANT, and SELECT ... INTO, which creates a table.
3. EXEC and EXECUTE. These run stored procedures, and can run dynamic SQL passed as a string.
4. WAITFOR. WAITFOR DELAY holds a worker thread for as long as it is told to.
5. Reaching outside the database. OPENROWSET, OPENQUERY, OPENDATASOURCE and OPENXML read other servers and files.
6. Server identity. SERVERPROPERTY, HOST_NAME() and SUSER_NAME() tell an agent about your infrastructure, not your data.
7. Tables and columns you did not choose, checked with a real SQL parser rather than string matching, and refused when the parser cannot tell.

Step 4: Add it to Claude

Local, for one person. In the Claude desktop app, open Settings, then Developer, then Edit Config. Add your MCP server to claude_desktop_config.json with its command and connection details. It runs on that computer, with the credentials in a local file and no shared record of what was asked.

Remote, for a team. In Claude (the app or claude.ai), open Settings, then Connectors, choose Add custom connector and paste the server’s HTTPS address. Custom connectors are reached from Anthropic’s cloud. The server therefore needs a public HTTPS address, sign-in so that only your people can use it, and a network path to your SQL Server. At the time of writing, custom connectors need a paid Claude plan. On Claude Team or Enterprise, an owner can add the connector once for the whole organization.

The Datablare route

Datablare is a hosted MCP gateway, so steps 2 to 4 are handled for you and every query is recorded.

1. Sign up. To look around first, choose Try the e-commerce sample in onboarding. It connects a ready-made online-shop database, so you can test Claude before touching SQL Server.
2. Add SQL Server as a data source: host, port 1433, database, and the ai_reader login. Turn on SSL for Azure SQL. If your server is behind a firewall, allow the IP address shown on the setup screen, or connect through an SSH tunnel. Datablare checks whether the login can write and tells you if it can.
3. Choose tables and hide columns. Only the tables you select are visible to Claude. In Modeling, switch off columns such as Email or PAN; any query that reads them is refused.
4. Copy the project’s MCP link from the Connect page.
5. In Claude, add it as a custom connector, click Connect, sign in to Datablare and choose Allow. Nothing secret is pasted into Claude.
6. Ask, for example: “What were our top ten customers by revenue last quarter?”
7. Open Audit. You see who asked, the question, the T-SQL that ran, the row count and the time taken. Refused requests appear too, with the reason.

What Datablare does on SQL Server

Datablare is upfront that SQL Server’s protection differs from PostgreSQL’s. Every session runs with IMPLICIT_TRANSACTIONS ON and is rolled back before it closes, so nothing a statement changed can survive. Before that, the guard refuses everything in the Step 3 list, and table and column checks run on a parsed copy of the query. Hidden columns are checked again on the result. Queries time out after 30 seconds by default (60 at most) and return at most 5,000 rows. Only a few run at once per database, so one busy agent cannot overload it. Results pass through to Claude and are never stored by Datablare.

The read-only login from Step 1 is still the stronger guarantee, and the setup screen says so. Datablare gives you the SQL for it. More detail is on the SQL Server page and in how it works.

Limits worth knowing

• Claude sees what it reads. Rows from allowed tables and columns go to Anthropic under its terms. If a column should not reach any AI provider, hide it or deny it on the login.
• Prompt injection. Text stored in your tables, such as customer notes, can carry instructions aimed at the model. Read-only access caps the harm at what Claude can read and repeat. It does not remove it.
• Expensive reads. A large scan on the primary can slow your application. Use a readable secondary where you have one, and set daily query limits per project.
• The model can be wrong. A clean query can still answer the wrong question. Describe your tables and add example questions in Modeling, and check the SQL in Audit when a number matters.

Get started

You can sign up for Datablare free, try Claude on the sample database, then connect SQL Server with a read-only login when you are ready. See connecting Claude for each Claude app, and security for what is stored and what is not.