MCP and SQL Server: What Every DBA Needs to Know About the Protocol Connecting AI to Your Database

Something significant is happening to your database. Not inside it, not to its schema or indexes or query plans, but to the access layer around it. AI tools are now being connected to SQL Server instances through a protocol called MCP, and in most organizations the DBA is the last person to find out it is happening.

A developer installs Claude Desktop or an AI coding assistant, connects it to an MCP server that points at the production database, and now an AI system can query your tables, analyze your execution plans, and potentially execute statements against live data. Whether that is useful or catastrophic depends almost entirely on how the connection was built and what controls are in place. Most of the time, in 2026, the controls are not in place.

This article explains MCP from first principles, shows you exactly how it connects to SQL Server, walks through every security risk with real-world CVE examples, and gives you the governance framework to build or evaluate an MCP deployment safely. If someone in your organization is building AI tools that touch your database, this is the article that explains what is actually happening under the hood.

1 What MCP Is and Where It Came From Beginner

The Model Context Protocol is an open standard for connecting AI systems to external tools, data sources, and services. Anthropic published the initial specification in November 2024 with reference implementations in TypeScript and Python. Within six months, every major AI vendor had adopted it. By the end of 2025, OpenAI, Google, Microsoft, and AWS all supported MCP in their AI products. In December 2025, Anthropic, Block (Square), and OpenAI transferred governance of both MCP and the Agent-to-Agent (A2A) protocol to the Linux Foundation under the newly formed Agentic AI Foundation, cementing MCP as a neutral, community-governed standard rather than Anthropic’s proprietary protocol.

The problem MCP solves is called the N times M integration problem. Before MCP, every AI tool needed a custom integration for every external system. Claude needed a custom SQL Server connector. GPT-4 needed a different custom SQL Server connector. If you had five AI tools and ten data sources, you needed fifty custom integrations, each built differently, each maintained separately, each with its own security model. MCP collapses this to N plus M: one MCP server per data source, one MCP client per AI tool, and any combination works.

How Fast MCP Grew

2 How MCP Works: The Three Primitives Beginner

Every MCP server exposes its capabilities through exactly three types of objects. This three-primitive model is deliberately minimal. It covers the vast majority of real-world integration scenarios while keeping the protocol simple enough to implement correctly.

Tools: Actions With Side Effects

A Tool is an executable operation that produces side effects in the real world. When an AI agent calls a Tool, something actually happens: a database row is written, an API is called, a file is created, a script runs. Tools are the most powerful primitive and the most security-sensitive. They are what make MCP useful for operational automation and what make it dangerous if improperly secured.

For a SQL Server MCP server, examples of Tools include: execute a query, insert a record, run a stored procedure, trigger a backup, restart an Agent job. Every Tool that can write, modify, or delete data in your database is a potential risk if the MCP server is compromised or manipulated.

Resources: Read-Only Data Access

A Resource is a data source that an AI client can read without taking a write action. Resources do not change the state of any external system. For SQL Server, Resources might expose the database schema, index metadata, execution plan cache contents, or a catalog of stored procedure signatures. The AI reads the Resource to understand the environment, then uses Tools to act on it.

Prompts: Reusable Templates

A Prompt is a pre-defined template for a common task. A SQL Server MCP server might expose Prompts for common DBA tasks: “diagnose slow query,” “generate index recommendation,” “summarize blocking session.” The AI client invokes the Prompt with parameters and gets a structured response. Prompts do not execute actions themselves but they guide the AI toward calling the right Tools with the right inputs.

3 The Architecture: Clients, Servers, and the Data Flow Beginner

An MCP deployment has three components: the host, the client, and the server. Understanding how they connect and where data flows is essential for understanding where the security boundaries are.

The Host is the AI application the user interacts with directly: Claude Desktop, ChatGPT, GitHub Copilot, a VS Code AI extension, or your organization’s internal AI assistant. The host contains the LLM and manages the conversation.

The MCP Client lives inside the host application. It handles the MCP protocol communication: connecting to servers, discovering their capabilities (Tools, Resources, Prompts), and forwarding tool call requests and results between the LLM and the servers.

