Vérification de l'âge avec Claude : Sessions hébergées vs. Fichiers locaux

Points clés à retenir

• Un connecteur Claude hébergé ne peut pas envoyer un selfie ou une photo de document d'identité à didit_verify_age ou didit_verify_id depuis l'appareil de l'utilisateur. Ces outils lisent les chemins absolus sur la machine exécutant le serveur Model Context Protocol (MCP).
• Le chemin hébergé correct est basé sur la session : créez une session pour un flux de travail existant, donnez à la personne l'url renvoyée, et récupérez la décision complétée avec didit_session_get_decision.
• Un flux de travail peut inclure l'estimation faciale de l'âge, qui estime l'âge, ou la vérification de documents, qui extrait la date de naissance et d'autres champs du document. Ce sont différents niveaux de preuve.
• Les outils de chemin de fichier restent utiles pour les déploiements stdio locaux ou auto-hébergés où le serveur MCP et le fichier image se trouvent sur la même machine.
• Le point de terminaison MCP hébergé de Didit expose 115 outils. Le serveur est gratuit, et le niveau gratuit inclut 500 vérifications gratuites par mois.

« Vérifier l'âge de cette personne depuis Claude » semble être un simple appel d'outil. L'intégration réelle présente une frontière importante : où se trouve l'image ? Cela détermine si Claude doit créer une session de vérification hébergée ou appeler un outil d'image autonome.

La page développeur MCP de Didit et le référentiel GitHub public décrivent le serveur qui connecte Claude aux contrôles d'identité et de fraude. Pour l'assurance de l'âge, la route de la session hébergée est le choix pratique pour une personne réelle utilisant Claude à distance. La route du chemin d'image autonome est conçue pour les environnements locaux ou auto-hébergés avec un accès direct au système de fichiers.

La frontière du système de fichiers que la plupart des exemples MCP manquent

L'outil autonome didit_verify_age accepte un image_path absolu. De même, didit_verify_id accepte un front_image_path absolu et un back_image_path facultatif. À l'intérieur du serveur MCP, ces chemins sont validés et lus à partir du disque avant que les fichiers ne soient soumis.

C'est simple dans un déploiement stdio local. Si Claude Desktop et un serveur Didit MCP auto-hébergé fonctionnent sur la même station de travail, un chemin tel que /Users/example/checks/selfie.jpg peut faire référence à un fichier réel disponible pour le processus serveur. La même idée fonctionne sur un serveur interne contrôlé lorsque l'application a déjà placé le fichier dans un répertoire local autorisé.

Cela ne fonctionne pas de la même manière avec le point de terminaison hébergé. Lorsque Claude appelle https://mcp.didit.me/mcp, un chemin absolu fait référence au système de fichiers du serveur de Didit, pas à l'ordinateur portable ou au téléphone de l'utilisateur de Claude. Taper un chemin local dans Claude hébergé ne télécharge pas ce fichier. Un utilisateur distant ne peut donc pas remettre un selfie ou une photo de document à l'outil hébergé simplement en nommant un chemin.

Ce n'est pas une limitation de l'estimation de l'âge elle-même. C'est une distinction de transport et de système de fichiers. Pour les utilisateurs hébergés, Didit résout le transfert avec une session de vérification et une URL destinée à l'utilisateur.

Le flux Claude hébergé qui fonctionne

Premièrement, l'organisation a besoin d'un flux de travail existant configuré dans la console Didit Business. Ce flux de travail définit les contrôles que la personne effectuera. Un flux de travail d'assurance de l'âge pourrait inclure l'estimation faciale de l'âge, la vérification de documents avec extraction de la date de naissance, ou une séquence Know Your Customer (KYC) plus large.

Claude appelle ensuite didit_session_create. La seule entrée requise est workflow_id ; l'outil n'accepte pas de « configuration de flux de travail » en ligne. Les entrées facultatives incluent la référence de l'utilisateur de l'échange ou de l'application dans vendor_data, un callback de redirection et une language d'interface utilisateur.

Utilisez didit_session_create avec :
{
  "workflow_id": "<uuid-de-flux-de-travail-existant>",
  "vendor_data": "user_18427",
  "callback": "https://example.com/age-check/complete",
  "language": "en"
}

Renvoyez l'URL de la session à l'utilisateur. Ne lui demandez pas de chemin d'image local.

La réponse contient session_id, url et session_token. Claude donne à la personne l'url renvoyée. La personne ouvre l'interface utilisateur de vérification hébergée de Didit sur son propre appareil et complète les étapes de capture définies par le flux de travail. Le transfert d'image se produit dans cette interface utilisateur plutôt que par un chemin tapé dans le chat.

Après la complétion, Claude appelle didit_session_get_decision avec l'ID de session renvoyé :

Utilisez didit_session_get_decision avec :
{
  "session_id": "<uuid-de-session-issue-de-creation>"
}

Résumez la décision de session et uniquement les champs extraits renvoyés par le flux de travail.

L'outil renvoie la décision de vérification complète et toutes les données extraites pour cette session. Les données exactes dépendent du flux de travail. La source MCP ne documente pas de raccourci booléen distinct pour le seuil d'âge. Pour les vérifications de documents, la décision peut inclure les données de document structurées renvoyées par les étapes de vérification configurées ; l'agent doit lire la réponse réelle plutôt que d'inventer un champ de commodité.

Ce que font réellement les outils d'image locaux

