KLINGO-CLINICAL-SYSLIFE-GCHAT/docs/n8n-agendamento-runbook.md

Runbook — Workflow de Agendamento no n8n (GChat/Z-PRO + gti-scheduling-mcp)

Registra problemas reais encontrados ao montar o workflow Agendamento - GChat - Z-PRO (clínica exemplo) (id yG2mi6ECBpPv4Hmn, servidor srvdevn8ngti / devn8n.gtigrupo.com.br), e como foram resolvidos — para não repetir o mesmo processo de descoberta ao duplicar este workflow para uma nova clínica. Ver também docs/superpowers/specs/2026-08-10-n8n-agendamento-workflow-design.md (design) e docs/superpowers/plans/2026-08-10-n8n-agendamento-workflow.md (plano).

1. Node MCP: qual usar e como instalar

• O node oficial do n8n (MCP Client Tool, @n8n/n8n-nodes-langchain) só conecta em MCP remoto via HTTP Streamable/SSE — não roda comando local (stdio). Para rodar o gti-scheduling-mcp como subprocesso local, use o pacote comunitário n8n-nodes-mcp (autor nerding-io).
• Instalação: Settings → Community Nodes → Install a community node → n8n-nodes-mcp.
• Ao conectar como tool de um AI Agent, o tipo do node no JSON do workflow precisa ser n8n-nodes-mcp.mcpClientTool (não n8n-nodes-mcp.mcpClient) — é uma variante "Tool" que o n8n gera automaticamente para nodes marcados como usáveis em AI Agents. Usar mcpClient na conexão ai_tool falha a validação com "cannot output ai_tool connections".
• É necessário setar a variável de ambiente do processo do n8n (não é configurável pela UI):

  N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE=true
  

  Nesse servidor, o n8n roda via systemd (n8n.service), com EnvironmentFile=/opt/n8n.env. A variável foi adicionada nesse arquivo, seguido de systemctl restart n8n. (Se o n8n rodasse em Docker, seria em environment: no docker-compose.yml.)

2. Credencial MCP (STDIO) — dois bugs reais

Tipo de credencial: mcpClientApi ("MCP Client (STDIO) API"), campos: command, args, environments.

• Bug 1 — command: "node" sozinho falhou com "Connection closed". O serviço systemd tem um PATH mais restrito que um shell interativo. Fix: usar o caminho absoluto (which node no servidor → /usr/bin/node).

• Bug 2 — o campo "Environments" é um <input> de uma linha só (mascarado como senha) na UI do n8n. O código real do node (nodes/McpClient/McpClient.node.ts no pacote n8n-nodes-mcp) espera o formato NOME=VALOR separado por quebra de linha real (split('\n')), mas navegadores removem quebras de linha ao digitar OU colar em campos de uma linha — então múltiplas variáveis nunca conseguem ser inseridas corretamente pela UI (tentamos: uma por linha, vírgula, espaço — todas colapsam a mesma forma, e a primeira variável acaba recebendo o resto do texto como valor, quebrando a validação).

  Fix: criar/recriar a credencial via API REST do n8n, que aceita o JSON com \n de verdade (não passa pelo campo quebrado da UI):

  # 1. Gerar uma API key: Settings → n8n API → Create an API key
  # 2. DELETE na credencial antiga (se existir), depois POST na nova:
  curl -X POST "https://devn8n.gtigrupo.com.br/api/v1/credentials" \
    -H "X-N8N-API-KEY: <chave>" \
    -H "Content-Type: application/json" \
    -d '{
      "name": "Client (STDIO) account",
      "type": "mcpClientApi",
      "data": {
        "command": "/usr/bin/node",
        "args": "/opt/gti-scheduling-mcp/dist/index.js",
        "environments": "SCHEDULING_PROVIDER=zpro\nZPRO_BASE_URL=https://...\nZPRO_API_TOKEN=...\nZPRO_API_ID=..."
      }
    }'
  

  Sintoma quando esse bug está presente: o log do n8n (journalctl -u n8n -f) mostra exatamente a mensagem de erro do gti-scheduling-mcp (Falha ao carregar a configuração: SCHEDULING_PROVIDER deve ser "zpro" ou "klingo".), seguida de MCP error -32000: Connection closed — o processo sobe e cai na validação de config antes de completar o handshake stdio.

3. Deploy do gti-scheduling-mcp no servidor do n8n

O node dist/index.js executado pela credencial precisa estar no mesmo host onde o n8n roda (o node comunitário spawna o processo localmente). Processo usado (sem repositório git configurado ainda neste projeto): tar local (excluindo node_modules/dist) → scp pro servidor → npm install && npm run build lá. Publicado em /opt/gti-scheduling-mcp.

