El servidor MCP de verificación de identidad para Claude

Puntos clave

• Un servidor MCP (Protocolo de Contexto del Modelo) de verificación de identidad le proporciona a Claude herramientas tipadas para operaciones reales de identidad y fraude; no le pide al modelo que invente un resultado de verificación.
• El servidor alojado de Didit expone 115 herramientas en https://mcp.didit.me/mcp a través de HTTP (Protocolo de Transferencia de Hipertexto) de tipo Streamable, sin estado y solo POST.
• El acceso utiliza OAuth (Autorización Abierta) 2.1 con PKCE (Proof Key for Code Exchange) y Registro Dinámico de Cliente. No existe un modo de clave de interfaz de programación de aplicaciones (API) para el servidor alojado.
• El servidor actúa como el usuario que ha iniciado sesión bajo didit:management y didit:verification; los roles de organización existentes continúan definiendo lo que Claude puede hacer.
• Las respuestas conocidas que contienen credenciales se redactan y las cargas útiles de error se sanean. Las anotaciones de las herramientas clasifican el comportamiento de lectura, escritura y destructivo; la eliminación con comodines tiene una comprobación de confirmación del lado del manejador, pero el esquema publicitado actual no expone ese campo de confirmación.
• La conexión MCP es gratuita. El uso mantiene los precios publicados de Didit, incluyendo un paquete completo de Conozca a su Cliente (KYC) de $0.33 y 500 verificaciones gratuitas por mes para cada función.

Si está evaluando un servidor MCP de verificación de identidad para Claude, la pregunta útil no es si Claude puede llamar a un punto final. Es si la conexión le proporciona al modelo de inteligencia artificial (IA) suficiente capacidad estructurada para completar un trabajo real, preservando al mismo tiempo la autenticación, la autorización, la auditabilidad y el control humano. Ahí es donde las implementaciones difieren.

Esta guía explica ese modelo de evaluación utilizando el conector de Claude de Didit como ejemplo concreto. Deliberadamente no repite la configuración paso a paso cubierta en la guía de instalación de Claude, la descripción general de la categoría en la referencia de herramientas MCP, o la secuencia de sesión en la guía del ciclo de vida de la sesión KYC. Los esquemas canónicos y actuales se encuentran en la documentación y en la fuente pública.

¿Qué es un servidor MCP de verificación de identidad?

MCP es un protocolo para proporcionar herramientas a un modelo. Un servidor MCP publica operaciones con nombres, descripciones y esquemas de entrada tipados. Un cliente MCP como Claude descubre esas operaciones, permite que el modelo seleccione una, valida sus argumentos y devuelve el resultado a la conversación.

Un servidor MCP de verificación de identidad aplica ese patrón al trabajo regulado de identidad y fraude. En lugar de responder con conocimientos generales cuando se le pide que verifique a un cliente, Claude puede crear una sesión de verificación real, recuperar su decisión, ejecutar una comprobación de detección o inspeccionar los flujos de trabajo configurados de una organización. Los datos devueltos provienen del servicio conectado, no de la memoria del modelo.

Esa distinción es esencial. MCP no convierte un modelo de lenguaje en una autoridad de identidad, y no transfiere la responsabilidad del cumplimiento al modelo. Le proporciona al modelo una ruta gobernada al sistema que realiza las comprobaciones y registra los resultados. El proveedor de verificación sigue siendo responsable del servicio; el cliente sigue siendo responsable de la política y la revisión; Claude coordina las operaciones permitidas.

Una definición útil: un servidor MCP de verificación de identidad es un adaptador consciente de la autorización que expone capacidades de identidad y fraude como herramientas tipadas que un cliente de IA puede descubrir e invocar.

Lo que el servidor de Didit permite dentro de Claude

Didit es infraestructura para identidad y fraude. Su catálogo MCP alojado le proporciona a Claude 115 herramientas que abarcan 19 dominios a nivel de máquina. El punto no es solo la cantidad; es el rango de trabajo que Claude puede conectar a través de una sesión autenticada.

Una interacción normal comienza con didit_context_get, que devuelve las organizaciones y aplicaciones a las que el usuario puede acceder. Claude puede entonces elegir herramientas que coincidan con la tarea:

