Passer au contenu principal
Les jeux d’outils permettent à une connexion MCP de Didit de charger une liste restreinte d’outils au lieu de tout le catalogue, et le mode lecture seule vous donne une connexion qui ne peut jamais modifier les données. Ces deux options se définissent chacune par un paramètre dans l’URL du serveur :
Sans paramètre, le serveur liste tous les outils auxquels votre rôle donne accès. Rien ne change donc pour une connexion que vous avez déjà.

Pourquoi charger moins d’outils

Votre client envoie au modèle la définition de chaque outil listé avant votre première question. Pour l’ensemble du catalogue Didit, cela représente des dizaines de milliers de tokens à chaque requête : environ 50 000 à 115 000, selon le tokenizeur du modèle. Certains clients limitent aussi le nombre d’outils qu’ils acceptent. Le compromis est une étape supplémentaire. Un outil hors de la liste n’est pas perdu, mais le modèle doit le trouver avec recherche d’outils avant de pouvoir l’exécuter. Un modèle qui voit tous les outils choisit le bon un peu plus souvent qu’un modèle qui doit d’abord chercher. Chargez tout lorsqu’une conversation couvre de nombreux domaines et que le coût en contexte n’a pas d’importance. Chargez core et les ensembles d’outils que vous utilisez le plus lorsque ce coût compte.

Choisir vos toolsets

Ajoutez toolsets à l’URL du serveur, avec une liste de noms séparés par des virgules :
core est la liste courte à partir de laquelle commencent la plupart des tâches. Elle couvre vos organisations et applications, les sessions de vérification (créer, rechercher, décider, expliquer, simuler dans le sandbox, consulter les livraisons de webhooks), la recherche de workflows, les analyses et le solde, la clé API de votre application et ses webhooks, la recherche de dossiers, d’utilisateurs, d’entreprises et de transactions, ainsi que la recherche dans la documentation.
  • core : la liste courte décrite ci-dessus.
  • account : organisations, applications, clés API, membres et rôles.
  • billing : forfait, solde de crédit, moyens de paiement, reçus et informations de facturation.
  • sessions : sessions de vérification (créer, rechercher, décider, examiner, partager, importer, PDF et livraisons de webhooks).
  • workflows : workflows de vérification et questionnaires (construire, modifier, valider et publier).
  • lists : listes personnalisées, liste de blocage et liste d’autorisation.
  • vendors : les personnes et entreprises que vous vérifiez (utilisateurs et entreprises des fournisseurs).
  • transactions : surveillance des transactions (transactions, filtrage des portefeuilles et règles avec backtesting).
  • cases : gestion des dossiers (créer, assigner, escalader et résoudre les dossiers).
  • investigator : l’Investigator (sa file d’attente d’examen, ses rapports, ses décisions, ses questions sur les politiques et ses performances).
  • webhooks : destinations de webhooks et alertes.
  • reports : analyses, exportations et journal d’audit.
  • branding : personnalisation en marque blanche du parcours de vérification.
  • verification : API de vérification autonomes (document d’identité, visage, AML, justificatif de domicile, téléphone, e-mail, base de données et vérifications d’entreprise).
  • travel_rule : Travel Rule (paramètres, annuaire des VASP, réseaux, adresses de portefeuille, transferts et messages).
  • marketplace : la marketplace des fournisseurs (le catalogue, vos connexions et vos demandes d’intégration).
  • networks : réseaux de fraude (sessions, utilisateurs et entreprises liés qui partagent un appareil, un document ou un contact).
  • compliance : l’assistant de conformité (votre profil réglementaire, ses exigences et les workflows générés à partir de celles-ci).
  • docs : recherche dans la documentation de Didit.
  • all : tous les outils que votre rôle peut utiliser. C’est la valeur par défaut.
La référence des outils répertorie chaque outil avec son type et l’autorisation de rôle dont il a besoin. Fonctionnement de la sélection :
  • Les toolsets doivent être sélectionnés explicitement. Une URL sans toolsets liste tous les outils.
  • Nommer des toolsets ne liste que ceux-là. ?toolsets=cases liste les outils de dossiers, ainsi que didit_context_get, que reçoit chaque connexion. Ajoutez core pour conserver aussi la liste courte.
  • Un toolset détermine ce qui est listé, pas ce que vous pouvez exécuter. Un outil hors de votre sélection s’exécute toujours lorsque le modèle l’appelle par son nom, avec les mêmes autorisations de rôle que d’habitude.
  • Un nom inconnu du serveur est ignoré. La connexion fonctionne quand même, et le serveur indique au modèle le nom ignoré ainsi que la liste des noms valides.
  • Votre rôle s’applique toujours. Un toolset n’accorde jamais une autorisation : voir rôles et autorisations.

Se connecter en lecture seule

