Can Paperclip Agents Run Your X Account? What the Agent-Company Model Gets Right and Wrong

Short answer: Yes, but not the way the demos imply. Paperclip orchestrates a team of agents. It does not hold your X credentials and it does not publish anything itself. Something further down the stack has to be the publisher.

That distinction is the whole article. Every "AI company runs your marketing" demo shows a Content Agent drafting, a Review Agent approving, and a Scheduling Agent publishing. The first two are real. The third is a hand wave over a stack of decisions Paperclip has made very deliberately, and almost nobody has written them down.

---

What Paperclip Actually Is

Paperclip is an open-source Node.js server with a React UI that manages teams of AI agents. Its own description: "The open-source app everyone uses to manage agents at work." Verified against the GitHub API on September 9, 2026:

Fact	Value
Repository	paperclipai/paperclip
Created	March 2, 2026
Stars	80,306
Forks	14,737
License	MIT
Latest release	v2026.831.1, September 2, 2026
Node version required	24.11 or newer

Install is one line: curl -fsSL https://paperclip.ing/install.sh | bash.

The model is a company. You define goals, "hire" agents into roles with a reporting structure, and give each a monthly budget. The site is blunt about who is in charge: "You operate as the board of directors. Agents can't hire new agents without your approval." Budgets are hard limits with a warning at 80 percent, and cost is logged per agent, per task, per project, per goal.

Agents do not run continuously. They run on heartbeats. Paperclip's bundled skill file says it plainly: "You run in heartbeats, short execution windows triggered by Paperclip. Each heartbeat, you wake up, check your work, do something useful, and exit." Typical intervals are every 4, 8, or 12 hours.

Two things follow for social. Heartbeats map cleanly onto a posting cadence, which is a genuinely good fit. And a heartbeat is a fresh, short-lived context, so anything your agent needs to know about your voice has to live in a file, not in a conversation it remembers.

---

The Demo Skips the Step That Matters

An agent in Paperclip is a database record until you give it an adapter, the bridge to the runtime that actually executes the model. Paperclip ships adapters for Claude Code (claude_local), Codex (codex_local), CLI agents such as Cursor and Gemini, and HTTP or webhook bots such as OpenClaw.

You teach that agent a procedure with a skill, and the file really is called SKILL.md, with YAML frontmatter carrying name and description. Skills are adapter agnostic: Claude, Codex, and custom adapters read the same file. For Claude the process adapter injects local skills using --add-dir; for Codex it writes them into $CODEX_HOME/skills. A SKILL.md written for another agent transfers, which is the point of the cross-agent skill standard.

But a skill is prose. It tells an agent how to do something. It does not let the agent reach outside the box. For that you need a tool, and that is where the publishing question actually lives.

---

How a Paperclip Agent Gets a Tool That Can Publish

There are two paths, and they have very different governance properties. Choosing between them is the real decision.

Path 1: the adapter's own runtime

Your agent runs Claude Code. Claude Code reads a .mcp.json in the agent's working directory. Whatever MCP servers are listed there are available to the agent, and Paperclip is not in the loop.

This is the easy path and it is the ungoverned one. Paperclip's own known-limitations section says so: "V1 does not claim host-wide MCP enforcement. If an unmanaged external client, hand-edited adapter config, or process outside the Paperclip-controlled workspace calls an upstream MCP server directly, Paperclip can warn about known overlapping config entries but cannot prevent or audit that bypass."

Translated: hand-edit .mcp.json to add a publishing server and your agent can post without Paperclip knowing. No approval card, no audit log, no rate limit.

Some third-party write-ups still describe this as the only path and say Paperclip "does not speak MCP directly." That was true earlier in the project's life and is out of date as of the MCP Access Governance work now in the repository. The docs site lags the code here. Check the repo, not the aggregators.

Path 2: Paperclip's MCP gateway

Paperclip now sits in front of upstream MCP servers as a proxy with a policy engine. Its docs separate two roles operators constantly confuse:

• Endpoint mode. Paperclip exposes its own MCP surface so Claude Code or an IDE can manipulate Paperclip tasks and agents. This is what the @paperclipai/mcp-server package on npm does. It is inbound and has nothing to do with posting to X.
• Gateway mode. A Paperclip agent calls an upstream MCP server through Paperclip. Every call passes profile selection, policy evaluation, optional human approval, rate limiting, redaction, and audit.

Four terms for the rest of this. A Connection is one MCP endpoint, transport remote_http (preferred) or local_stdio. A Catalog entry is one tool discovered on it, carrying a risk level and a status. A Profile decides whether an agent can see a tool. A Policy decides whether this exact call is permitted right now: allow, block, require_approval, rate_limit, trust_rule. Deny always beats allow.

