Draft, Approved, Scheduled, Published: Read MCP States Correctly

“Done” is an expensive word when it hides several unfinished steps. An assistant may have saved a caption, requested an approval, queued an image job, or submitted a delivery to a social provider. Each can produce a successful response at one layer while the final business outcome remains pending.

A reliable MCP content workflow preserves these distinctions. It tells you what the request did, what state the content is in, and what evidence confirms public delivery. This article explains how to read those states in Caroush without confusing a successful tool call with a published post.

Separate transport, operation, content, and delivery

There are at least four useful layers to inspect. Transport describes whether the client and server exchanged a response. The operation state describes the requested handler or job. The content state describes the saved object and its readiness. The delivery state describes what happened at a destination.

The HTTP Semantics standard defines transport status meanings. The MCP tools specification separately defines tool results and errors. A successful HTTP response can contain a tool error, and a successful tool handler can return work that continues elsewhere.

For example, a carousel request can be accepted and assigned a run identifier before its images exist. A publication request can enter a queue before a social provider confirms delivery. Those are normal asynchronous states, not reasons to invent completion.

Your content workflow should expose the layer relevant to the next decision. Editors need to know whether they can review the object; publishers need to know whether the destination accepted it.

A saved draft is an object, not a public commitment

Caroush documents create_text_post as saving a text-only post. The operation does not publish or schedule it. A successful response should identify the saved object and its actual state, not imply that followers can already see the text.

The distinction remains true when a draft is beautifully written. Editorial quality and publication state are independent. A caption can be ready for review but still require an account decision, timing, media checks, and the platform's approval flow.

A useful assistant response says where the draft was saved, provides the returned identifier or supported inspection route, and states that publication has not occurred. This lets another teammate continue without reconstructing the meaning of “ready.”

Use the AI post generator to prepare content, then inspect the saved result. If the task requested only a draft, stopping there is successful completion of that task. It is not an incomplete publication job unless publication was actually authorized.

Approved and scheduled describe different transitions

An approval may authorize an action to run or mark a content object as reviewed, depending on the tool. Neither meaning should be translated automatically into a live post. Caroush's approve_carousel operation marks a finished owned carousel as reviewed and ready to publish; it does not schedule or publish it.

Scheduling creates a future delivery commitment through a separate supported operation. The schedule has its own identity and status. The current Caroush documentation notes that a schedule identifier refers to a delivery record, not a generated post identifier.

This distinction prevents a common inspection error. If you want to know whether a scheduled destination completed, use the delivery reference and the documented read operation. Looking only at the original post can miss a pending or failed destination.

The social scheduling guide should make the intended timing and accounts explicit. At review, pair the content object with its delivery records rather than assuming one global status tells the whole story.

Read queued and running as work in progress

Caroush's results and background jobs documentation describes a structured envelope with request_id, status, and, when appropriate, operation_id, data, approval_url, or error. Queued and running indicate progress, not completed content.

When an operation reference is returned, follow it through get_job_status according to the documented schema. That read has its own successful result envelope. The operation being inspected has a separate state inside the returned data, so do not stop at the read's outer success status.

Some handlers return a native generation or automation reference. For a carousel, inspect the documented post reference through get_carousel. For a publishing delivery, inspect the returned schedule reference through get_schedule. Follow the type of resource actually returned.

A client should keep these references associated with the original task. If they disappear from the conversation, a teammate may submit replacement work simply because the assistant has no visible memory of the accepted job.

Verify publication through the delivery record

A provider can accept work for processing without immediately producing a public permalink. A connection can also succeed for one destination and fail for another. Describe each verified outcome separately when the service returns destination-level information.

For Caroush, inspect real delivery states and post_url values when available. Never manufacture a permalink by combining an account name with an assumed post identifier. A plausible URL is not evidence of publication.

Destination limits still apply. Direct TikTok publication through MCP is rejected in the documented workflow; use the reviewed composer for that route. Supporting several social networks does not establish that every content type or operation behaves identically on each one.

This is especially important for a cross-posting workflow. The creative idea can be shared across destinations while the operational result differs. A summary saying “published everywhere” should be supported by the actual requested destinations and their recorded outcomes.

Treat failed and unknown outcomes differently

A failed request provides evidence of a problem, but you still need to inspect where it failed. Validation may have stopped the action before execution. A handler may have failed after beginning native work. A provider can reject one destination after another succeeds.

An unknown outcome is even more explicit: the system cannot confirm the final effect. Caroush documents outcome_unknown as a state requiring reconciliation of existing records before a new request. It is not permission to issue a fresh mutation and hope for a cleaner response.

Preserve the request identity and inspect the content or delivery records. If you need operator help, provide the request reference and redacted error information. Do not copy tokens or the entire private campaign into a support message.

For editors, write an unresolved item in the handoff: which object is affected, which state is known, and who will verify it. Silence about uncertainty invites another teammate to repeat the action and create a duplicate.

Use a status vocabulary the team can act on

Choose short statements that name both the object and the next step. “Draft saved; review required” tells an editor what to do. “Publication approved; delivery queued” tells a publisher to wait and inspect the delivery. “Destination failed; other destinations verified” prevents a broad retry from repeating completed work.

Avoid turning every intermediate state into an alarming error. Queued work can be normal. The question is whether it progresses within the documented operational expectations and whether the responsible person knows how to follow it.

Likewise, avoid reporting only technical codes to a nontechnical reviewer. Preserve the exact state in the record, then explain its implication in ordinary language. The explanation should be faithful to the returned evidence, not a more reassuring substitute.

A small team can use these distinctions without building a complex dashboard. A task record containing the content identifier, operation reference, delivery references, verified state, and owner is often enough to keep the handoff clear.

Rehearse the confusing cases before a launch

Use controlled examples to check how the assistant reports a saved draft, an approval requirement, a queued job, and a failed delivery. The test should verify language as well as backend behavior. If the assistant calls every accepted request “published,” correct that interpretation before expanding its role.

Also rehearse a lost response. The proper recovery is to inspect the recorded state using the existing identifiers, not create another action with a new key automatically. This is particularly useful before a time-sensitive campaign when people may be tempted to retry quickly.

A trustworthy status report does not promise certainty that the service has not supplied. It makes the next decision easier by showing exactly what is known. That discipline keeps technical success, editorial readiness, and public delivery aligned without pretending they are the same event.