El servidor MCP de verificació d'identitat per a Claude

Punts clau

• Un servidor MCP (Model Context Protocol) de verificació d'identitat proporciona a Claude eines tipificades per a operacions reals d'identitat i frau; no demana al model que inventi un resultat de verificació.
• El servidor allotjat de Didit exposa 115 eines a https://mcp.didit.me/mcp mitjançant HTTP (Hypertext Transfer Protocol) Streamable sense estat i només POST.
• L'accés utilitza OAuth (Open Authorization) 2.1 amb PKCE (Proof Key for Code Exchange) i registre dinàmic de clients. No hi ha mode de clau d'API (interfície de programació d'aplicacions) per al servidor allotjat.
• El servidor actua com a usuari connectat sota didit:management i didit:verification; els rols d'organització existents continuen definint el que Claude pot fer.
• Les respostes conegudes que contenen credencials són redactades i les càrregues útils d'error són sanejades. Les anotacions de les eines classifiquen el comportament de lectura, escriptura i destructiu; l'eliminació amb comodí té una comprovació de confirmació per part del gestor, però l'esquema anunciat actualment no exposa aquest camp de confirmació.
• La connexió MCP és gratuïta. L'ús manté els preus publicats de Didit, inclòs un paquet complet de Know Your Customer (KYC) de 0,33 $ i 500 verificacions gratuïtes al mes per a cada funció.

Si esteu avaluant un servidor MCP de verificació d'identitat per a Claude, la pregunta útil no és si Claude pot cridar un punt final. És si la connexió proporciona al model d'intel·ligència artificial (IA) prou capacitat estructurada per completar el treball real, tot preservant l'autenticació, l'autorització, l'auditabilitat i el control humà. Aquí és on les implementacions difereixen.

Aquesta guia explica aquest model d'avaluació utilitzant el connector de Claude de Didit com a exemple concret. Deliberadament no repeteix la configuració pas a pas coberta a la guia d'instal·lació de Claude, la visió general de la categoria a la referència d'eines MCP, o la seqüència de sessions a la guia del cicle de vida de la sessió KYC. Els esquemes canònics i actuals es troben a la documentació i al codi font públic.

Què és un servidor MCP de verificació d'identitat?

MCP és un protocol per proporcionar eines a un model. Un servidor MCP publica operacions anomenades amb descripcions i esquemes d'entrada tipificats. Un client MCP com Claude descobreix aquestes operacions, permet que el model en seleccioni una, valida els seus arguments i retorna el resultat a la conversa.

Un servidor MCP de verificació d'identitat aplica aquest patró al treball regulat d'identitat i frau. En lloc de respondre des del coneixement general quan se li demana que verifiqui un client, Claude pot crear una sessió de verificació real, recuperar la seva decisió, executar una comprovació de cribratge o inspeccionar els fluxos de treball configurats d'una organització. Les dades retornades provenen del servei connectat, no de la memòria del model.

Aquesta distinció és essencial. MCP no converteix un model de llenguatge en una autoritat d'identitat, i no transfereix la responsabilitat de compliment al model. Proporciona al model una ruta governada al sistema que realitza les comprovacions i registra els resultats. El proveïdor de verificació continua sent responsable del servei; el client continua sent responsable de la política i la revisió; Claude coordina les operacions permeses.

Una definició útil: un servidor MCP de verificació d'identitat és un adaptador conscient de l'autorització que exposa les capacitats d'identitat i frau com a eines tipificades que un client d'IA pot descobrir i invocar.

Què permet el servidor de Didit dins de Claude

Didit és infraestructura per a la identitat i el frau. El seu catàleg MCP allotjat proporciona a Claude 115 eines que abasten 19 dominis a nivell de màquina. El punt no és només el recompte; és l'abast del treball que Claude pot connectar a través d'una sessió autenticada.

Una interacció normal comença amb didit_context_get, que retorna les organitzacions i aplicacions a les quals l'usuari pot accedir. Llavors, Claude pot triar eines que coincideixin amb la tasca:

• didit_session_create crea una sessió de verificació a partir d'un flux de treball configurat, mentre que didit_session_get_decision recupera la decisió resultant.
• didit_verify_id, didit_verify_passive_liveness i didit_verify_face_match realitzen comprovacions de documents i biomètriques enfocades quan els fitxers d'imatge requerits existeixen al sistema de fitxers del servidor MCP.
• didit_verify_aml realitza el cribratge Anti-Money Laundering (AML).
• didit_verify_kyb_search i didit_verify_kyb_select admeten el descobriment del registre Know Your Business (KYB) i la selecció de registres.
• didit_transaction_create registra l'activitat monitoritzada, i didit_transaction_screen_wallet realitza el cribratge de cartera Know Your Transaction (KYT).
• didit_case_create obre un cas d'investigació, mentre que didit_case_manage admet l'assignació, els comentaris, l'escalada, la reobertura, la resolució i les actualitzacions de camps.
• didit_workflow_create i didit_workflow_edit_graph permeten als usuaris autoritzats compondre fluxos de verificació; didit_webhook_create connecta els esdeveniments resultants als sistemes posteriors.

Aquests són exemples, no un substitut de la documentació canònica de l'eina MCP. El servidor actual només exposa eines: no publica recursos MCP ni plantilles de sol·licitud. La configuració de compliment especialitzada i la presentació d'informes legals segueixen sent fluxos de treball governats a la consola de negocis en lloc d'accions de xat autònomes.

El límit d'imatge de Claude allotjat

Cinc eines d'imatge —didit_verify_id, didit_verify_age, didit_verify_face_match, didit_verify_passive_liveness i didit_lists_entry_upload_face— accepten entrades de ruta absoluta que els seus gestors llegeixen del propi sistema de fitxers del servidor MCP.

Per tant, una imatge pujada a Claude allotjat no està normalment disponible per a aquestes eines: el connector no exposa cap eina d'etapa de fitxers. Veure una imatge al xat no és el mateix que proporcionar un front_image_path llegible. Les eines són pràctiques en desplegaments locals o auto-allotjats on els fitxers es poden col·locar al sistema de fitxers del servidor.

Per a un sol·licitant real que utilitza Claude allotjat, utilitzeu didit_session_create, envieu la url retornada i, a continuació, recupereu el resultat amb didit_session_get_decision. El sol·licitant captura l'evidència configurada a l'experiència allotjada de Didit; Claude no etapa la imatge.

El límit d'autenticació a avaluar

El punt final allotjat és https://mcp.didit.me/mcp, utilitzant HTTP Streamable sense estat i només POST. Claude es connecta mitjançant OAuth (Open Authorization) 2.1 amb PKCE (Proof Key for Code Exchange) i registre dinàmic de clients; el servidor allotjat no té mode de clau d'API.

La propietat de seguretat material és la identitat resultant. Les trucades s'executen com l'usuari de Didit connectat sota didit:verification i didit:management, mentre que el rol de backend de l'organització encara determina quines operacions tenen èxit. Un lector no es converteix en administrador perquè Claude va seleccionar una eina d'escriptura.

Per a l'avaluació, confirmeu que l'accés es pot revocar sense rotar una credencial d'aplicació de producció, que les accions segueixen sent atribuïbles a un usuari i que el context multi-organització és explícit. La seqüència exacta de descobriment, consentiment i configuració pertany a la guia d'instal·lació de Claude i la documentació d'autenticació.

La seguretat és més que l'autenticació

L'autenticació respon a qui truca. Un servidor MCP de grau de producció també ha de controlar el que veu el model i com procedeixen les accions arriscades.

Didit marca les eines amb anotacions de només lectura, escriptura, destructives, idempotents i de món obert. Un client pot utilitzar aquests senyals per agrupar o etiquetar operacions, però una anotació és una metadada descriptiva. No obliga automàticament el model o el servidor a sol·licitar confirmació.

La regla de confirmació és estreta. didit_session_delete elimina permanentment una sessió i només requereix session_id. L'eliminació per lots limitada amb una llista d'identificadors explícita tampoc requereix un camp de confirmació. El gestor per a una eliminació amb comodí rebutja delete_all: true tret que també es proporcioni confirm: true, però l'esquema d'entrada d'eliminació per lots anunciat actualment omet confirm. Tracteu-ho com un mecanisme de seguretat per part del gestor amb una bretxa d'esquema, no com un flux d'aprovació complet visible per al client. Els equips haurien d'afegir la seva pròpia política d'aprovació humana per a escriptures conseqüents en lloc de suposar que una anotació en imposa una.

Les sortides conegudes que contenen credencials es gestionen deliberadament: els camps de credencials de l'aplicació i les metadades del secret de signatura de webhook són redactats, mentre que les càrregues útils d'error són sanejades profundament abans de tornar al client. Això no és una promesa que tots els camps de cada resposta empresarial amb èxit s'eliminin globalment, de manera que els equips encara haurien de minimitzar les dades personals que demanen a Claude que recuperi. L'operació de revelació de credencials només existeix al catàleg complet local/stdio, requereix la seva pròpia confirmació i està exclosa del catàleg OAuth allotjat de 115 eines. L'operació de recàrrega de crèdit també està exclosa d'aquest catàleg allotjat.

Aquest model en capes és preferible a confiar en un missatge del sistema que simplement diu a un agent que “tingui cura”, però els seus límits s'han d'establir amb precisió. Els rols de backend, la validació d'entrades, la redacció dirigida, la sanejació d'errors i la comprovació del gestor d'eliminació amb comodí són l'aplicació. Les anotacions de risc i les instruccions de xat informen el comportament, i la bretxa actual de l'esquema de confirmació amb comodí pertany a la llista de comprovació d'un avaluador.

Com avaluar un servidor MCP per a treballs d'identitat

Abans de connectar qualsevol servei d'identitat o frau a Claude, verifiqueu el següent:

• Transport: Hi ha un punt final remot documentat que utilitza un transport MCP actual?
• Autenticació: L'accés representa un usuari mitjançant OAuth, o depèn d'una credencial àmpliament privilegiada copiada a la configuració?
• Autorització: Els rols de l'organització són aplicats pel backend en cada trucada?
• Esquemes: Les eines defineixen entrades restringides, accions permeses i errors útils?
• Metadades de risc: El client pot distingir lectures, escriptures, operacions destructives i trucades que afecten sistemes externs?
• Gestió de dades: Els secrets i les dades personals innecessàries són redactats dels resultats i errors de les eines?
• Límits: El proveïdor estableix el que el model no pot fer i on encara es requereix una revisió de compliment humana?
• Inspectibilitat: El vostre equip pot revisar el codi font i una referència d'eines mantinguda?

Didit publica la seva implementació al repositori públic de GitHub amb llicència MIT i documenta l'arquitectura a la descripció general de MCP i la guia d'autenticació. El codi base v5 està marcat com a privat per a la publicació de paquets i no es distribueix a través de npm. Per a Claude, el camí previst és el punt final allotjat i el seu flux d'autorització basat en navegador.

Quan el connector de Claude és una bona opció

El connector és més fort quan un humà vol que Claude investigui, coordini o executi operacions limitades en un espai de treball de Didit existent: revisar decisions recents, crear un enllaç de verificació allotjat, executar cribratges sense imatges, inspeccionar una cua de casos, comparar fluxos de treball o resumir l'activitat entre aplicacions. També és útil per als desenvolupadors que exploren esquemes abans d'implementar una integració de backend. Les comprovacions d'imatges autònomes necessiten l'accés a fitxers del costat del servidor descrit anteriorment.

No és un reemplaçament del codi de producció determinista on la vostra aplicació ha de desencadenar la mateixa operació en cada sol·licitud sense un usuari conversacional. En aquest cas, utilitzeu les API REST (Representational State Transfer) i els kits de desenvolupament de programari de Didit. MCP i REST serveixen a diferents trucades: un delega el treball d'una persona connectada a un client d'IA; l'altre connecta la lògica de l'aplicació directament al servei.

Els aspectes econòmics són els mateixos, independentment de quina interfície iniciï una comprovació. El servidor MCP en si és gratuït. Un paquet complet de KYC —verificació de documents d'identitat, prova de vida passiva, coincidència facial i anàlisi d'IP (Internet Protocol)— costa 0,33 $. Cada funció inclou 500 verificacions gratuïtes al mes. Didit dona suport a més de 2.000 empreses en producció en més de 220 països i territoris, més de 14.000 tipus de documents i més de 48 idiomes.

Connecta Didit a Claude

Si el model d'autorització i seguretat s'adapta al vostre cas d'ús, afegiu el connector personalitzat de Didit a Claude. El connector apunta al punt final HTTP Streamable allotjat i inicia el flux d'inici de sessió de Didit.

Per als passos exactes de Claude Desktop i Claude Code, utilitzeu la guia d'instal·lació dedicada. Per obtenir el context del producte i més exemples, visiteu la pàgina de desenvolupadors MCP de Didit.

El veredicte concís és el següent: un servidor MCP de verificació d'identitat val la pena utilitzar-lo amb Claude quan converteix les operacions d'identitat i frau en accions tipificades i conscients dels permisos sense debilitar els controls que les envolten. El recompte d'eines fa que la connexió sigui útil; OAuth, l'aplicació de rols, la redacció, els esquemes precisos i les comprovacions d'eliminació amb comodí estretament aplicades fan que el seu model de risc sigui inspeccionable.