MSSQL MCP Server

Enterprise-grade Model Context Protocol server for Microsoft SQL Server.

A production-ready MCP server built for real-world database work: exploring unfamiliar schemas, profiling data shape, validating pipelines in UAT, and moving confidently to production. If you work with SQL Server and want AI tooling that understands enterprise database workflows, this is for you.

Package Tiers

Choose the tier that matches your security requirements. All tiers share the same governance controls, audit logging, and multi-environment support.

Related MCP server: SQL Server MCP

Why This Exists

Most SQL + AI demos stop at "generate a query." That's table stakes. Real database work means:

• Navigating massive schemas you didn't design, often with cryptic naming conventions

• Understanding data shape before writing anything

• Working safely in regulated environments where one bad UPDATE can trigger an incident

• Moving fast in UAT so you can validate changes before they hit production

This server is built around those realities. It's stable, secure by default, and designed to make AI assistants genuinely useful on enterprise SQL Server instances.

What's here today

• Semantic schema discovery – search_schema finds tables/columns via wildcards with fuzzy matching and paginated results so large databases don’t blow up your context window.

• Table profiling – profile_table summarizes column shape (null %, cardinality, min/max/avg/median/p90) and can return a capped sample of rows.

• Relationship mapping – inspect_relationships enumerates inbound/outbound FKs with column mappings, so you can follow dependencies before touching data.

• Flexible authentication – SQL auth, Windows auth, and Azure AD are supported; pick what matches your infra.

• Safe data operations – read_data, describe_table, list_table, plus write tools (insert_data, update_data, delete_data, create_table, create_index, drop_table) when you need full agent-mode workflows.

• Preview + Confirm for mutations – update_data and delete_data show affected rows before execution; require explicit confirmation to proceed.

• Multi-environment support – Define named database environments (prod, staging, dev) in a JSON config; switch between them per request.

• Audit logging – Every tool invocation logged to JSON Lines format with timestamps, arguments (auto-redacted), and results.

• MCP-native – Works with Windsurf, Claude Desktop, and any MCP-compatible client.

Key tools at a glance

Discovery & Schema:

• search_schema – Wildcard/fuzzy search across tables and columns with pagination.

• describe_table – Column definitions, types, nullability, keys.

• list_table – List all tables in a database with optional filtering.

• list_databases – List databases on server-level environments.

• list_environments – Show configured environments and their policies.

Profiling & Analysis:

• profile_table – Column stats (null %, cardinality, min/max/avg/median/p90) with optional sample rows.

• inspect_relationships – FK mappings in both directions.

• inspect_dependencies – Full dependency analysis (views, procs, functions, triggers referencing an object).

• explain_query – Execution plan analysis via SHOWPLAN.

Data Operations:

• read_data – Safe SELECT with automatic row limits.

• insert_data – Parameterized inserts (single or batch).

• update_data – Preview affected rows, require confirmation.

• delete_data – Preview affected rows, require confirmation.

DDL Operations:

• create_table – Create tables with column definitions.

• create_index – Create indexes on existing tables.

• drop_table – Drop tables (requires confirmation).

Named Scripts:

• list_scripts – Show available pre-approved SQL scripts.

• run_script – Execute named scripts with parameters and governance controls.

• Scripts directory – Point the server at a folder containing scripts.json + .sql files by setting SCRIPTS_PATH (env var) or "scriptsPath" inside your environment entry. list_scripts/run_script remain disabled until this location is configured.

Operations:

• test_connection – Verify connectivity and latency.

• validate_environment_config – Check environment configuration for errors.

Prerequisites

You’ll need a current Node.js runtime (minimum 18, recommended 20 LTS). The tooling now shims legacy APIs so it also works on the newest Node releases, but installing an LTS build avoids surprises on fresh machines.

Verify with node -v (should show v20.x). If you already have a newer Node version installed, the server will still run thanks to the built-in SlowBuffer shim.

Quick start

Option 1: Install from npm (recommended)

npm install -g @connorbritain/mssql-mcp-server@latest

Then configure your MCP client:

{
  "mcpServers": {
    "mssql": {
      "command": "npx",
      "args": ["@connorbritain/mssql-mcp-server@latest"],
      "env": { "SERVER_NAME": "localhost", "DATABASE_NAME": "mydb", "READONLY": "true" }
    }
  }
}