4. Modelo de IA (OpenAI Chat Model node) — gotchas de configuração

Mesmo usando um provider "compatível com OpenAI" (ex.: Z.ai/GLM), o node OpenAI Chat Model (@n8n/n8n-nodes-langchain.lmChatOpenAi, v1.3) tem comportamento por padrão que quebra com endpoints não-OpenAI:

• responsesApiEnabled é true por padrão nessa versão — usa a "Responses API" da OpenAI (/responses), um endpoint proprietário que providers OpenAI-compatíveis geralmente não implementam (eles só têm /chat/completions). Sintoma: 404 Not Found / MODEL_NOT_FOUND. Fix: setar responsesApiEnabled: false explicitamente.
• Campo model é um resourceLocator — precisa de {mode: "id", value: "nome-do-modelo"} explícito. Omitir mode pode fazer o n8n tentar listar modelos via uma chamada de API (GET /models) que o provider alternativo pode não suportar do mesmo jeito, gerando erro parecido com o anterior.
• Base URL da credencial: o campo correto na credencial openAiApi é url (aparece como "Base URL" na UI, geralmente atrás de "Add Option").

5. Expressões em sub-nodes de IA (Memory/Tools) dentro do AI Agent

Dentro de nodes conectados via ai_memory/ai_tool/ai_languageModel (sub-nodes do AI Agent), referenciar um node upstream explicitamente (={{ $('Normalizar entrada').item.json.sessionId }}) falhou com "Key parameter is empty" — mesmo com o dado presente no item que chegou no AI Agent. Fix: usar ={{ $json.sessionId }} (referência ao item atual, sem nome de node) — é o padrão que o próprio n8n usa por padrão nesse campo, e funciona porque sub-nodes de IA herdam o item do node pai (AI Agent) na execução.

6. Contrato do webhook do Z-PRO/GChat (verificado, não documentado

oficialmente em lugar nenhum)

• Uma execução do workflow por mensagem do cliente — o Z-PRO não enfileira mensagens seguintes se o workflow não responder imediatamente.
• Corpo recebido: {step, entrada, number, contactName, protocol} — step deve ser "process"; protocol é o identificador do atendimento (não do telefone).
• Resposta esperada: texto puro, nunca JSON — node Respond to Webhook em modo text.

7. Z.ai/GLM como modelo temporário — limitação real de tool-calling

Usado como substituto temporário enquanto a chave da OpenAI não chegava. Dois endpoints testados:

• https://api.z.ai/api/coding/paas/v4 ("GLM Coding Plan"): funciona bem para chat simples, mas é restrito a ferramentas oficialmente suportadas (Claude Code, Goose, etc. — ver https://docs.z.ai/devpack/faq). Ao anexar uma tool MCP genérica ao AI Agent, o modelo passou a devolver respostas vazias silenciosamente (sem erro) em qualquer mensagem, mesmo sem chamar a tool. Confirmado desabilitando a tool: a conversa voltou a funcionar normalmente.
• https://api.z.ai/api/paas/v4/ (endpoint geral, mesma conta): suporta tool-calling arbitrário segundo a documentação, mas apresentou timeout consistente nesta conta/plano (possivelmente saldo separado do "Coding Plan").
• Conclusão: Z.ai/GLM não é uma substituição direta e confiável da OpenAI para um AI Agent com tools neste projeto. Recomendado usar a chave real da OpenAI (ou outro provider com suporte robusto e testado de function-calling) assim que disponível — só trocar a credencial e o model/responsesApiEnabled de volta, sem tocar no resto do workflow.

8. Tratamento de erro adicionado

Normalizar entrada e AI Agent têm onError: "continueErrorOutput", ambos roteados para um node Set ("Erro - Resposta padrão") com uma mensagem fixa amigável, que alimenta o Respond to Webhook. Isso garante que o Z-PRO sempre recebe alguma resposta, mesmo se a normalização lançar uma exceção ou o AI Agent falhar (timeout, erro de modelo, etc.) — testado com um timeout real do endpoint geral do Z.ai, confirmado funcionando.

9. Bug crítico — toolParameters do node MCP nunca era preenchido pelo modelo

Sintoma: toda chamada de agendar falhava com MCP error -32602: Input validation error: Invalid arguments for tool agendar: Required at clinicId, Required at startAt, Required at endAt, Required at patient. — mesmo com o prompt do sistema explicando o formato esperado em detalhe.

