Write tools & guardrails

​

Which connectors have write tools

​

The three guardrail rules

1. New objects are created paused / draft. A new object is never live: Meta ads are created PAUSED; new LinkedIn, Shopify and HubSpot objects are DRAFT; an e-conomic draft invoice is a draft; a new HubSpot marketing email can never send. It spends nothing and does nothing until you explicitly take it live.
2. Money / destructive / public actions require confirm: true. Anything that spends money (setting a campaign ACTIVE), changes a budget or bid, changes a price or inventory, publishes to a live website, sends a marketing email, or archives / deletes an object requires an explicit confirm: true argument.
3. Without confirm, you get a dry-run. A guarded tool called without confirm: true returns a preview object describing exactly what would happen and calls no upstream API. Nothing changes until you re-issue the call with confirm: true.

​

Default status: DRAFT / PAUSED

• Meta Ads: create_campaign, create_ad_set and create_ad create the object with status PAUSED. It exists, but does not deliver and spends nothing.
• LinkedIn Ads: the create tools produce the object in DRAFT status.
• Shopify: create_product creates the product as DRAFT (not published to any sales channel).
• HubSpot CMS: new pages / blog posts are forced to DRAFT on create; HubDB row writes land in the table’s draft.
• HubSpot Marketing Email: new emails are forced to state DRAFT and can never be sent or scheduled by create/update.
• e-conomic: create_draft_invoice creates a draft invoice; every write tool is preview-first (see below).

​

The confirm argument

• spend money: set a campaign’s status to ACTIVE (go live);
• change a budget or bid: e.g. update_budget on Meta Ads;
• change a price or inventory: e.g. on Shopify;
• publish to a live surface: a live website (HubSpot CMS), a marketing email (publish_email), or public organic-social content (LinkedIn);
• archive or delete an object.

​

The dry-run preview shape

{
  "preview": true,
  "action": "update_status",
  "connector": "meta-ads",
  "wouldChange": {
    "objectType": "campaign",
    "objectId": "1203456789012345",
    "from": { "status": "PAUSED" },
    "to": { "status": "ACTIVE" }
  },
  "requiresConfirm": true,
  "message": "Dry-run only. Re-issue this call with confirm: true to apply."
}

{
  "name": "update_status",
  "arguments": {
    "campaignId": "1203456789012345",
    "status": "ACTIVE",
    "confirm": true
  }
}

​

e-conomic write tools

• All four are preview-first. The first call never hits the e-conomic API; it returns a dry-run of the exact request (method, path, body). The change is applied only on a second call with confirm: true. requiresConfirm() is always true.
• No ledger posting and no deletion. The connector deliberately cannot post a draft to the ledger and has no DELETE method at all. A draft invoice is a real artifact the bookkeeper sees, but it does not affect the accounts until it is posted manually in e-conomic.
• update_customer is a full-record PUT (e-conomic has no PATCH): it reads the current customer, merges only the fields you supply, and strips server-owned fields. duplicate_invoice reads the source, strips id / amount / posting fields and creates a fresh draft.

​

Shopify write tools

• Orders, draft orders, customers and discounts are read-only, and graphql_query rejects mutations.
• New products are created DRAFT. Going live (publishing or status ACTIVE), archiving, changing a price, changing inventory or deleting requires confirm: true; the first call without confirm is a dry-run preview.
• Mutation responses are checked for userErrors, so a rejected write never looks like a success.

​

HubSpot CMS write tools

• Draft writes run freely: create_page_draft, update_page_draft, create_blog_post_draft, update_blog_post_draft, upsert_hubdb_row_draft. A draft never touches the live website.
• Actions that hit the live site or discard work require confirm: true: publish_page, publish_blog_post, publish_hubdb_table, reset_hubdb_draft. The first call without confirm returns a structured preview and calls no HubSpot API.
• HubDB row writes land in the table’s draft and stay invisible on live pages until publish_hubdb_table runs. No hard deletes in v1.

​

HubSpot Marketing Email write tools

• Free, reversible draft writes (4): create_email, update_email_draft, clone_email, create_email_ab_variation. They only work in draft and can never send; new emails are forced to state DRAFT, and create/update never accept state, publishDate or sendOnPublish.
• Confirm-gated writes (7): update_email (mutates the live version), publish_email (sends a real email, highest risk), unpublish_email, delete_email, reset_email_draft, restore_email_revision, restore_email_revision_to_draft. Without confirm: true they return a dry-run preview; the second call with confirm: true executes. Sending to real recipients is possible only via the explicitly confirmed publish_email.

​

Meta Ads write tools

​

LinkedIn Ads write tools

• Ad-management writes follow the standard model: new objects are created in DRAFT; activation, budget/bid changes, and archive/delete require confirm: true, otherwise a dry-run preview is returned. (Measurement writes such as creating/updating a conversion rule apply without confirm.)
• Organic-social writes publish public content, so they are confirm-gated by the same rules.

​

Why read-only connectors are different