Option 2: Build from source

git clone https://github.com/ConnorBritain/mssql-mcp-server.git
cd mssql-mcp-server/src/node
npm install
npm run build

Then point your MCP client to src/node/dist/index.js with your connection env vars.

Configuration

Environment variables

Authentication modes

SQL Server Authentication (SQL_AUTH_MODE=sql)
Standard username/password auth against SQL Server. Works with local instances, Docker containers, and Azure SQL with SQL auth enabled.

"env": {
  "SERVER_NAME": "127.0.0.1",
  "DATABASE_NAME": "mydb",
  "SQL_AUTH_MODE": "sql",
  "SQL_USERNAME": "sa",
  "SQL_PASSWORD": "YourPassword123",
  "SQL_PORT": "1433",
  "TRUST_SERVER_CERTIFICATE": "true"
}

Windows Authentication (SQL_AUTH_MODE=windows) NTLM-based auth using domain credentials. Ideal for on-prem SQL Server in Active Directory environments.

The server auto-parses DOMAIN\username format — you can provide the domain either as a separate SQL_DOMAIN field or embedded in SQL_USERNAME (e.g., CORP\svc_account). If both are present, the explicit SQL_DOMAIN takes precedence and the prefix is stripped from the username.

"env": {
  "SERVER_NAME": "sqlserver.corp.local",
  "DATABASE_NAME": "mydb",
  "SQL_AUTH_MODE": "windows",
  "SQL_USERNAME": "CORP\\svc_account",
  "SQL_PASSWORD": "YourPassword123",
  "SQL_DOMAIN": "CORP"
}

Azure AD Authentication (SQL_AUTH_MODE=aad or omit) Interactive browser-based Azure AD authentication. Opens a browser window on first connection to authenticate. Best for Azure SQL Database with AAD-only auth.

"env": {
  "SERVER_NAME": "myserver.database.windows.net",
  "DATABASE_NAME": "mydb",
  "SQL_AUTH_MODE": "aad"
}

Credential security

Never hardcode credentials in config files that might be committed to version control. The server supports several approaches for secure credential management:

Secret placeholders (recommended)

Use ${secret:NAME} syntax in your environments.json to reference secrets:

{
  "name": "prod",
  "server": "prod-server.database.windows.net",
  "username": "${secret:PROD_SQL_USERNAME}",
  "password": "${secret:PROD_SQL_PASSWORD}"
}

Pluggable secret providers

The server resolves ${secret:NAME} placeholders through a configurable chain of providers. Add a secrets block to your environments.json:

{
  "secrets": {
    "providers": [
      { "type": "env" },
      { "type": "dotenv", "path": "/absolute/path/to/.env" },
      { "type": "file", "directory": "/absolute/path/to/secrets/" }
    ]
  },
  "environments": [...]
}

Providers are tried in order — the first one to return a value wins.

If no secrets block is present, the server defaults to [{ "type": "env" }] (the original behavior).

Cross-platform .env setup (recommended for MCP clients):

MCP clients spawn the server as a child process, so shell profile variables (~/.bashrc, etc.) and Windows Credential Manager entries are often not available. The dotenv provider solves this:

1. Create a .env file with your secrets:

   # Windows: C:\Users\you\.mssql-mcp-server\.env
   # WSL/Linux: /home/you/.mssql-mcp-server/.env
   PROD_SQL_USERNAME=myuser
   PROD_SQL_PASSWORD=mypassword

2. Reference it in environments.json:

   {
     "secrets": {
       "providers": [
         { "type": "env" },
         { "type": "dotenv", "path": "C:\\Users\\you\\.mssql-mcp-server\\.env" }
       ]
     }
   }

3. Keep the .env file out of version control — add it to .gitignore.

Convenience fallback: If you don't want to add a secrets block, set the DOTENV_PATH environment variable to the absolute path of your .env file. The server will automatically create a dotenv provider from it.

Validating your setup

Use the validate_environment_config tool to verify your secrets configuration. It checks:

• Provider configs are valid (correct types, paths exist and are readable)

• All ${secret:NAME} references in your environments are resolvable

Platform-specific secret stores