The MCP Server is a separate process that wraps a specific tool or data source. A SQL Server MCP server accepts structured requests from the client, translates them into SQL or SQL Server API calls, executes them, and returns formatted results. The server never communicates with the LLM directly. All interaction is mediated through the client.

MCP uses JSON-RPC 2.0 as its message format. Communication happens over one of two transport mechanisms: standard input/output for locally-spawned servers (the server runs as a child process of the host application), or HTTP with Server-Sent Events for remote servers (the server runs as a network service accessible via URL). Remote servers require OAuth 2.1 authentication as of the 2026 MCP specification update.

4 Why MCP Replaced Custom Integrations Beginner

Before MCP, connecting any AI tool to any data source required writing custom integration code: parsing the AI tool’s specific function-calling API format, authenticating with the data source, translating between them, handling errors, and maintaining the integration as both systems updated their APIs. Multiply that by the number of AI tools times the number of data sources and the maintenance burden became enormous.

MCP standardizes the interface on both sides. A SQL Server MCP server written once works with Claude Desktop, GitHub Copilot, ChatGPT Enterprise, Amazon Q, Kiro IDE, and every other MCP-compatible AI client immediately, with no changes to the server code. When a new AI client launches, it supports your existing MCP servers from day one. When a new MCP server is published for a tool you use, every AI client your organization uses can connect to it immediately.

This is why adoption happened so fast. The value compounds with the size of the ecosystem. As of early 2026, over 500 public MCP servers cover databases (PostgreSQL, MySQL, SQLite, SQL Server), file storage, messaging (Slack, email), project management (Jira, Asana), cloud infrastructure (AWS, Azure, GCP), monitoring, and hundreds of other categories.

5 How MCP Connects to SQL Server Intermediate

A SQL Server MCP server is a program, typically written in Python or TypeScript, that wraps a SQL Server connection and exposes it as MCP-compatible Tools, Resources, and Prompts. The server connects to SQL Server using a standard connection library (pyodbc, sqlalchemy, or the Microsoft ODBC driver) and translates MCP tool calls into T-SQL statements.

Several community-built SQL Server MCP servers already exist. The most referenced is mssql_mcp_server on GitHub. Microsoft’s own Azure SQL MCP server is in active development. These servers provide schema discovery, query execution, and performance metadata access out of the box.

# How a SQL Server MCP server is configured in Claude Desktop
# File: ~/.config/claude-desktop/config.json (macOS/Linux)
# File: %APPDATA%\Claude\claude_desktop_config.json (Windows)

{
  "mcpServers": {
    "sqlserver-production": {
      "command": "python",
      "args": ["/path/to/mssql_mcp_server.py"],
      "env": {
        "MSSQL_SERVER":   "your-server-name",
        "MSSQL_DATABASE": "YourDatabase",
        "MSSQL_USERNAME": "mcp_readonly_user",
        "MSSQL_PASSWORD": "stored-securely-not-here"
      }
    }
  }
}

-- After configuring, Claude Desktop discovers the server's tools automatically.
-- You can then ask Claude in natural language:
-- "Show me the top 10 queries by CPU time in the last hour"
-- "Are there any blocking sessions right now?"
-- "What indexes are missing on the Orders table?"
-- "Check the error log for the last 24 hours"
-- Claude calls the appropriate MCP tool, gets results from SQL Server,
-- and presents them in a readable format with analysis

What the MCP Server Exposes to AI Clients

# Example tool definitions a SQL Server MCP server might expose
# (conceptual representation of what the AI client sees)

Tools available from sqlserver-production:
  - execute_query(sql: str, max_rows: int = 100)
      Execute a read-only SELECT query against the database
  - get_blocking_sessions()
      Return current blocking sessions from sys.dm_exec_requests
  - get_missing_indexes(database: str)
      Return missing index recommendations from DMVs
  - get_wait_statistics()
      Return current wait statistics from sys.dm_os_wait_stats
  - get_error_log(hours: int = 24)
      Return recent SQL Server error log entries

