A social media MCP server with a human approval gate

Why an MCP server, not just an API

Most social tools bolt an API onto a hosted dashboard. pendpost is built the other way round: the same capabilities are exposed as MCP tools and as a web dashboard, kept at parity by a test, so anything an agent can do, you can also do by hand, and the reverse. That makes it natural to operate from inside an MCP client instead of switching tools.

The safety model agents need

• Read-only tools can never publish. The read surface is separate from the write surface, so browsing and planning carry no risk of an accidental post.
• Writes create drafts, not posts. Every post is fail-closed: with no approval, it will not publish.
• Approval is a separate authority. It is held by you or by an auto-approve policy only you can enable, so by default a human approves and any autonomy stays owner-only.
• Autonomy is a dial you own. Opt into auto-approve to let pendpost publish on its own and scale to hands-off, then turn it off any time. Only the owner can change the policy.
• Anti-ban circuit breakers. A platform action block halts that lane and does not auto-resume, so an over-eager agent cannot get your account suspended.

How it compares to hosted social MCP servers

Hosted MCP servers for social media run in someone else's cloud and ask you to hand over your account credentials. pendpost runs locally: your tokens stay in your own .env, nothing phones home, and the code is MIT-licensed and yours to read or modify. The trade-off is honest: you run a process yourself instead of clicking connect on a website.

Connect it in four steps

$ npx pendpost
# serves the dashboard on http://127.0.0.1:8090 and MCP on /mcp

# For a client that expects a local command, bridge the HTTP endpoint:
$ npx -y mcp-remote http://127.0.0.1:8090/mcp

Then ask your agent to draft and schedule posts, and approve them yourself before they go live. Full setup, including platform credentials, is in the documentation.