Data-Api-Builder | The .NET Blog

SQL MCP Server sur Azure App Service — Sans Conteneurs

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

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Soyons honnêtes : chaque fois que je lis “nécessite un conteneur” dans un tutoriel, une petite partie de moi soupire. Les conteneurs sont formidables — jusqu’à ce que ton équipe n’ait pas de stratégie de conteneurs, et soudain une fonctionnalité qui semblait simple se retrouve bloquée par une complexité d’orchestration que personne n’avait anticipée.

C’est pourquoi celui-ci a retenu mon attention. Le SQL MCP Server peut désormais s’exécuter sur Azure App Service — sans Docker, sans Kubernetes, juste avec la même configuration Data API Builder (DAB) qui expose ta base de données SQL via MCP, REST et GraphQL.

Qu’est-ce que le SQL MCP Server ?

Contexte rapide si tu ne le connais pas encore. Le SQL MCP Server se place entre ton agent IA et ta base de données SQL. Au lieu de donner à ton agent un accès direct à la base de données (une très mauvaise idée), il expose tes tables et vues comme une couche d’abstraction — des entités avec des permissions définies.

Il est construit sur Data API Builder, ce qui signifie qu’un seul fichier de configuration gère MCP et REST et GraphQL simultanément. Ton agent parle à l’endpoint MCP. Ton application traditionnelle parle à REST ou GraphQL. Même config, même runtime, surfaces différentes.

C’est vraiment utile. Tu ne maintiens pas deux couches d’API séparées.

Le Problème des Conteneurs (et la Solution)

Le modèle de déploiement original du SQL MCP Server utilisait des conteneurs. Cela fonctionne bien dans beaucoup d’équipes — mais pas toutes. De nombreuses équipes .NET standardisent sur Azure App Service ou des VMs. Exiger un runtime de conteneur juste pour exposer un endpoint SQL ajoute de la friction que personne n’a demandée.

Le nouveau guide montre comment contourner entièrement le conteneur. Tout fonctionne avec une commande dab start, hébergé sur App Service comme un processus web .NET 8 standard.

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

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

# Ajouter une entité
dab add products --source dbo.products --permissions "authenticated:*"

# Configurer le fournisseur d'auth App Service
dab configure --runtime.host.authentication.provider AppService

# Démarrer le serveur
dab start

À ce stade, tu as MCP à /mcp, REST et GraphQL depuis le même processus, et rien qui tourne dans un conteneur.

Authentification Sans Clés d’API Partagées

C’est la partie que j’apprécie le plus. Quand tu déploies sur App Service, tu configures Microsoft Entra ID comme fournisseur d’authentification. Pas de secrets partagés dans les fichiers de configuration, pas de clés d’API à faire tourner.

La chaîne de connexion reste dans une variable d’environnement App Service (pas dans dab-config.json), et l’endpoint MCP est protégé par l’authentification de la plateforme. Si tu es déjà aligné sur Entra ID pour tes charges de travail Azure, cela s’intègre naturellement.

Pour le développement local, tu passes en mode Simulator et transport STDIO. Tu reviens en mode AppService avant le déploiement. Propre et explicite.

Déploiement sur 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"

Ensuite tu déploies ton projet DAB en utilisant la méthode de déploiement de code que ton équipe utilise déjà. Le détail clé : c’est un déploiement de code, pas de conteneur.

Pourquoi C’est Important pour les Développeurs .NET

Si tu construis des agents IA en .NET, ton agent devra tôt ou tard communiquer avec une base de données. Le SQL MCP Server te donne une façon structurée de le faire sans exposer des chaînes de connexion brutes.

Consulte le guide complet dans le billet original et le dépôt d’exemple sur GitHub.

Conclusion

Le SQL MCP Server sur App Service est une option pragmatique solide pour les équipes .NET qui souhaitent donner à leurs agents un accès structuré aux données SQL sans stratégie de conteneurs. Essaie-le — tes agents apprécieront la surface d’API propre.

SQL MCP Server — La bonne façon de donner accès aux bases de données aux agents IA

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

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Soyons honnêtes : la plupart des serveurs MCP de bases de données disponibles aujourd’hui sont effrayants. Ils prennent une requête en langage naturel, génèrent du SQL à la volée et l’exécutent contre vos données de production. Qu’est-ce qui pourrait mal tourner ? (Tout. Absolument tout.)