For enhanced security, load credentials from your platform's native secret store before launching the MCP server. Example scripts are provided in the examples/ folder:

Windows Credential Manager example:

# Store credential (one-time setup)
cmdkey /generic:MSSQL_PROD /user:myuser /pass:mypassword

# Retrieve and set as env var before launching
$cred = cmdkey /list:MSSQL_PROD | Select-String "User:"
# ... (see examples/load-from-credential-manager.ps1 for full script)

Azure Key Vault example:

# Retrieve secret from Key Vault
$secret = az keyvault secret show --vault-name "my-vault" --name "sql-password" --query "value" -o tsv
$env:PROD_SQL_PASSWORD = $secret

Security tiers

Multiple instances / Docker

If you're running multiple SQL Server instances (e.g., local dev on 1433, Docker on 1434), just change SQL_PORT:

"env": {
  "SERVER_NAME": "127.0.0.1",
  "DATABASE_NAME": "devdb",
  "SQL_AUTH_MODE": "sql",
  "SQL_USERNAME": "sa",
  "SQL_PASSWORD": "DockerPassword123",
  "SQL_PORT": "1434",
  "TRUST_SERVER_CERTIFICATE": "true"
}

You can also run multiple instances of the MCP server in your config, each pointing to a different database or environment.

Multi-environment configuration

For managing multiple databases (prod, staging, client DBs), create an environments.json file:

{
  "defaultEnvironment": "dev",
  "environments": [
    {
      "name": "dev",
      "server": "localhost",
      "database": "DevDB",
      "authMode": "sql",
      "username": "sa",
      "password": "DevPassword123",
      "trustServerCertificate": true,
      "readonly": false
    },
    {
      "name": "prod",
      "server": "prod-server.database.windows.net",
      "database": "ProdDB",
      "authMode": "aad",
      "readonly": true,
      "description": "Production - read only"
    }
  ]
}

Then point to it:

"env": {
  "ENVIRONMENTS_CONFIG_PATH": "/path/to/environments.json"
}

Tools accept an optional environment parameter to target a specific environment. The IntentRouter can also infer environments from natural language (e.g., "show tables in prod" → uses prod environment).

Environment policy fields

Named SQL scripts

For repeatable operations, you can define pre-approved SQL scripts that agents can execute with parameters. This is safer than ad-hoc SQL since scripts are reviewed in advance.

Setup:

1. Create a scripts directory with a scripts.json manifest:

{
  "scripts": [
    {
      "name": "find_user_by_email",
      "description": "Look up a user by email address",
      "file": "find_user_by_email.sql",
      "parameters": [
        { "name": "email", "type": "string", "required": true }
      ],
      "readonly": true,
      "tier": "reader"
    },
    {
      "name": "deactivate_user",
      "description": "Deactivate a user account",
      "file": "deactivate_user.sql",
      "parameters": [
        { "name": "userId", "type": "number", "required": true }
      ],
      "tier": "writer",
      "requiresApproval": true,
      "deniedEnvironments": ["prod"]
    }
  ]
}

2. Create the SQL files (use @paramName for parameters):

-- find_user_by_email.sql
SELECT UserId, Email, DisplayName, CreatedAt
FROM Users
WHERE Email = @email

3. Configure the path in environments.json:

{
  "defaultEnvironment": "dev",
  "scriptsPath": "./scripts",
  "environments": [...]
}

Or via environment variable: SCRIPTS_PATH=/path/to/scripts

Script governance fields:

Usage:

> Use list_scripts to see available scripts
> Run the find_user_by_email script with email "user@example.com"
> Preview the deactivate_user script with userId 123

⚠️ Safety & Prudence

With great power comes great responsibility.

This MCP server exposes powerful CRUD operations including drop_table, create_table, update_data, and insert_data. If you enable full autopilot mode in your AI assistant—or simply aren't inspecting each tool call—you could trigger destructive actions you don't intend.

Recommended Safeguards

1. Use READONLY=true by default. This globally disables all write operations, exposing only safe discovery tools. Enable write mode only when you explicitly need it.

2. Preview before mutations. update_data and delete_data show affected rows and require explicit confirmation (confirmUpdate: true / confirmDelete: true) before executing. Row counts are capped at 1000 by default.

