Skip to main content
Glama

Update Trigger

update_trigger

A send step's message, or a connection request's note, lives in its message_templates, so to change what a step sends, edit the template with update_node; an on_enter prompt on that step carries only extra instructions (tone, whether it may rephrase, what to write when a slot can't be filled), never the message itself.

You MUST call get_skill_guide('trigger_code') before writing code — the qualification rules, sandbox globals, tool surface, and out contract live in the skill. New or changed code runs on the trigger's next firing.

The agent's goal is injected into every turn on this agent, so it steers later runs and replies rather than merely describing them: a trigger edit that changes what the agent does leaves the goal asserting the old behavior. After this call, check the goal — when it describes what you just changed (a step you rewrote, a daily volume or cadence it states, a trigger it says is paused), bring it in line via update_agent(agent_id=..., goal=...) in the same turn. Dict with success, agent_id, trigger_id, next_run_at, and the edited trigger's full dict under trigger, plus a warning when an active trigger sits on a paused agent, since it doesn't fire until the agent is set back to active. Read the agent's other triggers via get_agent_details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoNew trigger code. Runs on the trigger's next firing.
labelNoNew label.
promptNoNew per-run instructions for this trigger. Name any outside resource a run reads (a Google Sheet, doc, file, URL) by the identifier its tool takes (the spreadsheet ID and tab, the URL), not only by its title — a later run doesn't see this chat.
statusNo'active' to resume firing, 'paused' to stop this trigger.
trigger_idYesID of the trigger to edit (from the agent's trigger list).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / prompt / description
      Previous value: -"New per-run instructions for this trigger."New value: +"New per-run instructions for this trigger. Name any outside resource a run reads (a Google Sheet, doc, file, URL) by the identifier its tool takes (the spreadsheet ID and tab, the URL), not only by its title — a later run doesn't see this chat."
  2. Changed1 schema field changed
    • changedInput schema / properties / trigger_id / description
      Previous value: -"ID of the trigger to edit (from the task's trigger list)."New value: +"ID of the trigger to edit (from the agent's trigger list)."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries the rest. It discloses that new/changed code fires on the next run, that an active trigger on a paused agent will not fire (surfaced as a warning), and that this edit can silently desync the agent's goal — real behavioral consequences beyond the annotations.

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?

Front-loaded with the core action and well-organized into summary/returns blocks, but the middle paragraph on message_templates and on_enter prompts is lengthy and partly tangential to invoking this tool. Every sentence carries information, but the density is high for a 5.

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?

No output schema exists, yet the description documents the return shape (success, agent_id, trigger_id, next_run_at, trigger, warning) and the paused-agent warning, plus the required skill-guide prerequisite and the goal-sync follow-up. Nothing an agent needs to call this correctly 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 coverage is 100%, so baseline is 3, but the description adds meaning the schema doesn't: writing code is gated on get_skill_guide('trigger_code') and status is framed as pause/resume semantics. It does not add format detail for label or trigger_id beyond the schema.

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?

States a specific verb and resource ('Edit one trigger by id, leaving its other fields untouched') and enumerates the editable surfaces (prompt, code, rename, pause/resume), which cleanly separates it from add_trigger and remove_trigger. An agent can identify the tool without opening the schema.

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?

Explicitly routes the agent: message content lives in message_templates so use update_node, code requires get_skill_guide('trigger_code') first, and goal drift should be repaired via update_agent in the same turn. It names when-not/alternatives rather than leaving them to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources