Servidor MCP para Verificação de Identidade no Claude

Principais pontos

• Um servidor MCP (Model Context Protocol) de verificação de identidade fornece ao Claude ferramentas tipadas para operações reais de identidade e fraude; ele não pede ao modelo para inventar um resultado de verificação.
• O servidor hospedado da Didit expõe 115 ferramentas em https://mcp.didit.me/mcp sobre HTTP (Hypertext Transfer Protocol) Streamable sem estado, apenas POST.
• O acesso usa OAuth (Open Authorization) 2.1 com PKCE (Proof Key for Code Exchange) e Registro Dinâmico de Cliente. Não há modo de chave de API (application programming interface) para o servidor hospedado.
• O servidor atua como o usuário logado em didit:management e didit:verification; as funções existentes da organização continuam a definir o que o Claude pode fazer.
• Respostas conhecidas que contêm credenciais são anonimizadas e os payloads de erro são higienizados. As anotações de ferramentas classificam o comportamento de leitura, escrita e destrutivo; a exclusão curinga tem uma verificação de confirmação do lado do manipulador, mas o esquema anunciado atualmente não expõe esse campo de confirmação.
• A conexão MCP é gratuita. O uso mantém os preços publicados da Didit, incluindo um pacote completo de Know Your Customer (KYC) de $0.33 e 500 verificações gratuitas por mês para cada recurso.

Se você está avaliando um servidor MCP de verificação de identidade para Claude, a pergunta útil não é se o Claude pode chamar um endpoint. É se a conexão oferece ao modelo de inteligência artificial (IA) capacidade estruturada suficiente para concluir trabalhos reais, preservando autenticação, autorização, auditabilidade e controle humano. É aí que as implementações diferem.

Este guia explica esse modelo de avaliação usando o conector Claude da Didit como exemplo concreto. Ele deliberadamente não repete a configuração passo a passo coberta no guia de instalação do Claude, a visão geral da categoria na referência de ferramentas MCP, ou a sequência de sessão no guia de ciclo de vida da sessão KYC. Os esquemas canônicos e atuais estão na documentação e no código-fonte público.

O que é um servidor MCP de verificação de identidade?

MCP é um protocolo para fornecer ferramentas a um modelo. Um servidor MCP publica operações nomeadas com descrições e esquemas de entrada tipados. Um cliente MCP, como o Claude, descobre essas operações, permite que o modelo selecione uma, valida seus argumentos e retorna o resultado para a conversa.

Um servidor MCP de verificação de identidade aplica esse padrão ao trabalho regulamentado de identidade e fraude. Em vez de responder com base em conhecimento geral quando solicitado a verificar um cliente, o Claude pode criar uma sessão de verificação real, recuperar sua decisão, executar uma verificação de triagem ou inspecionar os fluxos de trabalho configurados de uma organização. Os dados retornados vêm do serviço conectado, não da memória do modelo.

Essa distinção é essencial. O MCP não torna um modelo de linguagem uma autoridade de identidade, nem transfere a responsabilidade de conformidade para o modelo. Ele oferece ao modelo uma rota governada para o sistema que executa as verificações e registra os resultados. O provedor de verificação permanece responsável pelo serviço; o cliente permanece responsável pela política e revisão; o Claude coordena as operações permitidas.

Uma definição útil: um servidor MCP de verificação de identidade é um adaptador com reconhecimento de autorização que expõe capacidades de identidade e fraude como ferramentas tipadas que um cliente de IA pode descobrir e invocar.

O que o servidor da Didit permite dentro do Claude

Didit é infraestrutura para identidade e fraude. Seu catálogo MCP hospedado oferece ao Claude 115 ferramentas que abrangem 19 domínios de nível de máquina. O objetivo não é apenas a contagem; é a gama de trabalho que o Claude pode conectar em uma única sessão autenticada.

Uma interação normal começa com didit_context_get, que retorna as organizações e aplicativos que o usuário pode acessar. O Claude pode então escolher as ferramentas que correspondem à tarefa:

• didit_session_create cria uma sessão de verificação a partir de um fluxo de trabalho configurado, enquanto didit_session_get_decision recupera a decisão resultante.
• didit_verify_id, didit_verify_passive_liveness e didit_verify_face_match executam verificações focadas de documentos e biometria quando os arquivos de imagem necessários existem no sistema de arquivos do servidor MCP.
• didit_verify_aml executa a triagem Anti-Money Laundering (AML).
• didit_verify_kyb_search e didit_verify_kyb_select suportam a descoberta de registro e a seleção de registros do Know Your Business (KYB).
• didit_transaction_create registra a atividade monitorada, e didit_transaction_screen_wallet executa a triagem de carteira Know Your Transaction (KYT).
• didit_case_create abre um caso de investigação, enquanto didit_case_manage suporta atribuição, comentários, escalonamento, reabertura, resolução e atualizações de campo.
• didit_workflow_create e didit_workflow_edit_graph permitem que usuários autorizados componham fluxos de verificação; didit_webhook_create conecta eventos resultantes a sistemas downstream.

Estes são exemplos, não um substituto para a documentação canônica das ferramentas MCP. O servidor atual expõe apenas ferramentas: ele não publica recursos MCP ou modelos de prompt. A configuração de conformidade especializada e os relatórios estatutários permanecem como fluxos de trabalho governados no Business Console, em vez de ações autônomas de chat.

O limite da imagem hospedada no Claude

Cinco ferramentas de imagem — didit_verify_id, didit_verify_age, didit_verify_face_match, didit_verify_passive_liveness e didit_lists_entry_upload_face — aceitam entradas de caminho absoluto que seus manipuladores leem do próprio sistema de arquivos do servidor MCP.

Uma imagem carregada no Claude hospedado, portanto, não está normalmente disponível para essas ferramentas: o conector não expõe nenhuma ferramenta de preparação de arquivos. Ver uma imagem no chat não é o mesmo que fornecer um front_image_path legível. As ferramentas são práticas em implantações locais ou auto-hospedadas onde os arquivos podem ser colocados no sistema de arquivos do servidor.

Para um candidato real usando o Claude hospedado, use didit_session_create, envie o url retornado e, em seguida, recupere o resultado com didit_session_get_decision. O candidato captura a evidência configurada na experiência hospedada da Didit; o Claude não prepara a imagem.

O limite de autenticação a ser avaliado

O endpoint hospedado é https://mcp.didit.me/mcp, usando HTTP Streamable sem estado, apenas POST. O Claude se conecta através do OAuth (Open Authorization) 2.1 com PKCE (Proof Key for Code Exchange) e Registro Dinâmico de Cliente; o servidor hospedado não possui modo de chave de API.

A propriedade de segurança material é a identidade resultante. As chamadas são executadas como o usuário Didit logado em didit:verification e didit:management, enquanto a função de backend da organização ainda determina quais operações são bem-sucedidas. Um Leitor não se torna um administrador porque o Claude selecionou uma ferramenta de escrita.

Para avaliação, confirme se o acesso pode ser revogado sem rotacionar uma credencial de aplicação de produção, se as ações permanecem atribuíveis a um usuário e se o contexto de múltiplas organizações é explícito. A sequência exata de descoberta, consentimento e configuração pertence ao guia de instalação do Claude e à documentação de autenticação.

Segurança é mais do que autenticação

A autenticação responde quem está chamando. Um servidor MCP de nível de produção também deve controlar o que o modelo vê e como as ações de risco prosseguem.

A Didit marca as ferramentas com anotações de somente leitura, escrita, destrutivas, idempotentes e de mundo aberto. Um cliente pode usar esses sinais para agrupar ou rotular operações, mas uma anotação é metadado descritivo. Ela não força automaticamente o modelo ou o servidor a solicitar confirmação.

A regra de confirmação é restrita. didit_session_delete exclui permanentemente uma sessão e requer apenas session_id. A exclusão em lote limitada com uma lista de identificadores explícita também não requer um campo de confirmação. O manipulador para uma exclusão curinga rejeita delete_all: true a menos que confirm: true também seja fornecido, mas o esquema de entrada de exclusão em lote anunciado atualmente omite confirm. Considere isso como um backstop do lado do manipulador com uma lacuna de esquema, não como um fluxo de aprovação completo visível ao cliente. As equipes devem adicionar sua própria política de aprovação humana para escritas consequentes em vez de assumir que uma anotação a impõe.

As saídas conhecidas que contêm credenciais são tratadas deliberadamente: os campos de credencial de aplicação e os metadados de segredo de assinatura de webhook são anonimizados, enquanto os payloads de erro são profundamente higienizados antes de retornar ao cliente. Isso não é uma promessa de que todos os campos em cada resposta de negócio bem-sucedida são globalmente removidos, então as equipes ainda devem minimizar os dados pessoais que pedem ao Claude para recuperar. A operação de revelação de credencial existe apenas no catálogo local/stdio completo, requer sua própria confirmação e é excluída do catálogo OAuth hospedado de 115 ferramentas. A operação de recarga de crédito também é excluída desse catálogo hospedado.