One constraint catches people out. You cannot paste an arbitrary stdio command into a gateway connection. Paperclip's doc: "Operators do not paste arbitrary command / args for stdio. Allowed stdio entries are limited to the approved template catalog." So npx -y @opentweet/mcp-server is not addable as a governed stdio connection today. A hosted server over HTTPS is, which is why remote_http is the transport to use.

---

The Part Nobody Writes About: Your Publishing Tool Arrives Quarantined

Paperclip infers a risk level for every discovered tool from its MCP annotations, and treats it accordingly:

Risk	Trigger	Default treatment
read	annotations.readOnlyHint: true	Allowed by read-friendly profiles
write	readOnlyHint: false or writeHint: true	Requires approval by default
destructive	annotations.destructiveHint: true	Quarantined on first sight. Requires explicit operator action before any agent call can succeed

Now check what a real publishing server declares. In OpenTweet's MCP server source, opentweet_publish_tweet is annotated { destructiveHint: true, idempotentHint: false, openWorldHint: true }, and so is opentweet_schedule_tweet. That is the correct annotation, because publishing to a public timeline is not reversible in any meaningful sense.

Apply Paperclip's own table to it and the result is: your publish tool lands in the catalog quarantined, and no agent call against it succeeds until you open the Catalog view and re-enable it. Paperclip calls this the "changed-tool quarantine" rule and describes it as "the primary defense against an upstream server silently adding a destructive verb."

I chained two verified facts here rather than running the flow end to end, so treat the exact UI wording as unverified. The rule and the annotation are both from primary sources.

The practical consequence is a good one. If you want a human in the loop before anything goes live, you do not have to build it. Leave the tool quarantined, or re-enable it and attach a require_approval policy scoped to the publish tool, and every attempted post opens an approval card. Full autonomy becomes something you choose explicitly, which is the right default.

You can dry-run the decision before letting an agent near it:

curl -fsS -X POST -H "Authorization: Bearer $BOARD_API_KEY" \
  -H "Content-Type: application/json" \
  "$PAPERCLIP_URL/api/companies/$COMPANY_ID/tools/policy/test" \
  -d '{"companyId":"'"$COMPANY_ID"'","actor":{"actorType":"agent","actorId":"'"$AGENT_ID"'"},"request":{"toolName":"opentweet_publish_tweet","arguments":{}}}'

One more limitation worth planning around: there is no paperclipai tool ... CLI subcommand yet, so connections, profiles, and policies are UI and REST only.

---

Wiring a Publishing Layer Into a Paperclip Company

Short, because the interesting decisions are all above.

1. Get a key from a service that already holds your X connection. With OpenTweet that is a 7-day free trial, no credit card, and a key with the ot_ prefix.
2. In Paperclip, create an Application and a Connection with transport remote_http pointing at https://mcp.opentweet.io/mcp, authenticating with a bearer header. That server speaks Streamable HTTP and exposes 43 X tools.
3. Refresh the catalog, then re-enable the publish and schedule tools, which arrive quarantined for the reason above.
4. Create a profile exposing only what each role needs. A drafting agent gets the create and analytics tools. Only the publishing agent gets opentweet_publish_tweet.
5. Attach a require_approval policy on the publish tool while you learn what your agents write unsupervised.

If you would rather skip MCP entirely, the REST path is one call: POST https://opentweet.io/api/v1/posts with a bearer key, documented at opentweet.io/developer. An HTTP bot adapter can hit that directly. The full tool list is at opentweet.io/mcp, and which AI agents can post to X in 2026 covers who publishes and who can only draft.

---

Where the Agent-Company Model Breaks on Social

Arguing against my own conversion here, because this matters more than the setup.

An agent company optimises throughput. It turns a goal into parallel workstreams and produces more output per unit time. That is the right target for support triage or code review. It is the wrong target for X. Volume is not the constraint on that platform. Quality is. Nobody's account underperforms because they published 12 posts a week instead of 40.

Three failure modes to plan for:

Duplicate content. Three content agents with the same goal and the same source material converge, and heartbeats make it worse, because a fresh context every 8 hours has no memory of what the others already shipped. You want a dedup check between draft and publish, not a fourth agent reviewing the first three.

Voice drift. Each heartbeat is a fresh short window. Whatever defines your voice has to live in a skill file the agent reloads every wake, or it degrades toward generic model output within days.

