Skip to main content

Communications MCP: manage workspaces and webhooks

  • 9 new tools on the communications server. Two are read-only (comms_get_workspace_settings, comms_list_webhooks). Four need the new permission manage:comms.workspace (create a workspace, rename it, change its settings, add a sending identity) and three need manage:comms.webhooks (change, test, delete a webhook). Both are asked once, the first time they are needed, each on its own line; your first approval is unchanged.
  • Every change is a dry run first. The assistant shows you the before and after and needs your clear yes. Changing click consent comes with a plain explanation of what it does.
  • What an assistant cannot do. It cannot make a workspace the default, delete a workspace, replace or remove sending identities, create a webhook (its signing secret is shown once, to a person) or ever see a secret.
  • Webhook addresses are protected. Campaign events carry recipient email addresses, so an address change needs a confirmed preview, emails you first, and is refused if the email cannot be sent. Addresses are shown to the assistant as the host only.
  • API: POST /comm-api/api/workspaces/{id}/motor-blocks/add adds a verified domain's sending identity to a workspace without replacing anything. For assistants only: a new workspace email, no duplicate workspace names, a limit on webhook test events, and creating a webhook is refused. Nothing changes for the dashboard or other integrations.

Documentation changed