Connecting OpenClaw to multi-platform publishing: Skill, MCP and CLI, each walked through

OpenClaw is a resident agent that runs on your own computer, which matches OmniPost exactly: OmniPost also works only on this machine, with MCP and HTTP listening on 127.0.0.1 alone. Connecting the two needs no cloud account. Three routes below, ordered from least to most setup; every command was checked against OpenClaw's current documentation.

Prerequisite: install OmniPost, open it, scan the QR codes for the platforms you publish to under Accounts, and claim the 7-day Pro trial inside the app before the first agent-driven publish (the free tier gives agents read-only calls).

Route 1: a Skill folder (least setup)

OpenClaw loads Skills from a few fixed directories. A Skill is a folder with a SKILL.md, and the name inside SKILL.md must equal the folder name. Copy skills/omnipost/ from the omnipost-skill repo into either:

• ~/.openclaw/skills/omnipost/: OpenClaw's local Skill directory (default path), shared by all agents.
• <workspace>/skills/omnipost/: workspace Skills, highest precedence; the default workspace is ~/.openclaw/workspace.

Then run openclaw skills check once; it reports missing prerequisites (OmniPost has none, so the list should be empty). Open a new session and say:

Publish ~/posts/today.md to Zhihu and CSDN, draft it on the Official Account, and write the summary.

What the Skill teaches the agent: find the port in ~/.omnipost/server.json, get the runnable CLI path from GET /api/health, check alerts before publishing to see which account is about to lapse, read the content-rule sheets for 10 platforms (rules/) first, and interpret each target's result. The Skill does not depend on MCP; the agent completes everything through the CLI or HTTP.

Route 2: MCP (when you want tool-level approvals)

OmniPost's MCP endpoint uses SSE transport, and OpenClaw's remote MCP supports both sse and streamable-http. Add it with:

openclaw mcp add omnipost --url http://127.0.0.1:8787/sse --transport sse
openclaw mcp doctor omnipost --probe

doctor --probe makes a live connection and lists the tools; you should see 40-plus, including list_platforms, list_accounts, list_alerts, preview_content, create_draft, publish_post, schedule_post, list_posts, get_publish_status and get_account_overview. Writing it into the config file works too: under mcp.servers.omnipost set url and transport: "sse".

The benefit of MCP is that these tools fall under OpenClaw's own tool policy and approvals: set publish_post and schedule_post to prompt every time and let list_* through automatically. The desktop app must be running or the probe cannot connect.

Route 3: the CLI (scripts and scheduled jobs)

OpenClaw runs shell commands anyway, so the CLI is the most direct route:

omnipost alerts
omnipost publish --doc ./today.md --targets zhihu:default,csdn:default --mode publish --title "Title" --summary "Summary" --tags "a,b"
omnipost publish --doc ./today.md --targets weixin:default --mode draft
omnipost posts --limit 10

The full path of the omnipost command comes from the cli.shell field of GET /api/health: usually omnipost.cmd in the install directory on Windows, and /Applications/OmniPost.app/Contents/Resources/bin/omnipost-cli on macOS. To stagger several targets add --spacing 10 (10 minutes between targets, split into scheduled jobs).

A daily routine you can follow as is

1. alerts: if an account is about to lapse or has lapsed, deal with it first, otherwise the piece lands in the retry queue instead of going out.
2. preview: render the Markdown per target; image paths and title length (20 characters on Xiaohongshu) surface here.
3. publish: several targets in one call, each with its own title and summary if needed.
4. Read the results: published comes with a link; draft + MANUAL_PUBLISH means a draft-only platform such as WeChat, waiting for a human to mass-send; NEED_LOGIN is already queued and goes out within 48 hours of scanning again; VALIDATION_FAILED names the rule that was broken.
5. posts: collect links and statuses into your own log.

The honest part

There is no "ban protection". Cloud-server IPs are banned almost on sight, fixed-interval schedules are a signature in themselves, and the same structure repeated gets judged at the content level. OmniPost's policy layer adds daily caps, duplicate-title blocking, a failure circuit breaker, quiet hours and minimum spacing between targets, enforced server-side for agent calls, so an agent without brakes of its own is still stopped. No guarantees; it keeps the most machine-like behaviour out. Automated comments, DMs and human simulation: not offered.

To talk, open an issue titled with "chat" at github.com/OmniGoAI/omnipost-skill; 20 minutes gets you 3 months of Pro.