Resources available:
  - schema://tables
      Full schema definition for all tables in the database
  - schema://indexes
      Current index definitions and usage statistics
  - schema://stored-procedures
      Stored procedure signatures and descriptions

Prompts available:
  - diagnose_slow_query
      Template for analyzing a slow query with execution plan
  - review_blocking_incident
      Template for investigating a blocking chain

6 What an MCP Server for SQL Server Looks Like in Practice Intermediate

Here is a production-ready starting point for a secure, read-only SQL Server MCP server. This is the minimum viable implementation that a DBA should build or review when an MCP server is proposed for their SQL Server environment.

# Secure SQL Server MCP server using FastMCP 3.0
# pip install fastmcp pyodbc
# FastMCP 3.0 (January 2026) handles schema, validation, and docs automatically

from fastmcp import FastMCP
import pyodbc
import json
import re

mcp = FastMCP(
    name        = "sqlserver-dba-readonly",
    description = "Read-only SQL Server access for DBA operations and AI analysis"
)

# Use Windows Auth in production -- never hardcode SQL Auth credentials
CONN_STRING = (
    "DRIVER={ODBC Driver 18 for SQL Server};"
    "SERVER=your-prod-server;"
    "DATABASE=YourDatabase;"
    "Trusted_Connection=yes;"
    "Encrypt=yes;"
    "TrustServerCertificate=no;"
)

# ── SECURITY: forbidden keyword list ─────────────────────────────────────────
WRITE_KEYWORDS = [
    'INSERT', 'UPDATE', 'DELETE', 'DROP', 'TRUNCATE', 'CREATE',
    'ALTER', 'EXEC', 'EXECUTE', 'GRANT', 'REVOKE', 'DENY',
    'BULK', 'OPENROWSET', 'OPENDATASOURCE', 'xp_', 'sp_configure'
]

def is_safe_query(sql: str) -> tuple[bool, str]:
    """Validate that a query contains no write operations."""
    upper = sql.upper()
    for keyword in WRITE_KEYWORDS:
        # Word boundary check to avoid false positives (e.g., 'EXECUTE' in a column name)
        pattern = r'\b' + re.escape(keyword) + r'\b'
        if re.search(pattern, upper):
            return False, f"Operation '{keyword}' is not permitted through this MCP server."
    return True, ""

# ── RESOURCE: expose schema as read-only metadata ────────────────────────────
@mcp.resource("schema://tables")
def get_schema() -> str:
    """Database schema: table names, column names, types, and nullability."""
    conn   = pyodbc.connect(CONN_STRING)
    cursor = conn.cursor()
    cursor.execute("""
        SELECT t.TABLE_NAME, c.COLUMN_NAME, c.DATA_TYPE, c.IS_NULLABLE,
               c.CHARACTER_MAXIMUM_LENGTH
        FROM INFORMATION_SCHEMA.TABLES   t
        JOIN INFORMATION_SCHEMA.COLUMNS  c ON c.TABLE_NAME = t.TABLE_NAME
        WHERE t.TABLE_TYPE = 'BASE TABLE'
        ORDER BY t.TABLE_NAME, c.ORDINAL_POSITION
    """)
    rows = cursor.fetchall()
    cols = [d[0] for d in cursor.description]
    return json.dumps([dict(zip(cols, r)) for r in rows], default=str)

# ── TOOL: read-only analytics query with full guardrails ──────────────────────
@mcp.tool()
def run_analytics_query(sql: str, max_rows: int = 100) -> str:
    """
    Execute a read-only SELECT query.
    Write operations (INSERT, UPDATE, DELETE, DROP, EXEC, etc.) are blocked.
    Results capped at max_rows (default 100, maximum 1000).
    Query timeout: 30 seconds.
    """
    safe, reason = is_safe_query(sql)
    if not safe:
        return f"BLOCKED: {reason}"

    max_rows = min(max_rows, 1000)   # hard ceiling regardless of what caller requests

    conn = pyodbc.connect(CONN_STRING)
    conn.timeout = 30   # 30-second execution timeout

    try:
        cursor = conn.cursor()
        cursor.execute(f"SET ROWCOUNT {max_rows}; {sql}")
        cols = [d[0] for d in cursor.description]
        rows = cursor.fetchall()
        return json.dumps([dict(zip(cols, r)) for r in rows], default=str)
    except Exception as e:
        return f"Query error: {str(e)}"
    finally:
        conn.close()

