Boomerang

Update workflow trigger

updateWorkflowTrigger

DestructiveIdempotent

Update an existing workflow trigger activation: edit name/description/prompt/plan/schedule/channels, or change lifecycle status (ACTIVE/PAUSED/CANCELLED). trigger_id is required and must be the activation config UUID from list_workflow_triggers.id or create_workflow_trigger.trigger_id — never catalog_id. Only set fields that changed. SCHEDULED: any new cron / one_time_fire_at must be absolute UTC. WEBHOOK triggers have no cron — do not add cron when list shows trigger_kind=WEBHOOK; change prompt/channels/status only (supported_events are fixed on the catalog from create/template). Prefer list_workflow_triggers first to load id (as trigger_id) and trigger_kind.

Use when: Use to edit an existing live activation, or pause/resume/cancel it. trigger_id = list_workflow_triggers.id (the config UUID). Do NOT pass catalog_id as trigger_id. First-time opt-in of a WORKSPACE_OPT_IN template uses create_workflow_trigger with catalog_id instead. Call list_workflow_triggers first if you don't have the config id. For WEBHOOK rows, never invent a schedule.

Behavior: idempotent, destructive

workspace_id / user_id are injected from request headers.

Also returns pagination info (name, description, enabled, last_run_at, last_run_status, status, prompt, source, id, allowed_channels, selected_channels, cron, recurring, adhoc, config_status, plan, channel_metadata, agent_thread_id, editable, metadata, test_mode, test_cron, test_lead_minutes, test_recipients, scope, created_by, created_by_user_name, owner_user_id, owner_user_name, activation_mode, principal_type, catalog_id, audience_type, is_template, audience_filter, trigger_kind).

Input Schema

Name	Required	Description	Default
`cron`	No
`name`	No
`plan`	No
`prompt`	No
`status`	No
`channels`	No
`trigger_id`	No
`description`	No
`trigger_kind`	No
`agent_thread_id`	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.2/5.0

Behavior4/5

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

Annotations already declare idempotent/destructive, and the description repeats that ('Behavior: idempotent, destructive'), which is redundant. However it adds genuine beyond-annotation context: id must be the config UUID not catalog_id, cron/one_time_fire_at must be absolute UTC, WEBHOOK rows have no cron, supported_events are fixed on the catalog, and workspace_id/user_id are header-injected.

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

Conciseness3/5

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

The core guidance is reasonably front-loaded, but the catalog_id warning is repeated three times ('never catalog_id', 'Do NOT pass catalog_id as trigger_id', 'trigger_id = list_workflow_triggers.id') and the trailing enumeration of ~35 return fields is redundant given a native output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-param lifecycle mutation this covers the hard parts well: id provenance, scheduling constraints, kind-specific rules, and status transitions. The redundant return-field list is unnecessary since an output schema already defines them, but overall an agent has enough to call it correctly.

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

Parameters3/5

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

Schema coverage is 0% across 12 params, so the description must carry the load. It does clarify the critical ones (trigger_id must be the config UUID, cron vs one_time_fire_at UTC, WEBHOOK has no cron, channels), but leaves plan, description, agent_thread_id, channel_metadata, and the object-typed name/description shapes unexplained, so compensation is only partial.

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?

Specific verb+resource ('Update an existing workflow trigger activation') with the exact editable fields (name/description/prompt/plan/schedule/channels) and lifecycle transitions (ACTIVE/PAUSED/CANCELLED) named. It explicitly distinguishes itself from create_workflow_trigger and list_workflow_triggers, so an agent can route without opening schemas.

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?

A dedicated 'Use when' block states the trigger condition (edit an existing live activation, or pause/resume/cancel), and it names the alternative for a related case: first-time opt-in uses create_workflow_trigger with catalog_id. It also mandates calling list_workflow_triggers first, giving concrete when/when-not/alternative guidance.

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?