Approval fatigue. This is the one that kills the setup. Turn on require_approval and your agents generate more drafts than you will ever review. In OpenTweet's own data across the user base there are 22,071 posts a human approved and then never sent, median abandoned draft 107 days old. Those were written by people with real intent. An agent company drafting at ten times human speed hits that wall ten times faster.

Honest framing: Paperclip earns its structure for social when content is one function inside a larger agent operation. It is overkill if managing one X account is the whole job. For that, one agent with a good skill file and a scheduling queue beats an org chart.

---

Paperclip vs OpenClaw for Social

Both are open source, both are enormous, and they solve different problems.

	Paperclip	OpenClaw
Stars (September 9, 2026)	80,306	387,250
Model	A company of role-specialised agents	One personal agent
Execution	Heartbeats, short scheduled wake-ups	Continuous personal assistant
Tool governance	Profiles, policies, approvals, audit, quarantine	Skills and plugins, lighter governance
Best for social when	Content is one function of a larger agent operation	One person runs one or two accounts
Framework cost	Free, MIT	Free

Running a single account? OpenClaw as a social media manager is the lower-overhead answer, and the Claude versus OpenClaw comparison covers the trade in depth. Paperclip earns its structure when several goals compete for the same budget.

---

What It Actually Costs

Paperclip is free. MIT licensed, no paid tier, no hosted plan advertised as of September 9, 2026. The waitlist on paperclip.ing is for a managed version with no public pricing.

Model spend is your first real cost, metered by Paperclip per agent and per task with hard monthly budgets. Five agents on 8-hour heartbeats is 15 model invocations a day before any of them does useful work.

Publishing is the second, and it splits two ways:

• Direct X API. New developers cannot buy the old Basic tier at 200 per month or Pro at 5,000 per month as of April 2026. The options are metered pay-per-use or an Enterprise contract starting around 42,000. Pay-per-use is 0.015 dollars per post created, 0.005 per post read, and 0.20 dollars per post if it contains a link. That last one hurts: a marketing agent team producing link posts is the worst possible cost shape for that meter, 13 times more expensive per post than plain text. Full breakdown at X API pay-per-use explained.
• Flat rate through a platform. OpenTweet is 11.99 per month on Pro with the API and MCP server included, 29 on Advanced, 49 on Agency. No X developer account, no per-call meter, no surprise when an agent posts 40 times. See pricing and the agent-focused overview.

For a team of agents the flat rate is not a small saving. It is the difference between a predictable line item and a variable cost that scales with exactly the behaviour agents are best at, doing a lot of something quickly.

---

Frequently Asked Questions

Can Paperclip agents post to social media?

Yes, but Paperclip is not the publisher. It orchestrates and governs. The publish happens in a tool the agent reaches, either through Paperclip's MCP gateway or through the underlying runtime's own MCP config.

Does Paperclip have an official X or Twitter integration?

No. As of September 9, 2026 the bundled plugin list covers Discord, GitHub Issues, Linear, Slack, and Telegram. Social publishing goes through a general MCP connection, not a first-party integration.

Is @paperclipai/mcp-server how I connect Paperclip to X?

No, and this is the most common mix-up. That package exposes Paperclip to other MCP clients so Claude Desktop or Cursor can manage your Paperclip tasks. It points inbound. Reaching X is a separate outbound connection.

Why did my publishing tool not appear in the agent's tool list?

Almost certainly the changed-tool quarantine. Any tool annotated destructiveHint: true is quarantined the first time Paperclip discovers it. Open the Catalog view and re-enable it. Publishing tools are correctly annotated destructive, so this is expected, not a bug.

How is this different from just using Claude Code with an MCP server?

Budgets, approvals, audit, and role separation. If one agent and one skill file covers your use case, Claude Code with an MCP server is simpler and you should do that instead.

---

Get Started

1. Sign up for OpenTweet for the publishing layer, 7-day free trial, no credit card, and copy your ot_ key.
2. Add https://mcp.opentweet.io/mcp as a remote_http connection in Paperclip, then re-enable the quarantined publish tool.
3. Bind a profile to exactly one agent and attach a require_approval policy until you trust what it writes.
4. Write the SKILL.md once using the cross-agent skill guide. It works in Claude Code and Codex too.

A closing note on honesty. Paperclip is six months old, ships weekly, and had 5,419 open issues on September 9, 2026. Everything above was verified against the repository and the project's own docs on that date, and some of it will be stale within a month. Where I inferred rather than tested, I said so. If something here no longer holds, github.com/paperclipai/paperclip is the source of truth, not this page.

The OpenTweet MCP server is open-source and available on npm. Learn more at opentweet.io/mcp.