# ── TOOL: blocking sessions from DMV ─────────────────────────────────────────
@mcp.tool()
def get_blocking_sessions() -> str:
    """
    Return all currently blocking sessions with session ID, wait type,
    blocked count, and query text. Uses sys.dm_exec_requests.
    """
    conn   = pyodbc.connect(CONN_STRING)
    cursor = conn.cursor()
    cursor.execute("""
        SELECT
            r.session_id,
            r.blocking_session_id,
            r.wait_type,
            r.wait_time / 1000.0    AS wait_seconds,
            r.status,
            LEFT(st.text, 500)      AS query_text
        FROM sys.dm_exec_requests r
        CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) st
        WHERE r.blocking_session_id > 0
        ORDER BY r.wait_time DESC
    """)
    rows = cursor.fetchall()
    if not rows:
        return json.dumps({"message": "No blocking sessions found.", "count": 0})
    cols = [d[0] for d in cursor.description]
    return json.dumps([dict(zip(cols, r)) for r in rows], default=str)

# ── TOOL: missing index recommendations ──────────────────────────────────────
@mcp.tool()
def get_missing_index_recommendations() -> str:
    """
    Return top 10 missing index recommendations ranked by impact score.
    Source: sys.dm_db_missing_index_details and related DMVs.
    """
    conn   = pyodbc.connect(CONN_STRING)
    cursor = conn.cursor()
    cursor.execute("""
        SELECT TOP 10
            OBJECT_NAME(mid.object_id, mid.database_id) AS table_name,
            ROUND(migs.avg_total_user_cost * migs.avg_user_impact
                * (migs.user_seeks + migs.user_scans), 0) AS impact_score,
            mid.equality_columns,
            mid.inequality_columns,
            mid.included_columns
        FROM sys.dm_db_missing_index_group_stats migs
        JOIN sys.dm_db_missing_index_groups      mig ON migs.group_handle = mig.index_group_handle
        JOIN sys.dm_db_missing_index_details     mid ON mig.index_handle  = mid.index_handle
        WHERE mid.database_id = DB_ID()
        ORDER BY impact_score DESC
    """)
    rows = cursor.fetchall()
    cols = [d[0] for d in cursor.description]
    return json.dumps([dict(zip(cols, r)) for r in rows], default=str)

if __name__ == "__main__":
    mcp.run()

7 Real DBA Use Cases That Are Already Happening Beginner

The following use cases are not hypothetical. They are active deployments in organizations that have already connected MCP to their SQL Server environments. The question for every DBA is not “will this happen in my organization?” but “is it already happening, and do I know about it?”

Performance Diagnostics

A developer or DBA opens Claude Desktop, which is connected to a read-only SQL Server MCP server. They ask in plain English: “Which queries are using the most CPU in the last hour?” or “Are there any deadlocks in the last 24 hours?” The AI calls the appropriate DMV queries through the MCP server, receives the results, and presents an analysis with recommended actions. What previously required 20 minutes of DMV querying and execution plan analysis now takes two minutes of conversation.

Schema-Aware Query Generation

A developer needs to write a complex query joining multiple tables. They ask the AI: “Write a query showing revenue by customer segment for Q1 2026 using the schema in our sales database.” The AI calls the schema Resource through MCP, reads the actual table and column names, and generates syntactically correct T-SQL that references the real schema rather than hallucinated column names. The query works on the first try.

Incident Investigation

During an outage, a DBA asks the AI: “Something happened at 2:47 AM. Check the error log, look for blocking sessions that were open around that time, and tell me what you find.” The AI queries the error log tool, the blocking history tool, and the wait statistics tool, then synthesizes a narrative of what happened. Investigation that would take an hour takes ten minutes.

Index Tuning Assistance

A DBA asks: “What are the top missing indexes by impact score and generate CREATE INDEX statements for the top three?” The AI calls the missing index DMV tool, reads the results, evaluates the columns, and generates ready-to-review T-SQL. The DBA validates the output before executing anything.

