Approvals

A post on X or Threads cannot be taken back. Once it is out, people have seen it, screenshots exist, and deleting it later does not undo that. An AI assistant that misreads “draft something for tomorrow” as “post this now” is a real risk, and so is a script with a bug in a loop.

So Pickpost splits every action into two groups, and the split is part of the action’s definition, not something each client decides.

Group	Examples	From MCP	From the REST API
Runs directly	reading, creating and editing drafts, validating	runs	runs
Needs approval	posts.schedule, posts.publishNow, posts.delete, accounts.delete, and edits of a post that is already scheduled	becomes an approval card	403 ApprovalRequired

Drafts are cheap to fix, so agents can write and rewrite them freely. You see the edits live in the editor. Anything public, or hard to undo, stops at a card with Approve and Reject. A scheduled post is one you approved as it was: changing its text, options, accounts or time goes back to you.

Approving twice (a double click, a second tab) runs the action once.

Why the REST API only refuses

An MCP client is usually a person chatting with an assistant, and the card lands in front of that same person. A script has nobody watching. If it could create cards, a buggy loop could fill the app with hundreds of them. For now, a script prepares drafts and a person schedules them in the app.

What approval does not cover

Approving runs the action as you, with the arguments shown on the card. It does not check that the text is good. Run posts.validate before asking for approval: it checks each network’s character, media and thread limits, the same checks the editor runs while you type.

Where this is going

MCP clients that sign in get scoped tokens: a client with posts:write but no posts:publish can draft and nothing else. Third-party apps will get the same. The approval rule stays in place on top of scopes. See Plugins and apps.