Skip to main content
A configuração de credenciais pode ser habilitada separadamente com MCP_PUSH_CREDENTIALS_ENABLED=true. Essa opção libera somente a configuração de FCM, APNs e Web Push para chaves com push_providers.write e a função de gerenciamento de provedores; mensagens e administração podem continuar desabilitadas. Consulte account_get.credential.features.push_credentials e project_get.capabilities.push.apps.configure_provider_credentials. Sem essa opção, a configuração acompanha o sinalizador de mensagens existente; um false explícito a desabilita. A fase 2 usa a flag independente MCP_MESSAGING_ENABLED. A descoberta de ferramentas e project_get mostram o acesso disponível. Chaves existentes não recebem novas permissões automaticamente. O proprietário seleciona escopos em Conta → Chaves pessoais; vínculos de equipe, projetos autorizados e papéis atuais continuam sendo verificados. Cobrança, planos, pagamentos, créditos, faturas e gestão de assinaturas ficam excluídos. Comece com account_get, teams_list, projects_list({team_id}) e project_get({project_id}). Informe project_id em toda chamada de projeto. No SDK, use projectId; na API, X-Sendrealm-Project-Id. Nas novas operações, use o UUID id do app push, separado do ID público usado pelo SDK do dispositivo.

​
Revisar e confirmar

  1. Crie ou edite rascunhos de templates e campanhas de email, push ou ambos os canais. Leia o conteúdo detalhado antes de editar. Campos omitidos são preservados; messages substitui a lista de idiomas.
  2. Confira conteúdo renderizável, domínio verificado, provedores, targeting e destinatários alcançáveis. Audiência vazia nunca significa todos. all_contacts precisa ser explícito e preserva restrições de assinatura e supressão.
  3. Use <operação>_prepare e revise o input salvo, os destinatários e as consequências. A preparação expira em dez minutos e vincula usuário, chave, versão das permissões, projeto e versões dos recursos.
  4. Confirme com project_id, prepared_action_id e uma idempotency_key estável. Inputs diferentes exigem nova revisão. As ferramentas existentes de ciclo de vida de templates/automações também mantêm o argumento id do recurso.
  5. Nas novas operações, acompanhe o recibo com project_operations_get, respeitando poll_after_ms. completed confirma a operação solicitada; uma campanha pode ter entrado em revisão sem ainda ter sido entregue.
Envios passam pelo pipeline existente de revisão de spam e agendamento. campaigns_send e equivalentes solicitam o primeiro envio permitido pela revisão, atualmente com pelo menos cinco minutos de antecedência. Cancelamento só está disponível antes do processamento; mensagens já enviadas não podem ser recuperadas. Apenas rascunhos podem ser arquivados. Para sincronizar targeting entre os canais, use cross_channel_campaigns_update; divergências bloqueiam o envio. Retries com a mesma preparação e chave de idempotência retornam o recibo original. Workers revalidam acesso, conteúdo e versões; revogação, mudança de papel, perda de vínculo ou alteração de permissões podem interromper trabalho enfileirado. O status outcome_unknown exige inspeção do recurso e histórico e reconciliação com suporte: não crie outra preparação para repetir um efeito incerto.

​
Permissões e segurança

  • Templates: templates.write, templates.publish, templates.delete; testes reais de email usam templates.test.send e testes push usam push.test.send.
  • Campanhas: campaigns.draft.write para rascunhos; campaigns.deliver para preparar/confirmar envio, agendamento e cancelamento; campaigns.delete para arquivar.
  • Automações: automations.publish para publicar/pausar/retomar e automations.delete para excluir. Recuperação de execuções usa automation_runs.manage, preparação e motivo de auditoria.
  • Domínios: domains.write para criação, verificação, configuração, transferência e DNS; domains.delete para exclusão.
  • Push: push_apps.delete, push_channels.write, push_channels.delete e push_providers.write são permissões separadas.
  • Diagnósticos: diagnostics.read para mensagens, Live Activities de produção, entregas de automação, feed de eventos, eventos do dispositivo e analytics. Descoberta usa resources.read; status do Cloudflare também exige capacidade atual de gerenciar domínios.
Efeitos de automação ficam suprimidos por padrão. Solicitar automation_effects: "trigger" exige também automations.trigger e capacidade atual de gerenciar automações. Política e identidade acompanham filas e eventos derivados, inclusive replay. Testes sandbox continuam sem envio; os testes existentes de um dispositivo e de Live Activity mantêm seu fluxo e test_id próprio. Novos testes de templates exigem preparação. Configure FCM, APNs e Web Push diretamente com push_providers_configure_fcm, push_providers_configure_apns e push_providers_configure_web, usando push_providers.write. Os campos de credenciais são somente de escrita, passam pela validação do dashboard e não entram em preparações, recibos ou respostas. Confira push_providers_list depois. O handoff de configuração continua opcional; a autorização OAuth do Cloudflare usa domains_cloudflare_authorize e acompanhamento com project_handoffs_get. Códigos OAuth permanecem no navegador. OAuth para autenticação MCP continua adiado. Assets usam o armazenamento existente: obtenha upload_url/file_key, envie bytes por PUT e finalize com o mesmo recurso e chave. Upsert de canal segue substituição do dashboard: valores opcionais omitidos podem ser limpos; importância high, vibração true, visibilidade public e is_default: false são os padrões. Leia o canal antes de preparar a alteração. O SDK oferece métodos tipados em client.projectOperations, paginação com metadados e ausência de retry automático para mutações. Preserve filtros e cursores; use respostas detalhadas para conteúdo e traces. Os fluxos funcionam como ferramentas MCP comuns em Streamable HTTP e stdio, sem exigir MCP Tasks. Veja referência completa e exemplo SDK.