kaiva BRIDGE
GUIDE

How to set up a SQL Server or Azure SQL MCP server

Updated

Paste your SQL Server or Azure SQL connection string into Kaiva Bridge, a managed MCP cloud platform. Bridge reads the tables your login can see and creates two tools for each, one to look up rows and one to count and total them, then serves them at an MCP address you add to Claude, ChatGPT, Cursor or any other MCP client. Every tool only reads: each call is one generated SELECT, run in a transaction that is always rolled back.

Start freeRead the docs

Step by step

  1. Create a read-only login (recommended)Create a login that can only read, with the SQL under The read-only login below. The console shows the same SQL when you choose Show the SQL on the database form.
  2. Paste the connection stringChoose New server, then Database, then SQL Server, and paste the connection string in either form: sqlserver://user:password@host:1433/database, or Server=tcp:host,1433;Database=…;User ID=…;Password=… as SQL Server Management Studio and the Azure portal give it. Or choose Enter details separately.
  3. Test and introspectClick Test and introspect. Bridge connects over an encrypted connection, checks the server's certificate, reads the tables the login can see and lists two tools for each table, all switched off.
  4. Choose the tools and deploySwitch on the tools for the tables your AI needs and click Deploy server.
  5. Add it to your AI clientCopy the address from the Connect tab and add it to Claude, ChatGPT, Cursor or another MCP client. Claude and ChatGPT sign in with your Kaiva account, so no key is needed.

From a terminal, with the connection string piped in so it never lands in your shell history:

Terminal
npx @kaiva/bridge login
printf %s "$SQLSERVER_URL" | npx @kaiva/bridge push shop-db --sqlserver --secret-stdin
npx @kaiva/bridge install shop-db --client claude-code

The read-only login

Bridge already runs every query read-only. A login whose only role is db_datareader makes the database refuse writes as well, and it decides what Bridge can see: Bridge lists only the tables the login can read.

Run this as an administrator, with your own password and database name. On Azure SQL, create a contained user in the database itself instead, as the commented lines show:

Read-only login
-- SQL Server: a login, then a user for it in the database
CREATE LOGIN bridge_ro WITH PASSWORD = 'choose-a-password';
USE [shop];
CREATE USER bridge_ro FOR LOGIN bridge_ro;
ALTER ROLE db_datareader ADD MEMBER bridge_ro;

-- Azure SQL: in the database itself, instead of the lines above
-- CREATE USER bridge_ro WITH PASSWORD = 'choose-a-password';
-- ALTER ROLE db_datareader ADD MEMBER bridge_ro;

The tools your AI gets

Two for each table. For dbo.orders, Bridge creates get_orders and summarize_orders. A table in another schema carries the schema in its name, so support.tickets becomes get_support_tickets and summarize_support_tickets.

A get_ tool reads matching rows: up to 12 filters (equals, not equals, greater or less than, contains, null or not null), the columns to return, sorting and paging, at most 500 rows a call. A summarize_ tool counts rows, or returns a sum, average, minimum or maximum, optionally grouped by a column, without downloading the rows.

Exact numbers, money and dates come back as stored, as text: a large decimal keeps every digit, and a date and time is not moved to another time zone. Bridge reads up to 300 tables; views are not included.

How each call runs

SQL Server has no read-only transaction, so Bridge makes one: every call is a single SELECT generated from the schema, with your AI's values bound as parameters, run inside a transaction that is always rolled back. Your AI never writes SQL.

A query stops after 15 seconds and waits at most 3 seconds for a lock, so a busy table answers with a short message to retry rather than a call that hangs. Bridge renews its connections every minute, so a login you disable stops working for Bridge within about a minute.

Connecting: firewall, Azure SQL and certificates

Bridge connects over the internet and has no fixed address to add to a firewall rule, so the server must accept connections from outside your network. On Azure SQL, that means allowing public network access.

Azure SQL uses its Proxy connection policy for connections from outside Azure by default, which is what Bridge needs. If the database asks Bridge to connect to a different server, Bridge refuses and says to set the policy to Proxy.

Bridge signs in with a SQL login or a contained database user with a password. Windows sign-in and Microsoft Entra sign-in are not supported.

The connection is always encrypted, and the certificate is checked against the host name you gave. If your server's certificate comes from your own certificate authority, add that CA when you create the server (--ca-file in the CLI). Connecting without checking the certificate is possible only as an explicit choice (--no-verify-tls), and the connection stays encrypted.

If it does not connect

Login failed. SQL Server does not tell a client whether the password or the database is wrong, so check both, and that the login can open that database.

A named instance. Give the server's port instead: host,1433 rather than host\INSTANCE.

No answer within 5 seconds. Check the host and port, and that the server accepts connections from the internet.

A table is missing. Bridge lists the tables the login can read, and not views. Grant SELECT on the table (or db_datareader), then run Introspect again from the server's Source tab.

What you need

A SQL Server or Azure SQL database that accepts connections from the internet, a SQL login with a password (read-only recommended) and its connection string.

If your project keeps the connection string in DATABASE_URL, in the environment, .env.local or .env, npx @kaiva/bridge push shop-db --db finds it, recognises SQL Server from the address and never puts it on the command line.

Free includes 10 MCP servers, 200,000 tool calls a month and 200 pages of documents, with no card.

Other ways to do it

  • Microsoft's Data API builderData API builder can serve SQL Server and Azure SQL tables as an MCP server. You configure which tables it exposes and run it yourself.
  • An open-source SQL Server MCP serverOpen-source MCP servers for SQL Server run on your own machine or infrastructure. You keep them updated and decide how they reach the database and which login they use.
  • Give the AI a SQL consoleSome tools let an AI write any SQL. That is flexible, and it gives the AI as much access as the login it uses.

Questions

Can the AI change or delete my data?
No. Each tool runs one generated SELECT inside a transaction that is always rolled back. A login with only db_datareader adds the database's own refusal on top.
Does it work with Azure SQL?
Yes. Use a SQL login or a contained database user with a password, allow public network access, and keep the Proxy connection policy for connections from outside Azure.
Can I sign in with Windows or Microsoft Entra?
No. Bridge signs in with a SQL login or a contained database user with a password.
Are views included?
No. Bridge creates tools for tables, up to 300 of them.
Is my connection string safe?
It is encrypted at rest with AES-256-GCM and used only while a request runs. The password is never returned by the API, shown in the console or sent to your AI client.
Does my database need to be reachable from the internet?
Yes. Bridge connects over the internet and has no fixed address to add to a firewall rule.
Is it free?
Free includes 10 MCP servers, 200,000 tool calls a month and 200 pages of documents, with no card.

Related guides