Documentation Generation

An AI assistant connected to the schema Resource reads all table definitions, column names, and existing documentation, then generates or updates a data dictionary. Documentation that was perpetually out of date gets refreshed automatically when the schema changes.

8 The Five MCP Security Threats Every DBA Must Understand Intermediate

MCP creates capabilities that did not exist before. Those capabilities come with a new attack surface. Five specific threats are documented, reproducible, and have already been exploited in the wild.

9 Real CVEs and Real Incidents Beginner

MCP is less than 18 months old and already has documented CVEs and confirmed exploitation incidents. This is not theoretical risk.

CVE-2025-49596 (CVSS 9.4)

Attackers exploited unauthenticated MCP Inspector instances to execute arbitrary commands. The MCP Inspector is a developer debugging tool that, when left running on a network-accessible port without authentication, allowed remote code execution through the MCP protocol. The severity score of 9.4 reflects the combination of no authentication required and full command execution capability.

CVE-2025-6514

A shell command injection vulnerability in the mcp-remote package, a widely used utility for connecting to remote MCP servers. The vulnerability allowed attackers to inject shell commands through MCP server URLs. The package had been downloaded 437,000 times before the vulnerability was disclosed, meaning over 400,000 developer environments were potentially exposed.

First Malicious MCP Package (September 2025)

A package published to a community MCP server registry appeared to provide legitimate email integration functionality. It operated normally for two weeks while a secondary behavior quietly exfiltrated email data. Detection came through anomalous network traffic analysis, not through any MCP-specific monitoring. The incident highlighted the supply chain risk: the same trust model that makes npm and PyPI packages useful also makes malicious packages in those ecosystems dangerous when connected to AI agents with system access.

Supabase/Cursor SQL Injection Incident

A Cursor AI agent processing customer support tickets executed SQL injection commands that had been embedded in the ticket text by a user. The agent was legitimately asked to process tickets and correctly used its SQL access tool to do so. It could not distinguish between legitimate ticket content and the injected SQL commands. The result was exposure of integration tokens. This is a textbook prompt injection via external data: the malicious instruction did not come from the user’s prompt but from content the AI retrieved and processed.

10 What Makes Database MCP Servers Different Advanced

Not all MCP servers carry the same risk. A server that lets an AI search your documentation has a fundamentally different blast radius from a server that lets an AI query your production database. Database MCP servers sit at the top of the risk hierarchy for three reasons.

Data value. Your SQL Server databases contain your most sensitive organizational data: customer PII, financial records, employee data, health records, transaction history. A compromised database MCP server exposes all of it to whoever controls the attack.

Write consequences. Most MCP servers expose read-only capabilities. A database MCP server with write access can modify or delete data that took years to accumulate and may be practically impossible to fully recover. A deleted customer table is a business-continuity incident. A corrupted financial record is a compliance incident.

Privilege escalation path. A SQL Server account used by an MCP server may have access to extended stored procedures (xp_cmdshell, if enabled), linked servers, CLR assemblies, or other mechanisms that allow database-level access to escalate to operating system access. An attacker who compromises a database MCP server may be able to move laterally to the underlying server.

11 What an MCP Registry Is and Why Enterprises Need One Intermediate

An MCP registry is a centralized catalog of approved MCP servers within an organization. Without one, every employee with an AI tool can connect it to whatever MCP server they find on GitHub. With one, the organization controls which MCP servers are permitted, who can use them, what permissions each server operates with, and which AI clients are authorized to connect.

Think of it as the internal app store for AI integrations. The same way organizations manage which applications can be installed on corporate laptops, an MCP registry manages which AI integrations can be connected to corporate systems.

The Anthropic-managed public MCP Registry (launched September 2025) catalogs community-built servers. Enterprise organizations should treat this as an open-source registry, not an approved vendor catalog. Every server from the public registry needs internal security review before use in an enterprise environment with access to sensitive systems.

12 Building a Secure SQL Server MCP Server Intermediate

These are the non-negotiable security controls for any SQL Server MCP server in a production environment.

