Verificação de Idade com Claude: Sessões Alojadas vs. Ficheiros Locais

Principais conclusões

• Um conector Claude alojado não pode enviar uma selfie ou uma foto de documento de identidade para didit_verify_age ou didit_verify_id a partir do dispositivo do utilizador. Essas ferramentas leem caminhos absolutos na máquina que executa o servidor Model Context Protocol (MCP).
• O caminho alojado correto é baseado em sessão: crie uma sessão para um fluxo de trabalho existente, forneça à pessoa o url retornado e recupere a decisão concluída com didit_session_get_decision.
• Um fluxo de trabalho pode incluir estimativa de idade facial, que estima a idade, ou verificação de documentos, que extrai a data de nascimento e outros campos do documento. Estes são diferentes níveis de evidência.
• As ferramentas de caminho de ficheiro continuam úteis para implementações stdio locais ou autoalojadas onde o servidor MCP e o ficheiro de imagem estão na mesma máquina.
• O endpoint MCP alojado da Didit expõe 115 ferramentas. O servidor é gratuito e o nível gratuito oferece 500 verificações gratuitas por mês.

“Verificar a idade desta pessoa a partir do Claude” soa como uma única chamada de ferramenta. A integração real tem um limite importante: onde reside a imagem? Isso determina se o Claude deve criar uma sessão de verificação alojada ou chamar uma ferramenta de imagem autónoma.

A página de programadores MCP e o repositório público do GitHub da Didit descrevem o servidor que conecta o Claude a verificações de identidade e fraude. Para garantia de idade, a rota de sessão alojada é a escolha prática para uma pessoa real que usa o Claude remotamente. A rota de caminho de imagem autónoma foi projetada para ambientes locais ou autoalojados com acesso direto ao sistema de ficheiros.

O limite do sistema de ficheiros que a maioria dos exemplos de MCP ignora

A ferramenta autónoma didit_verify_age aceita um image_path absoluto. didit_verify_id aceita de forma semelhante um front_image_path absoluto e um back_image_path opcional. Dentro do servidor MCP, esses caminhos são validados e lidos do disco antes que os ficheiros sejam enviados.

Isso é simples numa implementação stdio local. Se o Claude Desktop e um servidor Didit MCP autoalojado forem executados na mesma estação de trabalho, um caminho como /Users/example/checks/selfie.jpg pode referir-se a um ficheiro real disponível para o processo do servidor. A mesma ideia funciona num servidor interno controlado quando a aplicação já colocou o ficheiro num diretório local permitido.

Não funciona da mesma forma com o endpoint alojado. Quando o Claude chama https://mcp.didit.me/mcp, um caminho absoluto refere-se ao sistema de ficheiros do servidor da Didit, não ao portátil ou telemóvel do utilizador do Claude. Digitar um caminho local no Claude alojado não carrega esse ficheiro. Um utilizador remoto, portanto, não pode fornecer uma selfie ou foto de documento à ferramenta alojada apenas nomeando um caminho.

Esta não é uma limitação da própria estimativa de idade. É uma distinção de transporte e sistema de ficheiros. Para utilizadores alojados, a Didit resolve a entrega com uma sessão de verificação e um URL voltado para o utilizador.

O fluxo do Claude alojado que funciona

Primeiro, a organização precisa de um fluxo de trabalho existente configurado na Consola Empresarial da Didit. Esse fluxo de trabalho define as verificações que a pessoa irá concluir. Um fluxo de trabalho de garantia de idade pode incluir estimativa de idade facial, verificação de documentos com extração da data de nascimento ou uma sequência mais ampla de Conheça o Seu Cliente (KYC).

O Claude então chama didit_session_create. O único input necessário é workflow_id; a ferramenta não aceita uma “configuração de fluxo de trabalho” inline. Os inputs opcionais incluem a referência do utilizador da troca ou aplicação em vendor_data, um callback de redirecionamento e um language da IU.

Use didit_session_create com:
{
  "workflow_id": "<uuid-de-fluxo-de-trabalho-existente>",
  "vendor_data": "user_18427",
  "callback": "https://example.com/age-check/complete",
  "language": "en"
}

Retorne o URL da sessão ao utilizador. Não lhes peça um caminho de imagem local.

A resposta contém session_id, url e session_token. O Claude fornece à pessoa o url retornado. A pessoa abre a IU de verificação alojada da Didit no seu próprio dispositivo e conclui os passos de captura definidos pelo fluxo de trabalho. A transferência da imagem ocorre nessa IU, em vez de através de um caminho digitado no chat.

Após a conclusão, o Claude chama didit_session_get_decision com o ID da sessão retornado:

Use didit_session_get_decision com:
{
  "session_id": "<uuid-da-sessão-de-criação>"
}

Resuma a decisão da sessão e apenas os campos extraídos retornados pelo fluxo de trabalho.

A ferramenta retorna a decisão de verificação completa e todos os dados extraídos para essa sessão. Os dados exatos dependem do fluxo de trabalho. A fonte do MCP não documenta um atalho booleano separado para o limite de idade. Para verificações de documentos, a decisão pode incluir os dados estruturados do documento retornados pelos passos de verificação configurados; o agente deve ler a resposta real em vez de inventar um campo de conveniência.

