Asking an assistant to draft a post is easy. Letting it publish is a different decision, and the interesting part isn’t the plumbing. It’s what happens when it gets something wrong.
Here’s how the connection works, and what to decide before you make it.
Three ways to connect one
MCP, if the agent is an assistant like Claude or an AI-enabled editor. The Model Context Protocol is how these applications talk to external tools, and an MCP server exposes publishing as tools the assistant can call directly. This is the least work: connect the server, and the assistant can compose, schedule and check posts in conversation.
An API key, if you’re writing the agent yourself. Your code holds a key for your own account and calls the API. Simple, and correct when the agent acts only for you.
OAuth, if your product acts on behalf of other people’s accounts. Each user authorises your app rather than pasting a key at you. If you’re building something multi-user, this is the one you want, and pasted API keys are a mistake you’ll have to migrate off later.
BulkPublish offers all three: an MCP server on npm as @bulkpublish/mcp-server, API key auth, and OAuth 2.1 for apps acting for other users.
Decide the failure mode first
An agent publishing to a real audience can be wrong in ways a human usually isn’t. Not typos, but confident, plausible, wrong. A made-up statistic in a post reads exactly like a real one.
So the first decision isn’t technical. It’s what happens between generation and publication.
Draft by default. The agent creates posts as drafts, a person reviews, a person publishes. This keeps everything useful about the agent and removes almost all the risk. For most people this is the right setting and they never move off it.
Approval workflow. The agent queues, a named person approves. Same idea with an audit trail, which matters with a team.
Scheduled with a delay. The agent schedules for later rather than publishing immediately, leaving a window to catch things. Weaker than review, because it relies on someone looking.
Direct publishing. Appropriate for narrow, well-defined jobs where content is templated rather than generated: a status page update, a new-release announcement built from a changelog. Much less appropriate for anything writing prose about your company from scratch.
Scope the access
Give the agent the narrowest access that does the job.
- Separate credentials, so agent activity is distinguishable from yours and revocable on its own
- Limited channels. An agent working on one account shouldn’t be able to reach all of them
- The narrowest scopes. If it only needs to create posts, it doesn’t need to delete them
The reason to bother is revocation. When something goes wrong you want to cut off exactly one thing at 2am, not rotate the key your whole pipeline uses.
The guardrails worth setting
Never let it state a number about your product. Pricing, plan limits and feature counts change, and a model will happily produce a plausible one. Anything factual about you should come from a source, not generation.
Give it your actual voice. An agent with no style guidance produces text that reads like an agent, which is its own reputational cost.
Watch the volume. Publishing quotas are a backstop against a loop, not just a billing tier. An agent in a retry loop can produce a lot of posts quickly.
Keep a human in the loop for anything sensitive. Anything touching news, controversy or an apology is not an agent’s job.
What this looks like with BulkPublish
- MCP server:
@bulkpublish/mcp-server, for assistants that speak MCP - API: 59 documented endpoints covering posts, scheduling, media, channels, labels, analytics and quotas
- Auth: API key, or OAuth 2.1 for acting on behalf of other accounts
- Platforms: 15, so the agent publishes everywhere from one interface
| 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 rather than published, which is the setting worth starting on.
The short version
Connect via MCP for an assistant, an API key for your own agent, OAuth if you’re acting for other people. Then decide the review step before you decide anything else, keep credentials separate and narrow, and never let a model generate a fact about your own product. Draft-by-default costs you almost nothing and removes almost all of the risk.