Schedule LinkedIn Posts Through MCP: Account, Approval and Timezone

A LinkedIn post can have a proposed time and still be a draft. In FeedSquad, creating the item and approving it are separate operations. Check both the destination and the stored state before relying on a launch date.

This guide describes FeedSquad's exposed tool contract and a procedure you can run. It does not claim that a particular account or deployed connector has passed a live publishing test. Start with the LinkedIn MCP overview if you are choosing a service.

Choose the account before creating the draft

Ask the assistant to list connected publishing accounts. FeedSquad's list_accounts is a read operation. For a company destination, use the company-page identifier returned by discovery rather than asking the model to infer it from a company name.

A LinkedIn member profile and a company page are different destinations. LinkedIn's member sharing documentation describes member authorization; that access does not establish organization publishing access. Confirm the destination available through your connected service.

A useful first prompt is:

List my connected LinkedIn destinations. Do not create a post. Show the account or page name and identifier so I can choose.

Stop if the intended destination is missing. Rewriting the post will not repair account access.

Save the exact content as a draft

Provide approved notes and say which destination to use. Specify that this is a draft and ask for its identifier. In FeedSquad, create_post saves a draft even when it carries a proposed publication time. Its auto_slot option can propose a slot; use auto_slot: false when you want a draft without an automatic proposal.

Ask the assistant to read the saved item back with get_post. Check the actual text, attached media and destination. The assistant's paraphrase of your request is not the same thing as checking what was stored.

Make the timezone unambiguous

Record the local date and time, an IANA timezone such as Europe/Helsinki, and the resolved timestamp with its offset. Use the offset that applies on the intended date. A recurring instruction such as “nine every Monday” needs a timezone policy; it should not be implemented as a permanently fixed UTC offset across daylight-saving changes.

For a one-off post, ask:

Show this saved draft and the intended publication time in Europe/Helsinki, including the UTC offset for that date. Do not approve it yet.

If the proposed slot differs from your request, resolve that difference before approval.

Approve only after the review

FeedSquad's confirm_post accepts an approval action and can commit a scheduled date. Approval can therefore enable later public publication. Do not use it as a harmless test that the assistant can see the draft.

After intentionally approving, inspect the stored calendar item through a second surface. A dateless approved item and a scheduled item are different outcomes. For an immediate send, publish_post operates on an already approved item; it is not needed just to inspect a schedule.

Resolve uncertainty before creating another item

If creation times out, look for the saved item first. FeedSquad supports an idempotency key on create_post; a retry intended to recover the same operation must reuse the key. A fresh key describes another operation and can create another draft.

If a public action is uncertain, check the service record and LinkedIn destination before retrying. Record what is known and leave the outcome uncertain until it can be reconciled. Use the scheduling acceptance test to examine edits, cancellations and failures separately.

For the assistant connection, follow the Claude LinkedIn workflow or the ChatGPT LinkedIn workflow. Keep platform credentials inside the service's authorization flow.