An agent publishing to social media has different requirements from a person doing it, and most of them come from the same fact: nobody is watching at the moment it acts.
What an agent needs that a person doesn’t
A draft state that’s genuinely useful. Not a hidden queue, but posts a human can see, review and publish. This is the single most important feature for agent publishing and it’s the one most often treated as an afterthought.
Validation before publishing, not at publish time. A person notices a caption is too long. An agent doesn’t, and if the check happens at publish time, the failure lands hours later when the agent is gone. Errors have to come back on the create call where the agent can react.
Scoped, revocable credentials. Separate from your other keys. When something goes wrong you want to revoke exactly the agent, not rotate the credential your production pipeline shares.
Quotas that stop a loop. A retry loop can produce a lot of posts fast. A hard ceiling is a safety feature here, not just a billing tier.
Structured errors. An agent can act on “caption exceeds 280 characters on x”. It can’t act on a generic 400.
The failure modes to design against
Confident invention. A model will produce a plausible statistic, price or feature claim rather than saying it doesn’t know. Nothing factual should be generated. Facts come from a source your code controls.
Retry storms. An agent that treats a timeout as failure and retries can duplicate posts, because a timed-out create may have succeeded. Retries need to be safe or checked, never blind.
Publishing at the wrong moment. An agent has no idea that today is a bad day to post something cheerful. Anything touching news or controversy needs a human.
Voice drift. Left alone, generated posts converge on the same register, and an audience notices before you do.
MCP versus an API key
Two ways to connect an agent, and they suit different things.
MCP, when the agent is an assistant like Claude or an AI-enabled editor. The server exposes named tools, the assistant picks which to call. Least work, and the right choice for a person working conversationally.
An API key, when you’ve written the agent yourself and it runs unattended. Direct calls, your own control flow, your own error handling.
OAuth, if your agent acts on behalf of other people’s accounts rather than yours. Each user authorises rather than pasting a credential.
What BulkPublish provides
- MCP server:
@bulkpublish/mcp-server - API: 59 documented endpoints covering posts, scheduling, media, channels, labels, analytics, RSS feeds and quotas
- Auth: API key (
Bearer bp_...), or OAuth 2.1 with granular scopes - Platforms: 15
- Validation: character limits and per-platform media rules checked when the post is created, not at publish
| Free | Pro | Business | |
|---|---|---|---|
| API requests/day | 30 | 5,000 | 50,000 |
| API keys | 1 | 5 | 10 |
| Posts | 3/day | 30/day | Unlimited |
Posts can be created as drafts, which is the setting to start on and, for most uses, to stay on.
OAuth scopes are granular (posts:read, posts:write, media:read, media:write, analytics:read, channels:read, full), so an agent that only needs to create drafts doesn’t get the ability to delete.
The short version
An agent needs a real draft state, validation on create rather than at publish, scoped credentials it can lose without taking anything else down, and quotas that stop a loop. Give it the narrowest scope that does the job, never let it generate a fact, and keep a human between generation and publication until you have a strong reason not to.