@plugandship, os dois pontos procedem.

No transcribe_audio o áudio entra como file_base64 e o servidor converte para multipart internamente, então o conteúdo passa pelo contexto do modelo mesmo. Sua conta está certa: base64 é ~1,33x os bytes e ~4 caracteres por token, então 1 min de MP3 a 64 kbps (480 KB) já dá 160 mil tokens. É limitação de design do MCP remoto (argumento de tool é JSON, binário só entra como base64 ou como referência) — e, somando, o body do MCP é limitado a 64 MB, bem abaixo do 1 GB do REST. Documentei isso no post: para arquivo longo, o caminho é o multipart do REST, ou enviar a transcrição pronta (BYOT) e usar só diagnostic/risk_audit. Upload assinado, com a tool recebendo apenas um id, é o próximo passo.

No webhook você achou um erro meu: o exemplo só recomputava o HMAC e não validava o t. Corrigi no post — agora recusa fora da janela de 5 minutos, e o t entra no material assinado ("."), então não é falsificável. O retry reusa o mesmo t, então a janela não quebra retry legítimo. Se o receptor executa ação a partir do evento, vale deduplicar por (event, timestamp do payload) também.

Obrigado pelo review — as duas correções estão registradas na Revisão 1 no final do post.