O Servidor MCP para Verificação de Identidade no Claude

Principais pontos

• Um servidor de Protocolo de Contexto do Modelo (MCP) para verificação de identidade fornece ao Claude ferramentas tipificadas para operações reais de identidade e fraude; não pede ao modelo para inventar um resultado de verificação.
• O servidor alojado da Didit expõe 115 ferramentas em https://mcp.didit.me/mcp através de HTTP (Hypertext Transfer Protocol) Streamable sem estado, apenas POST.
• O acesso utiliza OAuth (Open Authorization) 2.1 com PKCE (Proof Key for Code Exchange) e Registo Dinâmico de Cliente. Não existe modo de chave de interface de programação de aplicações (API) para o servidor alojado.
• O servidor atua como o utilizador com sessão iniciada em didit:management e didit:verification; as funções de organização existentes continuam a definir o que o Claude pode fazer.
• Respostas conhecidas que contêm credenciais são editadas e as cargas de erro são higienizadas. As anotações de ferramentas classificam comportamentos de leitura, escrita e destrutivos; a eliminação por "wildcard" tem uma verificação de confirmação do lado do "handler", mas o esquema publicitado atual não expõe esse campo de confirmação.
• A ligação MCP é gratuita. A utilização 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 funcionalidade.

Se está a avaliar um servidor MCP de verificação de identidade para Claude, a questão útil não é se o Claude pode chamar um "endpoint". É se a ligação dá ao modelo de inteligência artificial (IA) capacidade estruturada suficiente para completar trabalho real, preservando a autenticação, autorização, auditabilidade e controlo humano. É aí que as implementações diferem.

Este guia explica esse modelo de avaliação usando o conector Claude da Didit como exemplo concreto. Não repete deliberadamente 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 encontram-se na documentação e na fonte pública.

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

MCP é um protocolo para dar ferramentas a um modelo. Um servidor MCP publica operações nomeadas com descrições e esquemas de entrada tipificados. Um cliente MCP como o Claude descobre essas operações, permite que o modelo selecione uma, valida os seus argumentos e transporta o resultado de volta 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 conhecimento geral quando solicitado a verificar um cliente, o Claude pode criar uma sessão de verificação real, recuperar a sua decisão, executar uma verificação de triagem ou inspecionar os fluxos de trabalho configurados de uma organização. Os dados devolvidos 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, e não transfere a responsabilidade de conformidade para o modelo. Ele dá ao modelo uma rota governada para o sistema que executa as verificações e regista 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 tipificadas que um cliente de IA pode descobrir e invocar.

O que o servidor da Didit permite dentro do Claude

A Didit é uma infraestrutura para identidade e fraude. O seu catálogo MCP alojado dá ao Claude 115 ferramentas abrangendo 19 domínios a nível de máquina. O objetivo não é apenas a contagem; é a gama de trabalho que o Claude pode conectar através de uma sessão autenticada.

Uma interação normal começa com didit_context_get, que devolve as organizações e aplicações a que o utilizador pode aceder. O Claude pode então escolher ferramentas que correspondam à 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 biométricas quando os seus ficheiros de imagem necessários existem no sistema de ficheiros do servidor MCP.
• didit_verify_aml executa a triagem de Anti-Lavagem de Dinheiro (AML).
• didit_verify_kyb_search e didit_verify_kyb_select suportam a descoberta de registos Know Your Business (KYB) e a seleção de registos.
• didit_transaction_create regista a atividade monitorizada, e didit_transaction_screen_wallet executa a triagem de carteiras 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 campos.
• didit_workflow_create e didit_workflow_edit_graph permitem que utilizadores autorizados componham fluxos de verificação; didit_webhook_create conecta eventos resultantes a sistemas a jusante.

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

O limite da imagem do Claude alojado

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 os seus "handlers" leem do próprio sistema de ficheiros do servidor MCP.

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

Para um candidato real a usar o Claude alojado, use didit_session_create, envie o url devolvido e, em seguida, recupere o resultado com didit_session_get_decision. O candidato captura a evidência configurada na experiência alojada da Didit; o Claude não faz o "staging" da imagem.