• didit_session_create crea una sesión de verificación a partir de un flujo de trabajo configurado, mientras que didit_session_get_decision recupera la decisión resultante.
• didit_verify_id, didit_verify_passive_liveness y didit_verify_face_match ejecutan comprobaciones enfocadas de documentos y datos biométricos cuando los archivos de imagen requeridos existen en el sistema de archivos del servidor MCP.
• didit_verify_aml ejecuta la detección de Antilavado de Dinero (AML).
• didit_verify_kyb_search y didit_verify_kyb_select admiten el descubrimiento de registros y la selección de registros de Conozca a su Negocio (KYB).
• didit_transaction_create registra la actividad monitoreada, y didit_transaction_screen_wallet realiza la detección de carteras de Conozca su Transacción (KYT).
• didit_case_create abre un caso de investigación, mientras que didit_case_manage admite la asignación, comentarios, escalada, reapertura, resolución y actualizaciones de campos.
• didit_workflow_create y didit_workflow_edit_graph permiten a los usuarios autorizados componer flujos de verificación; didit_webhook_create conecta los eventos resultantes a los sistemas posteriores.

Estos son ejemplos, no un sustituto de la documentación canónica de herramientas MCP. El servidor actual solo expone herramientas: no publica recursos MCP ni plantillas de indicaciones. La configuración de cumplimiento especializada y la presentación de informes legales siguen siendo flujos de trabajo gobernados en la Consola de Negocios en lugar de acciones autónomas de chat.

El límite de imágenes de Claude alojado

Cinco herramientas de imagen — didit_verify_id, didit_verify_age, didit_verify_face_match, didit_verify_passive_liveness y didit_lists_entry_upload_face — aceptan entradas de ruta absoluta que sus manejadores leen del propio sistema de archivos del servidor MCP.

Por lo tanto, una imagen subida a Claude alojado no está normalmente disponible para estas herramientas: el conector no expone ninguna herramienta de preparación de archivos. Ver una imagen en el chat no es lo mismo que proporcionar una front_image_path legible. Las herramientas son prácticas en implementaciones locales o autoalojadas donde los archivos se pueden colocar en el sistema de archivos del servidor.

Para un solicitante real que usa Claude alojado, use didit_session_create, envíe la url devuelta y luego recupere el resultado con didit_session_get_decision. El solicitante captura la evidencia configurada en la experiencia alojada de Didit; Claude no prepara la imagen.

El límite de autenticación a evaluar

El punto final alojado es https://mcp.didit.me/mcp, utilizando HTTP Streamable sin estado y solo POST. Claude se conecta a través de OAuth (Autorización Abierta) 2.1 con PKCE (Proof Key for Code Exchange) y Registro Dinámico de Cliente; el servidor alojado no tiene modo de clave API.

La propiedad de seguridad material es la identidad resultante. Las llamadas se ejecutan como el usuario de Didit que ha iniciado sesión bajo didit:verification y didit:management, mientras que el rol de backend de la organización aún determina qué operaciones tienen éxito. Un Lector no se convierte en administrador porque Claude seleccionó una herramienta de escritura.

Para la evaluación, confirme que el acceso se puede revocar sin rotar una credencial de aplicación de producción, que las acciones siguen siendo atribuibles a un usuario y que el contexto de múltiples organizaciones es explícito. La secuencia exacta de descubrimiento, consentimiento y configuración pertenece a la guía de instalación de Claude y a la documentación de autenticación.

La seguridad es más que autenticación

La autenticación responde quién está llamando. Un servidor MCP de grado de producción también debe controlar lo que el modelo ve y cómo proceden las acciones de riesgo.

Didit marca las herramientas con anotaciones de solo lectura, escritura, destructivas, idempotentes y de mundo abierto. Un cliente puede usar esas señales para agrupar o etiquetar operaciones, pero una anotación es metadatos descriptivos. No obliga automáticamente al modelo o al servidor a solicitar confirmación.

La regla de confirmación es estricta. didit_session_delete elimina permanentemente una sesión y solo requiere session_id. La eliminación por lotes limitada con una lista de identificadores explícita tampoco requiere un campo de confirmación. El manejador para una eliminación con comodín rechaza delete_all: true a menos que también se proporcione confirm: true, pero el esquema de entrada de eliminación por lotes publicitado actualmente omite confirm. Trate esto como un respaldo del lado del manejador con una brecha en el esquema, no como un flujo de aprobación completo visible para el cliente. Los equipos deben agregar su propia política de aprobación humana para escrituras consecuentes en lugar de asumir que una anotación la impone.

Las salidas conocidas que contienen credenciales se manejan deliberadamente: los campos de credenciales de la aplicación y los metadatos de secreto de firma de webhook se redactan, mientras que las cargas útiles de error se sanean profundamente antes de regresar al cliente. Eso no es una promesa de que cada campo en cada respuesta comercial exitosa se elimine globalmente, por lo que los equipos aún deben minimizar los datos personales que le piden a Claude que recupere. La operación de revelación de credenciales existe solo en el catálogo completo local/stdio, requiere su propia confirmación y está excluida del catálogo OAuth alojado de 115 herramientas. La operación de recarga de crédito también está excluida de ese catálogo alojado.

