Azure SQL MCP

This guide describes the prerequisites a customer must complete before an Azure SQL Database can be accessed through the Azure SQL MCP server hosted in an Azure Web App.

1. Azure SQL Database

An existing Azure SQL Database can be used; no schema redesign is required. Existing tables, views, and stored procedures remain unchanged.

2. Network Connectivity (Web App → Private Endpoint / Peered VNet)

Before the MCP server can be reached, the customer's network must be able to resolve and route to the Web App and the SQL Server correctly.

2.1 Private DNS for the Web App Private Endpoint

Configure the required private DNS records so the Web App hostname resolves to the Private Endpoint IP from the customer's network.

If using Azure Private DNS Zones: link the privatelink.azurewebsites.net zone to the customer's VNet (or peer to the VNet hosting the zone), and confirm the A record for the Web App points to IP.

If using on-prem/custom DNS: add a conditional forwarder to Azure DNS (or a static A record) for the Web App's private-link hostname.

2.2 SQL Server Reachability

If SQL Server uses a Private Endpoint:

Confirm the Private Endpoint is accessible over the peered VNet (VNet peering configured, no blocking NSG/route table rules).

Confirm the SQL Server's DNS name resolves to its private IP from the Web App's network path (via privatelink.database.windows.net zone, linked/peered correctly).

If SQL Server uses a Public Endpoint:

Configure the SQL Server firewall to allow the Web App's outbound public IP address(es).

Azure SQL firewall rules do not support private IP addresses — only public IPs are valid firewall rule entries.

3. Configure Azure SQL Firewall (General)

The MCP server runs in an Azure Web App. Azure SQL must allow network access from that Web App — either via the private path (Section 2.2) or by explicitly allowing the Web App's outbound public IP address(es).

Create a dedicated SQL authentication account for the MCP service. Do not use a personal administrator account.

Grant only the permissions required (read-only or read/write, depending on the agreed use case).

Record the username and password securely.

Note: The current implementation authenticates via SQL login (username/password), not Azure AD / Managed Identity. Managed Identity setup is not required unless the customer wants to move to passwordless/AAD authentication as a separate hardening step.

5. Locate the Connection String

In the Azure Portal:

Azure SQL Database → Settings → Connection strings.

Copy the ADO.NET connection string.

Replace the placeholders with the dedicated SQL username and password.

Example:

Server=tcp:<server>.database.windows.net,1433;
Initial Catalog=<database>;
User ID=<mcp_user>;
Password=<password>;
Encrypt=True;
TrustServerCertificate=False;
Connection Timeout=30;

6. Provide Information

Provide the following back to the deployment team:

Azure SQL Server name

Database name

Completed connection string (or server/database plus credentials via a secure channel)

Confirmation that firewall rules have been applied

Confirmation that DNS/private endpoint connectivity has been validated (Section 2)

Any permission restrictions the MCP service should follow

7. MCP Deployment

The deployment team will:

Configure the Azure Web App with the DATABASE_CONNECTION_STRING application setting

Deploy the DAB configuration

Verify connectivity

Validate CRUD operations through the MCP endpoint

1. Azure SQL Database#

2. Network Connectivity (Web App → Private Endpoint / Peered VNet)#

2.1 Private DNS for the Web App Private Endpoint#

2.2 SQL Server Reachability#

3. Configure Azure SQL Firewall (General)#

4. Create a Dedicated SQL Login (Current Implementation)#

5. Locate the Connection String#

6. Provide Information#

7. MCP Deployment#