O que as ferramentas de imagem locais realmente fazem

Numa configuração stdio local ou autoalojada, as ferramentas autónomas podem ser um caminho direto para trabalhos em lote, utilitários de revisão interna ou aplicações que já controlam a ingestão de imagens.

Estimativa de idade facial

didit_verify_age requer image_path e aceita opcionalmente vendor_data. Estima a idade de uma pessoa a partir de uma imagem facial e também realiza uma verificação de vivacidade passiva. Uma estimativa não é prova de uma data de nascimento ou identidade exata.

# Apenas stdio local ou autoalojado
# O ficheiro deve existir no sistema de ficheiros do servidor MCP.
didit_verify_age {
  "image_path": "/caminho/absoluto/do/servidor/selfie.jpg",
  "vendor_data": "user_18427"
}

A estimativa de idade tem um preço de 0,10 $ por verificação. O input ainda é uma imagem facial e o serviço processa essa imagem para produzir o resultado. Descrever o método como sem documentos é preciso; descrevê-lo como não recolhendo dados pessoais ou não armazenando nada não é suportado pelo contrato da ferramenta MCP.

Extração de data de nascimento baseada em documentos

didit_verify_id requer front_image_path. Também pode receber back_image_path, minimum_age e outras opções documentadas. A ferramenta envia a imagem do documento de identidade, realiza o reconhecimento ótico de caracteres (OCR) e retorna dados estruturados do documento e verificações de autenticidade. O OCR pode extrair a data de nascimento juntamente com outros campos presentes no documento.

# Apenas stdio local ou autoalojado
didit_verify_id {
  "front_image_path": "/caminho/absoluto/do/servidor/id-frente.jpg",
  "back_image_path": "/caminho/absoluto/do/servidor/id-verso.jpg",
  "minimum_age": 18,
  "vendor_data": "user_18427"
}

A fonte descreve minimum_age como recusando a verificação quando a idade extraída é inferior ao valor fornecido. O agente deve ler a decisão retornada em vez de esperar um campo de resultado de limite extra. A verificação de ID custa 0,15 $ por verificação. Como a imagem completa do documento é enviada e os campos do documento são extraídos, esta rota não deve ser apresentada como recolhendo apenas uma data de nascimento.

Estimativa de idade, verificações de documentos e KYC completo não são intermutáveis

Rota	O que estabelece	Caminho do Claude alojado	Preço publicado
Estimativa de idade facial	Uma idade estimada a partir de uma imagem facial, mais vivacidade passiva	Use uma sessão alojada cujo fluxo de trabalho inclua estimativa de idade	0,10 $ por verificação
Verificação de ID	Verificações de autenticidade de documentos e campos de documentos extraídos, incluindo data de nascimento quando presente	Use uma sessão alojada cujo fluxo de trabalho inclua verificação de documentos	0,15 $ por verificação
KYC completo	Verificações de identidade configuradas combinando Verificação de ID, Vivacidade Passiva, Correspondência Facial e Análise de IP	Crie uma sessão para o fluxo de trabalho KYC existente e entregue o URL	0,33 $ por pacote

A primeira rota estima. A segunda baseia-se num documento emitido pelo governo enviado. A terceira combina várias verificações numa decisão de identidade mais ampla. As equipas de produto podem distinguir estes níveis de evidência sem alegar que qualquer mecanismo satisfaz automaticamente uma lei ou regulador.

O panorama regulatório é específico do método

As regras de garantia de idade diferem por jurisdição, tipo de serviço, conteúdo e risco. No Reino Unido, as orientações de garantia de idade da Lei de Segurança Online da Ofcom discutem vários métodos que podem ser altamente eficazes, incluindo estimativa de idade facial e correspondência de foto-identificação, enquanto avaliam a eficácia em relação a critérios como precisão, resistência à evasão, fiabilidade e imparcialidade. Na União Europeia, a visão geral da Diretiva de Serviços de Mídia Audiovisual da Comissão Europeia descreve medidas de proteção de menores que podem incluir PINs ou sistemas mais sofisticados de verificação de idade.

Essas fontes ilustram por que a linguagem de implementação é importante: “garantia de idade”, “estimativa de idade”, “verificação de documentos” e “verificação de identidade” estão relacionadas, mas não são sinónimos. Se um método específico se adapta a um serviço específico é uma avaliação específica da jurisdição e do contexto. A integração do MCP fornece as rotas técnicas; não faz essa avaliação para o operador.

Conecte o Claude sem borrar o limite

Use o link direto do conector Didit para o Claude alojado. O endpoint usa OAuth 2.1 com Proof Key for Code Exchange (PKCE). A visão geral do MCP, o guia de autenticação e a referência de ferramentas cobrem a conexão e a descoberta.

Para o padrão de sessão mais amplo, leia Verificação de Identidade KYC sobre MCP. Para uma visão ao nível do catálogo da integração, consulte a referência de ferramentas Didit MCP.

A regra prática é simples: o Claude alojado deve criar uma sessão e entregar à pessoa o seu URL; o stdio local ou autoalojado pode usar caminhos de imagem absolutos quando o servidor realmente tem esses ficheiros. Manter esse limite explícito torna os pedidos de garantia de idade precisos, executáveis e seguros para reutilização.