Skip to main content
Glama

Publish draft

publish_draft
Destructive

Publishes the article of one content calendar topic to one publishing destination of the site, from the destinations section of get_project (request it with sections ['destinations']). mode draft (the default) sends the article as a draft; mode publish makes it live. Draft mode runs on the first call without confirm only on a destination that finds posts only by a stored id (GoHighLevel) and has no publication of the article yet, but it still writes to the destination: ask the user before you call it. Publish mode, a draft to a destination that can find posts by slug (WordPress, Framer, Shopify, Webflow, and Contentful when it has no stored id; a post with the same slug, also one Keytomic did not make, can be set back to a draft), a draft to a destination that already has a publication of the article, in any mode and also a failed or unfinished one (when its post is live, the destination can turn it back into a draft), a draft of a content refresh, and each call to a webhook (draftMode receiver_decides) first return the plan and sends nothing (status plan): the destination, the mode, the expected URL (or that the URL is known after the publish), whether it adds a new post or updates the post of an earlier publish, and whether it uses a daily publish, with the publishes left today. Show the plan to the user, and call again with confirm: true only after the user agrees; that call reads the plan again and publishes. A destination whose draftMode is not_supported takes only mode publish (draft_mode_not_supported). The first send of the article to a destination in a mode uses 1 daily publish; a repeat after a succeeded publish uses none. Returns the status (sent_as_draft, published, or sent_to_receiver for a webhook, whose receiver decides the mode), the public URL (null in draft mode, because a draft has no public URL), whether the publish updated an earlier post and whether it used a daily publish. If a call that publishes times out or answers internal_error, call get_publication_status before you call this tool again: the publish can still finish on the server. When an earlier publish of the article to the same destination in the same mode succeeded, a repeat updates the same post and uses no new daily publish, but a webhook gets a new event on each call. When none succeeded and none is still pending, a repeat uses a new daily publish, and it can add a second post when a failed publish reached the destination. When the destination does not confirm the publish, the call answers publish_failed with a fixUrl, where the owner checks the destination: the article may or may not have reached it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>",
      "topicId": "<topicId>",
      "destinationId": "<destinationId>"
    },
    "name": "publish_draft"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNodraft (default) sends the article as a draft, which the destination keeps unpublished when its draftMode is kept_as_draft. A draft runs on the first call only on a destination that finds posts only by a stored id (GoHighLevel) and has no publication of the article yet. A draft to a destination that can find posts by slug (WordPress, Framer, Shopify, Webflow, and Contentful when it has no stored id), to a destination that already has a publication of the article (in any mode, also a failed or unfinished one), and a draft of a content refresh return a plan first, because the destination can turn a live post back into a draft. publish makes the article live.draft
confirmNotrue starts the publish. Send it only after the user saw the plan this tool returns without confirm and agreed. Without it, the tool returns the plan and starts nothing.
topicIdYesTopic whose article to publish, from list_calendar_topics.
projectIdYesSite to act on, from list_sites.
destinationIdYesDestination to publish to, from the destinations section of get_project (request it with sections ["destinations"]).

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations it discloses that calls actually write to the destination even in draft mode, that the first send in a mode consumes a daily publish quota, that repeats update the same post while webhooks fire a new event each time, and that failure yields publish_failed with a fixUrl. This is the kind of quota, idempotency, and partial-failure context that destructiveHint and idempotentHint alone cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the remainder is a wall of run-on sentences with tangled clauses (the 'Publish mode, a draft to a destination that can find posts by slug... first return the plan' sentence is nearly unparseable). It also repeats mode/confirm semantics already present in the schema, adding length without new information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world write tool with no output schema, it covers return values (status, public URL, updated-post flag, daily-publish flag), quota accounting, retry behavior, and partial-failure outcomes. An agent has enough to call it correctly and to recover safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema's mode and confirm descriptions already carry the plan/confirm semantics and the not_supported rule. The description largely restates that same material rather than adding new parameter-level meaning, so it sits at the baseline for fully documented schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb, resource, and scope: publishes the article of one calendar topic to one destination of the site, and names where destination IDs come from (get_project with sections ['destinations']). An agent can distinguish this from get_draft, update_draft, and get_publication_status from the opening line alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It spells out the decision tree explicitly: draft is the default, draft on a by-slug destination or an existing publication returns a plan first, publish mode also returns a plan first, and a not_supported draftMode only accepts publish. It also states the confirm workflow and the recovery path (call get_publication_status after a timeout) rather than leaving alternatives to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources