Sliq

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: wording the user could approve without changing a word, since the queue rejects a leftover {slot}), never the message itself. A [[double-bracketed]] part of a template is the user's to fill in while approving, so the run leaves it as written.

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

Name	Required	Description
`code`	No	New trigger code. Runs on the trigger's next firing.
`label`	No	New label.
`prompt`	No	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.
`status`	No	'active' to resume firing, 'paused' to stop this trigger.
`trigger_id`	Yes	ID of the trigger to edit (from the agent's trigger list).
`on_behalf_of`	No	An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 19, 2026

addedInput schema / properties / on_behalf_of

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
+}

changedInput schema / properties / status / anyOf

Previous value: -[
-  {
-    "enum": [
-      "active",
-      "paused"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "active",
+      "paused"
+    ],
+    "title": "Status",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

Changed1 schema field changedSep 25, 2026

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."

Changed1 schema field changedSep 23, 2026

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)."

First observedSep 15, 2026

TDQS

A4.6/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. The description adds substantial context beyond that: a new prompt/code replaces the existing one, code runs on the next firing, paused triggers' fields are not in context, newly written code carries an out contract and sandbox rules, and an active trigger on a paused agent yields a warning. This is rich behavioral disclosure.

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 action is front-loaded in the summary tag and the structure is clean (summary/returns). It is verbose, though, and the long message_templates paragraph is largely about an adjacent tool's behavior, which weighs slightly against strict conciseness.

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?

Although there is no output schema, the description embeds a returns section covering success, agent_id, trigger_id, next_run_at, the trigger dict, and the paused-agent warning. Combined with the guidance to read sibling triggers via get_agent_details, the agent has everything needed to call and interpret the result.

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 description coverage is 100%, so the baseline is 3. The description reinforces replacement semantics ('A new prompt or code replaces the current one') and the pause/resume meaning of status, but adds little beyond what the schema already documents for each parameter.

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?

The first sentence states a specific verb and resource with scope: 'Edit one trigger by id, leaving its other fields untouched.' It immediately separates this tool from add_trigger/remove_trigger and, via the message_templates discussion, from update_node. An agent knows what this does 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?

Explicit when-to-use cases are enumerated (refine prompt, attach/replace code, rename, pause/resume) and alternatives are named: use update_node to change what a send step sends, and get_skill_guide before writing code. It also gives prerequisites (read paused triggers via get_agent_details) and follow-ups (update_agent for the goal).

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

All Sliq 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?