docs: registra MCP ClinicAll Confirmação e confirmação de agenda via WhatsApp
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Gustavo
co-authored by
Claude Sonnet 5
Claude Sonnet 5
parent
97dff5cebb
commit
e791474d15
@@ -722,3 +722,81 @@ exemplo (lembrete proativo + AI Agent reativo) prontos pra ativar assim
|
|||||||
que houver uma clínica Klingo real com credencial `X-APP-TOKEN` e banco
|
que houver uma clínica Klingo real com credencial `X-APP-TOKEN` e banco
|
||||||
Postgres provisionado. Sem teste de ponta a ponta contra a API real —
|
Postgres provisionado. Sem teste de ponta a ponta contra a API real —
|
||||||
pendência explícita até então.
|
pendência explícita até então.
|
||||||
|
|
||||||
|
## 19. Confirmação de Agenda via WhatsApp (ClinicAll)
|
||||||
|
|
||||||
|
**Data:** 11/08/2026. Ver design completo em
|
||||||
|
`docs/superpowers/specs/2026-08-11-confirmacao-agenda-clinicall-design.md`
|
||||||
|
e plano em
|
||||||
|
`docs/superpowers/plans/2026-08-11-confirmacao-agenda-clinicall.md`.
|
||||||
|
|
||||||
|
**Motivação**: mesmo objetivo da seção 18 (Klingo), agora para o
|
||||||
|
ClinicAll — permitir que o paciente confirme presença numa consulta
|
||||||
|
via WhatsApp. Diferente do Klingo, o ClinicAll não tem uma API de
|
||||||
|
"Telefonia" separada: os endpoints de confirmação fazem parte do mesmo
|
||||||
|
`TCalendarController`/`TDomainController` já usado no MVP de
|
||||||
|
agendamento (seção 14.3), verificados diretamente no manual oficial
|
||||||
|
(`docs/API Clinicall.pdf`, v1.1.16, relido nesta sessão).
|
||||||
|
|
||||||
|
**MCP Server "ClinicAll - Confirmação de Agenda"** (`lHU5H0cZP4BJ6dWp`) — 5 tools:
|
||||||
|
|
||||||
|
| Tool | Endpoint | Workflow id |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| `listar_agendamentos_do_dia` | `GET /TCalendarController/agendamento/<data>` | `9pudW1QzBMh7c4ve` |
|
||||||
|
| `buscar_agendamento_por_cpf` | `GET /TCalendarController/agendamentoSemPaciente` (cpf + dataNascimento) | `i7Dw7xJZPpSbV3Ak` |
|
||||||
|
| `confirmar_presenca` | `POST /TCalendarController/AgendamentoFlags` | `3mAkzfGwGeRSvWvO` |
|
||||||
|
| `consultar_estados_agenda` | `GET /TDomainController/estadoAgenda` | `EGX5whFSJX6ew50a` |
|
||||||
|
| `consultar_situacoes_agenda` | `GET /TDomainController/situacaoAgenda` | `YzFJ5evrw2bzJTGi` |
|
||||||
|
|
||||||
|
**Diferenças reais em relação ao Klingo** (mesma disciplina de não
|
||||||
|
generalizar padrões entre providers sem verificar):
|
||||||
|
|
||||||
|
- **Strings exatas em vez de código curto**: o Klingo aceita `status:
|
||||||
|
'C'/'S'/'N'` pra confirmar. O ClinicAll exige duas strings longas e
|
||||||
|
exatas (`estadoAgenda`, `situacaoAgenda` — ex.: `"CONFIRMADO PELA
|
||||||
|
TELEFONISTA"`, `"Agendado"`), documentadas só nas tabelas de domínio
|
||||||
|
— por isso `consultar_estados_agenda`/`consultar_situacoes_agenda`
|
||||||
|
são tools obrigatórias no fluxo, não apoio opcional.
|
||||||
|
- **CPF + data de nascimento, não só CPF**: `agendamentoSemPaciente`
|
||||||
|
exige os dois campos, diferente do `lista_ultimo_por_cpf` do Klingo.
|
||||||
|
- **Telefone aninhado**: no ClinicAll, o telefone do paciente vem em
|
||||||
|
`item.Paciente.telefoneCelular` (objeto aninhado), não um campo
|
||||||
|
direto do item como no Klingo (`item.celular`) — refletido na
|
||||||
|
extração de dados do workflow de lembrete.
|
||||||
|
- **Sem NPS nem consulta de bloqueios**: não documentados no manual do
|
||||||
|
ClinicAll para este módulo — ficaram fora, sem inventar.
|
||||||
|
- **Pendência não verificada**: o manual não esclarece se
|
||||||
|
`agendamentoSemPaciente` (`GET, POST`) espera os parâmetros como
|
||||||
|
query string ou body. Implementado como `GET` + query string, por
|
||||||
|
analogia com todos os outros GETs deste manual (nenhum usa body) —
|
||||||
|
suposição registrada, não testada contra a API real.
|
||||||
|
- **Mesma pendência de autenticação já registrada no MVP de
|
||||||
|
agendamento do ClinicAll**: `authentication: "none"` em todos os
|
||||||
|
nodes HTTP (não `httpHeaderAuth` como no Klingo) — o manual do
|
||||||
|
ClinicAll não documenta nenhum mecanismo de auth por requisição.
|
||||||
|
|
||||||
|
**Workflow proativo "Lembrete de Confirmação - ClinicAll (exemplo)"**
|
||||||
|
(`liBLpRUmbcnWk05V`): mesmo desenho do Klingo (cron 8h → lista amanhã →
|
||||||
|
loop → `enviar_texto` do MCP Mensageria ZPRO), com um filtro a mais —
|
||||||
|
descarta itens com `situacaoAgenda: "Livre"` (sem `idPaciente`/
|
||||||
|
`Paciente`) antes de montar a mensagem. Validado (0 erros), deixado
|
||||||
|
**inativo de propósito**.
|
||||||
|
|
||||||
|
**Workflow de exemplo "Confirmação de Agenda - GChat - ClinicAll+Z-PRO
|
||||||
|
(exemplo)"** (`ylc3Jcz239ra6XZK`): mesmo padrão do Klingo (webhook →
|
||||||
|
AI Agent → memória Postgres), `systemMessage` ajustado pra pedir CPF
|
||||||
|
**e** data de nascimento, e pra sempre consultar
|
||||||
|
`consultar_estados_agenda`/`consultar_situacoes_agenda` antes de
|
||||||
|
chamar `confirmar_presenca` (nunca inventar a string exata). Tools
|
||||||
|
conectadas via `MCP Client Tool`: `buscar_agendamento_por_cpf`,
|
||||||
|
`confirmar_presenca`, `consultar_estados_agenda`,
|
||||||
|
`consultar_situacoes_agenda` (`listar_agendamentos_do_dia` fica de
|
||||||
|
fora, só serve ao workflow proativo). Validado (0 erros), deixado
|
||||||
|
**inativo de propósito**.
|
||||||
|
|
||||||
|
**Resultado**: MCP Server de confirmação de agenda (ClinicAll)
|
||||||
|
completo e validado estruturalmente, junto com os dois workflows de
|
||||||
|
exemplo, prontos pra ativar quando houver clínica ClinicAll real —
|
||||||
|
falta resolver a autenticação (mesma pendência do MVP de agendamento),
|
||||||
|
preencher o `baseUrl` real, e provisionar banco Postgres + credencial
|
||||||
|
pro cliente.
|
||||||
|
|||||||
Reference in New Issue
Block a user