Boomerang

Create workflow trigger

createWorkflowTrigger

Create a workflow trigger for a recipient. Two kinds: (1) SCHEDULED — Temporal cron or one_time_fire_at in absolute UTC (default); (2) WEBHOOK — Composio inbound CRM event, no cron. Always set name, ≤100-char description (never copy the prompt), prompt, channels, scope (USER|WORKSPACE), and draft metadata.preview per channel. For WORKSPACE also set activation_mode: WORKSPACE_MANDATORY (runs for everyone in the audience; no per-user opt-in) or WORKSPACE_OPT_IN (shared template teammates enable individually). For WEBHOOK also set trigger_kind=WEBHOOK and metadata.supported_events (or pass template_id from an admin WEBHOOK trigger_template so the backend inherits kind + supported_events). For SCHEDULED provide exactly one of cron or one_time_fire_at. When creating from an admin template seed, copy template_id, trigger_kind, and metadata.supported_events verbatim from the seed JSON — never invent event slugs.

Use when: Use for a new reminder/schedule OR a new event-driven HubSpot/Salesforce notification, OR to opt-in/activate an existing WORKSPACE_OPT_IN catalog template for the requesting user (pass catalog_id from create/list — that creates a USER activation; do not use updateWorkflowTrigger for first-time opt-in). Ask scope=USER vs WORKSPACE before free-form creates. If WORKSPACE, ask whether it must run for everyone with no opt-in (activation_mode=WORKSPACE_MANDATORY, workspace admin) or be a template teammates enable (WORKSPACE_OPT_IN). If the conversation seed includes a workflow_trigger_template_context JSON block, this is a template create: pass template_id + trigger_kind + metadata from that block, put template instructions into prompt (customize with the user), omit cron for WEBHOOK, and do not invent supported_events. If there is no seed but the user wants an admin template, call listTriggerTemplates first and copy id → template_id. Call list_workflow_triggers first to avoid duplicates. Always draft metadata.preview for the channel(s) in use.

workspace_id / user_id are injected from request headers.

Input Schema

Name	Required	Description	Default
`cron`	No
`name`	No
`plan`	No
`scope`	No
`prompt`	No
`channels`	No
`metadata`	No
`catalog_id`	No
`description`	No
`template_id`	No
`trigger_kind`	No
`audience_type`	No
`activation_mode`	No
`agent_thread_id`	No
`audience_filter`	No
`channel_metadata`	No
`one_time_fire_at`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 12, 2026

removedInput schema / properties / _triggered_by

Removed value: -{
-  "default": "",
-  "description": "REQUIRED. Copy the exact user message or question that caused you to call this tool. Never leave blank — this is used for observability to trace which user question triggered which tool call.",
-  "type": "string"
-}

First observedOct 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already signal a non-idempotent, non-destructive write, but the description adds substantial behavioral context beyond them: the WORKSPACE_MANDATORY vs WORKSPACE_OPT_IN activation semantics (runs for everyone, no per-user opt-in), the requirement to copy template_id/trigger_kind/metadata verbatim and never invent event slugs, and the note that workspace_id/user_id are injected from request headers.

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

Conciseness4/5

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

The purpose and the two kinds are front-loaded, and the 'Use when:' block is clearly delimited. It is long and occasionally repetitive ('draft metadata.preview' appears twice, template instructions are restated), but for a 17-param tool with two modes and several creation flows most sentences carry necessary conditional logic.

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?

Given the tool's complexity (17 params, two trigger kinds, template inheritance and opt-in flows), the description is complete: an output schema exists so return values needn't be covered, and the mutation/safety profile is already carried by annotations. Nothing an agent needs to invoke it correctly across the enumerated paths is missing.

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

Parameters4/5

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

Schema description coverage is 0%, so the description carries the full burden across 17 params. It explains the meaning of most of them (cron vs one_time_fire_at mutual exclusivity, scope USER|WORKSPACE, activation_mode values, trigger_kind, template_id, catalog_id creating a USER activation, metadata.preview/supported_events, description length cap and 'never copy the prompt'). A few params (plan, audience_type, audience_filter, agent_thread_id, channel_metadata) go unmentioned, hence not a 5.

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?

Opens with a specific verb+resource ('Create a workflow trigger for a recipient') and immediately partitions the tool into its two operating kinds (SCHEDULED vs WEBHOOK), which lets an agent distinguish it from updateWorkflowTrigger and the list tools. The scope is precise enough that no schema inspection is needed to know what the tool produces.

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?

Has an explicit 'Use when:' block covering three concrete scenarios (new reminder/schedule, event-driven notification, opt-in activation of a WORKSPACE_OPT_IN template). Names alternatives and their boundaries: it says to call listTriggerTemplates first, list_workflow_triggers first to avoid duplicates, and explicitly warns 'do not use updateWorkflowTrigger for first-time opt-in'.

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

All Boomerang tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?