3. Be a prudent human in the loop. Review tool calls before approval, especially for destructive operations. Don't blindly trust AI-generated queries against production data.

4. Use dedicated credentials. Connect with a database user that has only the permissions you intend to grant. Avoid sa or admin accounts in production.

5. Test in non-production first. Validate tool behavior against development or staging databases before pointing at production.

6. Monitor and audit. Audit logging is enabled by default—check logs/audit.jsonl for a record of all tool invocations. Sensitive parameters are auto-redacted.

The discovery tools (search_schema, profile_table, inspect_relationships) are designed to help you understand unfamiliar databases safely. Use them to build context before issuing any mutations.

Tool tuning

• Schema discovery pagination – Use SEARCH_SCHEMA_DEFAULT_LIMIT to tune how many rows search_schema returns per page (default 50, max 200). Combine with tableOffset/columnOffset params for manual paging.

• Profiling samples – Use PROFILE_SAMPLE_SIZE_DEFAULT to control how many rows are sampled internally (default 50). Control how many rows are actually returned with PROFILE_SAMPLE_RETURN_LIMIT (default 10). Both respect per-request overrides via sampleSize and includeSamples args.

Deployment

See DEPLOYMENT.md for enterprise deployment patterns including:

• Network topologies (direct, VPN, SSH tunnel, jump host, container)

• Docker / Docker Compose examples

• systemd service setup

• Security hardening checklist

• Multi-client fleet configuration

• Troubleshooting common connection issues

Roadmap

See ROADMAP.md for the full enterprise roadmap with status tracking.

Recently shipped (v0.3.x):

• ✅ Pluggable secret providers — dotenv and file providers join env; configure via secrets.providers in environments.json

• ✅ Per-environment connection pools — each environment gets its own isolated ConnectionPool (fixes cross-environment data leaks from the old global singleton)

• ✅ NTLM domain/username parsing — DOMAIN\user format auto-splits for tedious driver compatibility

• ✅ Configurable requestTimeout per environment (default 120s, up from the mssql package's 15s default)

• ✅ Version tracking — test_connection returns mcpServerVersion for debugging

• ✅ validate_environment_config now validates secrets providers and checks resolvability of all ${secret:NAME} references

Previously shipped:

• ✅ Multi-environment connection profiles with governance controls

• ✅ Per-environment policy controls (allowedTools, deniedTools, requireApproval, maxRowsDefault)

• ✅ Server-level access with database filtering (accessLevel: "server")

• ✅ Schema-level access control (allowedSchemas, deniedSchemas)

• ✅ Audit logging with session IDs and per-environment log levels

• ✅ Configuration validation tool (validate_environment_config)

• ✅ Secret placeholder resolution (${secret:NAME})

• ✅ Preview/confirm flows for UPDATE and DELETE

• ✅ Named SQL scripts (list_scripts, run_script) with full governance

• ✅ Dependency analysis (inspect_dependencies) for impact assessment

Recently completed:

• ✅ Shared core package (@connorbritain/mssql-mcp-core) — all three tiers are thin wrappers

• ✅ MCP Registry registration for all three packages

• ✅ Deployment & bastion pattern documentation

Next priorities:

• Pluggable secret providers (Azure Key Vault, AWS Secrets Manager)

• External log shipping (Syslog, Azure Monitor, Splunk)

Contributing

Contributions welcome! See CONTRIBUTING.md for guidelines. If you're working with SQL Server in environments where stability and security matter, I'd love to hear what tools would help you most.

If this project is useful to you, consider giving it a ⭐ on GitHub and sharing it with others who work with SQL Server. The more eyes on it, the better it gets.

License & attribution

MIT license. See LICENSE for details.

This project was originally forked from Microsoft's SQL-AI-samples and has since evolved into a standalone, production-focused MCP server. Thanks to the Microsoft Azure SQL team for the initial foundation, and to the MCP community for the protocol specs that make cross-agent tooling possible.

Versioning

This package follows semver. Note: version 1.0.1 is permanently reserved on npm due to a prior publish and cannot be used for future releases.

Repository: https://github.com/ConnorBritain/mssql-mcp-server
npm package: https://www.npmjs.com/package/@connorbritain/mssql-mcp-server
Issues & support: https://github.com/ConnorBritain/mssql-mcp-server/issues