MCP DB Wizard

Un serveur MCP pour Oracle qui ne vous fera pas virer

La configuration constitue l'intégralité du modèle de sécurité

Accessible par l'agent

• synuser_activity_log_get_by_pk table — une ligne par clé primaire, sous forme d'objet JSON
• synuser_activity_log_insert table — avec _update et _delete, à partir de la même sélection
• synuser_js_admin_getadmintoolinfo routine PL/SQL — enregistrements, collections et chaque paramètre OUT
• synuser_job_id_nextval séquence — la valeur suivante, et rien d'autre

Inaccessible, par construction

• Texte SQL provenant de l'appelant — les arguments sont des valeurs de liaison
• DDL — create, alter, drop
• Tout objet que vous n'avez pas sélectionné
• Tout schéma que la configuration ne nomme pas
• Le mot de passe Oracle — il vit dans l'environnement

Un agent qui peut écrire du SQL peut écrire DROP TABLE. Un agent détenant un outil appelé check_flight_availability peut vérifier la disponibilité d'un vol, car c'est tout ce que fait le code qui lui fait face.

La curation a lieu avant que le code n'existe

Le moindre privilège est facile à revendiquer et difficile à vérifier. Ici, la configuration décide de ce qui est émis : un objet que personne n'a sélectionné n'a ni outil, ni méthode, ni classe. Il est absent du binaire plutôt que protégé par un processus en cours d'exécution, donc aucun prompt ne peut l'atteindre.

Ce qu'un serveur MCP sans outil run-sql change

Vos règles métier sont déjà en PL/SQL

Des décennies de validation, de logique référentielle et de comportement d'audit vivent dans des packages. MCPDBWizard appelle ces routines telles qu'elles sont — enregistrements, collections, curseurs de référence et chaque paramètre OUT retourné — au lieu de demander à un modèle de langage de réinventer les règles dans un SELECT.

Ce qu'un agent voit lorsque votre PL/SQL devient des outils

Chaque appel est un outil nommé, pas une requête

Les requêtes arrivent sous forme de synuser_activity_log_get_by_pk(entry_id) contre un schéma strict — un argument mal orthographié est rejeté avant que la base de données ne soit touchée. Beaucoup plus facile à journaliser, à limiter en débit, à examiner après coup et à expliquer à un auditeur.

Outils MCP curatés et prompt SQL, côte à côte

Deux publics, deux enregistrements

Le proxy écrit qui a appelé quel outil et si cela a été autorisé ; chaque serveur écrit ce que l'outil a fait et comment il s'est terminé. Les noms des arguments toujours ; les valeurs uniquement si vous avez activé cette option, car un modèle les a choisies.

Où les journaux d'un serveur MCP devraient aller

Oracle 12c à 26ai

Y compris les types ajoutés depuis : JSON natif, BOOLEAN et VECTOR, et le CRUD de documents sur les vues de dualité JSON-relationnelles. Tout ce qui ne peut pas traverser JSON honnêtement — SDO_GEOMETRY, BFILE — est entièrement ignoré, et le journal indique quoi et pourquoi.

Comptes, jetons et une matrice d'octroi

De nombreux comptes, de nombreuses configurations, un coche par octroi. Deux équipes ayant besoin d'outils différents sur le même schéma, c'est deux configurations, pas une configuration et une règle — ce qui préserve la garantie du premier panneau.

Contrôle d'accès basé sur les rôles pour un serveur MCP

Vous comparez avec les propres routes d'Oracle ? Lisez une alternative au serveur MCP d'Oracle, les alternatives au serveur MCP SQLcl lorsque le SQL ad hoc est exclu, ou commencez par la question que la plupart des gens posent réellement : puis-je laisser un agent IA interroger ma base de données de production ?

La configuration décide de ce qui est généré ; le proxy décide qui peut l'appeler.

1. 01

   Sélectionnez les objets

   Connectez les pages Design à Oracle et cochez les packages PL/SQL que vous êtes prêt à exposer, ainsi que toute instruction SQL que vous avez écrite et testée vous-même, ainsi que les tables et séquences que vous souhaitez rendre accessibles directement. Cette sélection est enregistrée sous forme de fichier de configuration — propriétés ou JSON, versionnable et ne contenant aucun mot de passe. PL/SQL d'abord, car c'est le point essentiel : cochez les packages et procédures que vous êtes prêt à exposer, et chacun devient un outil avec ses paramètres typés. Ensuite, votre propre SQL — des instructions que vous avez écrites et testées, avec des paramètres de liaison typés en ligne. L'agent exécute celles-ci ; il ne compose pas les siennes. Enfin, les tables, curatées par opération plutôt que par table — une table nouvellement sélectionnée est en lecture seule, et create, update et delete sont à vous de cocher.
2. 02

   Générer, compiler, exécuter

   La page Runtime émet du Java pour exactement ces objets, le compile et le lance comme son propre serveur sur loopback. Tout ce que vous n'avez pas sélectionné n'a ni outil, ni méthode, ni classe — il est absent du binaire plutôt que simplement refusé.

   docker run -d --name mcpdbwizard \
     -p 8080:8080 \
     -e MCPDBWIZARD_ORACLE_HOST=db.example.com \
     -e MCPDBWIZARD_ORACLE_PORT=1521 \
     -e MCPDBWIZARD_ORACLE_SID=/PDB1 \
     -e MCPDBWIZARD_ORACLE_USER=appuser \
     -e DB_PASS_FILE=/run/secrets/oracle \
     -v mcpdbwizard-demo:/data \
     ghcr.io/srmadscience/mcpdbwizard:2.0.32
   

3. 03

   Pointez votre client MCP vers le proxy

   Les agents se connectent sur le port 8080, via Streamable HTTP, avec un jeton émis pour leur compte. Le proxy est le seul composant qui sait qui appelle — il vérifie le compte, l'octroi et la limite de débit, puis transmet.

   {
     "mcpServers": {
       "payroll": {
         "url": "http://localhost:8080/mcp/alice/payroll",
         "headers": {
           "Authorization": "Bearer <id>.<secret>"
         }
       }
     }
   }
   

Le démarrage rapide contient tout le parcours, y compris l'émission du jeton et l'octroi de la configuration.