Causa raiz: o node n8n-nodes-mcp (operação executeTool) tem um campo próprio toolParameters (JSON, obrigatório, valor padrão '{}') que carrega os argumentos reais enviados à tool. Ele não é preenchido automaticamente só por a tool estar conectada a um AI Agent — é preciso configurá-lo explicitamente com o helper $fromAI() do n8n, que é o mecanismo real usado para "deixar o modelo decidir este valor em cada chamada". Sem isso, o campo fica travado no {} padrão, e nenhum valor que o modelo "pensa" que está enviando chega de fato ao MCP.

Fix: configurar toolParameters assim (mistura valores fixos vindos do próprio workflow com $fromAI() só para o que o modelo precisa mesmo decidir):

={{ JSON.stringify({
  clinicId: $('Normalizar entrada').item.json.clinicId,
  startAt: $fromAI('startAt', 'Data e hora de início, ISO 8601 completo', 'string'),
  endAt: $fromAI('endAt', 'Data e hora de término, ISO 8601 completo', 'string'),
  patient: {
    name: $fromAI('patientName', 'Nome completo confirmado do paciente', 'string'),
    phone: $('Normalizar entrada').item.json.telefone
  }
}) }}

10. Bug crítico — systemMessage do AI Agent nunca era avaliado como expressão

Sintoma: um agendamento de teste foi criado com o campo de telefone contendo literalmente o texto {{ $('Normalizar entrada').item.json.telefone }} em vez de um número de telefone real.

Causa raiz: o campo parameters.options.systemMessage do node AI Agent só é avaliado como expressão do n8n se o valor inteiro do campo começar com =. Sem esse prefixo, tudo — inclusive trechos {{ ... }} escritos "como exemplo" dentro do texto — é enviado ao modelo como texto literal, e o modelo, sem saber que aquilo deveria virar um valor real, às vezes copia o placeholder ao pé da letra.

Fix: sempre prefixar o campo inteiro com = quando ele precisar referenciar dados reais do workflow (={{ $('Normalizar entrada')... }}).

Consequência que isso causou (transparência total): dois agendamentos de teste fictícios ficaram duplicados no Z-PRO (Consulta - TESTE-N8N Paciente Final, mesma data/hora) antes desse bug ser identificado — uma chamada que o agente reportou como "erro" na verdade teve sucesso silenciosamente no lado do Z-PRO. Os testes fictícios foram apagados manualmente depois. Isso reforça por que a disciplina de "uma execução por vez, conferir visualmente antes de tentar de novo" existe em todos os testes reais deste projeto — mesmo seguindo ela, um bug de configuração ainda pode gerar um resultado inesperado, e só a conferência visual pega isso.

11. Bug — modelo não sabe a data de hoje

Sintoma: pedido de agendamento para "amanhã" resultou em uma data no passado (2023) sendo enviada ao Z-PRO.

Causa raiz: modelos de linguagem não têm acesso à data/hora real do momento da conversa — sem essa informação no prompt, o modelo "chuta" uma data (geralmente relacionada à data de corte do treinamento).

Fix: incluir a data/hora atual no systemMessage via expressão do próprio n8n:

A data de hoje é {{ $now.setZone('America/Sao_Paulo').toFormat('yyyy-MM-dd (cccc)') }}

12. Bug — horário criado 3h adiantado/atrasado (fuso horário)

Sintoma: cliente pediu "sexta às 10h", o agendamento foi criado em produção às 7h — exatamente 3h a menos (o offset de America/Sao_Paulo, UTC-3).

Causa raiz: o exemplo de formato dado ao modelo usava sufixo Z (UTC) — ex. 2026-04-20T18:00:00.000Z. O modelo tratou o horário local que o cliente pediu (10h) como se já fosse UTC, sem converter, e o Z-PRO (que aparentemente armazena/exibe em UTC) mostrou 10h UTC como 7h local.

Fix: instruir o modelo a nunca usar Z/UTC e sempre escrever o mesmo número de hora que o cliente pediu, com offset -03:00 explícito (ex.: cliente pediu 10h → 2026-08-14T10:00:00-03:00). Isso evita qualquer aritmética de fuso horário pelo modelo — ele só copia o número que o cliente já disse, sem calcular nada. Ajustado tanto na descrição do $fromAI('startAt', ...)/$fromAI('endAt', ...) quanto numa regra explícita no systemMessage.

Se isso acontecer nas próximas clínicas: o offset -03:00 só está certo para fuso de Brasília. Se uma clínica futura estiver em outro fuso, ajustar o offset (e o $now.setZone(...) do prompt) de acordo.

Status final (10/08/2026)

Testado de ponta a ponta com sucesso, com a chave real da OpenAI (gpt-4o-mini): telefone correto, data correta, um único agendamento por teste, confirmado visualmente no Z-PRO. Workflow deixado desativado propositalmente — só ativar quando o Z-PRO de uma clínica real for configurado para apontar pra esse webhook.