Data-Api-Builder | The .NET Blog

SQL MCP Server no Azure App Service — Sem Contêineres

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

Esta publicação foi traduzida automaticamente. Para a versão original, clique aqui.

Vou ser honesto contigo: toda vez que vejo “requer um contêiner” em um tutorial, uma pequena parte de mim suspira. Contêineres são ótimos — até que a sua equipe não tem uma estratégia de contêineres, e de repente uma funcionalidade que parecia simples fica bloqueada por sobrecarga de orquestração que ninguém planejou.

Por isso esse aqui chamou minha atenção. O SQL MCP Server agora pode rodar no Azure App Service — sem Docker, sem Kubernetes, apenas com a mesma configuração do Data API Builder (DAB) que expõe seu banco de dados SQL via MCP, REST e GraphQL.

O que é o SQL MCP Server?

Contexto rápido se você ainda não o conhece. O SQL MCP Server fica entre o seu agente de IA e o seu banco de dados SQL. Em vez de dar ao agente acesso direto ao banco (o que seria uma péssima ideia), ele expõe suas tabelas e views como uma camada de abstração — entidades com permissões definidas.

É construído sobre o Data API Builder, o que significa que um único arquivo de configuração gerencia MCP e REST e GraphQL simultaneamente. Seu agente fala com o endpoint MCP. Sua aplicação tradicional fala com REST ou GraphQL. Mesma config, mesmo runtime, superfícies diferentes.

Isso é genuinamente útil. Você não mantém duas camadas de API separadas.

O Problema do Contêiner (e a Solução)

O modelo de deployment original do SQL MCP Server usava contêineres. Funciona bem em muitas equipes — mas não em todas. Muitas equipes .NET padronizam no Azure App Service ou VMs. Exigir um runtime de contêiner apenas para expor um endpoint SQL adiciona fricção que ninguém pediu.

O novo tutorial mostra como pular o contêiner completamente. Tudo funciona com um comando dab start, hospedado no App Service como um processo web .NET 8 padrão.

# Instalar Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Inicializar a configuração
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Adicionar uma entidade
dab add products --source dbo.products --permissions "authenticated:*"

# Configurar o provedor de auth do App Service
dab configure --runtime.host.authentication.provider AppService

# Iniciar o servidor
dab start

Neste ponto você tem MCP em /mcp, REST e GraphQL do mesmo processo, e nada rodando em contêiner.

Autenticação Sem Chaves de API Compartilhadas

Essa é a parte que mais aprecio. Ao fazer o deploy no App Service, você configura o Microsoft Entra ID como provedor de autenticação. Sem segredos compartilhados em arquivos de configuração, sem chaves de API para rotacionar.

A string de conexão fica em uma variável de ambiente do App Service (não no dab-config.json), e o endpoint MCP é protegido pela autenticação da plataforma. Se você já está alinhado com o Entra ID em suas cargas de trabalho Azure, isso se encaixa naturalmente.

Para desenvolvimento local, você muda para o modo Simulator e transporte STDIO. Volta para o modo AppService antes do deploy. Limpo e explícito.

Deploy no 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"

Depois você faz o deploy do seu projeto DAB usando o método de deployment de código que sua equipe já usa. O detalhe importante: é um deployment de código, não de contêiner.

Por que Isso Importa para Desenvolvedores .NET

Se você está construindo agentes de IA em .NET, eventualmente seu agente precisará falar com um banco de dados. O SQL MCP Server te dá uma maneira estruturada de fazer isso sem expor strings de conexão brutas.

Confira o tutorial completo no post original e o repositório de exemplo no GitHub.

Conclusão

O SQL MCP Server no App Service é uma opção pragmática sólida para equipes .NET que querem dar aos seus agentes acesso estruturado a dados SQL sem uma estratégia de contêineres. Experimente — seus agentes vão apreciar a superfície de API limpa.

SQL MCP Server — A forma certa de dar acesso a bancos de dados para agentes de IA

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Vamos ser honestos: a maioria dos servidores MCP de banco de dados disponíveis hoje são assustadores. Eles pegam uma consulta em linguagem natural, geram SQL na hora e executam contra seus dados de produção. O que poderia dar errado? (Tudo. Tudo poderia dar errado.)

