MCP social media posting: giving AI agents a safe way to publish
What the Model Context Protocol changes about letting an AI agent post to social media, and why draft-first, scope-limited tool design matters more than the protocol itself.
By André LugMCP (Model Context Protocol) is an open standard that lets AI agents discover and call tools at runtime, replacing bespoke per-provider function-calling layers. It standardizes invocation, not safety: what stops an agent from publishing by accident is tool design. PostGate's hosted MCP server creates drafts by default and only publishes when a call explicitly includes confirm: true.
The Model Context Protocol is an open standard for connecting AI models to external tools and data — a common shape an agent can discover and call at runtime, instead of a bespoke function-calling layer you hand-write for every model provider. That part is genuinely useful plumbing. But it answers a different question than the one that actually matters once the tool on the other end can publish to a real, connected social account: not "how does the agent call this," but "what stops the agent from calling it wrong." The protocol doesn't answer that. The tool design does.
PostGate handles OAuth, publishing and delivery evidence for every network through one API. Start free or read the docs.
What does MCP actually change for a publishing integration?
Before a standard like MCP, giving an LLM the ability to post to social media meant writing a provider-specific function schema, wiring it into whatever function-calling format that particular model expected, and repeating the exercise for the next model or the next agent framework. MCP collapses that into one server that exposes a fixed set of tools — the same tools, described the same way, regardless of which client connects to them. For PostGate, that hosted MCP server exposes profile discovery, post creation, delivery status, analytics, comments, replies, messages, deletion, and platform limits as callable tools, over the same HTTP transport an MCP-aware client already knows how to speak. (For connection details and client configuration, see the docs/setup page — this post is about why the tool design matters more than the wire protocol.)
That's a real convenience gain. It is not, by itself, a safety story — a tool an agent can call to post content is exactly as dangerous over MCP as it would be over a raw REST call the agent was instructed to make. The transport standardizes discovery and invocation. It says nothing about what happens when the agent decides, correctly or not, that now is the time to publish.
If you are still at the design stage, our guide to building an AI agent for social media covers which jobs to automate, the five parts an agent needs and a draft-only tool definition you can copy.
The risk was never the protocol — it's an agent that can hit publish
An agent that can post on a customer's behalf can also hallucinate a caption, misread which account a request was meant for, or act on a prompt-injected instruction buried in content it was asked to summarize. None of those failure modes are specific to MCP; they show up with any LLM-to-publishing-API wiring, whether it's a plugin, a custom tool call, or an MCP tool. What actually determines whether one bad tool call reaches a live account is what the API does at the boundary — before the agent's intent becomes a real HTTP request that a platform executes.
Why is draft-first the actual safety mechanism?
PostGate's create_post MCP tool creates a draft by default. It only publishes, schedules, or queues content when the call explicitly includes confirm: true — the same distinction the REST API makes with draft: true versus an immediate or scheduled request. An agent that calls the tool without setting that flag produces something a human can review, edit, or discard; it cannot produce a live post by accident, by hallucination, or because a document it read told it to.
This is a deliberate design choice, and it's enforced at the API boundary rather than left to the agent's instructions. Telling a model "always create a draft, never publish directly" in a system prompt is not the same guarantee — a prompt is data the model reasons over, and reasoning can be wrong or manipulated. A tool contract that requires an explicit, structured confirm: true to do anything irreversible fails closed instead.
{
"mcpServers": {
"postgate": {
"type": "http",
"url": "https://postgate.studio/mcp",
"headers": {
"Authorization": "Bearer $POSTGATE_API_KEY"
}
}
}
}Give the agent a key it can't do damage with
Draft-first behavior protects against one class of mistake. The credential handed to the agent is the other half of the boundary. PostGate keys carry a scope of read, publish, or full — read covers retrieval and analytics, publish adds content and scheduling, and full adds destructive and administrative operations like connection management and key issuance. An agent almost never needs full, and giving it anything broader than the job requires turns a tool-design safeguard into a credential-scoping problem instead.
A key can also be bound permanently to a single profile group — the durable tenant boundary in PostGate's model. A group-bound key cannot read or mutate another customer's profiles, posts, or data, and the API rejects any attempt to override that binding. For an agent acting on behalf of one specific customer, that's the credential to issue: narrow enough that even a fully compromised or maximally confused agent session can only reach the one account it was meant to operate on.
What does the hosted MCP server actually expose?
Beyond create_post, the same server surfaces profile discovery, delivery and status checks, analytics, comments, replies, messages, deletion, and platform limits as individual tools — the same operations available through the REST API and the generated SDKs for Node.js, Python, Go, Ruby, PHP, and .NET, since every one of them is generated from the same OpenAPI contract. An agent doesn't get a smaller or differently-behaved API; it gets the same operations, described as tools, with the same draft-first guardrail on the one that matters most.
Frequently asked questions
Can an AI agent accidentally publish a post through an MCP tool?
Not through PostGate's. The create_post MCP tool creates a draft by default and only publishes, schedules, or queues content when the call explicitly includes confirm: true. An agent that calls the tool without that flag produces something a human can review, edit, or discard — it cannot produce a live post by accident, by hallucination, or because a document it read told it to.
Why is a system prompt not enough to stop an agent from publishing?
Because a prompt is data the model reasons over, and reasoning can be wrong or manipulated — including by prompt-injected instructions buried in content the agent was asked to summarize. A tool contract that requires an explicit, structured confirm: true to do anything irreversible is enforced at the API boundary and fails closed instead of relying on the model behaving.
What tools does PostGate's hosted MCP server expose?
Profile discovery, post creation, delivery and status checks, analytics, comments, replies, messages, deletion, and platform limits — the same operations available through the REST API and the generated SDKs for Node.js, Python, Go, Ruby, PHP, and .NET, since all of them are generated from the same OpenAPI contract. The server speaks HTTP transport any MCP-aware client already understands.
What API key scope should I give an AI agent?
The narrowest that covers the job. PostGate keys carry read, publish, or full scope — read covers retrieval and analytics, publish adds content and scheduling, full adds destructive and administrative operations. An agent almost never needs full. A key can also be bound permanently to a single profile group, so even a fully compromised agent session can only reach the one account it was meant to operate on.
Is posting over MCP safer than a direct REST integration?
Not inherently. A tool an agent can call to post content is exactly as dangerous over MCP as over a raw REST call the agent was instructed to make. The transport standardizes discovery and invocation; it says nothing about what happens when the agent decides to publish. Safety comes from the tool design — draft-first defaults and scoped credentials — not from the protocol.
