Skip to main content
Glama
PlanetMarc

SqlDb-MCP-Server

by PlanetMarc

SQL Server MCP Server

A Model Context Protocol (MCP) server implementation that provides secure access to SQL Server databases. This server enables AI assistants and other MCP clients to query and interact with SQL Server databases through a standardized interface.

Overview

This MCP server acts as a bridge between MCP clients (like Claude Desktop or other AI assistants) and your SQL Server database, providing controlled access to execute queries and retrieve schema information. It implements the MCP protocol over stdio communication, making it suitable for integration with various AI tools and applications.

Related MCP server: Python MSSQL MCP Server

Features

Tools

The server exposes two primary tools for database interaction:

1. execute_query

  • Description: Execute any SQL query on the connected database

  • Input: SQL query string

  • Output: Query results in JSON format

  • Use Cases:

    • Data retrieval (SELECT statements)

    • Data manipulation (INSERT, UPDATE, DELETE)

    • Stored procedure execution

    • Complex joins and aggregations

2. get_schema_info

  • Description: Retrieve comprehensive database schema information

  • Input: None required

  • Output: List of all tables and stored procedures in JSON format

  • Use Cases:

    • Database exploration

    • Understanding table structures

    • Discovering available stored procedures

    • Schema documentation

Prerequisites

  • Node.js 20 or higher

  • npm 7 or higher

  • Access to a SQL Server database (Azure SQL, SQL Server, or SQL Server Express)

  • Docker Desktop (for containerized deployment)

  • Azure CLI (for Azure deployment)

Configuration

Environment Variables

The server requires the following environment variables for database connection. Create a .env file in the project root:

# Copy the example file
cp .env.example .env

Edit .env with your database credentials:

# Database Configuration
DB_USER=your_database_username
DB_PASSWORD=your_database_password
DB_SERVER=your_server.database.windows.net
DB_NAME=your_database_name
DB_ENCRYPT=true                    # Use encryption (recommended for Azure SQL)
DB_TRUST_CERT=false                 # Don't trust self-signed certificates

Security Notes

  • Never commit .env files to version control

  • Use Azure Key Vault or similar services for production deployments

  • Consider using Managed Identity for Azure deployments

  • Implement proper firewall rules for database access

Development

Install dependencies:

npm install

Build the server:

npm run build

For development with auto-rebuild:

npm run watch

Build and Testing

Local Build

  1. Install dependencies and build:

npm install
npm run build
  1. Test the build:

node build/index.js

Docker Build

  1. Build the Docker image:

docker build -t sql-server-mcp:latest .
  1. Test with Docker Compose:

docker-compose up

Deployment

Local Installation (Visual Studio Code)

To use with Visual Studio Code and MCP-enabled extensions:

  1. Install Roo Cline Extension (or another MCP-compatible extension):

    • Open VS Code

    • Go to Extensions (Ctrl+Shift+X)

    • Search for "Roo Cline" or your preferred MCP client extension

    • Click Install

  2. Configure MCP Server in VS Code settings:

    Open VS Code settings (settings.json):

    • Press Ctrl+Shift+P (or Cmd+Shift+P on Mac)

    • Type "Preferences: Open Settings (JSON)"

    • Add the MCP server configuration:

{
  "roo-cline.mcpServers": {
    "sql-server": {
      "command": "node",
      "args": ["C:/path/to/sql-server-mcp/build/index.js"],
      "env": {
        "DB_USER": "your_username",
        "DB_PASSWORD": "your_password",
        "DB_SERVER": "your_server.database.windows.net",
        "DB_NAME": "your_database",
        "DB_ENCRYPT": "true",
        "DB_TRUST_CERT": "false"
      }
    }
  }
}
  1. Alternative: Use workspace-specific configuration:

    Create .vscode/settings.json in your workspace root:

{
  "roo-cline.mcpServers": {
    "sql-server": {
      "command": "node",
      "args": ["${workspaceFolder}/sql-server-mcp/build/index.js"],
      "env": {
        "DB_USER": "${env:DB_USER}",
        "DB_PASSWORD": "${env:DB_PASSWORD}",
        "DB_SERVER": "${env:DB_SERVER}",
        "DB_NAME": "${env:DB_NAME}",
        "DB_ENCRYPT": "true",
        "DB_TRUST_CERT": "false"
      }
    }
  }
}

Note: The exact configuration key (e.g., roo-cline.mcpServers) may vary depending on your MCP client extension. Consult your extension's documentation for the correct configuration format.

Azure Deployment

This project includes comprehensive Azure deployment support with multiple options:

Option 1: Quick Deployment Script

Use the included PowerShell script for automated deployment:

# Login to Azure
az login