O limite de autenticação a avaliar

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

A propriedade de segurança material é a identidade resultante. As chamadas são executadas como o utilizador Didit com sessão iniciada 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 que o acesso pode ser revogado sem rodar uma credencial de aplicação de produção, que as ações permanecem atribuíveis a um utilizador e que o contexto multi-organização é 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.

A segurança é mais do que autenticação

A autenticação responde a quem está a ligar. 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 ferramentas com anotações de apenas leitura, escrita, destrutivas, idempotentes e de mundo aberto. Um cliente pode usar esses sinais para agrupar ou rotular operações, mas uma anotação é metadados descritivos. Não força automaticamente o modelo ou o servidor a solicitar confirmação.

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

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

Este modelo em camadas é preferível a depender de um "prompt" do sistema que apenas diz a um agente para "ter cuidado", mas os seus limites devem ser declarados com precisão. Funções de "backend", validação de entrada, edição direcionada, higienização de erros e a verificação do "handler" de eliminação por "wildcard" 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 por "wildcard" deve constar na lista de verificação de um 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 utilizador através de 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 consegue distinguir leituras, escritas, operações destrutivas e chamadas que afetam sistemas externos?
• Tratamento de dados: Os segredos e dados pessoais desnecessários são editados dos resultados das ferramentas e dos erros?
• Limites: O fornecedor declara o que o modelo não pode fazer e onde a revisão humana de conformidade continua a ser necessária?
• Inspecionabilidade: A sua equipa pode rever a fonte e uma referência de ferramentas mantida?

A Didit publica a sua implementação no repositório GitHub de licença MIT público e documenta a arquitetura na visão geral do MCP e no guia de autenticação. A "codebase" v5 é marcada como privada para publicação de pacotes e não é distribuída via npm. Para o Claude, o caminho pretendido é o "endpoint" alojado e o seu fluxo de autorização baseado em navegador.

Quando o conector Claude é uma boa opção

O conector é mais forte quando um humano quer que o Claude investigue, coordene ou execute operações limitadas num espaço de trabalho Didit existente: rever decisões recentes, criar um link de verificação alojado, executar triagens não baseadas em imagem, inspecionar uma fila de casos, comparar fluxos de trabalho ou resumir a atividade entre aplicações. Também é útil para programadores que exploram esquemas antes de implementar uma integração de "backend". As verificações de imagem autónomas precisam do acesso a ficheiros do lado do servidor descrito acima.

Não é um substituto para código de produção determinístico onde a sua aplicação deve acionar a mesma operação em cada pedido sem um utilizador conversacional. Nesse caso, use as APIs REST (Representational State Transfer) e "kits" de desenvolvimento de software da Didit. O MCP e o REST servem diferentes chamadores: um delega o trabalho de uma pessoa com sessão iniciada 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 próprio servidor MCP é gratuito. Um pacote KYC completo — verificação de documento de identidade, "liveness" passiva, "face match" e análise de IP (Internet Protocol) — custa 0,33 $. Cada funcionalidade inclui 500 verificações gratuitas por mês. A Didit apoia 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.

Conectar Didit ao Claude

Se o modelo de autorização e segurança se adequar ao seu caso de uso, adicione o conector personalizado Didit ao Claude. O conector aponta para o "endpoint" Streamable HTTP alojado e inicia o fluxo de início de sessão da Didit.

Para passos exatos do Claude Desktop e Claude Code, use o guia de instalação dedicado. Para contexto do produto e exemplos adicionais, visite a página de programadores Didit MCP.

O veredito conciso é este: um servidor MCP de verificação de identidade vale a pena usar com o Claude quando transforma operações de identidade e fraude em ações tipificadas e com reconhecimento de permissões, sem enfraquecer os controlos sobre elas. A contagem de ferramentas torna a ligação útil; OAuth, imposição de funções, edição, esquemas precisos e verificações de eliminação por "wildcard" estritamente aplicadas tornam o seu modelo de risco inspecionável.