Data-Api-Builder | The .NET Blog

SQL MCP Server su Azure App Service — Senza Container

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

Questo articolo è stato tradotto automaticamente. Per la versione originale, clicca qui.

Diciamoci la verità: ogni volta che vedo “richiede un container” in un tutorial, una piccola parte di me sospira. I container sono fantastici — finché il tuo team non ha una strategia per i container, e improvvisamente una funzionalità che sembrava semplice è bloccata da complessità di orchestrazione che nessuno aveva pianificato.

Ecco perché questo mi ha colpito. Il SQL MCP Server ora può girare su Azure App Service — senza Docker, senza Kubernetes, solo con la stessa configurazione di Data API Builder (DAB) che espone il tuo database SQL tramite MCP, REST e GraphQL.

Cos’è il SQL MCP Server?

Contesto rapido se non lo conosci ancora. Il SQL MCP Server si trova tra il tuo agente AI e il tuo database SQL. Invece di dare all’agente accesso diretto al database (un’idea pessima), espone le tue tabelle e view come uno strato di astrazione — entità con permessi definiti.

È costruito su Data API Builder, il che significa che un singolo file di configurazione gestisce MCP e REST e GraphQL contemporaneamente. Il tuo agente parla con l’endpoint MCP. La tua applicazione tradizionale parla con REST o GraphQL. Stessa config, stesso runtime, superfici diverse.

Questo è genuinamente utile. Non stai mantenendo due strati API separati.

Il Problema del Container (e la Soluzione)

Il modello di deployment originale del SQL MCP Server usava i container. Funziona bene in molti team — ma non in tutti. Molti team .NET standardizzano su Azure App Service o VM. Richiedere un runtime di container solo per esporre un endpoint SQL aggiunge attrito che nessuno ha chiesto.

Il nuovo walkthrough mostra come saltare completamente il container. Tutto funziona con un comando dab start, ospitato su App Service come un processo web .NET 8 standard.

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

# Inizializzare la configurazione
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Aggiungere un'entità
dab add products --source dbo.products --permissions "authenticated:*"

# Configurare il provider di autenticazione App Service
dab configure --runtime.host.authentication.provider AppService

# Avviare il server
dab start

A questo punto hai MCP su /mcp, REST e GraphQL dallo stesso processo, e niente che gira in un container.

Autenticazione Senza Chiavi API Condivise

Questa è la parte che apprezzo di più. Quando fai il deploy su App Service, configuri Microsoft Entra ID come provider di autenticazione. Nessun segreto condiviso nei file di configurazione, nessuna chiave API da ruotare.

La stringa di connessione rimane in una variabile d’ambiente di App Service (non in dab-config.json), e l’endpoint MCP è protetto dall’autenticazione della piattaforma. Se sei già allineato con Entra ID nei tuoi workload Azure, questo si integra naturalmente.

Per lo sviluppo locale, passi alla modalità Simulator e al trasporto STDIO. Torni alla modalità AppService prima del deployment. Pulito ed esplicito.

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

Poi fai il deploy del tuo progetto DAB usando il metodo di deployment del codice che il tuo team già utilizza. Il dettaglio chiave: è un deployment di codice, non di container.

Perché Importa per gli Sviluppatori .NET

Se stai costruendo agenti AI in .NET, prima o poi il tuo agente dovrà comunicare con un database. Il SQL MCP Server ti dà un modo strutturato per farlo senza esporre stringhe di connessione grezze.

Consulta il tutorial completo nel post originale e il repository di esempio su GitHub.

Conclusione

Il SQL MCP Server su App Service è una solida opzione pragmatica per i team .NET che vogliono dare ai propri agenti accesso strutturato ai dati SQL senza una strategia di container. Provalo — i tuoi agenti apprezzeranno la superficie API pulita.

SQL MCP Server — Il modo giusto per dare accesso ai database agli agenti AI

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Siamo onesti: la maggior parte dei server MCP per database disponibili oggi sono spaventosi. Prendono una query in linguaggio naturale, generano SQL al volo e lo eseguono contro i tuoi dati di produzione. Cosa potrebbe andare storto? (Tutto. Tutto potrebbe andare storto.)

