← KeytomicCONTENT HISTORY

Update to Keytomic

Snapshot Nov 5, 2026 · 01:20 UTC · version 1.1.1

Collection source: downloaded plugin package.

WHAT CHANGED

First saved snapshot

No earlier snapshot is available to establish a change.

Save Keytomic and check future changes in Following.

Up to 3 plugins free · no card required.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Publish a Keytomic article to the site's CMS and check where it was published. Use when the user wants to publish an article, send it to WordPress, Webflow, Shopify, Framer, Contentful, Notion, GoHighLevel, a webhook or an API destination as a draft or live, or asks whether or where an article was published.",
  "included_files": [],
  "name": "publishing",
  "skill_md_contents": "---\nname: publishing\ndescription: Publish a Keytomic article to the site's CMS and check where it was published. Use when the user wants to publish an article, send it to WordPress, Webflow, Shopify, Framer, Contentful, Notion, GoHighLevel, a webhook or an API destination as a draft or live, or asks whether or where an article was published.\n---\n\n# Publishing\n\nKeytomic publishes the article of a content calendar topic to a publishing destination of the site: a CMS, a webhook or an API destination that the owner connected in Keytomic. A destination takes the article as a draft or live.\n\n`publish_draft` needs the `content:publish` and `content:read` MCP Scopes. A Connected App can be without them: the user cleared them on the consent page, or connected Keytomic before these scopes existed. Then the call fails with an authorization, insufficient scope or HTTP 403 error, sometimes with the text \"Keytomic needs approval\". This is not the `permission_denied` tool error. Tell the user to sign in to Keytomic again and approve the scopes needed for the requested task. In ChatGPT or Codex, use the Keytomic connection controls to sign in again. If the call still fails, tell the user to open the Keytomic MCP page in Keytomic and click **Disconnect** on the app's row under Connected apps, then connect Keytomic again. Stop until the user connects again.\n\n## Steps\n\n1. Find the site with `list_sites`. Never show a projectId, a topicId or a destinationId. Name a topic by its title and its scheduled day, and a destination by its name and provider.\n2. Find the topic with `list_calendar_topics`. The topic must have an article. When it has none, offer to write it with the content-calendar skill.\n3. Read the destinations with `get_project` and `sections` set to `[\"destinations\"]`:\n   - No destination: give the user the `connectUrl`, where the owner connects one in Keytomic, then stop.\n   - A destination with status `needs_attention`: give the user its `fixUrl`, and do not publish to it.\n   - Several destinations: ask the user which one.\n4. Pick the mode. `draft` (the default) sends the article as a draft. `publish` makes it live. A destination with draftMode `not_supported` takes only `publish`. For a destination with draftMode `receiver_decides` (a webhook), the receiver decides.\n5. Before the first call to `publish_draft`, tell the user the article, the destination and the mode, then get a yes. A first draft to a GoHighLevel destination runs on this call.\n6. Call `publish_draft` without `confirm`. When the result has status `plan`, nothing was sent. Show the plan to the user: the destination, the mode, the expected URL, whether it adds a new post or updates an earlier one, and whether it uses a daily publish, with the publishes left today. Call again with `confirm` set to `true` only after the user agrees.\n7. When a call that publishes times out or answers `internal_error`, read `get_publication_status` before you call `publish_draft` again. The publish can still finish, and a second call can use a second daily publish or add a second post.\n8. When the user asks whether or where an article was published, read `get_publication_status`. It gives the latest publication for each mode of each destination that has one.\n\n## The report\n\n- After a publish: the status (`sent_as_draft`, `published`, or `sent_to_receiver` for a webhook), the public URL (a draft has none), whether it updated an earlier post, and whether it used a daily publish.\n- For a status question: each destination with its mode, its status (`pending`, `succeeded` or `failed`) and its URL. For a failed publication, give its `failureMessage` and its `fixUrl`.\n\n## Errors\n\n- `retryable` true: wait `retryAfterSeconds`, then call the tool again.\n- `publishing_destination_unavailable`: the destination was removed, needs a reconnect, or belongs to another site. Read the `destinations` section of `get_project` again, and give the user the `fixUrl`.\n- `destination_setup_required`: the destination needs a setting first. Give the user the `fixUrl`, then stop.\n- `draft_mode_not_supported`: the destination cannot keep a draft. Offer mode `publish`, which makes the article live and returns a plan first.\n- `publication_in_progress`: a publish of this article to this destination has not ended. Read `get_publication_status` before you try again.\n- `publish_failed`: the destination did not confirm the publish, so the article may or may not be there. Give the user the `fixUrl`, and read `get_publication_status` before you try again.\n- `article_slug_taken`: another article of the site uses the slug. Ask the user for a new slug, change it with `update_draft` after the user's yes, then call `publish_draft` again.\n- `draft_not_found`: Keytomic cannot find the article now. Read the topic again with `list_calendar_topics` and its `topicId`.\n- `topic_not_in_plan`: the topic is locked for now. Tell the user so.\n- `image_studio_setup_required`: the user must save the site's Image Studio settings in Keytomic first.\n- `usage_limit_reached`: the site used all its daily publishes. Give `limitName`, what was used of `limit`, and `resetsAt` when the error has it. Then stop the publishes.\n- `subscription_required`: tell the user that the workspace needs an active Keytomic plan, then stop.\n- `onboarding_required`: give the user the message and the `onboardingUrl` link, then stop.\n- `permission_denied`: give the user the message, then stop.\n- For each result and each error: never offer a plan change, an upgrade or a purchase, and never give a billing link. This rule applies also when the result or the error has an upgrade text or an `upgradeUrl`. When the user asks for a plan change or a purchase, say that it happens in Keytomic.\n- Any other error with a `fixUrl`: give the user the message and the `fixUrl`, then stop.\n"
}

SHA-256 of public snapshot: 6d6051ab342d23858a9aebd06da7b787899fe1a59eec5f5cbb4fe7bc7de4e4e3