Schema MCP#

Un serveur MCP local, en lecture seule, qui permet à un agent d’IA de lire la structure d’une base SQL Server — objets, code, dépendances, colonnes — sans jamais en lire les données.

MCP, le Model Context Protocol, est une norme qui permet d’ajouter des outils au harnais d’un agent, c’est-à-dire au programme qui exécute ce que le modèle d’IA demande. Ce harnais est l’application d’IA que vous installez, comme Claude Desktop, ou Claude Code et GitHub Copilot dans VS Code. Un serveur MCP est un programme qui fournit de tels outils : le modèle demande un outil comme il demande à lire un fichier, le harnais transmet la demande au serveur MCP, et la réponse revient dans la conversation. Ici, les outils interrogent une base SQL Server. Si la boucle entre le modèle et son harnais ne vous est pas familière, elle est décrite à part.

Cette page présente le serveur MCP : ce qu’il fait, ce qui le garantit, et ce qu’il coûte. La mise en place pas à pas — les scripts, l’installation, la déclaration des connexions — se trouve dans le README du dépôt, qui fait référence.

L’idée#

Comment laisser quelqu’un travailler sur une base de données sans lui montrer les données qu’elle contient ? La question est aussi ancienne que les bases de données, et SQL Server y répond par les droits.

Un login qui ne détient que le droit VIEW DEFINITION voit la structure d’une base. Il voit la liste des tables et leurs colonnes. Il lit le texte des vues, des procédures stockées et des fonctions. Il voit les index et les clés étrangères. En revanche, il ne peut lire aucune ligne d’aucune table. Et il ne peut rien modifier.

Schema MCP applique la même réponse à un agent d’IA. L’agent interroge la base par l’intermédiaire du serveur MCP. Le serveur MCP se connecte à l’instance SQL Server avec un login qui ne détient que ce droit. L’agent connaît donc la structure de la base, et rien de plus.

Quand vous écrivez du SQL avec un agent, vous n’avez donc plus à coller dans la conversation le résultat d’une requête sur le catalogue pour qu’il sache comment la base est construite. L’agent consulte lui-même les noms exacts des tables et des colonnes, leurs types, les procédures qui utilisent une table. Le SQL qu’il propose repose sur la base réelle, et non sur ce qu’il suppose.

Si c’est à vous d’autoriser cet accès, comme DBA ou comme responsable informatique, la question est autre : que peut faire cet agent sur la base, et comment le vérifier ? La partie Ce qui garantit que l’agent ne lit pas les données, plus bas, y répond.

Où il s’exécute#

Le serveur MCP est un programme qui s’exécute sur votre propre ordinateur, à côté de l’application d’IA qui l’utilise. Cette application le lance quand elle en a besoin, et dialogue avec lui par l’entrée et la sortie standard du programme. La norme MCP appelle cela un serveur local.

Trois conditions en découlent.

L’application d’IA est installée sur le même ordinateur, et elle prend en charge les serveurs MCP locaux. Ce serveur MCP est testé avec Claude Desktop, et vérifié avec Claude Code et avec GitHub Copilot dans VS Code. Tout client MCP capable de lancer un serveur local convient aussi. Un chat ouvert dans un navigateur web s’exécute en revanche sur les serveurs de son fournisseur : il ne peut pas lancer un programme sur votre ordinateur, et ne peut donc pas utiliser ce serveur MCP.

L’ordinateur fonctionne sous Windows. Le serveur MCP conserve vos connexions dans un fichier chiffré avec DPAPI, le mécanisme de chiffrement de Windows.

L’ordinateur atteint l’instance SQL Server par le réseau, comme SSMS le ferait. Le serveur MCP n’ouvre aucun port réseau : sa seule connexion est celle qu’il établit vers l’instance, avec le login que vous lui donnez.

Tout ce que renvoie le serveur MCP entre dans la conversation. Il est donc envoyé au fournisseur du modèle d’IA, comme le reste de ce que vous tapez. Ce qu’il renvoie est la structure de la base, et jamais ses données.

Ce qui garantit que l’agent ne lit pas les données#

Deux protections, dont une seule fait la garantie#

La première protection est le code du serveur MCP. Il n’exécute que des requêtes écrites à l’avance, qui lisent le catalogue de SQL Server, c’est-à-dire les vues système qui décrivent les objets de la base. Ni vous ni l’agent ne pouvez modifier ces requêtes. Les outils du serveur MCP prennent des paramètres, comme un nom de schéma ou une partie d’un nom d’objet. Ils ne prennent jamais de SQL. Ce code est public, et vous pouvez le lire dans le dépôt.

La seconde protection est celle qui fait la garantie : les droits du login. Même si le code du serveur MCP avait un défaut, ou avait été modifié, il ne pourrait pas faire plus que ce que son login permet. Et ces droits, c’est vous qui les accordez, avec un script que vous lisez avant de l’exécuter. Vous n’avez donc pas à faire confiance au serveur MCP : vous vérifiez vous-même, sur votre propre instance, ce que son login peut faire et ce qu’il ne peut pas faire.

Le dépôt fournit le script qui crée ce login. Il crée le login au niveau de l’instance, puis l’utilisateur correspondant dans la base. Il crée ensuite un rôle, en fait membre cet utilisateur, et accorde au rôle le droit VIEW DEFINITION. Si un autre compte a un jour besoin du même accès, il suffit de l’ajouter au rôle : aucun droit n’est à accorder de nouveau.

Par défaut, le droit couvre toute la base. Vous pouvez le limiter à un schéma. Le serveur MCP n’est pas informé de cette limite : il voit simplement moins d’objets. La limite vit ainsi dans les droits, là où vous la contrôlez, et non dans un réglage du serveur MCP.

Le script ajoute quatre refus, et seulement quatre. Quand des diagrammes de base de données ont été créés dans SSMS, quatre procédures du schéma dbo écrivent dans la table dbo.sysdiagrams, et le rôle public, auquel appartient chaque utilisateur de la base, est autorisé à les exécuter. C’est la seule voie d’écriture que les droits par défaut d’une base laissent ouverte, et le script la ferme. Un refus global, comme un deny select sur toute la base, s’appliquerait aussi aux vues système que lit le serveur MCP : le login ne verrait plus rien.

Une vérification que vous exécutez vous-même#

Un second script vérifie ce que le login peut réellement faire. Il s’exécute connecté avec ce login, puisqu’il contrôle les droits de la connexion qui l’exécute. Il ne modifie rien, et rend quatre verdicts, PASS ou FAIL : le login voit les définitions ; il ne lit aucune donnée, et une tentative réelle de lecture d’une table est refusée par SQL Server ; il n’écrit rien, et une tentative réelle de création de table est refusée, à l’intérieur d’une transaction annulée ; enfin, les fonctions de dépendances répondent.

Un troisième script liste ce que la base accorde au rôle public. Chaque utilisateur en est membre, login du serveur MCP compris, et ne peut pas en être retiré : un droit accordé à public est donc détenu par tous.

Le README détaille ces trois scripts en quatre étapes, avec le compte sous lequel chacun s’exécute et le résultat attendu.

Le seul chiffre qui touche aux données#

Deux outils donnent le nombre approximatif de lignes de chaque table. À première vue, on dirait que le serveur MCP a lu les tables. Ce n’est pas le cas : SQL Server conserve ce nombre dans son catalogue, dans la vue système sys.partitions, et le droit VIEW DEFINITION le rend visible, exactement comme SSMS l’affiche dans les propriétés d’une table. Le serveur MCP ne compte jamais les lignes, et ne les lit jamais.

Avec votre compte Windows#

Le serveur MCP peut aussi se connecter en authentification Windows. Il se connecte alors avec le compte qui a lancé l’application d’IA : en pratique, le vôtre, celui que vous utilisez aussi dans SSMS.

Cela change ce que les droits peuvent garantir. La boucle de travail met en jeu deux identités : l’agent lit la structure avec les droits du serveur MCP, et vous appliquez les scripts qu’il propose avec vos propres droits. En authentification Windows, ces deux identités n’en font qu’une. Si votre compte garde les droits avec lesquels vous travaillez, le serveur MCP les détient aussi, et la garantie repose alors sur son code. Si votre compte est limité à VIEW DEFINITION, la garantie tient de nouveau, mais vous ne pouvez plus rien appliquer avec lui. Un login SQL Server dédié au serveur MCP sépare les deux identités.

Les droits du login bornent ce serveur MCP, et rien d’autre. Votre application d’IA peut offrir au modèle d’autres outils, comme un autre serveur MCP qui exécute du SQL, ou une ligne de commande capable de lancer sqlcmd. Ces outils s’exécutent sous votre compte Windows, avec ses droits, quelle que soit la façon dont ce serveur MCP se connecte.

Le serveur MCP signale les deux cas où un compte lit à coup sûr toutes les données : un compte sysadmin, et un compte qui détient le droit SELECT sur toute la base. Il le dit dans la console quand vous testez la connexion, une fois dans le premier résultat que reçoit l’agent, et chaque fois qu’on le demande à l’outil server_info. Quand il ne détecte rien, il ne dit rien, et ce silence n’est pas une garantie : un compte peut être restreint sur certaines tables et pas sur d’autres.

Ce que le code de votre base peut révéler#