Dedicated Low-Privilege SQL Account

-- Create a dedicated SQL login for MCP read-only access
-- Never use sa or an existing high-privilege account

CREATE LOGIN mcp_analytics_reader
    WITH PASSWORD     = 'UseAStrongPasswordHere2026!',
         CHECK_POLICY = ON,
         CHECK_EXPIRATION = ON;

USE YourDatabase;
CREATE USER mcp_analytics_reader FOR LOGIN mcp_analytics_reader;

-- Grant SELECT only on specific schemas that contain analytics-safe data
GRANT SELECT ON SCHEMA::dbo    TO mcp_analytics_reader;

-- Explicitly deny access to sensitive tables even within granted schemas
DENY SELECT ON dbo.CustomerPII          TO mcp_analytics_reader;
DENY SELECT ON dbo.PaymentCardData      TO mcp_analytics_reader;
DENY SELECT ON dbo.EmployeeSalaries     TO mcp_analytics_reader;
DENY SELECT ON dbo.HealthRecords        TO mcp_analytics_reader;

-- Grant VIEW DATABASE STATE for DMV access (performance monitoring)
-- This allows access to sys.dm_exec_requests, sys.dm_os_wait_stats, etc.
-- without granting access to actual table data
GRANT VIEW DATABASE STATE TO mcp_analytics_reader;
GRANT VIEW SERVER STATE   TO mcp_analytics_reader;

-- For a write-capable MCP server (use with extreme caution):
-- Create a SEPARATE login with write access to specific tables only
-- NEVER share the read and write accounts
CREATE LOGIN mcp_write_scoped
    WITH PASSWORD = 'DifferentStrongPassword2026!',
         CHECK_POLICY = ON;

USE YourDatabase;
CREATE USER mcp_write_scoped FOR LOGIN mcp_write_scoped;
-- Grant write only to the specific tables that require it
GRANT INSERT ON dbo.AIAuditLog     TO mcp_write_scoped;
GRANT INSERT ON dbo.AIQueryLog     TO mcp_write_scoped;
-- Nothing else

Audit Logging at the MCP Layer

# Log every tool call at the MCP server level
# This creates an AI-specific audit trail separate from SQL Server's own auditing
# Both are needed: SQL Server audits the query, MCP audits the AI context

import logging
import json
from datetime import datetime

# Configure structured logging for MCP audit trail
logging.basicConfig(
    filename = '/var/log/mcp/sqlserver_mcp_audit.log',
    level    = logging.INFO,
    format   = '%(asctime)s %(message)s'
)

def log_tool_call(tool_name: str, args: dict, result_row_count: int,
                  client_id: str = "unknown"):
    """
    Log every MCP tool call with context.
    This creates the AI-layer audit trail that SQL Server logging does not provide.
    """
    audit_entry = {
        "timestamp":        datetime.utcnow().isoformat(),
        "tool_name":        tool_name,
        "args":             args,
        "result_row_count": result_row_count,
        "client_id":        client_id,   # which AI client made the call
        "server":           "sqlserver-prod-readonly"
    }
    logging.info(json.dumps(audit_entry))

# Also write to a SQL Server audit table for centralized review:
def log_to_sql_audit(tool_name: str, query_text: str, row_count: int):
    conn   = pyodbc.connect(CONN_STRING)
    cursor = conn.cursor()
    cursor.execute("""
        INSERT INTO dbo.MCPAuditLog
            (ToolName, QueryText, RowCount, LoggedAt)
        VALUES (?, ?, ?, SYSDATETIME())
    """, tool_name, query_text[:2000], row_count)
    conn.commit()

The MCP Audit Log Table

-- Create a dedicated audit table for all MCP tool calls
-- This is queryable from SQL Server directly for compliance and investigation

CREATE TABLE dbo.MCPAuditLog (
    AuditID      BIGINT         IDENTITY(1,1) PRIMARY KEY,
    ToolName     VARCHAR(200)   NOT NULL,
    QueryText    NVARCHAR(2000) NOT NULL,
    RowCount     INT            NOT NULL,
    ClientID     VARCHAR(200)   NULL,       -- which AI client initiated the call
    LoggedAt     DATETIME2      NOT NULL DEFAULT SYSDATETIME()
);