L’équipe Azure SQL vient de présenter SQL MCP Server, et il adopte une approche fondamentalement différente. Construit comme une fonctionnalité de Data API builder (DAB) 2.0, il donne aux agents IA un accès structuré et déterministe aux opérations de base de données — sans NL2SQL, sans exposer votre schéma, et avec un RBAC complet à chaque étape.

Pourquoi pas de NL2SQL ?

C’est la décision de conception la plus intéressante. Les modèles ne sont pas déterministes, et les requêtes complexes sont les plus susceptibles de produire des erreurs subtiles. Les requêtes exactes que les utilisateurs espèrent que l’IA peut générer sont aussi celles qui nécessitent le plus de vérification quand elles sont produites de manière non déterministe.

À la place, SQL MCP Server utilise une approche NL2DAB. L’agent travaille avec la couche d’abstraction d’entités de Data API builder et son constructeur de requêtes intégré pour produire du T-SQL précis et bien formé de manière déterministe. Même résultat pour l’utilisateur, mais sans le risque de JOINs hallucinés ou d’exposition accidentelle de données.

Sept outils, pas sept cents

SQL MCP Server expose exactement sept outils DML, quelle que soit la taille de la base de données :

describe_entities — découvrir les entités et opérations disponibles
create_record — insérer des lignes
read_records — interroger des tables et vues
update_record — modifier des lignes
delete_record — supprimer des lignes
execute_entity — exécuter des procédures stockées
aggregate_records — requêtes d’agrégation

C’est malin, car les fenêtres de contexte sont l’espace de réflexion de l’agent. Les inonder de centaines de définitions d’outils laisse moins de place au raisonnement. Sept outils fixes gardent l’agent concentré sur la réflexion plutôt que la navigation.

Chaque outil peut être activé ou désactivé individuellement :

"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
 }
 }
}

Démarrage en trois commandes

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

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

dab start

Voilà un SQL MCP Server en fonctionnement qui expose votre table Customers. La couche d’abstraction d’entités vous permet de créer des alias pour les noms et colonnes, de limiter les champs par rôle et de contrôler exactement ce que les agents voient — sans exposer les détails internes du schéma.

L’aspect sécurité est solide

C’est là que la maturité de Data API builder porte ses fruits :

RBAC à chaque couche — chaque entité définit quels rôles peuvent lire, créer, mettre à jour ou supprimer, et quels champs sont visibles
Intégration Azure Key Vault — chaînes de connexion et secrets gérés de manière sécurisée
Microsoft Entra + OAuth personnalisé — authentification de niveau production
Content Security Policy — les agents interagissent via un contrat contrôlé, pas du SQL brut

L’abstraction du schéma est particulièrement importante. Vos noms internes de tables et colonnes ne sont jamais exposés à l’agent. Vous définissez des entités, des alias et des descriptions qui ont du sens pour l’interaction IA — pas votre diagramme ERD de base de données.

Multi-bases et multi-protocoles

SQL MCP Server supporte Microsoft SQL, PostgreSQL, Azure Cosmos DB et MySQL. Et comme c’est une fonctionnalité de DAB, vous obtenez des endpoints REST, GraphQL et MCP simultanément depuis la même configuration. Mêmes définitions d’entités, mêmes règles RBAC, même sécurité — sur les trois protocoles.

L’auto-configuration dans DAB 2.0 peut même inspecter votre base de données et construire la configuration dynamiquement, si vous êtes à l’aise avec moins d’abstraction pour du prototypage rapide.

Mon avis

C’est ainsi que l’accès base de données d’entreprise pour les agents IA devrait fonctionner. Pas « hey LLM, écris-moi du SQL et YOLO sur la prod ». À la place : une couche d’entités bien définie, une génération de requêtes déterministe, RBAC à chaque étape, cache, monitoring et télémétrie. C’est ennuyeux de la meilleure façon possible.

Pour les développeurs .NET, l’histoire d’intégration est propre — DAB est un outil .NET, le MCP Server tourne en conteneur, et il fonctionne avec Azure SQL, que la plupart d’entre nous utilisent déjà. Si vous construisez des agents IA qui ont besoin d’accéder aux données, commencez ici.

Pour conclure

SQL MCP Server est gratuit, open-source et tourne partout. C’est l’approche prescriptive de Microsoft pour donner aux agents IA un accès sécurisé aux bases de données. Consultez le post complet et la documentation pour commencer.