Schedule Finished Social Posts Through MCP

Select a finished piece by identity

Start by retrieving the intended piece with get_content_piece. Check its current status and media, particularly if someone recently edited it. An old video URL may still be associated with a piece while a replacement render is processing; the publish request must use the ready version.

Ask the assistant to repeat the piece's script or title in the proposed schedule. A stable identifier is essential for the tool, while recognizable content helps the human catch an accidental selection. Both should refer to the same output.

If you are publishing a clip from an existing recording, the clipping workflow has a separate publish_clip tool. Use the identifier returned for that clip rather than treating it as a content-piece identifier. The cross-posting guide covers the creative decisions involved in sharing a video across destinations.

Resolve the exact connected accounts

Use list_publish_destinations for the selected brand and read the returned accounts. Match both platform and account identity. A team with several brands can have similar names across destinations; a platform label alone is not enough.

Prolifik's documented destinations include Instagram, TikTok, YouTube and X. The tool can only work with connections available to the authenticated account and brand. Adding or reconnecting a social account stays in the dashboard.

For the workshop example, suppose the intended destination is the brand's Instagram account. The assistant should resolve that particular account and use its returned connection identifier. It should not add every available account because the user asked for “social media.”

Also match the media to the destination. A returned carousel image set is different from a timed video. Check the eligible publishing path before assuming that one output can be delivered in the same form everywhere.

Turn the requested time into an unambiguous timestamp

Use a date, clock time and named time zone in the human request. The tool payload uses a timestamp with an offset. For example, November 2, 2026 at 09:00 in Europe/Vilnius corresponds to 2026-11-02T09:00:00+02:00. This is a worked example, not a universal offset for Vilnius throughout the year.

Have the assistant show the local time and resolved timestamp together. That catches a wrong day, an unintended zone or a daylight-saving assumption before the schedule is created.

The caption must use real event information when you apply the example. Do not invent a booking link or a ticket deadline to make the schedule look complete.

Make one explicit scheduling request

A clear request is:

Schedule the reviewed workshop piece to the selected Instagram connection on November 2, 2026 at 09:00 Europe/Vilnius. Use the approved caption exactly. Show the selected piece, account and resolved timestamp before submitting. After submission, return the publication identifier and the stored scheduled time.

For rendered content, publish_content takes the brand identifier, piece identifier, connection identifiers and an idempotency key. Supplying scheduledAt schedules the post; omitting it means publishing now. That omission changes the action, so it deserves an explicit check.

The assistant should respect the client's confirmation settings for publishing. A request to review a schedule is different from a request to create it. The Prolifik MCP guide explains the tools and which actions affect external accounts.

Confirm the record without calling it posted

After the write succeeds, retrieve the publication record with get_content_publish or the relevant listing tool. Confirm that the content and destination match the request and that the scheduled time was stored correctly.

“Scheduled” means the service has accepted future work. “Posted” requires a later provider result. At the intended time, inspect the record again and use the returned status or destination link as evidence of publication. If the record fails, retain the platform's reason instead of reporting that the post went out.

Avoid blindly repeating a publishing call after a connection interruption. Recover the existing publication or reuse the same idempotency key for the same request. A new key should represent a new intended action, not uncertainty about the previous response.

Handle a changed caption or failed destination

Prolifik provides tools to update a not-yet-posted content caption or cancel a pending publication. Use the relevant operation and then retrieve the record again. Do not assume that editing the original chat message changed a schedule already stored in the service.

When a destination fails, inspect its status before retrying. A disconnected account needs attention in the dashboard. Another successful destination does not prove that this one published, and retrying every destination can create unnecessary duplication.

For recurring planning and calendar work beyond a single explicit post, use the product's scheduler. An MCP scheduling call handles an identified piece and destination; it does not itself create an indefinite content programme. Keep the confirmation for this post tied to its actual publication record.