SQL MCP Server на Azure App Service — без контейнеров

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Этот пост переведён автоматически. Чтобы прочитать оригинал, нажмите здесь.

Честно говоря: каждый раз, когда в туториале вижу «требует контейнер», где-то внутри вздыхаю. Контейнеры великолепны — пока у вашей команды нет стратегии контейнеризации, и функция, казавшаяся простой, вдруг упирается в неожиданную оркестрационную сложность, которую никто не планировал.

Именно поэтому это привлекло моё внимание. SQL MCP Server теперь может работать на Azure App Service — без Docker, без Kubernetes, только с тем же конфигурационным файлом Data API Builder (DAB), который открывает ваш SQL-датабаз через MCP, REST и GraphQL.

Что такое SQL MCP Server?

Кратко для тех, кто ещё не знаком. SQL MCP Server располагается между вашим AI-агентом и SQL-базой данных. Вместо того чтобы давать агенту прямой доступ к базе данных (ужасная идея), он открывает ваши таблицы и представления как уровень абстракции — сущности с определёнными правами доступа.

Построен на Data API Builder, что означает: один конфигурационный файл управляет MCP и REST и GraphQL одновременно. Ваш агент общается с MCP-эндпоинтом. Традиционное приложение общается с REST или GraphQL. Одна конфигурация, одна среда выполнения, разные интерфейсы.

Это действительно удобно. Не нужно поддерживать два отдельных API-слоя.

Проблема контейнеров (и её решение)

Изначальная модель развёртывания SQL MCP Server использовала контейнеры. Это хорошо работает во многих командах — но не во всех. Многие .NET-команды стандартизировались на Azure App Service или виртуальных машинах. Требовать контейнерный runtime только ради одного SQL-эндпоинта — это лишнее трение, которого никто не просил.

Новое руководство показывает, как обойтись без контейнера вовсе. Всё работает через команду dab start, запущенный как стандартный .NET 8 веб-процесс на App Service.

# Установка Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Инициализация конфигурации
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Добавление сущности
dab add products --source dbo.products --permissions "authenticated:*"

# Настройка провайдера аутентификации App Service
dab configure --runtime.host.authentication.provider AppService

# Запуск сервера
dab start

На этом этапе у вас есть MCP по адресу /mcp, REST и GraphQL из того же процесса — и ничего в контейнере.

Аутентификация без общих API-ключей

Это та часть, которую я ценю больше всего. При развёртывании на App Service вы настраиваете Microsoft Entra ID в качестве провайдера аутентификации. Никаких общих секретов в конфигурационных файлах, никаких API-ключей для ротации.

Строка подключения хранится в переменных среды App Service (не в dab-config.json), а MCP-эндпоинт защищён платформенной аутентификацией. Если ваши Azure-нагрузки уже используют Entra ID, интеграция происходит органично.

Для локальной разработки переключайтесь в режим Simulator и STDIO-транспорт. Возвращайтесь к режиму AppService перед развёртыванием. Чисто и явно.

Развёртывание на App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Затем разверните свой DAB-проект методом, который уже использует ваша команда. Ключевой момент: это развёртывание кода, а не контейнера.

Почему это важно для .NET-разработчиков

Если вы создаёте AI-агентов на .NET, рано или поздно им нужно будет работать с базой данных. SQL MCP Server предоставляет структурированный способ сделать это — без открытия сырых строк подключения или написания собственных API-слоёв.

Ознакомьтесь с полным руководством в оригинальной статье и примере на GitHub.

Итог

SQL MCP Server на App Service — практичный выбор для .NET-команд, которые хотят дать агентам структурированный доступ к SQL-данным без контейнерной стратегии. Попробуйте — ваши агенты оценят чистый API-интерфейс.