For social media operators

Let your agent run
socials. Keep control.

The right operating model is not an agent that needs a human beside it all day. It is a person who sets the boundary once, then lets the agent plan, draft, connect accounts with human approval, publish within a cap, and learn from results. PostLake puts that boundary on the agent connection itself, not only in a prompt.

Free tier. No card · one API for every network · full MCP access

Before you start

Same setup the docs quickstart uses. Do this once:

1. Sign up at app.postlake.dev and verify your email (unlocks free credits).
2. On Channels, create a profile (e.g. my-brand) and connect at least one account. Bluesky is the fastest first channel: no app review. Instagram/TikTok/Facebook need each platform's review before API posting.
3. Connect the hosted MCP server at https://api.postlake.dev/mcp in your agent host. It signs in through OAuth, so do not paste an API key into the agent.

A safe first instruction

After the MCP connection is authorised, give the agent one clear operating policy. It can request a signed connection link, but only a person completes social-network approval:

Set up my PostLake account safely. First call whoami and list_social_accounts.
If no channels are connected, call get_connect_link and send me the signed link.
Wait for me to approve access on the social network, then confirm the channel exists.
Before writing, call get_platform_capabilities and validate_post.
Save the first posts as drafts for my approval. Do not publish until I explicitly approve it.

Make it work

Tool-specific glue on top of the shared setup above:

1. Connect the agent through hosted MCP OAuth. It receives its own connection, not your account-level API key.
2. Open Agents in PostLake and give the connection a name you will recognise, such as Claude content agent or Launch crew.
3. Set the profiles it may use, the networks it may publish to, a daily post limit, and whether it may spend purchased credit packs. These limits are enforced on every publish, not merely suggested in the prompt.
4. Have the agent call whoami before planning work. It sees its own profiles, platforms, remaining daily capacity, and credit rules, so it can adapt instead of discovering a boundary through a failed post.
5. When the agent needs a new channel, it calls get_connect_link. Send that signed link to the human who owns the account. They complete the platform's OAuth approval, then the agent confirms the connection and continues.
6. Turn on Require my approval before publishing. Review the calendar when it suits you, then publish approved drafts without asking the agent to police itself.
7. Review activity from the Agents page and revoke any connection instantly. A revoked agent must complete OAuth again before it can act.

Read the response (don't skip this)

You get one Post with an overall state and a targets[] array. One entry per account. Always check each target; partial success is normal.

{
  "id": "post_a1b2c3",
  "state": "partial",
  "targets": [
    { "platform": "bluesky",  "state": "published", "url": "https://bsky.app/…" },
    { "platform": "linkedin", "state": "failed",
      "error": { "type": "invalid_request", "message": "…", "retryable": false } }
  ]
}

Where the post goes

Same rules as the docs. Pick one addressing style:

See Publishing: where to post.

Do more (same API)

Pitfalls specific to this path

Common questions

Go deeper in the docs

These guides stay short on purpose. Canonical behaviour lives here:

Also: Media · Errors · MCP · Analytics

Related guides

All guides · Full docs · llms.txt · Markdown