-- Index for efficient time-range queries during investigation
CREATE NONCLUSTERED INDEX IX_MCPAuditLog_LoggedAt
ON dbo.MCPAuditLog (LoggedAt DESC)
INCLUDE (ToolName, QueryText);

-- Query the audit log for suspicious patterns:
-- Find queries that ran outside business hours
SELECT ToolName, QueryText, RowCount, LoggedAt
FROM dbo.MCPAuditLog
WHERE DATEPART(HOUR, LoggedAt) NOT BETWEEN 7 AND 19
ORDER BY LoggedAt DESC;

-- Find queries returning unusually large row counts (potential data exfiltration)
SELECT ToolName, QueryText, RowCount, LoggedAt
FROM dbo.MCPAuditLog
WHERE RowCount > 500
ORDER BY RowCount DESC;

13 The DBA Governance Checklist for MCP Beginner

Use this checklist when evaluating an existing MCP deployment or approving a new one. Every item is non-negotiable for a production SQL Server environment.

Account Security

• MCP server uses a dedicated SQL login, not sa or a shared admin account
• Login has SELECT-only access, not db_datareader on the whole database
• Sensitive tables (PII, financial, health) are explicitly denied even within granted schemas
• Separate accounts for read-only MCP and write-capable MCP, never shared
• MCP login password stored in a secrets vault, not in plaintext config files
• MCP login is not a member of any SQL Server fixed roles (no db_owner, no sysadmin)

Query Controls

• Server has a forbidden keyword list blocking INSERT, UPDATE, DELETE, DROP, EXEC, xp_
• Query execution has a hard row cap (1000 rows maximum) regardless of what the AI requests
• Query execution has a timeout (30 seconds) to prevent runaway analytical queries from blocking OLTP
• Dynamic SQL constructed by the MCP server uses parameterized queries, not string concatenation
• High-risk operations (bulk export, schema changes) require explicit human approval, not AI-only execution

Audit and Visibility

• Every MCP tool call is logged at the application layer with timestamp, tool name, and query text
• SQL Server audit is enabled for the MCP login to capture all queries at the database layer
• MCPAuditLog table or equivalent is populated after every tool call
• Audit logs are reviewed weekly or alert rules exist for anomalous patterns
• DBA knows which AI clients are connected to each MCP server

Server Review

• MCP server source code has been reviewed by at least one DBA or security team member
• Community MCP servers from public registries have been assessed before use
• Tool descriptions reviewed for hidden instructions (tool poisoning check)
• MCP server dependencies (pip packages, npm packages) are pinned and reviewed
• MCP server runs under a service account with minimum OS-level permissions

14 The 30/90/180 Day Security Roadmap Advanced

If MCP is already being used in your organization or is about to be introduced, this is the phased response. It is adapted from CISA’s May 2025 guidance on AI system trustworthiness and the SentinelOne MCP security framework.

Within 30 Days

• Inventory every MCP deployment in the organization. Ask development teams, check Claude Desktop configs, review VS Code extension lists, audit network logs for MCP port traffic (default: local IPC or HTTP on developer-chosen ports).
• For every MCP server connected to SQL Server: identify what login it uses and what permissions that login has. Revoke anything above read-only immediately if no documented business justification exists.
• Implement authenticated server connections. Any MCP server running without authentication on a network-accessible port is an immediate remediation item.
• Create the MCPAuditLog table and configure the MCP server to populate it.

Within 90 Days

• Deploy centralized MCP gateway architecture. All MCP traffic to production SQL Server routes through a gateway that enforces authentication, authorization, logging, and rate limiting.
• Implement approval workflows for high-risk operations. Database deletions, bulk exports, schema changes, and stored procedure execution require human approval before the MCP tool executes.
• Establish an approved MCP server catalog. Publish a list of reviewed and approved MCP servers. Block unapproved MCP connections at the network or application level.
• Enable SQL Server Audit for the MCP login to capture database-layer activity independently of the MCP server’s own logging.

