Claude Code can schedule a social media post when an MCP server exposes the necessary publishing tools. You connect the server, authenticate, and ask Claude to work with a real account rather than return a caption for you to copy elsewhere.
The part to design carefully is the write boundary. A request to prepare content should not quietly become permission to schedule it. And a message saying "done" should not replace a check of the saved post.
This tutorial uses one text-only LinkedIn draft to demonstrate a controlled workflow. The server in the example is PostSider's hosted MCP service. I build PostSider; the command and argument examples below describe the integration, not an authenticated publishing session executed for this article.
Connect the hosted MCP server
You need Claude Code installed and a publishing account with the intended social media channel already connected.
Add the remote server from your terminal:
claude mcp add --transport http postsider https://mcp.postsider.com/mcp
This connection uses Streamable HTTP. You do not need to launch a local PostSider MCP process.
Open Claude Code and enter:
/mcp
Select the server and follow its OAuth sign-in flow. Review the organization and permissions before granting access. The workflow needs read access to inspect posts and write access to create and schedule them.
Do not paste an API key into the conversation or append it to the endpoint URL. The hosted route uses OAuth credentials handled by the client.
Keep normal write-confirmation prompts enabled. Do not bypass permission checks just to make the first test faster.
Make the first request read-only
Start by asking Claude to identify the available accounts:
List my connected PostSider channels.
Do not create or modify anything.
Show each account's name, platform, and ID so I can select one.
The relevant tool is postsider_list_channels. Select the intended account from the returned data instead of guessing an ID or assuming that the first LinkedIn result is correct.
This is especially important when you manage a personal profile and a company page, or several client accounts.
Ask Claude to check the organization's publishing state with postsider_get_publishing_state. If publishing is paused, stop rather than attempting to work around it.
You can also inspect the target date range with postsider_list_posts before preparing a new post. A calendar read helps reveal an existing announcement, although it is not a lock against concurrent writes.
Specify the content and time before creating a draft
Use one account and one piece of approved text for the first run. Media uploads and multiple destinations introduce additional requirements that can wait.
Give Claude the exact content and an explicit future time:
Prepare one text-only LinkedIn draft for the account I selected.
Copy:
Before scheduling your next social media post, check the destination
account and the timezone.
Target time:
November 16, 2026, at 14:00 UTC.
Show the resolved channel ID, exact copy, and UTC timestamp.
Ask for permission before creating the draft.
Do not schedule or publish anything yet.
Replace the date with a future time when you use this example. If you specify a local time, include an IANA timezone such as America/New_York and ask Claude to show the UTC conversion for review.
Avoid "tomorrow morning." The assistant would have to choose both the time and its timezone interpretation.
Set the creation action explicitly
In this server's current schema, postsider_create_post defaults to schedule. Creating a draft therefore requires an explicit type: "draft".
Drafts also require a date in the current contract.
Once you authorize draft creation, this is an illustrative argument shape:
{
"type": "draft",
"date": "2026-11-16T14:00:00Z",
"shortLink": false,
"posts": [
{
"channelId": "CHANNEL_ID_FROM_LIST_CHANNELS",
"content": "Before scheduling your next social media post, check the destination account and the timezone.",
"images": [],
"settings": {}
}
],
"tags": [],
"idempotencyKey": "linkedin-draft-2026-11-16-example-001"
}
This JSON is for the MCP tool, not the REST endpoint. Ask Claude to inspect the connected server's live tool schema before calling it.
Replace the channel placeholder with the selected account ID. Choose a unique idempotency key for the operation and preserve it for unchanged retries. Do not reuse this example key for separate posts.
The empty settings object is used for this simple LinkedIn example. It should not be copied indiscriminately to other networks, which may require additional fields or media.
Read the draft back before approving its schedule
After creation, retain the real post ID returned by the tool. Ask Claude to call postsider_get_post using that ID.
The response includes a posts array. Find the record whose id matches the returned post ID and compare its saved content, destination, and publishDate with the proposal. Confirm that it is a draft.
Inspect the platform preview in the dashboard too, especially when you later add links or media.
Do not assume that a tool with "validation" or "missing fields" in its description performs every necessary check. In this implementation, postsider_get_post_missing_fields is a narrow missing-content diagnostic. An empty result does not prove that the eventual publication will succeed.
The full MCP scheduling walkthrough explains that limitation and the complete tool sequence.
Confirm scheduling as a separate action
Once the saved draft is correct, give explicit permission to schedule that particular post.
The confirmation should identify the saved post ID and the exact account. Repeat the intended timestamp so that the action does not depend on an earlier, ambiguous message.
For example:
Schedule the saved draft with ID [actual post ID] to [exact account name]
at the confirmed UTC timestamp.
Keep the saved content unchanged. Do not modify other posts.
Before changing status, verify that the date is still in the future
and that organization publishing is not paused.
After scheduling, read the same post ID again and show the saved result.
The status-change tool is postsider_update_post_status. Its arguments look like this:
{
"postId": "POST_ID_FROM_CREATION",
"status": "schedule"
}
This operation changes status; it does not accept a replacement date. If the draft's saved date needs correction, stop and review the change in the dashboard before scheduling.
Chat confirmation is not a substitute for an organization's required approval workflow. Keep those requirements separate from the assistant's instructions.
Verify the record instead of trusting the completion message
After the status change, Claude should retrieve the same post again.
A useful completion report includes the real post ID, selected account, saved text, publishing timestamp, and state. Ask it to report any mismatch or error instead of summarizing the operation as successful.
A QUEUE state means scheduled. It does not mean the social network has already published the content.
Check again after the publication time. Account authorization or platform requirements can still cause a failure. Inspect the published URL when one is available.
Recover from a timeout without creating another post
A creation timeout does not establish whether the write succeeded.
If Claude retries the same creation operation, it should keep the original idempotency key and unchanged arguments. A new key can turn recovery into another creation request.
If the outcome remains unclear, stop and inspect the calendar. Do not ask the assistant to invent an ID or create a replacement because it cannot find a response.
This is why retaining the returned post ID matters: later checks can target a specific record rather than search by caption and hope it is the right one.
Reuse a prompt with clear write boundaries
After the first run, you can reuse this prompt with your own values:
Prepare one text-only social media post.
Account: [platform and exact account name]
Copy: [approved text]
Target time: [future date, time, and timezone]
1. List channels and resolve the intended account ID.
2. Check publishing state and inspect the target date range.
3. Inspect the live tool schemas.
4. Show the exact proposal before any write.
5. Ask permission to create one draft with type=draft and a unique,
stable idempotency key.
6. Read the created draft by its returned ID. Compare saved content,
destination, timestamp, and draft state. Check provider requirements.
7. Ask separate confirmation before scheduling that draft.
8. After confirmation, recheck publishing state and the future date,
schedule that saved post, and retrieve the same ID again.
9. Report the saved result and any errors.
Do not publish immediately, alter other posts, bypass required team
approvals, or create a duplicate to recover from a timeout.
This does not guarantee that an agent will obey every instruction. It makes the intended sequence explicit and gives you identifiable points at which to check its actions.
Start with one post you can follow from draft to publication. Expand the workflow only after you can verify what the assistant changed.
Disclosure: I am the founder of PostSider. This article was prepared with AI assistance. No authenticated social media scheduling was performed for this article; verify the live schemas and your own results before relying on the workflow.
Top comments (1)
tr.ee/dev-to