O time do Azure SQL acabou de apresentar o SQL MCP Server, e ele adota uma abordagem fundamentalmente diferente. Construído como uma funcionalidade do Data API builder (DAB) 2.0, dá aos agentes de IA acesso estruturado e determinístico a operações de banco de dados — sem NL2SQL, sem expor seu esquema, e com RBAC completo em cada etapa.

Por que não NL2SQL?

Essa é a decisão de design mais interessante. Modelos não são determinísticos, e consultas complexas são as mais propensas a produzir erros sutis. As consultas exatas que os usuários esperam que a IA gere são também as que precisam de mais escrutínio quando produzidas de forma não determinística.

Em vez disso, o SQL MCP Server usa uma abordagem NL2DAB. O agente trabalha com a camada de abstração de entidades do Data API builder e seu construtor de consultas integrado para produzir T-SQL preciso e bem formado de maneira determinística. Mesmo resultado para o usuário, mas sem o risco de JOINs alucinados ou exposição acidental de dados.

Sete ferramentas, não setecentas

O SQL MCP Server expõe exatamente sete ferramentas DML, independentemente do tamanho do banco de dados:

describe_entities — descobrir entidades e operações disponíveis
create_record — inserir linhas
read_records — consultar tabelas e views
update_record — modificar linhas
delete_record — remover linhas
execute_entity — executar stored procedures
aggregate_records — consultas de agregação

Isso é inteligente porque janelas de contexto são o espaço de pensamento do agente. Inundá-las com centenas de definições de ferramentas deixa menos espaço para raciocínio. Sete ferramentas fixas mantêm o agente focado em pensar em vez de navegar.

Cada ferramenta pode ser habilitada ou desabilitada individualmente:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Começando em três comandos

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Isso é um SQL MCP Server rodando e expondo sua tabela Customers. A camada de abstração de entidades significa que você pode criar aliases para nomes e colunas, limitar campos por papel, e controlar exatamente o que os agentes veem — sem expor detalhes internos do esquema.

A história de segurança é sólida

É aqui que a maturidade do Data API builder compensa:

RBAC em cada camada — cada entidade define quais papéis podem ler, criar, atualizar ou deletar, e quais campos são visíveis
Integração com Azure Key Vault — strings de conexão e segredos gerenciados com segurança
Microsoft Entra + OAuth personalizado — autenticação de nível de produção
Content Security Policy — agentes interagem através de um contrato controlado, não SQL cru

A abstração de esquema é particularmente importante. Seus nomes internos de tabelas e colunas nunca são expostos ao agente. Você define entidades, aliases e descrições que fazem sentido para a interação com IA — não seu diagrama ERD do banco de dados.

Multi-banco e multi-protocolo

O SQL MCP Server suporta Microsoft SQL, PostgreSQL, Azure Cosmos DB e MySQL. E como é uma funcionalidade do DAB, você obtém endpoints REST, GraphQL e MCP simultaneamente da mesma configuração. Mesmas definições de entidades, mesmas regras RBAC, mesma segurança — nos três protocolos.

A auto-configuração no DAB 2.0 pode até inspecionar seu banco de dados e construir a configuração dinamicamente, se você estiver confortável com menos abstração para prototipagem rápida.

Minha opinião

É assim que o acesso empresarial a bancos de dados para agentes de IA deveria funcionar. Não “ei LLM, escreve SQL pra mim e YOLO contra produção.” Em vez disso: uma camada de entidades bem definida, geração determinística de consultas, RBAC em cada etapa, cache, monitoramento e telemetria. É chato da melhor maneira possível.

Para desenvolvedores .NET, a história de integração é limpa — DAB é uma ferramenta .NET, o MCP Server roda como contêiner, e funciona com Azure SQL, que a maioria de nós já está usando. Se você está construindo agentes de IA que precisam de acesso a dados, comece aqui.

Finalizando

SQL MCP Server é gratuito, open-source e roda em qualquer lugar. É a abordagem prescritiva da Microsoft para dar aos agentes de IA acesso seguro a bancos de dados. Confira o post completo e a documentação para começar.