> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Exemplos do MCP da Didit: prompts e conversas com agentes

> Prompts e conversas de agentes com o MCP da Didit: fluxo e sessão de KYC, busca KYB em registros, fila de revisão, back-test de regras e webhook.

Alguns padrões que mostram em que o MCP da Didit se destaca. Formule as solicitações em linguagem simples: o agente escolhe as ferramentas. Todas as ferramentas citadas abaixo existem na [referência de ferramentas](https://docs.didit.me/pt-br/integration/mcp/tools.md).

***

## Prompts rápidos

**Operações e monitoramento (entre aplicações)**

* *"Mostre as últimas 5 sessões em revisão de todas as minhas aplicações."* → `didit_session_search` com `status: "In Review"`, `limit: 5`
* *"Quantas pessoas tentaram a verificação de telefone, mas abandonaram nos últimos 15 dias?"* → `didit_analytics` com `last_n_days: 15` (uma única chamada; lê o funil do recurso)
* *"Encontre o cliente com vendor\_data `user_8842` e me diga a qual aplicação está associado e qual é o status."* → `didit_vendor_user_search`
* *"Qual é o meu saldo de créditos e a taxa de conversão deste mês?"* → `didit_org_get_balance` + `didit_analytics`

**Configuração**

* *"Crie um fluxo de verificação (workflow) de KYC com leitura de documento + prova de vida e me dê um link de verificação."* → `didit_workflow_create` → `didit_session_create`
* *"Crie um fluxo de verificação de identidade que aceite apenas passaportes, seguido de uma prova de vida por selfie."* → `didit_workflow_create`: basta dizer `documents_allowed: ["PASSPORT"]`; o MCP expande isso para aceitar somente passaportes em todos os países (consulte [Avançado → configurações de recursos](https://docs.didit.me/pt-br/integration/mcp/advanced.md#configurações-de-recursos-e-listas-de-permissões)).
* *"Novo fluxo: ler um passaporte; se o documento for recusado, recusar a sessão; se a profissão informada for ≈ 'Software Engineer' (≥60%), fazer uma prova de vida; caso contrário, pedir um comprovante de endereço em espanhol; depois, decidir automaticamente."* → `didit_workflow_get_field_definitions` → `didit_workflow_validate_graph` → `didit_workflow_set_graph`
* *"No fluxo `26d33c04…`, depois da verificação de identidade: se for recusada, recusar a sessão; se a profissão for ≥80% semelhante a 'Software Engineer', adicionar uma etapa de Document-AI para comprovante de fundos; depois, continuar."* → `didit_workflow_search` → `didit_workflow_get_graph` → `didit_workflow_edit_graph` (operações pequenas, salvas como um rascunho revisável)
* *"Em quais países posso oferecer login com BankID ou MitID em vez da leitura de um documento?"* → `didit_workflow_get_id_verification_methods_catalog`
* *"Registre um destino do webhook para atualizações de status em `https://myapp.com/webhooks/didit`."* → `didit_webhook_create`

**Conformidade**

* *"Faça a triagem AML desta carteira e adicione-a à lista de bloqueio se houver correspondência."* → `didit_transaction_screen_wallet` → `didit_blocklist_add`
* *"Abra um caso para a sessão `…` e atribua-o a mim."* → `didit_case_create` → `didit_case_manage`
* *"A Acme Ltd é uma empresa registrada no Reino Unido? Quem são os acionistas?"* → `didit_verify_kyb_search` → `didit_verify_kyb_select`

***

## 1. Colocar a verificação no ar

> **Você:** "Configure a verificação de identidade da Didit na minha aplicação com leitura de documento e prova de vida, e me dê um link para eu testar."
>
> **Agente:** Primeiro vou criar o fluxo. *(chama `didit_workflow_create` com `workflow_label: "Standard KYC"`, `features: [{ "feature": "OCR" }, { "feature": "LIVENESS" }]`)*: publiquei **"Standard KYC"**, `workflow_id = 6f2c…`. Agora, uma sessão para testar. *(chama `didit_session_create` com `workflow_id: "6f2c…"`, `vendor_data: "test-user-1"`)*: aqui está o seu link: `https://verify.didit.me/session/…`. Abra-o no celular para percorrer o fluxo. Em produção, o seu backend cria as sessões com a API REST:
>
> ```bash theme={null}
> curl -X POST https://verification.didit.me/v3/session/ \
>   -H "x-api-key: $DIDIT_API_KEY" \
>   -H "Content-Type: application/json" \
>   -d '{ "workflow_id": "6f2c...", "vendor_data": "internal-user-id", "callback": "https://myapp.com/done" }'
> ```
>
> Esse `x-api-key` é a **chave de API REST** da sua aplicação, usada pelo seu backend; ela é independente da forma como você entrou neste MCP, que usa *Log in with Didit*. Quer que eu registre também o destino do webhook?
>
> **Você:** "Sim, o meu endpoint é `https://myapp.com/webhooks/didit`."
>
> **Agente:** *(chama `didit_webhook_create` com `label: "Production"`, `url: "https://myapp.com/webhooks/didit"`, `webhook_version: "v3"`, `subscribed_events: ["status.updated"]`)*: pronto. O segredo de assinatura vem ocultado na resposta que recebo, então copie-o em **Webhooks** no console e guarde-o como `DIDIT_WEBHOOK_SECRET`. Verifique o cabeçalho `X-Signature-V2` de cada entrega antes de confiar nela.

***

## 2. KYB: verificar uma empresa no registro de empresas

> **Você:** "A Acme Trading Ltd é uma empresa real do Reino Unido? Tenho o número de registro 12345678."
>
> **Agente:** *(chama `didit_verify_kyb_search` com `country_code: "GB"`, `name: "Acme Trading Ltd"`, `registration_number: "12345678"`)*: um candidato: **ACME TRADING LTD**, constituída em 2019, status *ativo*, sede registrada em Manchester. Quer o registro completo, com administradores e acionistas?
>
> **Você:** "Sim, e me diga quem são os beneficiários finais."
>
> **Agente:** *(chama `didit_verify_kyb_select` com o `kyb_response_id` do candidato)*: registro completo obtido: dois diretores e uma pessoa com controle significativo que detém 75%+ das ações e dos direitos de voto. O registro inclui o histórico de arquivamentos e o endereço registrado. Esta foi uma consulta cobrada ao registro de empresas (duas chamadas que consomem créditos). Se quiser que isso aconteça automaticamente para todo cliente empresarial, posso adicionar `KYB_REGISTRY` a um fluxo de KYB com `didit_workflow_create`; `didit_workflow_get_kyb_registry_catalog` nos informa quais níveis de dados o registro do Reino Unido vende.

***

## 3. Processe a fila de revisão

> **Você:** "O que está aguardando minha revisão e qual é o problema de cada uma?"
>
> **Agente:** *(chama `didit_session_search` com `status: "In Review"`, `limit: 10`)*: quatro sessões em duas aplicações estão em revisão. Vou ler cada decisão. *(chama `didit_session_get_decision` para cada `session_id`)*
>
> | Sessão | Aplicação | Por que parou |
> | - | - | - |
> | `a1f3…` | Onboarding | Pontuação de correspondência facial 71 (limiar 80), prova de vida aprovada |
> | `b7c2…` | Onboarding | Documento expirado há 2 meses |
> | `c904…` | Marketplace | AML: uma correspondência com PEP, correspondência de nome de 92%, data de nascimento diferente |
> | `d215…` | Marketplace | Comprovante de endereço com mais de 90 dias |
>
> **Você:** "Aprove `a1f3`: conferi a selfie e é a mesma pessoa. Recuse `b7c2`, documento expirado."
>
> **Agente:** *(chama `didit_session_update_status` com `session_id: "a1f3…"`, `new_status: "Approved"` e depois com `session_id: "b7c2…"`, `new_status: "Declined"`, `comment: "Expired document"`)*: as duas foram atualizadas. *(chama `didit_session_add_review` em `a1f3…` com a nota "Manual selfie review: same person")*: nota de revisão adicionada para que o registro de auditoria mostre por que a pontuação foi ignorada. Os dois casos de AML e de comprovante de endereço continuam abertos; é só pedir, e eu abro um caso para o resultado PEP com `didit_case_create`.

***

## 4. Teste uma regra de transação retrospectivamente antes de ativá-la

> **Você:** "Quero sinalizar quem fizer mais de 3 transferências acima de \$1,000 em uma hora. Quantos alertas isso geraria?"
>
> **Agente:** *(chama `didit_transaction_rule_backtest` com `conditions` sobre `amount > 1000`, uma `aggregation` de contagem ≥ 3 em uma janela de 1 hora, `period_days: 90`)*: Nos últimos 90 dias, essa regra teria disparado em 14 transações de 6 titulares; 2 desses titulares já estão sinalizados. Quer que eu a crie no modo `TEST`, para que ela registre as correspondências sem executar nenhuma ação?
>
> **Você:** "Sim, modo TEST."
>
> **Agente:** *(chama `didit_transaction_rule_create` com `title: "Velocity: 3+ transfers over $1,000 per hour"`, `category: "aml_ctf"`, `mode: "TEST"`, as mesmas `conditions` e `aggregation` e uma lista de `actions` que sinaliza o titular)*: regra criada. Acompanhe-a com `didit_transaction_rule_get` depois de alguns dias; quando estiver satisfeito, `didit_transaction_rule_update` muda o `mode` para `ACTIVE`. `didit_transaction_rule_library_list` também traz as regras de velocidade predefinidas da Didit, caso você prefira instalar uma delas.

***

## Os resultados da sessão são assíncronos

`didit_session_create` retorna um `session_id`, um `session_token` e uma `url` hospedada, mas a verificação ainda não aconteceu. O usuário abre a `url` e conclui o fluxo. A decisão final chega por meio de:

1. Um **webhook** `status.updated` (recomendado), ou
2. `didit_session_get_decision` (polling, como alternativa).

Os dois têm o mesmo formato: **sempre arrays no plural**, com um `node_id` por entrada:

```json theme={null}
{
  "session_id": "uuid",
  "status": "Approved",
  "session_kind": "user",
  "id_verifications":  [ { "node_id": "first_id", "status": "Approved", "first_name": "Jane" } ],
  "liveness_checks":   [ { "node_id": "first_liveness", "status": "Approved", "score": 95.4 } ],
  "face_matches":      [ { "node_id": "first_face_match", "status": "Approved", "score": 96.1 } ],
  "aml_screenings":    [ { "node_id": "first_aml", "status": "Approved", "total_hits": 0, "hits": [] } ],
  "reviews": []
}
```

Nunca leia as chaves V2 no singular (`id_verification`, `liveness`): elas só são enviadas quando um destino está explicitamente configurado com `webhook_version: "V2"`. Consulte [Modelos de dados](https://docs.didit.me/pt-br/reference/data-models.md) para a referência de campos de cada recurso e [Avançado → Webhooks](https://docs.didit.me/pt-br/integration/mcp/advanced.md#tratamento-de-webhooks) para as regras de verificação e de novas tentativas.

***

## Combine-o com a integração de um único prompt

O MCP é ótimo para *operar* a Didit. Para que um agente *escreva* uma integração completa (rota de backend + SDK de frontend + handler de webhook + esquema de banco de dados), entregue a ele o [Prompt de integração](https://docs.didit.me/pt-br/integration/integration-prompt.md): ele percorre as sete etapas e chama ferramentas MCP para criar o fluxo de verificação (workflow), a sessão e o webhook em tempo real.

***

> [card] [Referência de ferramentas](https://docs.didit.me/pt-br/integration/mcp/tools.md)
>
> Tudo o que o agente pode chamar.

> [card] [Avançado e solução de problemas](https://docs.didit.me/pt-br/integration/mcp/advanced.md)
>
> Funções, comportamento entre aplicações, webhooks, auto-hospedagem.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.