Este modelo em camadas é preferível a depender de um prompt de sistema que simplesmente diz a um agente para “ter cuidado”, mas seus limites devem ser declarados com precisão. Funções de backend, validação de entrada, anonimização direcionada, higienização de erros e a verificação do manipulador de exclusão curinga são imposição. As anotações de risco e as instruções de chat informam o comportamento, e a atual lacuna do esquema de confirmação curinga pertence a um checklist do avaliador.

Como avaliar um servidor MCP para trabalho de identidade

Antes de conectar qualquer serviço de identidade ou fraude ao Claude, verifique o seguinte:

• Transporte: Existe um endpoint remoto documentado usando um transporte MCP atual?
• Autenticação: O acesso representa um usuário através do OAuth, ou depende de uma credencial amplamente privilegiada copiada para a configuração?
• Autorização: As funções da organização são impostas pelo backend em cada chamada?
• Esquemas: As ferramentas definem entradas restritas, ações permitidas e erros úteis?
• Metadados de risco: O cliente pode distinguir leituras, escritas, operações destrutivas e chamadas que afetam sistemas externos?
• Tratamento de dados: Segredos e dados pessoais desnecessários são anonimizados dos resultados e erros da ferramenta?
• Limites: O provedor declara o que o modelo não pode fazer e onde a revisão de conformidade humana ainda é necessária?
• Inspecionabilidade: Sua equipe pode revisar o código-fonte e uma referência de ferramentas mantida?

A Didit publica sua implementação no repositório GitHub público licenciado pelo MIT e documenta a arquitetura na visão geral do MCP e no guia de autenticação. O código-base v5 é marcado como privado para publicação de pacotes e não é distribuído via npm. Para o Claude, o caminho pretendido é o endpoint hospedado e seu fluxo de autorização baseado em navegador.

Quando o conector Claude é uma boa opção

O conector é mais forte quando um humano deseja que o Claude investigue, coordene ou execute operações limitadas em um workspace Didit existente: revisar decisões recentes, criar um link de verificação hospedado, executar triagens sem imagem, inspecionar uma fila de casos, comparar fluxos de trabalho ou resumir atividades entre aplicativos. Também é útil para desenvolvedores que exploram esquemas antes de implementar uma integração de backend. Verificações de imagem autônomas precisam do acesso a arquivos do lado do servidor descrito acima.

Não é um substituto para código de produção determinístico onde sua aplicação deve acionar a mesma operação em cada solicitação sem um usuário conversacional. Nesse caso, use as APIs REST (Representational State Transfer) e os kits de desenvolvimento de software da Didit. MCP e REST atendem a diferentes chamadores: um delega o trabalho de uma pessoa logada a um cliente de IA; o outro conecta a lógica da aplicação diretamente ao serviço.

A economia é a mesma, independentemente da interface que inicia uma verificação. O servidor MCP em si é gratuito. Um pacote KYC completo — verificação de documento de identidade, prova de vida passiva, correspondência facial e análise de IP (Internet Protocol) — custa $0.33. Cada recurso inclui 500 verificações gratuitas por mês. A Didit suporta mais de 2.000 empresas em produção em mais de 220 países e territórios, mais de 14.000 tipos de documentos e mais de 48 idiomas.

Conecte a Didit ao Claude

Se o modelo de autorização e segurança se encaixa no seu caso de uso, adicione o conector personalizado da Didit ao Claude. O conector aponta para o endpoint HTTP Streamable hospedado e inicia o fluxo de login da Didit.

Para etapas exatas do Claude Desktop e Claude Code, use o guia de instalação dedicado. Para contexto do produto e exemplos adicionais, visite a página do desenvolvedor MCP da Didit.

O veredicto conciso é este: um servidor MCP de verificação de identidade vale a pena usar com o Claude quando ele transforma operações de identidade e fraude em ações tipadas e com reconhecimento de permissão, sem enfraquecer os controles sobre elas. A contagem de ferramentas torna a conexão útil; OAuth, imposição de função, anonimização, esquemas precisos e verificações de exclusão curinga estritamente aplicadas tornam seu modelo de risco inspecionável.