1

Fiquei com uma dúvida no MCP remoto: como o transcribe_audio recebe o arquivo? O servidor não enxerga o disco de quem usa, então se o áudio entrar como base64 no argumento da tool ele passa pelo contexto do modelo, e poucos minutos de áudio já viram muito mais token do que cabe. Um jeito comum é a tool devolver uma URL de upload assinada, o agente sobe o arquivo com curl e depois chama a análise passando só o id.

No esboço de verificação do webhook eu incluiria a checagem do t, recusando timestamp com mais de uns 5 minutos. Sem isso, quem capturar uma requisição válida consegue reenviar ela depois.

Carregando publicação patrocinada...
1

@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.