Ajoutez read_only=true à l’URL du serveur :
Une connexion en lecture seule ne liste que les outils qui lisent des données, et le serveur refuse tout appel qui créerait, modifierait ou supprimerait quelque chose. Ce refus est appliqué côté serveur pour chaque appel, il tient donc même si votre client garde en mémoire un outil d’une connexion précédente. Utilisez ce mode pour produire des rapports, explorer un compte, ou pour un agent dont vous ne voulez pas qu’il agisse seul. Pour autoriser à nouveau les modifications, connectez-vous sans read_only.

Accéder aux outils que vous n’avez pas chargés

Lorsqu’une connexion ne liste qu’une partie du catalogue, le serveur ajoute quatre outils pour que rien ne soit hors d’atteinte :
  • didit_tool_search (lecture) : recherche des outils selon ce que vous voulez faire (« exporter des sessions au format CSV »), ou liste un jeu d’outils. Chaque résultat indique ce que fait l’outil, ses paramètres et s’il est en lecture, en écriture ou destructif.
  • didit_tool_describe (lecture) : renvoie la description complète et le schéma d’entrée d’au plus cinq outils.
  • didit_tool_call_read (lecture) : exécute un outil en lecture seule qui ne figure pas dans la liste. Il refuse un outil qui modifie des données.
  • didit_tool_call_write (destructif) : exécute un outil qui crée, modifie ou supprime des données et qui ne figure pas dans la liste. Non proposé sur une connexion en lecture seule.
Un appel via didit_tool_call_read ou didit_tool_call_write est contrôlé exactement comme un appel direct : les autorisations de votre rôle, le mode lecture seule et toutes les exigences confirm: true continuent de s’appliquer. Les deux outils sont séparés afin que votre client puisse vous demander confirmation avant une modification, tout en laissant passer une simple consultation. Avec core chargé, une demande telle que « inviter un nouveau membre dans mon organisation » se déroule ainsi :
  1. Le modèle appelle didit_tool_search avec invite a teammate et obtient didit_org_invite_member, marqué comme un outil en écriture.
  2. Il appelle didit_tool_call_write en passant didit_org_invite_member comme name, accompagné des propres arguments de cet outil.
  3. Votre client vous demande d’approuver l’appel, comme pour tout outil qui modifie des données.
Lorsque tous les outils sont chargés, il n’y a plus rien à découvrir : ces quatre outils ne sont donc pas listés.

Set it up in your client

Configurez-le dans votre client : suivez les mêmes étapes que dans le guide d’installation, en ajoutant les paramètres à l’URL.
Gardez les guillemets : sinon votre shell interpréterait lui-même le ? et le &.
Si votre client vous permet de définir des en-têtes sans modifier l’URL, envoyez plutôt X-MCP-Toolsets: core,workflows et X-MCP-Readonly: true. Pour les ensembles d’outils, une valeur dans l’URL prime sur l’en-tête, et le mode lecture seule est activé dès que l’un des deux le demande.
Le plugin ChatGPT utilise son propre catalogue fixe et réduit, accessible à l’adresse https://mcp.didit.me/mcp/chatgpt. Les ensembles d’outils et le mode lecture seule ne s’appliquent pas à lui. Voir Connecter ChatGPT.

Prompts, instructions et recherche dans la documentation

Le serveur aide le modèle à démarrer au bon endroit :
  • Instructions. À la connexion, le serveur demande au modèle de commencer par didit_context_get, lui indique comment organization_id et application_id sont résolus, de construire dans une application sandbox, et quels ensembles d’outils cette connexion a chargés.
  • Prompts. Les clients qui prennent en charge les prompts MCP proposent cinq points de départ : integrate_didit, review_queue, explain_session, build_workflow et verification_report. Dans Claude Code, ils apparaissent sous forme de commandes slash.
  • Recherche dans la documentation. didit_docs_search effectue une recherche dans ces pages de documentation et renvoie les sections correspondantes avec leurs liens, afin que les questions sur le fonctionnement de Didit soient traitées à partir des pages à jour.

Vérifier ce qui a été chargé par une connexion

Demandez à votre client :
Le modèle répond à partir des instructions du serveur. Pour vérifier qu’un serveur prend en charge les ensembles d’outils avant de vous y fier, consultez son endpoint d’état :
La réponse répertorie toolsets et read_only sous features.

Étapes suivantes

Installation

Connectez Claude, ChatGPT, Cursor, VS Code, Codex ou tout autre client MCP.

Référence des outils

Chaque outil, son type et l’autorisation requise pour le rôle.

Authentification

Connectez-vous avec Didit, les portées et les autorisations requises pour le rôle.

Exemples d'instructions

Des instructions prêtes à l’emploi dès le premier jour.
Dernière modification le 12 novembre 2026