Mode serveur

Avec MCP_ENABLED=true, Sovrium génère un jeu d'outils MCP à partir de votre configuration. Rien n'est exposé par défaut : une entité n'apparaît que si son schéma déclare aiAccess, et un identifiant ne se voit présenter que les outils que son rôle peut appeler.

Surfaces exposées

Quatre familles d'objets deviennent des outils.

Surface	Nom d'outil	Ce qu'il fait
Tables utilisateur	`{app}_{table}_{op}`	Lire, lister, créer, mettre à jour, supprimer des enregistrements.
Automatisations manuelles	`{app}_automation_{name}`	Invoquer une automatisation à déclencheur manuel.
Modèles d'action	`{app}_action_{name}`	Exécuter un modèle d'action.
Internes admin	`{app}_auth_` / `{app}_system_`	Vues en lecture seule des tables auth et système, rôle admin uniquement.

tools/list est filtré par connexion : un identifiant viewer n'apprend même jamais qu'un outil de suppression existe. Seules les automatisations à déclencheur manuel sont éligibles — une automatisation cron ou déclenchée par changement d'enregistrement n'a aucun appelant à exposer.

Déclarer l'éligibilité

aiAccess est la déclaration d'intention de l'auteur du schéma. Elle est délibérément séparée de MCP_ENABLED : l'écrire n'expose rien, et l'interrupteur de l'opérateur n'expose rien que vous n'ayez écrit.

app.yaml

tables:
  - name: contacts
    aiAccess: true

Ce booléen couvre le cas courant — exposer la table avec les valeurs par défaut. La forme objet prend le relais quand ces défauts ne conviennent pas, et fournir un objet constitue en soi le signal d'activation ; il n'y a pas de champ enabled à renseigner.

app.yaml

tables:
  - name: contacts
    aiAccess:
      description: Customer contacts. Use this when the user asks about people.
      operations: [read, list, create, update]
      fieldExposure: permissioned
      annotations:
        readOnly: false
        destructive: false

Propriété	Signification
`description`	La description d'outil que lit le modèle. Jusqu'à 2000 caractères.
`operations`	Sous-ensemble de `read`, `list`, `create`, `update`, `delete`. Les tables exposent les cinq par défaut.
`fieldExposure`	`permissioned` (défaut), `all` ou `whitelist`.
`whitelistFields`	Quels champs, quand `fieldExposure: whitelist`. Requis et non vide dans ce mode.
`annotations`	Indications de risque — voir plus bas.
`requireConfirmation`	Force l'indication destructive quel que soit le type d'opération.

Les automatisations et les modèles d'action acceptent le même bloc mais ignorent operations : chacun expose un unique outil d'invocation.

description est le champ au plus fort levier de cette page. Le modèle choisit ses outils en les lisant. « Customer contacts. Use this when the user asks about people » produit un comportement nettement meilleur qu'un « Read from contacts » généré automatiquement, parce qu'il dit quand recourir à l'outil et pas seulement ce qu'il touche. Investissez ici avant de régler quoi que ce soit d'autre.

Exposition des champs

Mode	Champs présents dans le schéma d'outil
`permissioned`	Aucune liste de champs — un objet `data` opaque. Le défaut.
`all`	Tous les champs, toujours soumis au RBAC de champ au moment de l'appel.
`whitelist`	Seulement les noms listés dans `whitelistFields`.

Tous les appelants voient le même schéma d'outil. Le catalogue est compilé une seule fois à partir de votre configuration : l'étape par connexion décide donc quels outils un rôle voit, et non la forme de chacun.

C'est pourquoi permissioned ne nomme aucun champ, et pourquoi il est le défaut : c'est le seul mode qui ne révèle rien de vos colonnes à un rôle qui ne peut pas s'en servir. L'application des permissions se fait au moment de l'appel — une lecture omet les champs que le rôle de l'appelant n'a pas le droit de lire, et une écriture vers un champ qu'il n'a pas le droit d'écrire est rejetée. Recourez à all ou whitelist si vous préférez que le client dispose de véritables indications d'arguments, et à whitelist en particulier quand une table porte des colonnes que le rôle peut lire mais qui ne regardent simplement pas l'IA.

Annotations de risque

Les annotations sont compilées dans la définition d'outil MCP pour qu'un client décide d'exécuter un appel silencieusement ou de demander d'abord à son utilisateur. Elles correspondent une pour une aux indications du protocole :

Annotation	Indication MCP	Signifie
`readOnly`	`readOnlyHint`	Lecture seule — approbation automatique sans risque.
`destructive`	`destructiveHint`	Détruit ou envoie quelque chose — demander d'abord.
`idempotent`	`idempotentHint`	Appeler deux fois est sans danger ; pas d'effet de bord dupliqué.
`openWorld`	`openWorldHint`	Sort de l'application — API externe, appel réseau.

Non renseignées, des valeurs raisonnables sont déduites du type d'opération, et MCP_CONFIRM_DESTRUCTIVE (actif par défaut) marque en outre les outils de suppression et les automatisations non idempotentes comme destructifs.

Le cas qui mérite un réglage manuel est l'automatisation techniquement idempotente mais pratiquement irréversible — envoyer un courriel, débiter une carte. requireConfirmation: true force l'indication destructive sur celles-là, quoi qu'impliquerait le type d'opération.

Pages associées

Présentation de MCP — activer le serveur.
Connecter un client — y diriger un assistant.
Authentification, RBAC et limites — l'application derrière le filtrage.
Vue d'ensemble des tables — où se place aiAccess sur une table.
Actions réutilisables — les modèles d'action en tant qu'outils.

Dernière mise à jour 1 septembre 2026

← PrécédentPrésentation de MCP Suivant →Connecter un client

Modifier cette page Signaler un problème

Cette documentation a été rédigée avec de l'IA : des erreurs ou du contenu obsolète sont donc possibles. Sovrium est en bêta. Les contributions et corrections sont les bienvenues.