Le droit VIEW DEFINITION donne accès au texte des vues, des procédures, des fonctions et des déclencheurs, tel qu’il a été écrit. Si ce code contient en clair des mots de passe ou des jetons d’API, l’agent les lira, et ils partiront chez le fournisseur du modèle avec le reste de la structure. Le serveur MCP ne cherche pas à compenser cette pratique. Ce risque existe d’ailleurs déjà pour quiconque a reçu ce droit, et le README donne une requête pour chercher ces informations avant d’ouvrir l’accès.

Ce que l’agent obtient#

Le serveur MCP sert une boucle de travail simple. L’agent lit la structure de la base par l’intermédiaire du serveur MCP. Il propose un script. Vous relisez ce script, et vous l’appliquez vous-même. Le serveur MCP fournit des faits exacts sur la base, et le modèle d’IA écrit le SQL avec eux : les vrais noms de tables et de colonnes, les vrais types, la vraie nullabilité.

Huit outils servent cette boucle, et un neuvième s’ajoute quand vous fournissez un fichier de conventions.

Parcourir la base. list_objects liste les tables, les vues, les procédures, les fonctions, les déclencheurs et les séquences, filtrés par schéma, par nom, par type ou par date de modification. Pour chaque table, il donne le nombre approximatif de lignes, ce qui fait apparaître d’emblée la table principale parmi ses satellites. Pour chaque module, il donne la longueur de son texte : l’agent sait ce qu’un objet coûtera à lire avant de le demander. find_columns trouve les tables et les vues qui portent une colonne d’un nom donné.

Comprendre un objet. describe_object en donne un résumé compact : pour une table, ses colonnes et leurs types, ses clés, ses index, ses clés étrangères, ses contraintes et ses déclencheurs ; pour une procédure ou une fonction, ses paramètres. Sur demande, il ajoute les descriptions (MS_Description) de l’objet et de ses colonnes. script_object rend le script CREATE complet de l’objet, tel que SSMS le produit. L’agent s’en sert quand il doit modifier l’objet.

Mesurer l’impact d’une modification. find_references dit ce qui utilise un objet, ou ce qu’il utilise, d’après le graphe de dépendances que SQL Server entretient. Or ce graphe ne voit pas le SQL dynamique : quand une procédure construit une requête dans une chaîne de caractères puis l’exécute, le nom de la table est dans la chaîne, et SQL Server ne l’enregistre pas comme une dépendance. search_modules cherche un fragment dans le texte des modules, et trouve ce nom. Les deux outils se lisent donc ensemble. Sur une base de production mesurée, un peu plus de 1 % des procédures, vues et fonctions contenaient du SQL dynamique.

Savoir sur quelle base on travaille. use_connection choisit la base parmi les connexions que vous avez déclarées. Chaque résultat nomme la base dont il vient : une mauvaise cible se voit tout de suite. server_info donne la version du serveur MCP, son emplacement, et les commandes qui gèrent les connexions. L’agent peut ainsi vous répondre si vous lui demandez comment en supprimer une.

Suivre les conventions de votre équipe, si vous en avez. Placez un fichier conventions.md à côté de l’exécutable, et le serveur MCP propose l’outil read_conventions, qui renvoie ce fichier tel quel. La description de l’outil demande à l’agent de l’appeler avant d’écrire du SQL. Sans le fichier, l’outil n’existe pas, et il ne coûte rien. Le serveur MCP n’impose aucune convention et n’en fournit aucune ; le dépôt en publie un exemple.

Limites connues#

Les dépendances sont données au niveau de l’objet, pas de la colonne. SQL Server ne résout pas les dépendances de colonnes de façon fiable, donc le serveur MCP ne les promet pas.
Un module créé avec l’option with encryption n’a pas de texte lisible : search_modules ne le trouve pas.
La date de modification d’une table change aussi quand l’un de ses index change. Pour les vues, les procédures et les fonctions, elle indique bien la dernière modification du code.
Les déclencheurs de base de données, ceux qui réagissent aux instructions DDL, ne sont pas couverts : ils n’appartiennent à aucun schéma. Les déclencheurs de tables et de vues le sont.

Ce que ces choix coûtent#

Chaque borne du serveur MCP a sa contrepartie. Elles se lisent avant de l’adopter.

Aucune donnée, même un échantillon. Le serveur MCP ne montre aucune ligne, aucune statistique, aucun profil de colonne. Une statistique d’index contient des valeurs réelles de la colonne : la lire serait déjà lire des données. En contrepartie, l’agent ne peut pas vérifier seul une hypothèse sur le contenu d’une table. Il vous donne la requête, et c’est vous qui l’exécutez.

Aucune écriture. Le serveur MCP ne produit pas de SQL et n’en applique aucun. L’agent propose, et vous appliquez : c’est une étape manuelle à chaque modification, et c’est aussi ce qui permet au login de rester au plus bas des droits.