Within 180 Days

• Build comprehensive identity governance. Every MCP tool call is attributable to an individual user, not just an AI client. OAuth 2.1 flow from the AI client through the MCP server to the database, preserving user identity at each layer.
• Implement automated anomaly detection on the MCP audit logs. Alert on: queries running outside business hours, row counts above threshold, queries targeting sensitive tables, repeated failed queries (reconnaissance pattern).
• Formal security review process for any new MCP server before production approval. Reviews include source code inspection, dependency review, tool description audit (tool poisoning check), and penetration testing of the server itself.

15 Where MCP Is Headed in 2026 and Beyond Intermediate

The MCP specification continues to evolve rapidly. Two changes on the 2026 roadmap are directly relevant to database security.

Stateless operation. Current MCP servers must maintain session state, which limits horizontal scaling and complicates load balancing. The new specification standardizes session creation, resumption, and migration so server restarts and scale-out events are transparent to clients. For enterprise SQL Server deployments this means MCP servers can be deployed behind load balancers with high availability, making them suitable for production-critical AI workflows rather than just developer tooling.

Incremental scope consent. The 2026 specification update introduced incremental scope consent, allowing MCP clients to request only the minimum access needed for each specific operation rather than requesting all permissions upfront at connection time. This directly reduces the blast radius of a compromised session: an AI agent that only needed to read order data for this session cannot use its credentials to access customer PII in the same session.

The broader trajectory is clear: MCP is becoming the standard integration layer between AI systems and enterprise infrastructure, in the same way that REST APIs became the standard integration layer between web applications. Organizations that build secure governance frameworks around MCP now will be positioned to move fast and safely as AI capabilities expand. Those that do not will discover their governance gap at the worst possible time.

16 What This Means for the DBA Role Everyone

MCP creates new responsibilities and new opportunities for DBAs and data architects that did not exist 18 months ago.

New responsibility: MCP security ownership. The DBA is the person in the organization who understands the data layer, the permission model, the audit capabilities, and the risk of unauthorized access better than anyone else. No one is better positioned to evaluate whether an MCP server is safely configured, whether the SQL login has appropriate permissions, or whether the query controls are sufficient. If the DBA does not own this layer, someone who does not understand these risks will.

New responsibility: AI query pattern tuning. AI-generated queries through MCP produce distinctive patterns: high-frequency schema discovery calls, parallel DMV queries, complex multi-table analytical queries with no indexes to support them. These patterns need to be understood and tuned just like any other application workload. The DBA who sees unusual query patterns after MCP is deployed and recognizes them as AI-generated is in a position to optimize for them.

New opportunity: AI-assisted DBA operations. A read-only MCP connection to SQL Server, built correctly with the controls in this article, is a genuinely powerful productivity tool. Blocking investigation that took an hour takes ten minutes. Index analysis that required opening SSMS, running DMV queries, and cross-referencing execution plans can be done in a single natural language conversation. Documentation that was never written gets generated from the schema automatically. The DBA who builds and owns the secure MCP server is the one who gets those productivity benefits and demonstrates them to the organization.

References

• Model Context Protocol: Official Specification
• MCP Blog: Introducing the MCP Registry (September 2025)
• Complete Guide to MCP Enterprise Adoption and Security (December 2025)
• SentinelOne: MCP Security Complete Guide (April 2026)
• TrueFoundry: MCP Security Risks and Best Practices (May 2026)
• Practical DevSecOps: MCP Security Vulnerabilities (January 2026)
• Research: MCP Threat Modeling and Tool Poisoning Analysis (2026)
• Veeam: MCP Security Risks Explained (February 2026)
• DEV Community: Complete Guide to MCP in 2026
• GitHub: mssql_mcp_server (SQL Server MCP Server)
• Microsoft Docs: Vector Support in SQL Server 2025
• CISA: Guidelines for Securing AI Systems (May 2025)
• SQLYARD: What Every Senior DBA Needs to Know About LLMs, RAG, Agents, and MCP
• SQLYARD: SQL Server Orphan Users Guide
• SQLYARD: SQL Server Index Tuning 2026