Este modelo en capas es preferible a depender de una indicación del sistema que simplemente le dice a un agente que “tenga cuidado”, pero sus límites deben establecerse con precisión. Los roles de backend, la validación de entrada, la redacción dirigida, la sanitización de errores y la verificación del manejador de eliminación de comodines son la aplicación. Las anotaciones de riesgo y las instrucciones de chat informan el comportamiento, y la brecha actual en el esquema de confirmación de comodines pertenece a la lista de verificación de un evaluador.

Cómo evaluar un servidor MCP para el trabajo de identidad

Antes de conectar cualquier servicio de identidad o fraude a Claude, verifique lo siguiente:

• Transporte: ¿Existe un punto final remoto documentado que utilice un transporte MCP actual?
• Autenticación: ¿El acceso representa a un usuario a través de OAuth, o depende de una credencial con amplios privilegios copiada en la configuración?
• Autorización: ¿Se aplican los roles de la organización por el backend en cada llamada?
• Esquemas: ¿Las herramientas definen entradas restringidas, acciones permitidas y errores útiles?
• Metadatos de riesgo: ¿Puede el cliente distinguir lecturas, escrituras, operaciones destructivas y llamadas que afectan a sistemas externos?
• Manejo de datos: ¿Se redactan los secretos y los datos personales innecesarios de los resultados y errores de las herramientas?
• Límites: ¿El proveedor establece lo que el modelo no puede hacer y dónde sigue siendo necesaria la revisión de cumplimiento humana?
• Inspectabilidad: ¿Puede su equipo revisar la fuente y una referencia de herramientas mantenida?

Didit publica su implementación en el repositorio público de GitHub con licencia MIT y documenta la arquitectura en la descripción general de MCP y la guía de autenticación. El código base v5 está marcado como privado para la publicación de paquetes y no se distribuye a través de npm. Para Claude, la ruta prevista es el punto final alojado y su flujo de autorización basado en navegador.

Cuando el conector de Claude es una buena opción

El conector es más fuerte cuando un humano quiere que Claude investigue, coordine o ejecute operaciones limitadas en un espacio de trabajo Didit existente: revisar decisiones recientes, crear un enlace de verificación alojado, ejecutar detecciones sin imágenes, inspeccionar una cola de casos, comparar flujos de trabajo o resumir la actividad en las aplicaciones. También es útil para desarrolladores que exploran esquemas antes de implementar una integración de backend. Las comprobaciones de imagen independientes necesitan el acceso a archivos del lado del servidor descrito anteriormente.

No es un reemplazo para el código de producción determinista donde su aplicación debe activar la misma operación en cada solicitud sin un usuario conversacional. En ese caso, use las API REST (Representational State Transfer) y los kits de desarrollo de software de Didit. MCP y REST sirven a diferentes interlocutores: uno delega el trabajo de una persona que ha iniciado sesión a un cliente de IA; el otro conecta la lógica de la aplicación directamente al servicio.

La economía es la misma, independientemente de la interfaz que inicie una verificación. El servidor MCP en sí es gratuito. Un paquete completo de KYC — verificación de documentos de identidad, prueba de vida pasiva, coincidencia facial y análisis de Protocolo de Internet (IP) — cuesta $0.33. Cada función incluye 500 verificaciones gratuitas por mes. Didit es compatible con más de 2,000 empresas en producción en más de 220 países y territorios, más de 14,000 tipos de documentos y más de 48 idiomas.

Conecte Didit a Claude

Si el modelo de autorización y seguridad se ajusta a su caso de uso, agregue el conector personalizado de Didit a Claude. El conector apunta al punto final HTTP Streamable alojado e inicia el flujo de inicio de sesión de Didit.

Para conocer los pasos exactos de Claude Desktop y Claude Code, utilice la guía de instalación dedicada. Para el contexto del producto y ejemplos adicionales, visite la página de desarrolladores de Didit MCP.

El veredicto conciso es este: un servidor MCP de verificación de identidad vale la pena usarlo con Claude cuando convierte las operaciones de identidad y fraude en acciones tipadas y conscientes de los permisos sin debilitar los controles que las rodean. El recuento de herramientas hace que la conexión sea útil; OAuth, la aplicación de roles, la redacción, los esquemas precisos y las comprobaciones de eliminación de comodines estrictamente aplicadas hacen que su modelo de riesgo sea inspeccionable.