Il team di Azure SQL ha appena presentato SQL MCP Server, e adotta un approccio fondamentalmente diverso. Costruito come funzionalità di Data API builder (DAB) 2.0, dà agli agenti AI un accesso strutturato e deterministico alle operazioni sul database — senza NL2SQL, senza esporre il tuo schema, e con RBAC completo ad ogni passaggio.

Perché non NL2SQL?

Questa è la decisione di design più interessante. I modelli non sono deterministici, e le query complesse sono le più propense a produrre errori sottili. Le query esatte che gli utenti sperano che l’AI possa generare sono anche quelle che richiedono più scrutinio quando prodotte in modo non deterministico.

Invece, SQL MCP Server usa un approccio NL2DAB. L’agente lavora con il livello di astrazione delle entità di Data API builder e il suo query builder integrato per produrre T-SQL accurato e ben formato in modo deterministico. Stesso risultato per l’utente, ma senza il rischio di JOIN allucinati o esposizione accidentale di dati.

Sette strumenti, non settecento

SQL MCP Server espone esattamente sette strumenti DML, indipendentemente dalle dimensioni del database:

describe_entities — scoprire entità e operazioni disponibili
create_record — inserire righe
read_records — interrogare tabelle e viste
update_record — modificare righe
delete_record — rimuovere righe
execute_entity — eseguire stored procedure
aggregate_records — query di aggregazione

Questo è intelligente perché le finestre di contesto sono lo spazio di pensiero dell’agente. Inondarle con centinaia di definizioni di strumenti lascia meno spazio per il ragionamento. Sette strumenti fissi mantengono l’agente concentrato sul pensare piuttosto che sul navigare.

Ogni strumento può essere abilitato o disabilitato 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
 }
 }
}

Iniziare in tre comandi

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

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

dab start

Ecco un SQL MCP Server funzionante che espone la tua tabella Customers. Il livello di astrazione delle entità significa che puoi creare alias per nomi e colonne, limitare i campi per ruolo e controllare esattamente cosa vedono gli agenti — senza esporre dettagli interni dello schema.

La storia della sicurezza è solida

Qui è dove la maturità di Data API builder ripaga:

RBAC ad ogni livello — ogni entità definisce quali ruoli possono leggere, creare, aggiornare o eliminare, e quali campi sono visibili
Integrazione con Azure Key Vault — stringhe di connessione e segreti gestiti in modo sicuro
Microsoft Entra + OAuth personalizzato — autenticazione di livello produzione
Content Security Policy — gli agenti interagiscono attraverso un contratto controllato, non SQL grezzo

L’astrazione dello schema è particolarmente importante. I nomi interni delle tue tabelle e colonne non vengono mai esposti all’agente. Definisci entità, alias e descrizioni che hanno senso per l’interazione AI — non il tuo diagramma ERD del database.

Multi-database e multi-protocollo

SQL MCP Server supporta Microsoft SQL, PostgreSQL, Azure Cosmos DB e MySQL. E poiché è una funzionalità di DAB, ottieni endpoint REST, GraphQL e MCP simultaneamente dalla stessa configurazione. Stesse definizioni di entità, stesse regole RBAC, stessa sicurezza — su tutti e tre i protocolli.

L’auto-configurazione in DAB 2.0 può persino ispezionare il tuo database e costruire la configurazione dinamicamente, se sei a tuo agio con meno astrazione per la prototipazione rapida.

La mia opinione

Ecco come dovrebbe funzionare l’accesso aziendale ai database per gli agenti AI. Non “hey LLM, scrivimi un po’ di SQL e YOLO sulla produzione.” Invece: un livello di entità ben definito, generazione deterministica delle query, RBAC ad ogni passaggio, caching, monitoraggio e telemetria. È noioso nel miglior modo possibile.

Per gli sviluppatori .NET, la storia dell’integrazione è pulita — DAB è uno strumento .NET, l’MCP Server gira come container, e funziona con Azure SQL, che la maggior parte di noi sta già usando. Se stai costruendo agenti AI che hanno bisogno di accesso ai dati, inizia qui.

Conclusione

SQL MCP Server è gratuito, open-source e gira ovunque. È l’approccio prescrittivo di Microsoft per dare agli agenti AI un accesso sicuro ai database. Consulta il post completo e la documentazione per iniziare.