Dans une configuration stdio locale ou auto-hébergée, les outils autonomes peuvent être un chemin direct pour les tâches par lots, les utilitaires de révision interne ou les applications qui contrôlent déjà l'ingestion d'images.

Estimation faciale de l'âge

didit_verify_age nécessite image_path et accepte en option vendor_data. Il estime l'âge d'une personne à partir d'une image faciale et effectue également un contrôle de vivacité passif. Une estimation n'est pas une preuve d'une date de naissance ou d'une identité exacte.

# Stdio local ou auto-hébergé uniquement
# Le fichier doit exister sur le système de fichiers du serveur MCP.
didit_verify_age {
  "image_path": "/chemin/serveur/absolu/selfie.jpg",
  "vendor_data": "user_18427"
}

L'estimation de l'âge est facturée 0,10 $ par vérification. L'entrée est toujours une image faciale, et le service traite cette image pour produire le résultat. Décrire la méthode comme sans document est exact ; la décrire comme ne collectant aucune donnée personnelle ou ne stockant rien n'est pas pris en charge par le contrat d'outil MCP.

Extraction de la date de naissance basée sur les documents

didit_verify_id nécessite front_image_path. Il peut également recevoir back_image_path, minimum_age et d'autres options documentées. L'outil soumet l'image du document d'identité, effectue une reconnaissance optique de caractères (OCR) et renvoie des données de document structurées et des contrôles d'authenticité. L'OCR peut extraire la date de naissance ainsi que d'autres champs présents sur le document.

# Stdio local ou auto-hébergé uniquement
didit_verify_id {
  "front_image_path": "/chemin/serveur/absolu/id-avant.jpg",
  "back_image_path": "/chemin/serveur/absolu/id-arrière.jpg",
  "minimum_age": 18,
  "vendor_data": "user_18427"
}

La source décrit minimum_age comme refusant le contrôle lorsque l'âge extrait est inférieur à la valeur fournie. L'agent doit lire la décision renvoyée plutôt que de s'attendre à un champ de résultat de seuil supplémentaire. La vérification d'identité est de 0,15 $ par vérification. Étant donné que l'image complète du document est soumise et que les champs du document sont extraits, cette voie ne doit pas être présentée comme ne collectant qu'une date de naissance.

L'estimation de l'âge, les contrôles de documents et le KYC complet ne sont pas interchangeables

Route	Ce qu'elle établit	Chemin Claude hébergé	Prix publié
Estimation faciale de l'âge	Un âge estimé à partir d'une image faciale, plus la vivacité passive	Utilisez une session hébergée dont le flux de travail inclut l'estimation de l'âge	0,10 $ par vérification
Vérification d'identité	Contrôles d'authenticité de documents et champs de documents extraits, y compris la date de naissance le cas échéant	Utilisez une session hébergée dont le flux de travail inclut la vérification de documents	0,15 $ par vérification
KYC complet	Contrôles d'identité configurés combinant la vérification d'identité, la vivacité passive, la correspondance faciale et l'analyse IP	Créez une session pour le flux de travail KYC existant et transmettez l'URL	0,33 $ par pack

La première route estime. La seconde repose sur un document émis par le gouvernement soumis. La troisième combine plusieurs contrôles dans une décision d'identité plus large. Les équipes produit peuvent distinguer ces niveaux de preuve sans affirmer qu'un mécanisme donné satisfait automatiquement une loi ou un régulateur.

Le paysage réglementaire est spécifique à la méthode

Les règles d'assurance de l'âge diffèrent selon la juridiction, le type de service, le contenu et le risque. Au Royaume-Uni, le guide d'assurance de l'âge de l'Ofcom pour la loi sur la sécurité en ligne discute de plusieurs méthodes qui peuvent être très efficaces, y compris l'estimation faciale de l'âge et la correspondance d'identification photo, tout en évaluant l'efficacité par rapport à des critères tels que la précision, la résistance au contournement, la fiabilité et l'équité. Dans l'Union européenne, la présentation de la directive sur les services de médias audiovisuels de la Commission européenne décrit les mesures de protection des mineurs qui peuvent inclure des codes PIN ou des systèmes de vérification de l'âge plus sophistiqués.

Ces sources illustrent pourquoi le langage d'implémentation est important : « assurance de l'âge », « estimation de l'âge », « vérification de documents » et « vérification d'identité » sont liés mais non synonymes. La question de savoir si une méthode particulière convient à un service particulier est une évaluation spécifique à la juridiction et au contexte. L'intégration MCP fournit les routes techniques ; elle ne fait pas cette évaluation pour l'opérateur.

Connecter Claude sans brouiller la frontière

Utilisez le lien profond du connecteur Didit pour Claude hébergé. Le point de terminaison utilise OAuth 2.1 avec Proof Key for Code Exchange (PKCE). La présentation MCP, le guide d'authentification et la référence des outils couvrent la connexion et la découverte.

Pour le modèle de session plus large, lisez la vérification d'identité KYC via MCP. Pour une vue de niveau catalogue de l'intégration, consultez la référence des outils Didit MCP.

La règle pratique est simple : Claude hébergé doit créer une session et remettre son URL à la personne ; stdio local ou auto-hébergé peut utiliser des chemins d'image absolus lorsque le serveur possède réellement ces fichiers. Garder cette frontière explicite rend les invites d'assurance de l'âge précises, exécutables et sûres à réutiliser.