# Run deployment script
.\deploy-azure.ps1 `
  -ResourceGroupName "mcp-sql-rg" `
  -Location "eastus" `
  -ContainerName "mcp-sql-server"

Option 2: GitHub Actions CI/CD

  1. Fork this repository

  2. Set up GitHub Secrets:

    • AZURE_CREDENTIALS - Service principal JSON

    • DB_USER - Database username

    • DB_PASSWORD - Database password

    • DB_SERVER - Server URL

    • DB_NAME - Database name

    • DB_ENCRYPT - "true" or "false"

    • DB_TRUST_CERT - "true" or "false"

  3. Push to main branch to trigger deployment

Option 3: Manual Azure Container Instance

# Create resource group
az group create --name mcp-sql-rg --location eastus

# Create container registry
az acr create --resource-group mcp-sql-rg --name mcpsqlregistry --sku Basic

# Build and push image
az acr build --registry mcpsqlregistry --image mcp-sql-server:latest .

# Deploy container instance
az container create \
  --resource-group mcp-sql-rg \
  --name mcp-sql-server \
  --image mcpsqlregistry.azurecr.io/mcp-sql-server:latest \
  --cpu 1 --memory 1 \
  --environment-variables \
    DB_USER=$DB_USER \
    DB_SERVER=$DB_SERVER \
    DB_NAME=$DB_NAME \
    DB_ENCRYPT=true \
    DB_TRUST_CERT=false \
  --secure-environment-variables \
    DB_PASSWORD=$DB_PASSWORD

For detailed deployment instructions, see DEPLOYMENT.md.

Debugging

MCP Inspector

Use the MCP Inspector for interactive debugging:

npm run inspector

This will start the inspector and provide a URL to access debugging tools in your browser.

Container Logs

For containerized deployments:

# Docker
docker logs <container-id>

# Azure Container Instance
az container logs --resource-group mcp-sql-rg --name mcp-sql-server

Troubleshooting

Common Issues

  1. Connection Timeout

    • Check firewall rules on SQL Server

    • Verify connection string format

    • Ensure database server is accessible from deployment environment

  2. Authentication Failed

    • Verify credentials in .env file

    • Check SQL Server authentication mode

    • Ensure user has necessary permissions

  3. Build Errors

    • Ensure Node.js 20+ is installed

    • Delete node_modules and run npm install again

    • Check TypeScript compilation errors with npm run build

Security Best Practices

  1. Credential Management

    • Use environment variables, never hardcode credentials

    • Implement Azure Key Vault for production

    • Use Managed Identity when possible

  2. Network Security

    • Configure firewall rules restrictively

    • Use Private Endpoints for Azure SQL

    • Implement VNet integration for containers

  3. Access Control

    • Use least-privilege database accounts

    • Implement row-level security where needed

    • Audit database access regularly

License

MIT

Support

For issues and questions:

Available Tools

2 tools
execute_queryB

Execute a SQL query on the database

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSQL query to execute

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden for behavioral disclosure. It merely says 'execute a SQL query' without warning that this could modify data, require specific permissions, or produce side effects. The agent is not informed whether read-only queries are enforced or if destructive operations are possible, which is a critical omission.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that wastes no words. It is concise and immediately understandable, earning full marks for conciseness and structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that executes arbitrary SQL, the description is severely incomplete. With no output schema and no annotations, the agent has no idea what the return value looks like (e.g., result set, affected row count), what errors might occur, or what safety constraints apply. The minimal description is insufficient for an agent to use this tool effectively and safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with the 'query' parameter described as 'SQL query to execute'. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool executes a SQL query on the database, using a specific verb and resource. This distinguishes it from the sibling tool get_schema_info, which retrieves schema information, so there is no ambiguity about what this tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus get_schema_info. It does not mention contexts, prerequisites, or exclusions, leaving the agent to infer appropriate usage without any supporting direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_schema_infoA

Retrieve database schema information, including tables and stored procedures

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. The term 'Retrieve' implies a non-destructive read, but it does not state permissions, performance characteristics, or the exact return format. This is acceptable for a simple read tool but leaves some ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence communicates the purpose without superfluous words, making it immediately scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless metadata tool, the description communicates the main outputs (tables, stored procedures) and implies a read-only use case. However, it does not specify edge cases or contrast with execute_query, so a small gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema is trivially covered. No parameter explanation is needed, and the baseline for zero parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Retrieve' with a clear resource 'database schema information' and enumerates tables and stored procedures, distinguishing it from the sibling execute_query which handles data queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for schema inspection but does not explicitly state when to prefer this over execute_query or provide exclusions. Sibling differentiation is absent, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv0.1.0
    • First observedexecute_query
    • First observedget_schema_info

TDQS

A3.7/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one executes arbitrary SQL queries, the other retrieves schema metadata. There is no overlap or ambiguity between them.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern with snake_case (execute_query, get_schema_info), making them predictable and uniform.

Tool Count3/5

With only two tools, the server feels minimal for a database-oriented MCP. While each tool is useful, the set is borderline thin for the apparent scope.

Completeness4/5

The execute_query tool can handle all SQL operations (including CRUD and DDL), and get_schema_info provides structural insight, covering core database needs. Minor gaps like dedicated transaction or table management tools exist but are not critical since they can be performed via SQL.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    A Model Context Protocol server that enables secure and structured interaction with Microsoft SQL Server databases, allowing AI assistants to list tables, read data, and execute SQL queries with controlled access.
    58
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables Language Models to interact with Microsoft SQL Server databases by inspecting table schemas, executing SQL queries, and reading table data through a standardized Model Context Protocol interface.
    27
    -
  • F
    license
    A
    quality
    D
    maintenance
    Enables AI assistants to query, analyze, and manage SQL Server databases through natural language via the Model Context Protocol.
    6
    1
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PlanetMarc/SqlDb-MCP-Server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server