Des réponses plafonnées. Chaque réponse occupe de la place dans la conversation, et cette place se compte en tokens. Une liste ne dépasse donc jamais 200 lignes par défaut, un plafond fixé par la variable d’environnement DDL_MAX_RESULTS, que l’agent ne peut pas modifier. Quand une demande est trop large, l’outil renvoie la répartition des résultats par schéma, par type ou par préfixe de nom, plutôt qu’une liste tronquée. L’agent doit alors resserrer sa demande, ou vous poser une question. Pour la même raison, describe_object est l’outil qui fait connaître une table : sur une grosse table d’une base de production, il a renvoyé environ un sixième de ce que renvoyait script_object, en une seconde au lieu de quarante.

Des définitions d’outils à charger. Les neuf outils représentent environ 3 000 tokens. Un client qui charge ses outils d’avance les paie dans chaque conversation, même quand elle ne concerne aucune base. Un client qui les charge à la demande ne les paie que lorsqu’une conversation les cherche.

Une charge sur l’instance, faible mais réelle. Le serveur MCP ne lit que le catalogue, et ces requêtes sont en général rapides. La plus coûteuse est une recherche dans le texte de tous les modules, sans filtre : sur une base de 36 000 objets et 32 000 modules, elle a pris 11 secondes. La recherche s’arrête dès qu’elle a trouvé plus de résultats qu’elle ne peut en renvoyer.

Windows, et un exécutable qui n’est pas encore signé. Le chiffrement des connexions repose sur DPAPI, et l’exécutable publié est construit pour Windows x64. Faute de signature, Windows peut le bloquer sur une machine où le Contrôle intelligent des applications (Smart App Control) est activé.

Essayer#

Sans approcher une base qui compte. Le dépôt fournit un script qui crée une base de démonstration : une vingtaine d’objets répartis sur quatre schémas, sans aucune donnée. Plusieurs de ces objets sont des pièges, chacun annoncé par un commentaire : un nom qui contient les caractères spéciaux de like, du SQL dynamique, une référence à une table qui n’existe pas, une vue cassée par la suppression d’une colonne. Cette même base sert aux tests d’intégration du dépôt.

L’installation. Le serveur MCP est un exécutable unique, schema-mcp.exe, d’environ 93 Mo. Il contient le runtime .NET : rien d’autre n’est à installer. Chaque release publie l’exécutable, un fichier qui contient son empreinte SHA-256, et l’avis des composants tiers qu’il embarque. La vérification de l’empreinte prouve que le téléchargement est complet et intact ; elle ne prouve pas qui a construit le fichier. L’exécutable se construit aussi depuis les sources, avec le SDK .NET.

Les connexions. Vous les déclarez dans une console, avec l’exécutable lui-même : le nom de l’instance, la base, le login et le mot de passe. Le serveur MCP ne les demande jamais pendant une conversation, et l’agent ne les voit jamais. Elles sont stockées dans un fichier chiffré pour votre compte Windows. Ce chiffrement protège le fichier s’il est volé ou exposé par accident, dans une sauvegarde ou pendant un partage d’écran. Un programme qui s’exécute sous le même compte peut en revanche le déchiffrer, comme le fait le serveur MCP. Ce niveau de protection correspond à ce que le mot de passe permet : lire des définitions d’objets, et rien d’autre.

Le client. Chaque application d’IA déclare ses serveurs MCP dans un fichier de configuration qui lui est propre, et dont le format change d’un client à l’autre, parfois d’une version à la suivante. La déclaration tient pourtant en trois informations, les mêmes pour tous : un nom pour le serveur MCP, le chemin complet de l’exécutable, et l’emplacement du fichier des connexions. Le plus simple est de demander à l’agent de votre client d’écrire cette déclaration, puis de relancer le client et de demander à l’agent quelle version du serveur MCP tourne. Pour répondre, l’agent appelle l’outil server_info ; s’il ne le trouve pas, le client n’a pas chargé le serveur MCP.

La partie Installation du README donne les commandes, et la dernière release porte l’exécutable.

État et licence#

Les premières releases datent de septembre 2026. Le journal des modifications dit ce que chaque version a changé.

Le code est publié sous licence MIT : github.com/SharpPyxis/SharpPyxis.SqlServer.SchemaMcp. L’exécutable publié contient aussi le runtime .NET et des bibliothèques tierces, chacune sous sa propre licence, et le dépôt les liste. L’une d’elles, Microsoft.Data.SqlClient.SNI, n’est pas open source : elle est distribuée sous les Microsoft Software License Terms.

Comme tout ce que publie SharpPyxis, ce serveur MCP est conçu et écrit avec un agent IA. Chaque commit du dépôt le déclare, par une ligne de co-auteur.