Um agente publicando em redes sociais tem requisitos diferentes de uma pessoa fazendo isso, e a maioria deles vem do mesmo fato: ninguém está observando no momento em que ele age.
O que um agente precisa que uma pessoa não precisa
Um estado de rascunho genuinamente útil. Não uma fila escondida, mas posts que um humano pode ver, revisar e publicar. Este é o recurso mais importante para publicação por agentes e o que mais frequentemente é tratado como algo secundário.
Validação antes de publicar, não no momento da publicação. Uma pessoa percebe quando uma legenda está longa demais. Um agente não percebe, e se a verificação acontece no momento da publicação, a falha chega horas depois, quando o agente já foi embora. Os erros precisam voltar na chamada de criação, onde o agente pode reagir.
Credenciais com escopo, revogáveis. Separadas das suas outras chaves. Quando algo dá errado, você quer revogar exatamente o agente, não girar a credencial que seu pipeline de produção compartilha.
Cotas que interrompem um loop. Um loop de retentativa pode produzir muitos posts rapidamente. Um teto rígido é um recurso de segurança aqui, não apenas um nível de cobrança.
Erros estruturados. Um agente pode agir sobre “legenda excede 280 caracteres no x”. Ele não pode agir sobre um 400 genérico.
Os modos de falha contra os quais projetar
Invenção confiante. Um modelo vai produzir uma estatística, preço ou alegação de recurso plausível em vez de dizer que não sabe. Nada factual deveria ser gerado. Fatos vêm de uma fonte que seu código controla.
Tempestades de retentativa. Um agente que trata um timeout como falha e tenta de novo pode duplicar posts, porque uma criação que expirou pode ter tido sucesso. Retentativas precisam ser seguras ou verificadas, nunca às cegas.
Publicar no momento errado. Um agente não tem ideia de que hoje é um dia ruim para postar algo alegre. Qualquer coisa que toque em notícias ou controvérsia precisa de um humano.
Deriva de voz. Deixados por conta própria, os posts gerados convergem para o mesmo registro, e um público percebe isso antes de você.
MCP versus uma chave de API
Duas formas de conectar um agente, e cada uma serve para algo diferente.
MCP, quando o agente é um assistente como Claude ou um editor com IA integrada. O servidor expõe ferramentas nomeadas, o assistente escolhe quais chamar. Menor esforço, e a escolha certa para uma pessoa trabalhando de forma conversacional.
Uma chave de API, quando você mesmo escreveu o agente e ele roda sem supervisão. Chamadas diretas, seu próprio fluxo de controle, seu próprio tratamento de erros.
OAuth, se o seu agente age em nome das contas de outras pessoas, não das suas. Cada usuário autoriza em vez de colar uma credencial.
O que o BulkPublish oferece
- Servidor MCP:
@bulkpublish/mcp-server - API: 59 endpoints documentados cobrindo posts, agendamento, mídia, canais, etiquetas, analytics, feeds RSS e cotas
- Autenticação: chave de API (
Bearer bp_...), ou OAuth 2.1 com escopos granulares - Plataformas: 15
- Validação: limites de caracteres e regras de mídia por plataforma verificados na criação do post, não na publicação
| Free | Pro | Business | |
|---|---|---|---|
| Requisições de API/dia | 30 | 5.000 | 50.000 |
| Chaves de API | 1 | 5 | 10 |
| Publicações | 3/dia | 30/dia | Ilimitadas |
Posts podem ser criados como rascunhos, que é a configuração para começar e, para a maioria dos usos, para permanecer.
Os escopos de OAuth são granulares (posts:read, posts:write, media:read, media:write, analytics:read, channels:read, full), então um agente que só precisa criar rascunhos não recebe a capacidade de excluir.
A versão curta
Um agente precisa de um estado de rascunho real, validação na criação em vez de na publicação, credenciais com escopo que ele possa perder sem derrubar mais nada, e cotas que interrompem um loop. Dê a ele o escopo mais estreito que resolva o trabalho, nunca deixe que ele gere um fato e mantenha um humano entre a geração e a publicação até você ter um bom motivo para não fazer isso.