Call the activateConnectorRule MCP tool

Turn ON one saved automation rule (rule_id from getConnectorRules). LAUNCH action, two-step: the first call (no confirm_token) returns a preview of the provider, trigger and filters, the action with every parameter in full (the whole message template for a DM rule, the destination for a provider action), and the daily cap, plus a confirm_token, and turns nothing on. The token binds that exact rule state; if anything changes, the next call previews again. Relay the preview to the user; after they approve, call again with the same rule_id plus confirm_token. Once on, the rule runs on every matching event with no further confirmation: a send_linkedin_message rule DMs leads automatically, an outbound rule acts in the provider, and add_to_campaign enrolls leads in a campaign. Activation also re-checks the provider webhooks; a warning in the result means the rule is on but that re-check did not fully succeed. A campaign-managed rule is refused.

Called through the Actions bridge: the response is that tool's own result, wrapped as { data: <tool result> } under HTTP 200. Billing, daily-cap, and confirm-step outcomes are embedded INSIDE data, never remapped to an HTTP status (see the templated /api/v1/actions/{toolName} operation above for the full protocol, and x-mcp-actions for this tool's machine-readable scope/cap/confirm_behavior fields). Authentication, request-shape, and optional idempotency-protocol failures still use their documented non-200 statuses.